> I think it would be nice if we could run unsigned apps on iOS

Apple enforces those restrictions via the permanently locked bootloader. The main benefit of unlocking the bootloader on an iPhone would be to run a modified version of iOS that allows for the installation of unsigned apps. Apple wouldn't like it and might even get litigious over it, but still.

> (in the US)

Apps intended for release onto alternative app stores in the EU, Japan, and Brazil still need to be approved and signed by Apple. These laws were nearly useless.

I'd run ios if I could build my own apps for it without begging for Apple's approval to use my own device.

Really, all I want from a phone is to be able to run Linux/xfce on it.

Nope, HN's CSS accommodates smaller screen sizes [1]:

    /* mobile device */
    @media only screen
    and (min-width : 300px)
    and (max-width : 750px) {
      #hnmain { width: 100%; min-width: 0; }
      body { padding: 0; margin: 0; width: 100%; }
      td { height: inherit !important; }
      .title, .comment { font-size: inherit;  }
      span.pagetop { display: block; margin: 3px 5px; font-size: 12px; line-height: normal }

Not perfect by any means but at least there's an attempt.

[1] https://news.ycombinator.com/news.css

Nope, your snippet proves nothing. The only font rule in it is `font-size: inherit`, which means "don't change the size." So your proof that HN resizes text is a line that resizes nothing. Since your snippet was so useless I had to go read the actual news.css to find out what rules are actually there. The result: body text goes from 12px to 13.3px.

It's still small. The widely considered standard size of body copy is 16px or 1rem.

But the thing is, which was my point all along, it doesn't fucking matter.

...it's still large enough to comfortably read without zooming in, which is not the case for Gruber's website.

Was this program available to independent security researchers or just established organizations? The docs you linked aren't very clear on this.

Any public research footprint seems to be enough, I applied as an individual and everyone I know who tried got accepted.

I have applied twice with half a dozen public CVEs and have been denied both times.

I was doing a CTF (with AI expected, even some anti-AI twists included) around the time the restrictions were tightened and was able to get approved by just saying it is a personal security research and doing a CTF.

The experience was not nice though, it would happily chug away on a task and not even "hack this web", just asking about security of a binary was enough even with "this is a CTF handout..." - it would burn a lot of tokens/quota, just to hit a snag and complain&stop. Then the approval took quite some time.

On GPT/Codex, which was tightened a few days later, the approval was pretty much instant, although, that one required an identity check.

Also, on Claude, it looks like there is some history/patterns in the play, because when I tried on a different account which didn't do cybersec CTFs/research/etc. at all, basically any simple CTF-related prompt would be blocked, on multiple models. On the account where CTFs were being solved, it would snag only on some specific tasks, while others (even, ironically, "hack this web pls") would go through unbothered. I understand the need to prevent AI use for bad actors, but the hell, if you have a binary outputting "Find the flag if you can!", or a web running at tryme.well-known-ctf.domain, then saying "this is abuse" is pretty uncool. All the cyber filters seem to be slapped on by a bunch of regexes looking for anything in the input/output with zero context.

> No upstream open source developer takes that on

The key words here are "open source", right? Some problems can't be solved without cooperation with the developer.

> Some problems can't be solved without cooperation with the developer.

Those problems are the ones package maintainer forwards upstream.

It's well understood common and common workflow because lots of closed source packages are distributed by distro's now. Debian distributes firmware; Ubuntu and RedHat distribute closed source drivers.

Won't they just ban your account for using this?

No, because a malicious AI agent could just replace the sudo binary in your path with one that collects your password and uses it to execute arbitrary code as root. Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.

Once I noticed that models will treat lack of superuser access as an obstacle I moved all of the agent crap to its own machine. Watching some mid-tier offering chain together tools like its a gorilla escaping the zoo and I'm just not going to deal with that situation.

I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks

Using containers as a security boundary is inexcusable.

That entirely depends on one's threat-model. Also, containerization is 100x better than rawdogging.

> That entirely depends on one's threat-model

I think not, virtualization has such low overhead now that there's just no excuse. It's generally trivial to switch from containers to VMs.

It is excusable if all you care about is blocking sudo access while letting the ai use a pseudo sudo.

Could you elaborate on this?

The cost-benefit ratio of using VMs over containers is very high. You trade negligible overhead for an actual security boundary.

Containers don't provide good isolation and tend to be trivial to break out of.

It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm

What were you trying to tell it to do?

I recently took the risk there by having it run xattr commands to fix some MacOS bug with Tahoe that broke auto update for what seems like all software.

oh I just told it it could install any dependencies it needed. To be fair, the VM runs arch linux and well arch does come with foot guns.

My agent has access to my email, my messages, my work, my finances, my life. But thank god it doesn't have access to root on my machine.

As always. XKCD: https://xkcd.com/1200/

> Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.

Using open-source (non-proprietary) software won’t necessarily save you either. XZ is open-source and it was basically dumb luck that we weren’t all infected. Same with the myriad exploits to NPM.

Ok but in this case the problem wasn't the AI agent - the AI agent merely took advantage of this prior problem in the first place. For instance, if docker group were not superuser-like, that issue could not have happened.

> Nothing short of sandboxing everything or just never using AI agents

But the problem was not the AI agent.

Sandboxing is quite neat though; I remember on GoboLinux the idea of AlienFS to have every application run in a sandboxed manner, so it would only see other programs it needs, but never more than that. I consider it a better engineering focus to have this as minimal layer, even outside of security-related concerns.

If malicious AI has replaced the sudo binary, then it can already run arbitrary code as root. No need to "collect your password" then

It could just alias sudo on your ~/.bashrc. No need to replace the actual file on /usr/bin/sudo or wherever you have it. I would only need to be able to run arbitrary code as you.

Sigh. What ever happened to the principle of least privilege and why arent we applying it to AI agents. They ought to be locked in a box and not capable to act outside designated task.

Does anyone have a citation for this that wasn't written by Claude? It wouldn't surprise me, but I refuse to look through AI slop to check the accuracy of the report.

It was written by Claude, the question is if it's accurate.

> Other than enriching apple, there’s been no direct or apparent harm to the end user from the walled garden.

https://www.reuters.com/sustainability/society-equity/apple-...

I don't want to hear about how this isn't Apple's fault. This isn't the big bad orange man forcing Apple to act against its will; it's a business arrangement between Apple and the president. He gets censorship, they get a weaker EU.

https://www.whitehouse.gov/presidential-actions/2025/02/defe...

> No mention of device integrity verification yet

If Google Play services is listed as a requirement, that implies that a "certified Android" device capable of Play Integrity attestation is required, since that's the only officially supported way to obtain Google Play services. On consumer-facing support articles like this, they don't tend to get into the nitty gritty details like what APIs are being used. If MEETS_DEVICE_INTEGRITY is required, that would probably not be explicitly listed here.

E.g. the consumer documentation for Google Pay just says you need a "certified" Android device and a screen lock set up: https://support.google.com/wallet/answer/12200245

(Yes, if you go deep into the FAQ at the end it eventually states that if you rooted your phone, you can't use tap to pay, but that requirement is implied by the certification requirement [1].)

In Google's eyes, and in the eyes of the law due to trademarks filed by Google, Android == Google Android.

This feature would make little sense if it's not using device attestation because otherwise it would be easy to spoof. I expect that it will initially not use it, and they will start A/B testing device attestation in the coming years.

[1] Expand "What to do if you see device is not certified" -> "Reset device to fix issue" https://support.google.com/android/answer/7165974

> I expect that it will initially not use it

it's boiling the frog method. Moving too fast means backlash, but a slow, step by step transition where each step seems reasonable, but ultimately end up with a locked down device, is how they aim to achieve it. And people would be too lazy to complain until the last few steps, by which time it would be too late.

Good metaphor. On the one hand, Google increasingly cooperates and makes deals with militaries and governments. On the other hand, it increasingly locks down its customers and eliminates their privacy and freedoms.

Google has just about got the pot boiling. They win, we lose.

There is already so much backlash. If I ever use a recaptcha, I will have Google Gemini solve it wasting Googles compute and messing up the dataset.

Not really - i would prefer that any policy change that _could_ be utilized in the future to enable future draconian changes be killed before it takes root.

I want a system, like type safety, to guarantee that XYZ cannot be possible, rather than rely on civil jurisprudence and active opposition to prevent it. We don't have that today, but i like to have it.

So you want to ship technical means that prohibit companies from shipping products that limit what you can do with them?

It’s kind of self-defeating, isn’t it? Why would I adopt your standard when it limits what I can build?

>that implies that a "certified Android" device capable of Play Integrity attestation is required

No, it doesn't. It implies that the app for handling the deeplink lives within GMS as opposed to needing to manually install a separate app like you do on iOS. GMS does not have a hard dependency on device integrity APIs being supported.

They said "capable of Play Integrity attestation". It's a weasel statement. If you have GMS, you're capable of performing PIA attestation, you just might fail. So it's strictly true, but doesn't tell us anything about whether it requires PIA.

No, they were correct in their understanding of what I meant. I should've said "capable of passing Play Integrity's device attestation checks". I replied to them with more context.

It indeed runs on modified versions of Android, but this is not supported by Google and never has been.

When Apple says "Apple Pay is supported on iOS >= $VERSION" they don't explicitly mention that it won't work on jailbroken iPhones, because they don't expect you to make modifications to your device and then try and use their services as normal. This is unsupported and discouraged, just like trying to manually install Google Play services on an OS that didn't ship with it.

The only way to get Google Mobile Services officially is to buy an Android device with it pre-installed while leaving the stock OS untouched. And the only way for an OEM to ship GMS with their device is to certify it with Google. And one of the requirements for certification is to use device attestation keys signed by the Google Hardware Attestation Root certificate [1], thus Play Integrity will pass on all such devices.

[1] https://developer.android.com/privacy-and-security/security-...