Yeah, and there are solid performance reasons for that too even beyond any legal/privacy ones. Relaying across an ocean could actually be a fairly significant latency hit in many cases. Services that are completely focused on privacy even against some level of state actions (like Tor) may just accept and eat that, but that's not definitely not the threat scenario Apple is targeting and it would diminish its appeal as a fairly transparent service. Even purely in the browser people do engage in a certain amount of real-time activity. I can't see Apple considering adding thousands of miles worth of RTT ideal.

All depends on where the destination server is. If the destination is in the U.S., you might benefit from your traffic being routed through Apple's private network.

You can choose in the OS to use a general location or stick to something in your proximity.

At least in the Developer Beta 2

The two options are basically city-level or country but same TZ level. e.g. Toronto, or somewhere in Canada in Eastern time (which I mean would almost certainly be limited to Toronto -- presumably these options make more sense on say the East Coast for the US where there are a number of possible major locations that fit)

There are clearly some bugs. Occasionally I, in Canada, get routed through the US. This guy got routed through the US. Neither case should happen by Apple's description. Apple is quite intentionally trying to avoid their relays getting around geo-restrictions (likely to avoid them getting blacklisted).

I'd assume apple can be required to relay any customer's traffic's into by the government.

Only the ingress proxy is controlled by apple. The egress proxy is required to decrypt the URLs.

Actual egress location and locations returned by various geoip databases have little to do with each other.

> Private relay will egress from the same general region as the client source location.

It's supposed to, but that is definitely not currently the case.

If that will be fixed during the beta period is unclear.