They bought an OS with a powerful permission and inter-app communication system. They started with permitting very powerful / useful apps able to work together and be well integrated into the OS and have had to figure out how to increasingly restrict / sandbox them over time.
-
-
Replying to @CopperheadOS
Yeah. But it was a lot of time. Apple had already production-tested the idea of asking users for critical permissions and making apps survive a “no”. For years by the time Google belatedly began copying those ideas.
1 reply 0 retweets 5 likes -
Replying to @matthew_d_green
Google had AppOps since something like Android 4.3. They started on that a long time ago. It only became something they wanted to deploy in the standard user interface in 6.0 but it had existed as an available (but not exposed to non-power-users) feature for a long time already.
2 replies 0 retweets 2 likes -
Replying to @CopperheadOS @matthew_d_green
They chose not to prioritize making it one of the prominent user-facing features for a long time but it's not like they didn't know it was a good idea. There's essentially a budget of (potentially) breaking changes that can be made in a release and they prioritized other ones.
1 reply 0 retweets 1 like -
Replying to @CopperheadOS
In a world where Google was the only mobile OS developer in the world, or where Google was some scrappy startup, this would make sense. In the real world Apple prioritized these changes and made them all ages earlier. Google just didn’t prioritize privacy.
2 replies 1 retweet 2 likes -
Replying to @matthew_d_green @CopperheadOS
At the end of the day, if management says “we’re going to prioritize [long list of features that aren’t privacy, and oh yeah we’re going to build our own *town*” that’s management saying privacy isn’t that important.
1 reply 1 retweet 2 likes -
Replying to @matthew_d_green
For privacy features, it's not really about resources assigned to it. It's about needing to make breaking changes and only being able to get away with a certain level of that for each major OS version and API version.
3 replies 0 retweets 2 likes -
Replying to @CopperheadOS @matthew_d_green
This is mostly a false narrative. For some things (hidepid/sysmon) it's partly true, but zeroing out call/SMS data would never have broken anything. CM/LOS did it with no problems.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @matthew_d_green
CyanogenMod / LineageOS used the functionality Google wrote. PrivacyGuard is a UI to AppOps, which is the same way Android's own 6.0+ permission toggles work for legacy apps.
2 replies 0 retweets 0 likes -
Providing empty data means the apps stop providing the functionality users expect, and the apps can't check to see that the permission is gone to request it from the user. It's a major usability issue. It works for power users, it doesn't work for regular people.
2 replies 0 retweets 0 likes
Nobody expects any app to be able to read their call or SMS history. That's just not a reasonable functionality to provide, at all. Most also don't expect ability to read contacts.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.