What they did was the opposite: ask Microsoft for GDIDs used by attacker-associated IPs within several 24-hour time periods during which attack-related activity took place. Windows pings Microsoft regularly with the GDID, establishing links between your GDID and any IP addresses you use. The IP logs from Microsoft and the VPS provider showed at least 10 instances where a single VPN IP accessed the attacker's VPS and also pinged Microsoft with at least one GDID within a 24-hour period. They found a constant GDID that all instances shared. This seems to have been the most damning GDID-related evidence in the DOJ complaint [1] and yet it wasn't mentioned in the article you linked (or any other articles about this I've seen pop up on HN). It includes the diagram from the complaint (page 18) that outlines this, but devoid of context. The ngrok stuff that the article focuses on was just the cherry on top and was discussed later in the complaint.

What also becomes clear when you read the complaint is that the GDID was just one piece of the puzzle and that they had plenty of other evidence. Attacker-associated IPs were used to access the suspect's Apple, Snapchat, and Facebook accounts, at least one of which was his actual residential IP, not a VPN IP. Once they had revealed the identity of the person who owned these accounts, they were able to all-but-confirm that this was in fact the attacker.

What remains unclear even after reading the complaint is how they were so sure that the GDID they obtained visited specific websites, but honestly, at that point, they were already drowning in evidence, so I don't know if it matters that much. It could be as simple as "he was signed into Edge with his Microsoft account and had sync enabled".

[1] https://www.justice.gov/usao-ndil/media/1450651/dl?inline

From: https://ageverification.dev/av-doc-technical-specification/d...

The EU reference implementation is adding ZKP.

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.

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.

    /* 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 }

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

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

Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.

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

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

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