I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.
I don't know if you read the article properly (or maybe I didn't) but the 'accident' was improved privacy. Then they took the better privacy feature out. So that could qualify for a fuck Google comment.
I don't know if you read the article properly but this was never an actual feature. They were debug screens that required a third-party app to access. There's no way to access these settings at all from the system UI.
Right on, right on. While I like the potential of this app, the millions of devices with billions of applications that would simply stopping working with its introduction mean it will need a carefully orchestrated rollout. HN readers might be comfortable with "ever beta" technologies, but the other 99% of users are not (and it's odd that smart people fail to appreciate this).
"billions of applications that would simply stopping working".
So what? The user can just re-enable the app's access to whatever it was trying to fetch.
I don't buy the "millions of apps simply stop working" line. If the apps stops working because it was blocked trying to access my address book, then the app developer should have done better to expect the unexpected when fetching anything from outside the application that isn't essential to its core function and purpose.
Even the simplest of javascript functions will handle a null value or failed fetch. There's even an "onerror" handler for HTML img tags! And you're telling me that millions of apps will fail because they don't receive what they're trying to fetch? Sounds like an exaggeration, or bad programming, or a bad OS.
The point is not to protect apps that are overreaching, by intent or just sloppy permissions, but to reduce the chance of unexpected behaviour to the customer (or if you're tinfoil hat , "the product").
The implementation on the part of the developer may be tiny, but you still have to have give those companies time to make and test the changes. Look what happens when companies move the Send button or whatever on their UI-- I tidal wave of internet bile comes rolling in. An app developer might appreciate a heads up before deluging their inbox/tracker with complaints and 1 star reviews.
No, because people coded to the API they were given. They got permission through the application's manifest, as specified by the documentation. They coded to standards. Dynamically revoking permissions breaks that contract.
It sounds like you are more familiar with web frontend programming. I'd caution you that Android app development has differences that are important to this discussion.
>> "Dynamically revoking permissions breaks that contract."
While I'm no expert in native app dev, it's interesting to see so many people are so confident the apps will break under those circumstances, without actually any first hand experience.
I would likewise caution anyone putting forward this idea, that unless you've seen the effect revoking permissions has had on your app, or another app, then anything you put forward in this discussion is hearsay.
I'm not jumping on the meme train about millions of apps crashing due to permission revoking. Google should just include the feature, and have it default to off, with appropriate warnings about tripping some apps when switched on. It doesn't need to be a complicated thing.
Well this is going to be productive.
I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.