Live data from Hacker News

Virtual Keyboard Developer Leaked 31M Client Records

mackeepersecurity.com

71–77 of 77 posts

Re: Virtual Keyboard Developer Leaked 31M Client Records

#72

These guys write Mac malware for a living and use nefarious tactics to fool users into installing it, while making it really hard to uninstall. I've seen it on the Mac of many less technically inclined people. Things like: “your Mac has been infected, click here” while the user is downloading some torrent or watching porn. Faking the system's dialog boxes, using chatbots “is your Mac slow?”, etc. I'm amazed Apple ha…

One day we will find out what Windows 10 sends home too. Is it "only" ad tracking data like ads, or what several security advisors suggest it acts like a key logger?

The problem I see, a smartphone is me thing. A PC of your lawyer, your doctors is a hell another dimension. And unfortunately it's a group of jobs like these that run on Windows Professional often without an admin or AD server. Guess what, it's a wet dream for them.

Re: Virtual Keyboard Developer Leaked 31M Client Records

#73
post #5

>When researchers installed Ai.Type they were shocked to discover that users must allow “Full Access” to all of their data stored on the testng iPhone, including all keyboard data past and present. It raises the question of why would a keyboard and emoji application need to gather the entire data of the user’s phone or tablet? I have a suspicion that due to how cheap bulk storage is these days, that companies collect…

I have a hard time believing this company is GDPR ready.

Re: Virtual Keyboard Developer Leaked 31M Client Records

#74
post #66

2-step authentication is a must these days, when they can leak keyboard typing, your password becomes useless.

But they are also leaking your phone number next to your keystrokes, so 2FA based on text messages is also broken. (To attack/reroute SS7, the subscriber number is all you need – which isn't much of a secret, but mostly public data, anyway.)

Re: Virtual Keyboard Developer Leaked 31M Client Records

#75
post #8

Earlier quoted context omitted.

"all keyboard data". for a keyboard app? seems right on point. why wouldn't it want it?

With the basic permissions the keyboard can only type, it has no capability to send the keystrokes out to the internet or store them where they could be sent. If you don't trust the keyboard developer to not be an idiot with your keystrokes, better to not give that access.

why would you ever install a keyboard from someone you don't trust?

Re: Virtual Keyboard Developer Leaked 31M Client Records

#76
post #44
post #43

This little comment about Mongo really bothers me... I disagree that it's a flaw. It's obviously the fault of the tech team for not securing the DB "One flaw is that the default settings of a MongoDB database would allow anyone with an internet connection to browse the databases, download them, or even worst case scenario to even delete the data stored on them"

Insecure by default is flawed by default. Unless a product requires certification to use it can’t rely on expert knowledge to provide safety.

Imagine that you created a tool that had all security features enabled. The usability of it would be incredibly low and barrier of entry so high that rarely anyone would use your tool. The idea behind allowing "open access" is to allow for a new user to learn the most important aspect of your tool by realizing what problems it solves.

Of course, from a security standpoint, people will still make mistakes like this, but the onus is NOT on the tool developers. They make it configurable for a reason.

Re: Virtual Keyboard Developer Leaked 31M Client Records

#77
post #76
post #44

Earlier quoted context omitted.

Insecure by default is flawed by default. Unless a product requires certification to use it can’t rely on expert knowledge to provide safety.

Imagine that you created a tool that had all security features enabled. The usability of it would be incredibly low and barrier of entry so high that rarely anyone would use your tool. The idea behind allowing "open access" is to allow for a new user to learn the most important aspect of your tool by realizing what problems it solves. Of course, from a security standpoint, people will still make mistakes like this, b…

Sorry, a world where every tool is riddled with security holes by default and every developer needs to learn them inside and out to close them all through configuration is a ridiculous burden.

Is it really that difficult to require someone to set a secure password before a product is usable?

Post reply on HN