Live data from Hacker News

Android developer verification: Early access starts

android-developers.googleblog.com

461–470 of 694 posts

Re: Android developer verification: Early access starts

#461
I'm already annoyed by the fact that when I upgrade my own apps, self-developed and only used by me, which are installed either from Android Studio or by letting the app itself download the update from my server (with the app installation permission) and me then installing it, that I must send the app to Google for them to make a security check.

It's not an option, even if they pretend it to be one: if I click the text "install without scanning", nothing happens. I must accept the big button that uploads the app for a scan. It's none of their business.

ADB is no alternative for me, because it's easier for me to send a websocket command to my 9 devices (mostly dashboards) so that they download the file and start the upgrade process, so that I then only need to press the "upgrade" button manually on each device. Remove the dashboards from the walls, just to plug an USB cable in them, to upgrade the apps?

Re: Android developer verification: Early access starts

#462
post #193

Earlier quoted context omitted.

> Yeah, let's ask the Debian team about installing packages from third party repos. Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows. Hence you don't realize how good of an argument it is, because you even bamboozled yourself without realizing it. It gets a worse argument if we want to discuss Qubes and other di…

"Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows." This is only true if you use Secure boot. It is already not needed and insecure so should be turned off. Then any OS can be installed.

> This is only true if you use Secure boot. [...] so should be turned off. Then any OS can be installed.

You can only turn off Secure Boot because Microsoft allows it. In the same way Android has its CDD with rules all OEMs must follow (otherwise they won't get Google's apps), Windows has a set of hardware certification requirements (otherwise the OEM won't be able to get Windows pre-installed), and it's these certification requirements that say "it must be possible to disable Secure Boot". A future version of Windows could easily have in its hardware certification requirements "it must not be possible to disable Secure Boot", and all OEMs would be forced to follow it if they wanted Windows.

And that already happened. Some time ago, Microsoft mandated that it must not be possible to disable Secure Boot on ARM-based devices (while keeping the rule that it must be possible to disable it on x86-based devices). I think this rule was changed later, but for ARM-based Windows laptops of that era, it's AFAIK not possible to disable Secure Boot to install an alternate OS.

Re: Android developer verification: Early access starts

#463
post #393

Earlier quoted context omitted.

I don't really see how you can both allow developers to update their apps automatically (which is widely promoted as being good security practice) and also defend against good developers turning bad. How does Google know if someone has sold off their app? In most cases, F-Droid couldn't know either. A developer transferring their accounts and private keys to someone else is not easily detected.

> which is widely promoted as being good security practice Maybe that's the mistake right there? It is a good practice only as long as you can trust the remote source for apps. Illustration: it is a good security practice for a Debian distro, not so much for a closed source phone app store.

OPEN SOURCE EVERYTHING is the premier solution.. again.

Re: Android developer verification: Early access starts

#464
post #442

Earlier quoted context omitted.

If neither does what you want, you'll use other metrics, which often make ios a better choice. Simple as that

If they're going to reduce me to a user, iOS is the better choice. I had an iPhone before and it's a picture taking, instagram, social media machine with iMessage—bringing the console wars to normies since inception. Because the hardware is so constrained an iphone lasts forever compared to a similar android. My two year old pixel is slow now, but I know people completely happy with a five year old iphone. Pause, I c…

I have multiple generations of pixel phones and could not tell the difference in performance between them in basic tasks. Maybe because i installed GrapheneOS which makes both stock android and ios feel like a bloat and spyware riddled toy.

Re: Android developer verification: Early access starts

#465

> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choi…

I also think we should stop calling it "sideloading". We need a better word. Sideloading has a negative vibe, as if it's a dangerous thing to install apps from sources other than the Play Store.

>Sideloading has a negative vibe

Maybe you've just been drinking the propaganda? "Sideloading" to me rolls off the tongue no worse than "hotswapping" or "overclocking".

Re: Android developer verification: Early access starts

#466
post #342

I want to be able to install apps from alternative app stores like F-Droid and receive automatic updates, without requiring Google's authorization for app publication. Manually installing an app via adb must, of course, be permitted. But that is not sufficient. > Keeping users safe on Android is our top priority. Google's mandatory verification is not about security, but about control (they want to forbid apps like R…

[dead]

Re: Android developer verification: Early access starts

#467
> Keeping users safe on Android is our top priority.

Then let me decide which apps can access the internet, and which app can access which domain names / IP addresses.

Because it feels like there are a lot of DATA THIEVES out there, selling my data to companies you work with.

We call them Firewalls on the PC.

Re: Android developer verification: Early access starts

#468

Ancedotal: I used to believe in this "freedom to install". Than my Father got scammed (~$1000) in the name of Electricity recharge. The APK was sent over WhatsApp. Now I am not so sure how to implement this freedom. At the bare minimum there has to be big red warnings. One thing which can immediately improve security is forbidding SMS read access forever. Just like Apple does. No App should be able to read SMS.

Sounds like an iPhone is the better option for your dad.

Re: Android developer verification: Early access starts

#469
post #391

Earlier quoted context omitted.

If an app updates to require new permissions, or to suddenly require network access, or the owner contact details change, Google Play should ideally stop that during the update review process and let the users know. But that wouldn't be good for business.

>...or to suddenly require network access... That's the most baffling thing to me. There is simply no option to remove network permissions from any app on my Pixel phone. It's one of the reasons why I avoid using mobile apps whenever I can.

It is solvable from user space.

E.g. TrackerControl https://github.com/TrackerControl/tracker-control-android can do it, it is a local vpn which sees which application is making a request and blocks it.

You can write your own version of it if you don't trust them.

Re: Android developer verification: Early access starts

#470
post #456

Earlier quoted context omitted.

What incentive is there for OEMs to not add this option though? Does Google refuse to veriy their firmware if they offer this feature?

> Does Google refuse to veriy their firmware if they offer this feature? If a manufacturer doesn't follow the Android CDD ( https://source.android.com/docs/compatibility/cdd ), Google will not allow them to bundle Google's closed source apps (which include the Google Play store). It was originally a measure to prevent fragmentation. I don't know whether this particular detail (not exposing this particular permission)…

It's not explicitly part of the CDD, but implicitly. The device must support the Android permissions model and is only allowed to extend this implementation using OWN permissions (in a different namespace than 'android'), but not allowed to deviate from it.

INTERNET is a "normal permission", automatically granted at install time if declared in the manifest. OEMs cannot change the grant behavior without breaking compatibility because:

The CDD explicitly states that the Android security model must remain intact. Any deviation would fail CTS (Compatibility Test Suite) and prevent Play certification.

Post reply on HN