Comment by Groxx
3 months ago
yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.
powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.
(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)
You may be overthinking it. Verification of some sort isn’t the end of the world, it’s arguably an acceptable damage control stop-gap that has precedent on other platforms like special entitlements on iOS and kernel extensions on Windows.
Googles proposal was to require everyone to verify to publish any app through any channel. That would be the equivalent of a web browser enforcing a whitelist of websites, because one scam site asked for access to something bad.
If scam apps use an API designed by Google to steal user data, then they should fix that, without throwing the baby out with the bathwater.
might have meant to reply to someone else? I haven't said anything about verification here
I mean the solution really is a comprehensive permissions system, for an accessibility system that needs to read notifications you should be able to deny it network permissions and whitelist which app's notifications it's allowed to read
entirely agreed, but in the context of this thread that means you just have to convince someone to enable it for the one app, rather than the phone as a whole. which doesn't seem to help at all with the coercion scenario (if anything that might make it safer-sounding and therefore easier), just under normal use / to limit possibly-malicious apps.