Hacker Newsnew | past | comments | ask | show | jobs | submit | bjornroberg's commentslogin

This initiative is going to yield a net positive in general societal robustness and security, not only for critical infra and big players. On the contrary, it will make it easier for SMBs without people working 100% with compliance to increase the robustness of their supply chains.


I wonder if it could be that they won't because the real mechanism is that AI wrapper pricing power is weak (switching costs near zero) but state of the art models makes it difficult to lower prices due to higher cost.


I think this is a smart move, and if Mozilla were the same as 10 years ago, I'd have hope for something good.


Solves yesterday's problem. The calcification is UI calcification, and agents don't care about UIs. An MCP server (or a half-decent OpenAPI surface) lets a user-controlled agent compose vendor primitives without touching the DOM, without TOS risk, without overlay maintenance. IoC doesn't get forced by extensions. It gets forced by agents that can read docs and click buttons faster than the vendor can ship features. The vendors who notice will expose that surface voluntarily, because the alternative is getting scraped anyway.


Yeah, this. The vocabulary ratchet is underrated as a policy tool. "Install" became "sideload." "Sideload" became "install from unknown sources." "Unknown sources" is becoming "unverified packages." Each rename shifts the Overton window a little further from "this is the normal way to put software on a computer you own" toward "this is a suspicious deviation Google has graciously decided to tolerate for now."

By the time the technical mechanism lands, the framing has been prepared for a decade. The 24-hour cooldown, the seven taps, the three scare screens all _feel_ proportional to the danger the language has been implying. That's not an accident, that's the policy working as designed.


On the other side of the coin, those of us doing tech support for unsavvy family members do not want them installing software from any source but some vetted app store. Making it a bit harder is a real boon for those of us that still carry the mental scars of so many Bonzi Buddy removals.


Do you consider F-Droid a "vetted app store"?


Yes I do but I don't want to help my parents install it


You should, as it is much safer than the one from Google.


Can you explain how?

Yeah, but it doesn't include the apps that lay-people want to use, such as Facebook, Venmo, and Google Maps. I like open source software as much as the next guy, but most of it seems very off-brand to your average joe. Setting people up with Firefox is one thing, trying to get them to use AntennaPod instead of Spotify is a much taller order.


The detail that keeps getting lost in these threads: the "advanced flow" for power users is delivered through Google Play Services, not the Android OS. That's the whole game.

It means the safeguard is not part of AOSP. It ships as a closed component that Google can narrow, gate, or remove in any Play Services update, with no Android version bump, no OEM coordination, no user consent beyond the usual auto-update. "Open platform with an escape hatch" is load-bearing in the PR; "closed escape hatch bolted onto an open kernel" is what's actually shipping.

The second tell is timing. It's five months from enforcement and the flow has not appeared in any beta, dev preview, or canary build. We're being asked to treat a blog post and UI mockups as a functional guarantee. No other platform change of this scope lands without a shipping preview this late, and Google knows it.

The third piece most devs skim past: registration requires uploading evidence of your private signing key. Whatever you think of the verification program in principle, that specific requirement changes the threat model of every Android key in existence, including the ones protecting apps people already depend on.

"Sideloading still works" is only true in the narrow sense that some ceremony remains. The mechanism protecting that ceremony is owned by the party with the strongest incentive to eventually close it.


What follows is the "advanced flow." I feel like there should be a class action lawsuit in response to this as when I purchased my device I had an expectation that I could install apps without this insane limitation

    Enable Developer Mode ↗ by tapping the software build number in About Phone seven times

    In Settings > System, open Developer Options and scroll down to “Allow Unverified Packages.”

    Flip the toggle and answer a scare screen confirming that you are not being coerced

    Enter your device unlock pin/password

    Restart your device

    Wait 24 hours

    Return to the unverified packages menu at the end of the security delay

    Scroll past additional scare screen warnings and select either “Allow temporarily” (seven days) or “Allow indefinitely.”

    On the next scare screen, confirm that you understand the risks.

    You can now install unverified packages on the device by tapping the “Install anyway” option in the package manager.


Even shutting down HAL9000 was easier than this, and I'm half joking.


I named my phone HAL9000 and when I read this I immediately thought, "Well yeah I just turn it off"


How is this unreasonable? This is to prevent cases where people are told to urgently install the app while on a call, so the call has to be broken and person has a day to actually do something about the call.

Are you that zoomer brained to not be able to wait a day to install your APK?


> the "advanced flow" for power users is delivered through Google Play Services, not the Android OS. That's the whole game.

What is the source for this claim? I can believe it, but I haven't seen where the claim actually comes from, and it doesn't seem to be mentioned in Google's announcements.


If the "advanced flow" is delivered through play services, what does this mean for degoogled Android phones? Or are those not concerned with the new side loading limitations?

Put simply, If I were to install plain AOSP and F-Droid would I be able to continue installing apps normally?


Yes because enforcement of the signing is also done via Google play services.


If you're directly using AOSP, can't you just change the code to remove the check?


The artifact can be faked cheaply now, so the only buying signal left is commitment. That's exactly the "ruthless" move the post argues for, I think.


Broadly agree. Moving from prompt to action is the right direction. I think the prepared statements analogy is not fully comparable in that SQL has a clear boundary between code and data whereas tool calls don't. However, this isn't fatal, just being honest about the shape of the trade-off.

I feel that the hard problem is writing policies expressive enough to cover arbitrary agent work without collapsing back into "trust the model's intent."


Poked around for a few minutes and this is nicely done. Coverage of the less common records (MTA-STS, BIMI, TLSA, CAA) in one place is the part that jumped out. Usually I bounce between two or three sites to get those.

One thing that would be handy: a shareable permalink for a given lookup result, so you can paste it into a ticket or chat instead of retyping the query.


thanks for the feedback- that would be useful- I'll look into something.


It's an interesting domain and deploy-time learning seems to be a powerful approach! I'll look further into it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: