Live data from Hacker News

Android Developer Verification: Threat masquerading as protection

f-droid.org

471–480 of 793 posts

Re: Android Developer Verification: Threat masquerading as protection

#471

Earlier quoted context omitted.

What Norway has sounds pretty crazy to me. If I am reading this correctly, Trump can disable the entire Norwegian healthcare system by calling Apple and Google and having them block BankID.

Trump can close down a lot of the British NHS by telling AWS to stop supplying it. Everyone apart from a few countries (China, Russia, Iran, North Korea, etc.) is dependent on the US.

Yes but that’s a blunt instrument, which would risk reaction. However putting an individual on a sanctions list is routine and easy.

And a president could always just call up the CEOs and ask for their least favourite Norwegian to be cancelled without any paperwork.

Re: Android Developer Verification: Threat masquerading as protection

#472
post #11

Earlier quoted context omitted.

I thought the same thing but he apparently has a point. The stated purpose covers only a tiny sliver of the capabilities. The agreement points to the TOS where it (last time I looked) says service may be terminated at any time without stating a reason. Nothing guarantees it won't be used for things other than security. And finally he has a point where it also doesn't really do much for security. If we ask their fine…

Isn’t Google going to do what Apple has been doing since forever? Or is Google somehow doing something worse?

No, you're still allowed to install whatever apps you want, whether they're verified or not, from the system app stores or not. What developer verification brings is the ability to install apps outside the system app stores without a warning, as required by the antitrust judgment against Google.

People here are complaining about a separate thing, which is that the process for installing an app outside a blessed way is changing, becoming harder for the first such installation and easier for subsequent installations on new devices.

Re: Android Developer Verification: Threat masquerading as protection

#473

I think the most fun part with Google is that if some wayward algorithm decides it doesn’t like you, along with nuking your app and developer account it will probably nuke your 20 year old gmail, your kids Google Drive accounts, your wife’s YouTube premium, the Adsense account of some company you worked for in 2008, and disable your Nest cameras. And you’ll never reach a human to sort it out.

To avoid this, I tried to close my Google Play Developer account. A decade ago I published a free app on it, which was online for half a year. It was to no avail. They will not close the account. I received only automated responses about bringing my old app into compliance with current policy, to then transfer it to another developer account. Only then would Google graciously allow me to close my Developer account. M…

I tried to close my account, and got the response. But they closed it when I failed to verify it.

Re: Android Developer Verification: Threat masquerading as protection

#475
post #142

Earlier quoted context omitted.

It's Android but without Google's services, there's an alternative app store. The irony of Chinese vendors providing a breath of fresh low-DRM air.

It seems like China is becoming the "freedom superpower" while USA is getting "corporate superpower" vibes. Huh

I'm curious why you think China is actually more open in this regard. The CCP has direct influence over the apps that are allowed to be installed on these phones. There is nothing more free about them.

Re: Android Developer Verification: Threat masquerading as protection

#476
post #42
post #39

Earlier quoted context omitted.

The only reason I have not switched Graphene is because for reasons I do not understand, Graphene OS is very closely tied with Google hardware. I bought a /e/os Fairphone instead.

Those reasons are explained clearly and openly. Ironically, your /o/OS is way less open than GOS on Google hardware.

I just want to be as far from Google as I can. I do not want to buy google hardware. Graphene does not allow me to do that.

Re: Android Developer Verification: Threat masquerading as protection

#477

Earlier quoted context omitted.

GrapheneOS is currently the blessed child. Like CyanogenMod previously. They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google. Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, f…

> They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google. Very little in GrapheneOS has gone back upstream post-Copperhead. > Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for…

> Very little in GrapheneOS has gone back upstream post-Copperhead.

Most of what we've landed upstream has been post-Copperhead. AOSP made it increasingly difficult to contribute without being an Android partner and it's nearly impossible now. We've contributed elsewhere including to the Linux kernel and PowerDNS. We don't try to submit security improvements to the Linux kernel anymore based on direct experience of it not being worth the effort required but we still submit patches for bugs. We're not interested in arguing with upstream developers about whether security improvements are worthwhile so we won't contribute those changes to projects not enthusiastic about it. We've made recent contributions to various projects we use including PowerDNS because they don't make it too difficult to contribute.

> What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.

Google didn't invent MTE or memory tagging.

Pixel 8 launched in October 2023 as the first production device with MTE and GrapheneOS began using MTE in production later that month. Pixel OS still doesn't use MTE by default and only began offering a way to use it with Android 16 via Android Advanced Protection Mode (AAPM). AAPM only uses MTE for a few core processes and apps explicitly opting into it which are nearly non-existent. It doesn't use it for the kernel, most of the OS or almost any user installed apps.

GrapheneOS uses MTE for the kernel, all of the base OS processes including apps with a tiny list of minor exceptions to work around HAL issues and many users installed apps by default. It supports opting into using MTE for all user installed apps by default and then disabling it for the ones not compatible with it which are becoming less common in large part due to GrapheneOS users reporting issues to app developers.

Re: Android Developer Verification: Threat masquerading as protection

#479
post #63
post #39

Earlier quoted context omitted.

The only reason I have not switched Graphene is because for reasons I do not understand, Graphene OS is very closely tied with Google hardware. I bought a /e/os Fairphone instead.

It's because only Pixel devices have proper hardware security to build anything secure on top.

Hardware security is irrelevant to me. I just want to leave Google behind me. I do not want Google's hardware.

Re: Android Developer Verification: Threat masquerading as protection

#480

Earlier quoted context omitted.

Article got developer verification completely wrong. The point of developer verification is to be able to install apps outside the app store without warning, which brings Google Android builds in compliance with the antitrust ruling. Third party Android builds can choose other trust roots or disable ADV completely and require warnings for everything because they are not subject to the judgment. Separately, the proces…

That's only the consumer side of it though. As the post states: > Should a developer[...] elect to register themself with Google as a “verified” developer, they should expect to sign up for an account and pay a fee, surrender detailed personal information and upload government-issued identification, and then proceed to register the identifiers and signing keys for all the apps they intend to distribute (now or ever).…

This is no different from before. If you want consumers to be able to install your app without a warning on Google builds, you have to jump through verification hoops. The only thing that ADV changes for developers is that now they can distribute their apps outside the system app stores without a warning as well, which is a new benefit, not a new restriction.

The correct thing to complain about is requiring developer mode for unverified installs, which doesn't seem necessary, not ADV. If you complain about ADV, of course the legislators are going to ignore you. ADV makes Google builds strictly more open and resolves the complaints of the state.

Post reply on HN