Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android developer verification: Early access starts

android-developers.googleblog.com

Post reply on HN
Print view View original

141–150 of 694 posts

Re: Android developer verification: Early access starts

#141

Post by Groxx »

thisislife2 wrote: post #88
svat wrote: post #7

From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.) The “Why verification is important” s…

I don't buy this argument at all that this specific implementation is under pressure from the government - if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps in the first place! Why should apps have access to a user's SMS / RCS? (Yeah, I know it makes onboarding / verification easy and all, if an app can acces…

re OTPs, there's a special permission-less way to request sms codes, with a special hash in the content so it's clearly an opt-in by both app and sender: https://developers.google.com/identity/sms-retriever/overvie...

so no, it's not necessary at all. and many apps identify OTPs and give you an easy "copy to clipboard" button in the notification.

but that isn't all super widely known and expected (partly because not all apps or messages follow it), so it's not something you can rely on users denying access to.

Re: Android developer verification: Early access starts

#142

Post by lokar »

xyzzy_plugh wrote: post #127

> 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…

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

Re: Android developer verification: Early access starts

#143

Post by arcfour »

catlikesshrimp wrote: post #79
ryandrake wrote: post #10

Earlier quoted context omitted.

Let's take the "W". This is pretty good news!

I am not english native. Is "The W" a synonym for "A Win", described as a positive outcome after a contest? Is there more nuance or context than that?

Yes, but it's often just "a W" or simply "W" in response to something good or seen as a "win."

There is also the same thing with L for loss/loser. "that's an L take", "L [person]", "take the L here", etc.

They are pretty straightforward in their meaning, basically what you described. I believe it comes from sports but they are used for any good or bad outcome regardless of whether it was a contest.

Re: Android developer verification: Early access starts

#144

Post by Groxx »

klabb3 wrote: post #102
themafia wrote: post #3

> Keeping users safe on Android is our top priority. I highly doubt this is your "top" priority. Or if it is then you're gotten there by completely ignoring Google account security. > intercepts the victim's notifications And who controls these notifications and forces application developers to use a specific service? > bad actors can spin up new harmful apps instantly. Like banking applications that use push or SMS…

> > intercepts the victim's notifications > And who controls these notifications and forces application developers to use a specific service? Am I alone in being alarmed by this? Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps? And they must instead rely on centralized control to disable those apps after the crime? So.. what’s the point of the s…

yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.

powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.

(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)

Re: Android developer verification: Early access starts

#145

Post by notepad0x90 »

This is the worst of both worlds, you can spread your malware as a sideloaded apk just fine, but when it's so big that you're probably burned anyways, then you need to verify your account.

I think a better compromise would have been for google to require developer verification, but also allow third party appstores like f-droid that don't require verification but still are required to "sign" the apks, instead of users enabling wide-open apk sideloading. that way, hobbyists can still publish apps in third party stores, and it is a couple of more steps harder for users to fall for social engineering,because they now have to install/enable f-droid, and then find the right malicious app and download it. The apk downloaded straight from the malicious site won't be loaded no matter what.

Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores, and maybe even require an inconsistent set of steps to search and find apps to make it harder to social engineer people (like names of buttons, ux arrangements, number of clicks,etc.. randomize it all).

What frustrated me on this topic from the beginning is that solutions like what I'm proposing (and better ones) are possible. But the HN prevailing sentiment (and elsewhere) is pitchforks and torches. Ok, disagree with google, but let's discuss about how to solve the android malware problem that is hurting real people, it is irresponsible to do otherwise.

Re: Android developer verification: Early access starts

#146

Post by arcfour »

wmf wrote: post #52
ajkjk wrote: post #42

Earlier quoted context omitted.

this is an absurd rant. they invest, like, billions into security. It's not as perfect as you want it to be but "completely ignoring" is a joke. if you've got actual grievances you should say what they are so that we can actually get on your side instead of rolling our eyes

I'm not the OP but we know that SMS is not secure. Google should try banning that first.

Some security is better than no security. It already took years to even get some of these backwards-thinking companies and services to adopt SMS OTP and it's simple for non-technical users to intuit. Also, believe it or not, some people don't have smartphones, and they will riot if you try to make them switch to any other MFA method...

Of course, I'm not saying we shouldn't push to improve things, but I don't think this is the right reaction either.

Re: Android developer verification: Early access starts

#147

Post by edoceo »

EMIRELADERO wrote: post #68
edoceo wrote: post #33

Earlier quoted context omitted.

It's a device you own, sure. But you've licensed the software.

This is misleading though. There is simply no other choice if you want to use mainstream apps. It could be argued (successfully in my view) that any agreement is null and void due to its acceptance under duress. Users have an inherent legal right to unconditionally access the full advertised functionality of devices they purchase. Any agreement after that is inherently suspect and I wouldn't be surprised to find out…

I agree it's not awesome, or even good. Unfortunately, it's what we've got today. A fact HN seems to dislike.

Re: Android developer verification: Early access starts

#148

Post by arcfour »

sowbug wrote: post #120
BrenBarn wrote: post #23

The key question for me is whether this "advanced flow" will allow the practical use of entirely separate app stores (like F-Droid) or if they're going to throw up tons of barriers for every individual app install.

If I were designing the advanced flow, I'd require the decision to be made at phone setup time. Changing your mind later requires a factory reset. Real sideloaders (F-Droid users, etc.) know at setup time that that's how they'll be using their phone, so it works for them. But ordinary users who are targets for sideloading malware will become a lot less attractive if attackers must convince them to wipe their phone to…

I hadn't installed a non-Play Store app for something like 5 years until this year. I don't see why I should have been forced to factory reset my phone then.

Re: Android developer verification: Early access starts

#149

Post by nromiun »

sipofwater wrote: post #84
sipofwater wrote: post #81

* "Android Developer Verification Discourse" by agnostic-apollo ( https://github.com/agnostic-apollo ), Termux app ( https://github.com/termux/termux-app ) developer: https://gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a... (gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a6bef53d417a6) and https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (old.reddit.com/r/termux/comments/1ourtxj/android_deve…

Android Debug Bridge ( https://developer.android.com/tools/adb ) using two Android smartphones and Termux ( https://github.com/termux/termux-app ): * Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://o…

You don't need two phones to use ADB with Termux. Just put the ADB settings app on a split screen and it will work just fine. I used it several months ago.
Post reply on HN