| ▲ | tekacs 4 hours ago |
| Just to talk about a different direction here for a second: Something that I find to be a frustrating side effect of malware issues like this is that it seems to result in well-intentioned security teams locking down the data in apps. The justification is quite plausible -- in this case WhatsApp messages were being stolen! But the thing is... that if this isn't what they steal they'll steal something else. Meanwhile locking down those apps so the only apps with a certain signature can read from your WhatsApp means that if you want to back up your messages or read them for any legitimate purpose you're now SOL, or reliant on a usually slow, non-automatable UI-only flow. I'm glad that modern computers are more secure than they have been, but I think that defense in depth by locking down everything and creating more silos is a problem of its own. |
|
| ▲ | __jonas 4 hours ago | parent | next [-] |
| I agree with this, just to note for context though: This (or rather the package that was forked) is not a wrapper of any official WhatsApp API or anything like that, it poses as a WhatsApp client (WhatsApp Web), which the author reverse engineered the protocol of. So users go through the same steps as if they were connecting another client to their WhatsApp account, and the client gets full access to all data of course. From what I understand WhatsApp is already fairly locked down, so people had to resort to this sort of thing – if WA had actually offered this data via a proper API with granular permissions, there might have been a lower chance of this happening. See: https://baileys.wiki/docs/intro/ |
|
| ▲ | vlovich123 4 hours ago | parent | prev | next [-] |
| The OS should be mediating such access where it explicitly asks your permission for an app to access data belonging to another publisher. |
| |
| ▲ | tekacs 4 hours ago | parent | next [-] | | I could certainly see the value in this in principle but sadly the labyrinthine mess that is the Apple permission system (in which they learned none of the lessons of early UAC) illustrates the kind of result that seems to arise from this. A great microcosm illustration of this is automation permission on macOS right now: there's a separate allow dialog for every single app. If you try to use a general purpose automation app it needs to request permission for every single app on your computer individually the first time you use it. Having experienced that in practice it... absolutely sucks. At this point it makes me feel like we need something like an async audit API. Maybe the OS just tracks and logs all of your apps' activity and then: 1) You can view it of course. 2) The OS monitors for deviations from expected patterns for that app globally (kinda like Microsoft's SmartScreen?) 3) Your own apps can get permission to read this audit log if you want to analyze it your own way and/or be more secure. If you're more paranoid maybe you could use a variant that kills an app in a hurry if it's misbehaving. Sadly you can't even implement this as a third party thing on macOS at this point because the security model prohibits you from monitoring other apps. You can't even do it with the user's permission because tracing apps requires you to turn SIP off. | | |
| ▲ | FridgeSeal 3 hours ago | parent | next [-] | | > Maybe the OS just tracks and logs all of your apps' activity The problem here, is that like so many social-media apps, the first thing the app will do is scrape as much as it possibly can from the device, lest it lose access later, at which point auditing it and restricting its permissions is already too late. Give an inch, and they’ll take a mile. Better to make them justify every millimetre instead. | |
| ▲ | whstl 3 hours ago | parent | prev [-] | | This just sounds like another security nightmare. We're not in 1980 anymore. Most people need zero, and even power users need at most one or two apps that need that full access to the disk. In macOS, for example, the sandbox and the file dialog already allow opening any file, bundle or folder on the disk. I haven't really come across any app that does better browsing than this dialog, but if there's any, it should be a special case. Funny enough, WhatsApp on iOS is an app that reimplements the photo browser, as a dark pattern to force users to either give full permission to photos or suffer. The only time where the OS file dialog becomes limited is when a file is actually "multiple files". Which is 1) solvable by bundles or folders and 2) a symptom of developers not giving a shit about usability. |
| |
| ▲ | bhhaskin 4 hours ago | parent | prev | next [-] | | This sounds great on paper, but what happens when the OS isn't working for the user like Windows? | | |
| ▲ | hamandcheese 4 hours ago | parent | next [-] | | Switch OS. | |
| ▲ | iwontberude 4 hours ago | parent | prev | next [-] | | Windows is dead | |
| ▲ | pixl97 4 hours ago | parent | prev [-] | | I mean this was an app for accessing WhatsApp data, you would approve it and go on... the problem is with it sending data off to a 3rd party. | | |
| ▲ | bhhaskin 3 hours ago | parent [-] | | I think you miss understood. If the OS becomes the arbiter of what can and cannot be accessed; it's a slippery slope to the OS becoming a walled garden that only approved apps and developers are allowed to operate. Of course that is a pretty large generalization, but we already see it with mobile devices and are starting to see it with windows and Mac OS. I don't think we should be handing more power to OS makers and away from users. There has to be a middle ground between wall gardens and open systems. It would be much better for node & npm to come up with a solution than locking down access. | | |
| ▲ | whstl 3 hours ago | parent [-] | | The arbiter of what can be accessed should be the user, and always the user. The OS should be merely the enforcer. Currently OSs are a free-for-all, where the user must blindly trust third-party apps, or they enforce it clumsily like in macOS. This was fine in 1980 but isn't anymore. |
|
|
| |
| ▲ | Gigachad 3 hours ago | parent | prev [-] | | MacOS does this. It has a popup to grant access to folders like documents. |
|
|
| ▲ | nicoburns 3 hours ago | parent | prev | next [-] |
| I'm pretty sure WhatsApp does this for anti-competitive reasons not security reasons. |
|
| ▲ | userbinator 4 hours ago | parent | prev | next [-] |
| Meanwhile locking down those apps so the only apps with a certain signature can read from your WhatsApp means that if you want to back up your messages or read them for any legitimate purpose you're now SOL, or reliant on a usually slow, non-automatable UI-only flow. ...and this gives them more control, so they can profit from it. Corporate greed knows no bounds. I'm glad that modern computers are more secure than they have been I'm not. Back when malware was more prevalent among the lower class, there was also far more freedom and interoperability. |
|
| ▲ | hmokiguess 4 hours ago | parent | prev | next [-] |
| xkcd covers this really well: https://xkcd.com/2044/ |
|
| ▲ | blell 3 hours ago | parent | prev | next [-] |
| I imagine the average HN commenter seeing every new story being posted and thinking "how could I criticise big tech using this" |
|
| ▲ | there_is_try 4 hours ago | parent | prev [-] |
| I don't really know what I'm doing, but. Why couldn't messages be stored encrypted on a blockchain with a system where both user's in a one-one conversation agree to a key, or have their own keys, that grants permission for 'their' messages. And then you'd never be locked into a private software / private database / private protocol. You could read your messages at any point with your key. |
| |
