Saagar Jha

Story time! When I was working on Android security at Google there was one project I wanted to actively sabotage. Unfortunately, I was unable to do so before I left the company. The authors probably have no idea of this. But their feature was this one.

https://androiddev.social/@MishaalRahman/110968267321676068
1 replies →
1 replies

millionsofplayers :yeah:

(replying to Saagar Jha)

@saagar@federated.saagarjha.com @comex@mas.to Apparently mcaffee blocks the server you’re quote posting

Saagar Jha

(replying to millionsofplayers :yeah:)
@millions @comex Huh, that’s weird. It’s an Android-focused instance; does it tell you why it was blocked?

millionsofplayers :yeah:

(replying to Saagar Jha)

@saagar@federated.saagarjha.com @comex@mas.to No but I was able to get past it by turning on mobile data

Saagar Jha

(replying to Saagar Jha)
Why would I ever admit to this? My job was to make Android more secure. This feature does not make Android more secure. In fact it makes Android less secure, and less usable to boot.

The endgame for this feature is people install malware on their device. It must unship, period.
1 replies →
1 replies

Jernej Virag :androidHead:

(replying to Saagar Jha)

@saagar Why is it always Play involved when I hear the worst things happening to Android developers and users?

Saagar Jha

(replying to Jernej Virag :androidHead:)
@jernej Their job is one of the hardest in many ways, and they’re in a position where their mistakes (whether simple or complex) have a disproportionate affect on how Android is perceived

Jernej Virag :androidHead:

(replying to Saagar Jha)

@saagar Which is why I'm constantly wondering why they have such a repeatedly poor record of user/developer respect and community building. Hard job in this sense also means extra care needs to be taken to do the right tihng.

Just look at the latest target API bump mess on developer side.

Saagar Jha

(replying to Jernej Virag :androidHead:)
@jernej I don’t think Android has a very good feedback loop when it comes to learning from shipping problematic things. Actually Google in general struggles at this

Saagar Jha

(replying to Saagar Jha)
Why does it exist? First, some background. As Android evolves, some APIs are found to have problematic privacy or security implications. As a result, they get updated: perhaps restricted a bit more, or maybe even removed entirely. This is, in general, a good thing!

Saagar Jha

(replying to Saagar Jha)
However, changing APIs means that apps that were built for older versions may break. So, they’re often “grandfathered in”: there are rules like “we changed this in SDK Y, so if your app was built against X or below you can keep the old behavior”. This keeps them working as-is.

Saagar Jha

(replying to Saagar Jha)
Of course, this means bad actors can just always target X or below and keep doing the malicious thing. For this reason, the Play Store has long had a policy where you need to build with a more recent SDK for app updates at some point. This is also a reasonable policy!

Saagar Jha

(replying to Saagar Jha)
Now, what happens to apps that never update? They can keep being installed, and since they were build with SDK X, can keep accessing the old, problematic APIs.

This is the motivation that was used to propose this feature.

Saagar Jha

(replying to Saagar Jha)
This is something that should get solved! Or…wait, should it? This definitely solves the problem, but you’ll notice that I never mentioned any harms. Has anyone actually installed an old app and been harmed because it did something that was let through because of the old SDK?

Saagar Jha

(replying to Saagar Jha)
The truth is that I don’t know if this has harmed anyone. At least I didn’t spot any examples when I skimmed the proposal. But, it sounds plausible, so let’s assume it has happened and motivated this change. This does mean we’ll have to look elsewhere when evaluating it, however.

Saagar Jha

(replying to Saagar Jha)
Most apps on the Play Store are not malware (seriously!) This has held true over time. Most of the old apps that haven’t been updated are games, or old utilities, or defunct social networks. Some have backends that don’t work anymore. But they’re not trying to be malicious!
1 replies →
1 replies

Saagar Jha

(replying to Saagar Jha)
Goodwill is incredibly hard to build up and very easy to destroy. This change tells developers that we do not support apps that are “finished” and never updated. It tells our users their apps they’re looking for may suddenly stop being available for them to install.

Saagar Jha

(replying to Saagar Jha)
Nobody is going to stop to think “why” this was done. They’re just going to hate it. In the case of users, this is where they go to the internet and install whatever they find, which will become a prime target for malware if it isn’t already.

Saagar Jha

(replying to Saagar Jha)
And for the few who do understand why…it just comes across as fundamentally lazy. There’s a number inside Google that shows how many apps are available for each SDK. This change makes that number go down for old versions. But that number is irrelevant! This was to stop harm.

Saagar Jha

(replying to Saagar Jha)
We have existing mechanisms to remove malware from the Play Store. This is nothing new! Old apps which exhibit bad behavior can be removed selectively. Apps that use problematic APIs do so because Android allows them to. That can stop being the case! Why was this not scoped?

Saagar Jha

(replying to Saagar Jha)
I *know* this is more work. I really do. But you have to do it. Look, I’m sorry I didn’t mention this to you all when I was at Google. I’m telling you know, and I hope you undo this before someone sideloads something they shouldn’t have. I was waiting for an example to show…

Saagar Jha

(replying to Saagar Jha)
The alternative is people write about how Android doesn’t do backwards compatibility and probably a news story about a sideloaded game that infects people. That, I assure you, will be worse than whatever this change is aiming to improve.

Saagar Jha

(replying to Saagar Jha)
Most of our work was actually navigating around this fact. By their nature, blanket policies affect legitimate use more than illegitimate use, because there is more good than bad. When we cause pain by being overly broad, it makes people resent the process.