> Microsoft has a list of IP addresses that has been used by a computer with a certain GDID, but FBI needs to get the GDID in the first place
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".
I think the difference is that, on Windows, there are background services that constantly ping Microsoft with the device ID. A device ID on its own is not really harmful if it's not exposed to the internet.
There is no information about the author of this article, and it has the "AI smell". It's safer to operate under the assumption that it is AI generated unless and until the author reveals themself or at least anonymously confirms that it is not AI generated. This saves you from having made a fool of yourself by spreading it around, if it later becomes apparent that AI wrote it.
> A next version of the Technical Specifications for Age Verification Solutions will include as an experimental feature the Zero-Knowledge Proof (ZKP) solution
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.
> 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.
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.
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.
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.
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.
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