Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> If you represent the interests of corporations then try leading with that next time.

I don't. I'm just saying Google and whichever boogeyman you'd care to slot into position 2 share the same interests. Far more than you or me and Google anyway.

> Besides being a broad statement that lacks citations and no doubt relies on contrived examples where this was implemented poorly

To a laymen user, any software that is running without code signing has a much much much higher chance of being something that has gone wrong rather than Joe Public found a cool image editing app that doesn't want to be distributed via the Play store. Are there exceptions? Sure, I'm certainly a big one. Does that mean I don't understand Google's position here? No.

> it's also clearly a violation of the EU Digital Markets Act.

If true, they'll end up in court, same as Apple did.





> To a laymen user, any software that is running without code signing has a much much much higher chance of being something that has gone wrong rather than Joe Public found a cool image editing app that doesn't want to be distributed via the Play store.

Don't give me these "political" answers. That's just another broadly-agreeable statement that's completely unrelated to the one I asked you to substantiate:

> Escape hatches are great, but each also represents a security weakness waiting to be exploited.

There are 3 problems here:

0. If Google genuinely cared about Android security to this degree, they wouldn't be giving threat actors 4 months to run wild with 0-days before publishing them:

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

https://xcancel.com/GrapheneOS/status/1964754118653952027

1. Crossing the escape hatch != security breach

Mobile security relies on sandboxing, not on Google's approvals. Even the most malicious app approved by Google shouldn't be able to steal information, access information from other apps without authorization, or execute actions on user's behalf.

Whenever this core principle is broken due to inevitable security vulnerabilities, it should be treated as such and promptly patched. Instead these shortcomings are used as convenient excuses to advance these political goals.

2. An escape hatch can be anything:

- "allow installation from unknown sources" like we've always had

- secret settings menu + PIN/password + require a switch to be flipped in the recovery menu during boot + require an ADB command to executed + warnings at every step.

- ADB commands + switch in recovery menu + time delay + require a full device reset with all data being lost

First one is somewhat vulnerable to social engineering though I've personally never encountered a device where someone was tricked into doing this, so it must be more resistant than downloading malware on Windows.

Second is close to impervious to social engineering. Grandma isn't going to be accessing the recovery menu or running ADB commands any time soon.

Third one, while far too restrictive in my opinion would still be better than nothing, it would be impenetrable to social engineering, and safeguard any existing data on the device even in case of a serious concurrent vulnerability in the Android sandbox.

Are all of these completely unacceptable?

On the balance of probabilities, "Joe Public" isn't being tricked into doing anything, he is trying to install ReVanced to get ad-free Youtube.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: