“Facebook Research” was the Onavo codebase, under a different name, signed by Facebook’s Enterprise certificate.

iOS devices must be activated to use them. This is indeed stored in a database. AppleCare and third-party repair centers can query activation information using GSX.

You are correct about pre-T1 Intel Macs though. Apple will have a blind spot by design, until support is dropped for old machines.

This may help: https://chrome.google.com/webstore/detail/icloud-passwords/p...

> That said, doesn’t iOS notify you when an app wants to use location services? Did all of these users just opt into that? That seems crazy, if so.

Not so crazy.

Local news, weather, and similar apps with a reasonable rationale for Location Services access are often the culprits.

They will put phrases like “See privacy policy.” in the justification text (When asking permission) so they can claim that the user consented.

They have some pretty bad past practices: https://www.zdnet.com/article/accuweather-caught-sending-geo...

And they have continued, off-and-on, to use other location-collecting SDKs.

I think the pitch here is “Semi-managed WireGuard peer provisioning and NAT punching as a service” usable by anyone who may not otherwise have a clue how WireGuard works (eg. friends sharing access to a file/media server), within 5 minutes or less from download/login to “done”

How would that work? Connections are mainly peer-to-peer with Tailscale. An attack (I suppose pushing new key pairs to specific peers and pointing them through a malicious endpoint?) would likely require a very noisy and detectable process.

This may make sense if they were replying via e-mail to the issue.

Different poster here but just curious: Are you a Deutsche Telekom user, by chance?

Nope. Still only working very sporadically for me.

The face:b00c part is in the Interface ID, so this did not even need a large block (Though I am sure they have one).