The problem is that it's hard to write an interesting Mac desktop application that runs in a sandbox. The kind of complexities that require a full blown desktop application just don't fit in a sandbox. (As opposed to a game, mobile, or web app.) Whatever runs in a sandbox turns out to be just a prettier version of a web app, or a self-contained game.
I struggle to find out how they are not "interesting" or usable. But I get that it can be hard for developers integrate all constraints of sandboxing.
App Distribution on MacOS was always different (even since pre OSX) compared to the rest of UNIX world. The drag-and drop to deploy for instance must seem ridiculous for people used to install via apt-get command line. Yet it’s way more users friendly because it put the burden of complexity in developer hands instead of users’s.
Put a few app developers in jail for what they do and render their businesses bankrupt and maybe we don't need to treat our phones as hostile to their owners?
Back in the day, apps that did this were called spyware and would be forcibly removed by Antivirus/Anti-malware programs. It's incredible that Facebook gets a pass for equivalent behaviour.
Right?! Remember when ad/spyware that tracked every site you visited were considered devilish and flagged by virus scanners? Now it's the norm. Crazy.
I am not a fan of operating systems that deliberately obfuscate things that could technically be done. If I was developing my mobile customer service app then I would like to develop it in such a way that it would not mysteriously fail due to some overly complicated access keys. Or to require a 'rooted' device.
I would not expect my app to be fit for the Google store though. Or any other online app store. Maybe rather than permissions it is the store and what is allowed in the store that is a problem.
For example: which of the following permissions does the Facebook app currently get on Android?
- access Bluetooth settings
- access nfc settings
- view network connections
I bet you don't know off the top of your head, and I'm certain that fewer than one in a hundred users do.This is not because Android team is lazy. All of this information is already surfaced to those who care to look, right there in the play store app. There's a spectrum of options between removing capabilities, presenting them in more detail, and providing a UI that doesn't make people's eyes glaze over. There is a constant tension among these three poles, and no matter where you are, there will be some use case that isn't served well.
Often the "it's too complicated" excuse is really a cover for "we make out money off your data and fund the development of this software to harvest it".
Mass market customers don't read contracts and readily give out SSNs, credit card info, and other personal identifiers.
As a law prof. at NYU said,
>“For the most part [having read the contract] doesn’t matter,” she said. “Things don’t usually go wrong — except when they do. And then it matters.”[0]
[0]https://www.nytimes.com/2013/07/13/your-money/novel-length-c...
Do you have any studies or sources that support a permissions dependency tree approach for mass market customers?
I like "just-in-time" permissions (i.e. This app wants to use your location. yes/no?) That way, you aren't faced with accepting or not using the service at all, at the outset. [0]
[0] https://news.engin.umich.edu/2017/10/nobody-reads-privacy-po...
This "just in time" stuff is awful, in it's simple form, the user only has to click incorrectly once. The obvious way is a dep tree. Start with:
"should any app be able to download your contact list?"
if no (global!!) -> "can I have one contact right now" and tag that information for the provider "I don't expect you to keep this" or "please keep this info and use it to market to me". Really, it's mostly just excuses, there is no reason to upload the data 99% of the time, only the local software "needs" it for a instant, and even then, that's because the OS stack is designed wrong. I don't want new law to mandate this stuff, I want users to demand it with existing contract law.
Making it "per app" instead of global settings with very deliberate and specific (one time unless instructed otherwise) exceptions is exactly what I would do if I wanted to design a system to maximize my user data snarf ability.
Android is new, nothing is "great" at first, I'm not expecting it to be right yet, but ignoring obvious fixes like this going forward is (hopefully) going to give it's forks more power.
Android started off with a blanket permission screen required to even install an app — all or nothing.
I think Apple didn't always have that. There was the Path scandal and outcry that caused Apple to introduce better privacy options.
The issue is (in old versions of Android) you cannot be selective about which ones you grant.
The relevance is that when it comes to transparency, the big dialog of all permissions can disclose a fair amount of detail to the user about exactly what they're being asked to allow.
The difference is that before Android, in the world of windows - we already had a culture of spyware bundled with freeware - as well as viruses/RATs - and plain malicious software - that made it plain that simply allowing random code to execute in a context where it could read data and/or sensors (gps,mic,camera etc) would be a disaster.
There were to workarounds: stewardship (the Linux distro model, like software in debian main etc) or sandboxing.
Android chose too little of each, which essentially amounted to a false sense of security. And here we are.
But in other cases, this is also just Google that we're talking about. There's for example a presentation [1] where a Google dev introduces this new permission system and afterwards someone from the audience asks, if it's also possible to block internet access with it.
And the Google dev responds in the most innocent of ways that it doesn't need to be possible, because clearly the rest of their permission system works so flawlessly that no critical information one could want to upload to the internet would be available to apps anyways.
I know, never attribute to malice that which is adequately explained by stupidity, but it's not like the guy should be able to be this ignorant in the position that he's in. And Google does have reason to be malicious here. Without internet permission, their ads can't be displayed.
Especially the example in the video of the flashlight app is one where the permission system falls completely flat. In order to toggle the flashlight, you need to ask for full access to the camera, meaning you can take pictures as you like. And since you have internet, you can actually do something malicious with those pictures, too. Clearly, the user did not intend for their flashlight app to take pictures and much less so for it to upload them to the internet.
[1] Relevant question is at 18:07: https://www.youtube.com/watch?v=f17qe9vZ8RM
Just being able to write an app (code on the device) and deploy an ad (code on the Internet - possibility to run "code" like fonts, or trigger calls to site/unique.jpg) - would make preventing data exfiltration and/or tracking absurdly hard while continuing to cater to advertisers aka the paying customers.
Technically it is NOT google's fault to open those access to Apps.
Just like credit card CVV, the right to grant you the access to it, prohibit you to store in your server. For personal information, I think social networks need to be held responsible to live up to the same standard.
By granting Facebook permission to read my contact, my understanding is that they should only use my contact to match against their DB and find those who are on FB. I don't think this require them to persist all my contact/conversation history in their own server.
That's why, of course, chips for physical purchase have moved to one-time codes, effectively, so that your credit card number can't be stored without permission. Ideally, someday our online purchases will work the same way.
The Custom ROMs that exist around it do not play into this. They cannot influence how shitty the ecosystem is, as that's entirely in the hand of Google.