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

491–500 of 694 posts

Re: Android developer verification: Early access starts

#491

Post by raxxorraxor »

fauigerzigerk wrote: post #419
lopis wrote: 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.

Some apps would use this for loopback addresses, which as far as I know will then need network permission. The problem here is the permission system itself because ironically Google Play is full of malicious software.

And neither Android nor iOS a safer than modern Desktop systems. On the contrary because leaking data is its own security issue.

Re: Android developer verification: Early access starts

#492

Post by kldg »

ashleyn wrote: post #121
Lammy wrote: post #17

Earlier quoted context omitted.

Google have their own reasons too. They would love to kill off YouTube ReVanced and other haxx0red clients that give features for free which Google would rather sell you on subscription. Just look at everything they've done to break yt-dlp over and over again. In fact their newest countermeasure is a frontpage story right beside this one: https://news.ycombinator.com/item?id=45898407

yt-dlp's days are fairly numbered as Google has a trump card they can eventually deploy: all content is gated behind DRM. IIRC the only reason YouTube content is not yet served exclusively through DRM is to maintain compatibility with older hardware like smart TVs.

Youtube already employs DRM on some of their videos (notably their free* commercial movies). if you try to take a screenshot, the frame is blacked out. this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction; detection of DRM protection and applying the bypass is likely trivial for the kinds of people already writing scripts and programs utilizing yt-dlp. the css method of bypass has been widely disseminated for years (over a decade?), but programmers love puzzles, so a sequel to current DRM implementation seems justified. YT could also substantially annoy me by expiring their login cookies more frequently; I think I have to pull them from my workstation every month or two as-is? at some point, they could introduce enough fragility to my scripts where it's such a bother to maintain that I won't bother downloading/watching the 1-3 videos per day I am today -- but otoh, I've been working on a wasm/Rust mp4 demuxer and from-scratch WebGL2 renderer for video and I'm kind of attached to seeing it through (I've had project shelved for ~3 weeks after getting stuck on a video seek issue), so I might be willing to put a lot of effort into getting the videos as a point of personal pride.

the real pain in the butt in my present is Patreon because I can't be arsed to write something separate for it. as-is, I subscribe to people on Patreon and then never bother watching any of the exclusive content because it's too much work. some solutions like Ghost (providing an API for donor content access) get part of the way to a solution, but they are not themselves a video host, and I've never seen anyone use it.

Re: Android developer verification: Early access starts

#493

Post by cubefox »

gpm wrote: post #116
dgoldstein0 wrote: post #110

Earlier quoted context omitted.

Did we read the same thing? I think Google here said there would be a $25 fee per developer (for those who can't fit in their limited distribution category). I suppose it's much better than a fee per paid install but it's not nothing.

See the "Empowering experienced users" section. They announced the $25 "verification" plan awhile ago. The new part in this article is that they're going to have it remain possible to install software that didn't do that "verification". > 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 quote doesn't say anything about the hoops "experienced users" have to go through in order to install said software.

Re: Android developer verification: Early access starts

#494

Post by LtWorf »

raxxorraxor wrote: post #491
fauigerzigerk wrote: post #419

Earlier quoted context omitted.

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

Some apps would use this for loopback addresses, which as far as I know will then need network permission. The problem here is the permission system itself because ironically Google Play is full of malicious software. And neither Android nor iOS a safer than modern Desktop systems. On the contrary because leaking data is its own security issue.

Wasn't the loopback address recently used maliciously?

Re: Android developer verification: Early access starts

#495

Post by quotemstr »

kldg wrote: post #492
ashleyn wrote: post #121

Earlier quoted context omitted.

yt-dlp's days are fairly numbered as Google has a trump card they can eventually deploy: all content is gated behind DRM. IIRC the only reason YouTube content is not yet served exclusively through DRM is to maintain compatibility with older hardware like smart TVs.

Youtube already employs DRM on some of their videos (notably their free* commercial movies). if you try to take a screenshot, the frame is blacked out. this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction; detection of DRM protection and applying the bypass is likely trivial for the kinds of people already writing scripts and programs utilizing yt-dlp. the css method of bypass has bee…

> this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction

That's not real DRM then. The real DRM is sending the content such that it flows down the protected media path (https://en.wikipedia.org/wiki/Protected_Media_Path) or equivalent. Userspace never sees decrypted plaintext content. The programmable part of the GPU never seen plaintext decrypted content. Applying some no-op blur filter would be pointless since anything doing the blur couldn't see the pixels. It's not something you can work around with clever CSS. To compromise it, you need to do an EoP into ordinarily non-programmable scanout of the GPU or find bad cryptography or a side channel that lets you get the private key that can decode the frames. Very hard.

Is this how YT works today? Not on every platform. Could it work this way? Definitely. The only thing stopping them is fear of breaking compatibility with a long tail of legacy devices.

Re: Android developer verification: Early access starts

#496

Post by fukka42 »

leoedin wrote: post #364
rom1v wrote: 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…

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.

Quite simple: Actual human review that works with the developers.

But this costs money, and the lack of it is proof google doesn't really care about user security. They're just lying.

Re: Android developer verification: Early access starts

#497

Post by raxxorraxor »

GuB-42 wrote: post #428
leoedin wrote: post #364

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.

The point here is that app developers have to identify themselves. Google has no intention to verify the content of sideloaded apps, just that it is signed by a real person, for accountability. They don't know if the person who signed the app is the developer, but should the app happen to be a scam and there is a police investigation, that is the person who will have to answer questions, like "who did you transfer th…

Still believe that signing binaries this way is always bullshit.

I stopped developing for mobile systems ages ago because it just isn't fun anymore and the devices are vastly more useless. As a user, I don't use apps anymore either.

But you can bet I won't ever id myself to Google as a dev.

Re: Android developer verification: Early access starts

#498

Post by Noaidi »

Sorry, really confused user here, so can someone ELI5 for me? I was looking to go to GrapheneOS, will this effect that at all? The title now says they will allow side-loading and it sounds like good news but everyone in here is still complaining. I do not mind this extra step and I think it is way better than what my POS iPhone 16e with Liquid@ss is offing me.

"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. We are gathering early feedback on the design of this feature now and will share more details in the coming months. "

Re: Android developer verification: Early access starts

#499

Post by nirui »

Excuse me, what exactly is "sideloading"? If I wanted to run third-party code on a system through the means that's supported by the system, then it should be called "running", it's a part of normal operation.

The word "sideload" made it sound like you're smuggle something you shouldn't onto the system. Subtle word tricks like this could sneak poisons into your mind, be watchful.

Re: Android developer verification: Early access starts

#500

Post by 1vuio0pswjnm7 »

rom1v wrote: 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…

If "automatic updates" were optional and off-by-default then users would not be vulnerable to something like SimpleMobileTools

Why not let the user decide

Letting someone else decide has potential consequences

Using F-Droid app ("automatic updates") is optional, as it should be

"Automatic updates" is another way of saying "allow somone else to remotely install software on this computer"

Some computer owners might not want that. It's their decision to make

I disable internet access to all apps by default, including system apps

When source code is provided I can remove internet access before compilation

Anyway, the entire OS is "user-hostile" requiring constant vigilance

It's controlled by an online ad services company

Surveillance as a business

Post reply on HN