HN user
A next version of the Technical Specifications for Age Verification Solutions will include as an experimental feature the Zero-Knowledge Proof (ZKP) solution
From: https://ageverification.dev/av-doc-technical-specification/d...
The EU reference implementation is adding ZKP.
Except that within days of this service going live there's going to be a freeageverification.com that instantly generates an attestation proof for anyone for free. I fail to see how this is not untenable. You can compare it to geoblocks that can be circumvented using VPNs, but at least VPNs are costly to run and are usually paid services. With the implementation of verification (ZKP) described in the article, there is no cost to generate attestation proofs nor any limit on the number of proofs nor any way to stop a known-but-anonymous abuser from generating new proofs.
Maybe the EU knows it's untenable and is still moving forward because they will be able to demonstrate to the public that privacy enables abuse, creating pretext to make the system not private anymore after it's already been implemented.
Not to mention self-signed custom builds of GrapheneOS.
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.
...it's still large enough to comfortably read without zooming in, which is not the case for Gruber's website.
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 }
Was this program available to independent security researchers or just established organizations? The docs you linked aren't very clear on this.
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.
There is a difference between mandating that your customers use one specific Linux distro which is maintained by a controversial company, and supporting all Linux distros through an imperfect-but-fully-working method.
Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.
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.
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.
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, 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-...
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
Minecraft Legacy Console Edition apparently leaked on 4chan recently, too: https://github.com/MCLCE/MinecraftConsoles
Almost no coverage on HN or mainstream media though. Surprising, considering the popularity of this game.
Here's the technical measures that are being worked around: https://blog.mozilla.org/en/firefox/fingerprinting-protectio...
IMO you need to actually work around a technical measure intended to stop you for it to qualify as an exploit.
Even well-known vulnerabilities like SQL injection don't qualify under this definition?
Most tech businesses exist because problems exist. Tailscale delivers a solution that's available today. The only alternative is to sit and wait for IPv6. I don't imagine Tailscale is against IPv6 any more than security professionals are against memory-safe programming languages.
The entire rule is as follows:
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
There are not "exceptions"; there is one exception, and that's educational apps. But it's unclear why Pythonista is educational while the apps mentioned in the article are not. In fact, Pythonista is even listed in the "Productivity" section in the App Store.
Apple's own Swift Playground app does the exact thing that supposedly violates the rules, abusing an inconsistently-applied exception for "educational" apps [1].
Recent regulation doesn't help here, by the way. iOS apps submitted for "notarization" to be distributed in alternative app stores in the EU, Japan, etc. still must comply with a subset of the guidelines, including 2.5.2. EU is probably not interested in strengthening the DMA so that Apple doesn't have to approve everything because then it makes other EU regulations easier to bypass (e.g. Chat Control).
Looks like YC wasted their money on this one, unless it's exempt because one of the founders used to work at Apple or something: https://news.ycombinator.com/item?id=45041185
But do they do it whether you're logged in or not?
I noticed the ChatGPT app also checks Play Integrity on Android (because GrapheneOS snitches on apps when they do this), probably for the same reason. Claude's app doesn't, by the way, but it also requires a login.
1. Gatekeeping. OK, fine
Proceeds to explain why your opinion is not "fine" but rather invalid, because Apple boiled you like a frog...
Every time someone mentions here that they're concerned macOS is becoming more like iOS, Apple apologists show up to explain how that's not actually happening. I guess now you guys have just accepted it.
From the article:
While sadly, it doesn’t look like there will be any ADB command you can send to your phone to make it immediately jump to the end of that 24-hour delay
There's also no evidence that adb-sideloaded app stores will be able to skip PackageInstaller's developer verification enforcement, so no, you will have to wait 24 hours to install F-Droid and actually use it.
Wasn't most of the hype surrounding the Motorola partnership based on the idea that you'd be able to get a device with GrapheneOS pre-installed, boosting the legitimacy of GrapheneOS as a competitor to Google Android? Sure, "GrapheneOS adds several more supported devices" is cool and all, but it's not nearly as exciting...
Apple's argument for locking down the iPhone but not the Mac has always been some variation of "Mac users are professionals and iPhones are for everyone."
That argument no longer holds water with the release of the Macbook Neo and the associated Tiktok advertising campaign [1].
That would be very similar to LiveContainer for iOS [1]. I think that unsandboxed JIT is still possible as of Android 16, but Google has been cracking down on it.
Or at least include this flag in the system backups and restore it upon switching to a new device...
If you get most/all of your apps from F-Droid, they're essentially establishing a policy of "any time you get a new phone, you can't use it for 24 hours", which is... insane?
How do you know this? It's been confirmed that you can use adb to temporarily bypass verification on a per-app basis, yes, but from what I can see, there's no indication that sideloading one app over adb will also skip the 1-day period.
This matters if you're sideloading an app store like F-Droid, because sideloaded app stores still have to go through PackageInstaller [1], which probably still enforces verification checks for adb-sideloaded apps?
[1] https://developer.android.com/reference/android/content/pm/P...
Google could easily put an end to that if they wanted. Just block adb access from the loopback address and VPN. I'm surprised this isn't already in place. The setup flow for those apps you're referring to is awkward enough that it's clear it was never intentional to be able to access adb on-device.