Betrayed by the Android UI [slides]
docs.google.com
docs.google.com
1. Every user should be able to select a custom color and pattern, e.g. to display around the border of system UI. This should be stored in such a fashion that an app can’t simply “guess” what color/pattern to show in a fake UI.
2. Part of the “set up new device” overview for all new users should be to remind them what the UI is supposed to look like.
3. For crying out loud can we move away from these simplistic, ugly UIs. I’m tired of looking at unimaginative colored rectangles on machines capable of displaying cool, photo-realistic artwork. Make Google/Apple/etc. hire entire teams of hundreds of artists to create cool, extremely-difficult-to-render UIs with beautiful buttons, etc. and then bad actors won’t be able to just hack together a real-looking UI in 5 minutes.
While I agree that today's phone UIs are boring, I don't think replacing them with photorealistic, "extremely-difficult-to-render" UIs is a good idea -- nor would that protect against imitation by malicious app publishers.
Usability would go straight out the window. Every menu in every app would become an assault on the eyes, or at least an incredible nuisance. UI elements should be clear and consistent, and should stay out of the way.
Sorry but I don't believe the App Store approval process make any difference in that regard.
Apple does make your app run in a sandbox to try to detect known malware, just like Google does for the play store.
As for the other parts of the review process, 99% of why they are here seem to be to protect's Apple interests (cf spotify).
https://docs.google.com/presentation/d/1Ya2BThnbkXzAtXR3zh9S...
Google: Hey so we had this new thing called FLAG_WINDOW_IS_OBSCURED
Me: Really? Google? You're going to fix your problem by telling everybody to watch out your problems?
I would say this is more akin to a feature than accessibility, in practical means...
Google has several time been tempted to just remove it but since many have legitimate use cases for it that are very popular (like facebook messaging bubble), it has been not been removed fully.
Like it is mentioned in the talk, you need the 'draw on top' permission to do so. The caveat is that apps downloaded from the play store get it by default.
From what I have seen, the talk seem to only talk about the doability of such an attack, not that it has been seen in the wild ? In theory, you could craft an app with a legitimate draw on top behavior + the malware one and get it published that way. The approval/rejection on the play store is very obscure though, so hard to get any more info on that.
IIRC, Google has also added a "an app is drawing on top of the screen" permanent notification when an app does so, causing many people to be pissed at this 'useless' notification. ffs.
iOS does have a11y capabilities as well, so there is that surface of attack, although I don't know if it is exploited.
Why not have a section for (if you do use the feature) justifying why you need draw on top. Then have someone go over the source code to verify that the information volunteered matches up with what is going on behind the scenes. Or just decrypt APK and search for usages of the library?
Also, why is such an intrusive feature enabled by default?! I want proper prompts explaining why they want it, and to be able to decide if I want to give them those permissions.
That someone is who exactly? Did you ever try to contact support for any google product and get more than some standard text blocks back? And that's just regular support people. For what you suggest you'd need an army of people literate in Java, reviewing any app with that permission, including every update, ever uploaded to the app store.
The best way would be to just get rid of this feature, and then maybe look at what the most common use cases for it were and add a few APIs for those.
Now I remember that part. It is not exactly a public API.
As I remember it, what it actually is is a permission to show system window. Its original intent is to allow apps to show dialogs. I am not sure it was even intended to be used by third party apps..
But in the old android days, if you declare for a permission in the manifest and the user gives it at install time, you have it (there were already some forbidden permission, but this was not one of them).
When Google started revising the Android permission system, this one must have been a thorny problem. It was not supposed to be used by third party apps but there were 'legitimate' use cases, like the facebook messenger and its bubble.
One of the beta versions after Marshmallow started treating this permission very carefully with warnings around it. There was a very noisy part of the testers up in arms against that idea. "How dare you remove a feature that I use (even though it is a hack and a dangerous one) ?" So instead it looks like they were very cautious in how to handle this change.
Fwiw, the play store security team is way more active that the FUD says .. and it does not look like there is any know exploitation of draw on top in the wild. Maybe they do indeed analyze the code of apps using draw on top. Maybe the combination of having to only incorporate a hack based on draw on top on apps served on the play store and the increased scrutiny that goes with it make it unattractive to malware creators ?
To be honest, I fail to see why draw on top is so important. The most I have ever used it is with apps like https://play.google.com/store/apps/details?id=com.actinarium.... to draw a grid on top of the system. It could easily become a library instead (and there are already some).
I would be all in favor of just removing it, or making it another runtime permission. I am not even sure that runtime permissions work that well, on iOS or Android. Most people I know have just been conditioned to tap 'yes' on all dialogs.
So it took a lot of time, but finally this is going to be formalized
Edit: watched the video of the talk linked above; the above descriptions seem to be accurate