Apps can now block sideloading easier and force downloads through Google Play | Hacker News Reader

Apps can now block sideloading easier and force downloads through Google Play

androidauthority.com

25 pointscglong22 comments

There's no such thing as "your Android phone" - this phone is not really yours. Not just because Android acts against your interest, but also because you have no access to the TEE (which powers DRM for example).

Things will get even worse because Google is working on the AVF framework which includes so called "protected VMs" - of course they're meant to be protected from you, the user. Their "security" (where you're the "attacker") is based on the TEE but also a so called "protected vm firmware". In their design document they explicitly say that these protected VMs can provide "security" only with locked bootloader.. you probably know what that means..

I’m sick to death of “x isn’t really yours”, “you don’t really own x”. Nerds think that it’s a great pinch of dramatic language to make their point, but I guarantee you that it always comes across is tiring opinionated pedantry. Can we please, please, stop it.

What's your alternative?

Funny, when I tell people that line (usually in response to a request for support with something that the real owner deliberately broke), they usually respond “Huh, I never thought about it like that. Do you have any suggestions?”, and then we have a useful discussion about software freedom and the tradeoffs with convenience and reliability that are necessary these days.

So, no, I will not stop it.

Why are you sick of it when the statement is true?

OP is highlighting an example of software being used to redefine what ownership means - from you pay, it is yours to do as you wish to you pay and it is, highly conditionally, yours to use within an ever changing envelope defined by an evolving terms of service agreement and ecosystem with progressively more anti-features that are not clearly communicated at any stage of the purchasing process and rarely seem to benefit the user aside from 'security'.

Feels like the type of changes outlined in the post are the very definition of "x isn't really yours".

As others have pointed out this is an extremely sneaky way to do this. It isn't Google doing it just enabling the ecosystem to do it, with the net effect being the same.

Smart move, you're not forcing the use of your app store if all major applications enable this of their own will

Yep. It will become the default after a bit. As I mentioned in the other thread, Google is using its monopoly position to force consumers to do business with it (by forcing them to have a google account to use the play walled garden).

https://news.ycombinator.com/item?id=41517159

Extremely sneaky, and by being much more subtle than Apple they might just get away with it, while achieving the same basic effect: locking down their walled garden.

Unfortunate.

Why are you opposed to letting the authors decide on whether or not they want their app sideloaded?

Because that makes me less free.

Why are you opposed to letting the user install software in any way they want?

I'm fine with letting users sideload software, but I'm also fine with letting the people writing the software decide how they want it distributed. Everyone gets to have their say!

Because I am tired of living in what Cory Doctorow calls a "demon haunted world".

https://locusmag.com/2017/09/cory-doctorow-demon-haunted-wor...

Google's hegemony will lead to companies enabling this 'to be on the safe side'. This is a move entirely to maintain Google's dominance of android app distribution.

Seems like it's going to get even more annoying to get apps for a country that you're traveling in. So many apps you want to use as a tourist are geolocked

Note this can practically only be enforced by apps that communicate with a server. For pure client side apps, one can simply patch the code (albeit this won't give them access to the saved data due to signature mismatch).

However, Google is developing a new obfuscation method called pairip (officially automatic integrity protection) that makes it really hard to patch apps by moving some java code to an encrypted vm riddled with checksums and anti debugging checks.. Fortunately "really hard" (and yes, the vm is crazy..) doesn't mean impossible.

But for server side services, this will unfortunately serve its purpose.

[dupe]

More discussion: https://news.ycombinator.com/item?id=41515588

sigh so no more cracked Spotify on Android, I guess. Too bad. A lot of the Android warez scene will take a huge hit from this.

Yep. Could be a big hit to GrapheneOS users. I wonder how Aurora Store will manage.

Likely through the use of the free market.

Privacy conscious folks will just... not use those apps. With any luck app devs will notice that apps with this flag get installed less and stop setting it.

How so? Assuming they’re modifying the APK they can just remove whatever check is in place. I’m guessing something like microG could emulate this API and always return true as well (though this veers more into DRM bypass which may cause legal trouble for microG).

For apps that communicate with a server, there will be so called hardware attestation, like the API doesn't just return "true" but a signature which the server can validate. Keys for this are in the TEE/whatever secure element the phone has (and there's a $500K bounty for extracting secrets from the TEE).

For apps that don't, Google is currently developing a new obfuscation VM called pairip (that libpairipcore.so). This extracts some java code into a VM, so patching an app is not simply a matter of patching smali code - that VM employs many checksums on its memory.

Reply on news.ycombinator.com