Live data from Hacker News

Android developer verification: Early access starts

android-developers.googleblog.com

281–290 of 694 posts

Re: Android developer verification: Early access starts

#281

They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed. You will not be able to use any of your banking apps without first removing all of those... We need alternatives, this will not work and is a risk to freedom/democracy for all of us. Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. H…

> They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed.

Sincere question: do you have any evidence for this?

I don't see anything in the article that backs it up, and your asserion seems to be at odds with the description of a side load capability for "risk tolerant" users. What you describe would certainly break much of the usefulness of side loading for me.

I certainly don't trust Google, or underestimate their capacity for duplicity. I'm just not sure about the outcome you describe.

Re: Android developer verification: Early access starts

#282

so still distributing with f-droid is messed up? i now have to pay a fee to develop an open-source app via f-droid to everyone? this is a misleading title. they only allow side-loading unverified apps only on fewer devices.

Don't know if you read the whole article

> Based on this feedback and our ongoing conversations with the community, 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 choice in their hands.

Or am I misreading your comment?

Re: Android developer verification: Early access starts

#283

"Based on this feedback and our ongoing conversations with the community, 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 use…

That's because developer verification outside of Google Play isn't required yet.

Re: Android developer verification: Early access starts

#284

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.

> The APK was sent over WhatsApp. Why did your father enable installing APK packages from third party sources? That's a setting buried deep inside the developer settings, which themselves have to be activated with a very arcane manipulation

I believe this only works this way on some android forks, iirc you are talking about Samsung. Stock android would show a warning "do you want to install apk from this app?" and lead you to a settings page that enables apk installs from this particular app. No need to separately enable the ability to install apks in general.

I always thought this is a very weird flow, it adds hoops yet accomplishes nothing because the hoops are all trivial and the same for every app.

Re: Android developer verification: Early access starts

#285

Earlier quoted context omitted.

Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices? I just can't see any good reason for it but my banking app has invested more work into detecting any possible hint of rooting than into its UX. It's absurd.

Probably because it makes it easier to observe and/or intercept API calls and other data exchange between the client and the server. It's trivial to disable things like SSL cert pinning, etc. on rooted devices.

… and then the return argument is that those who actually want to do this nefariously are already going to be able to hide device modifications/rooting.

Re: Android developer verification: Early access starts

#286

Earlier quoted context omitted.

It may not be banks themselves doing this. For example, my bank here in Hungary, Erste Bank has announced that the central bank requested that they stop allowing their android app to run on "modified" devices. They even have a workaround: switch to SMS-based 2FA and use their website (which works well on any screen and has all the features of the app except 2FA)

> the central bank requested That's the answer, it's regulatory bodies causing this.

In 90% it's insurance compliance.

Re: Android developer verification: Early access starts

#287

They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed. You will not be able to use any of your banking apps without first removing all of those... We need alternatives, this will not work and is a risk to freedom/democracy for all of us. Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. H…

Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices? I just can't see any good reason for it but my banking app has invested more work into detecting any possible hint of rooting than into its UX. It's absurd.

At most banks, the absolute control belongs to risk and regulation department. A bank must safeguard their license above all else, and it is very easy for them to loose it if the bank is found doing something it should not (though for the big ones, they sometimes operate in a gray zone, which means they manage to keep their licenses despite relatively steep fines). Even for the simplest ui/ux change, risk department has the final say. Source: I’ve been working 15+ years in the banking industry.

Re: Android developer verification: Early access starts

#288

They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed. You will not be able to use any of your banking apps without first removing all of those... We need alternatives, this will not work and is a risk to freedom/democracy for all of us. Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. H…

Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices? I just can't see any good reason for it but my banking app has invested more work into detecting any possible hint of rooting than into its UX. It's absurd.

If you run a pentest, allowing rooted devices will almost certainly show up as a vulnerability. It'll be marked "low risk", but you'll also be told that you don't want to "accept risk" for too many "low risk" vulnerabilities.

So somebody then needs to say that this is not something they worry about rather than doing the easy thing and remediating it.

Re: Android developer verification: Early access starts

#289
post #252
post #142

Earlier quoted context omitted.

What if it imposed a longish (one time) cooldown period? A day?

1 day is not longish. That would greatly harm apps like F-Droid. You'd have to go through it every time you want to update your apps.

He said one-time.

Re: Android developer verification: Early access starts

#290
post #217

Earlier quoted context omitted.

> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible. What, the same way they hold Microsoft responsible for the fact that you can install whatever you want in Windows? Obviously, there can exist an easy way for a non-technical user to install unverified ap…

This is actually a good point, and something I've been wondering about too. What changed between the 90s and now, that Microsoft didn't get blamed for malware on Windows, but Google/Apple would be blamed now for malware on their devices? It seems that the environment today is different, in the sense that if (widespread) PCs only came into existence now, the PC makers would be considered responsible for harms therefro…

What changed is that Apple made the masses familiar with the concept of installing software only from a store with a vetting process. For short, the walled garden. That was mostly an alien thing in the world of software. All of us grew with the possibility of getting an installer and install it whenever we wanted. There were some form of protections against piracy but nothing else.

Once Apple created the walled garden every other company realized how good it could be for their bottom lines and attempted to do the same thing.

So, to answer your question, Microsoft got blamed for viruses and made fun of but there wasn't a better way in the mainstream. There is one now.

PCs will resist this trend for a while because it's also mainstream that they are used to do work. Many people use a PC every day with some native application from a company they have a direct contract with. For example: accounting software. Everybody can add another example from their own experience. Those programs don't come from the Windows store and it will be a long term effort to gatekeep everything into the store or move them into a web browser.

The .NET MAUI technology we had a post about yesterday is one of the bricks that can build the transition.

Post reply on HN