You have no control where your packets get routed on the Internet, by design of the basic protocols.

Personal data should be protected by TLS (edit: and/or application-level encryption) so packet routing is irrelevant to privacy and data protection.

I am very worried that the demand for protection of personal data (which is good) is mutating into an expectation of fully regional Internets that do not peer with each other (which IMO is bad).

Every time I bring up on HN that enforcing national (or regional) law on any extranational company that sends packets to your country will inevitably result in the internet being siloed into legal regions, I get super angry responses. HN seems to love the idea of regulating, taxing, etc. any company that communicates over the internet with people in their country (I’ve even seen packets compared to physical packages subject to customs), but hates to recognize the logical conclusions of that.

If you pay attention to the time those comments come out you'll see a specific pattern around european users coffee/lunch/evening times.

No, the solution is not to silo internet into legal regions, the solution is to people in the USA to also lobby for stronger data protection laws.

When any server in USA soil can be changed into a backdoor, accompanied with a gag order on disclosure, I certainly do not want all my egress traffic routed into any computer in USA.

I thought private relay was supposed to exempt TLS traffic, and serve to protect unencrypted HTTP and DNS?

That’s the (current) rule for app network traffic. Traffic from Safari includes all network connections for iCloud subscribers.

If personal data from EU citizens is routed through the US in the clear or in a decryptable form, that's probably forbidden under the GDPR. There are exceptions, but this doesn't look like one of these.

And while I may not have direct control over where my data is actually routed, but there absolutely are legal restrictions on where companies may route them.

GDPR covers processing and storage of personal data. Packet routing is neither.

It is easier for US to ask Apple to monitor the traffic for a specific user, if the exit node is in US soil. Although the sibling comments say that it is probably a bug, and I hope that it actually is.

Thanks to the design of Private Relay, apple can’t monitor a specific user’s traffic.

From a design perspective you are right.

But from a threat model I would dare to say, if you control the platform (OS, Cloud Service) you can easy bypass encryption or deploy your own keys as well.

In the end it is still a trust question.

Until I see a subpoena that fails to yield any user information, I'll continue to be doubtful as to their claims.

> Personal data should be protected by TLS

I guess it's sort of a good thing that Apple is getting into the business of giving away snake oil to combat people selling it. The big iOS privacy changes that would help are DNS over HTTPS (maybe it already does this and requiring permissions for non-HTTPS network access. Maybe they could limit relay routing to non-HTTPS browser traffic?

Before calling private relay ‘snake oil’ and talking about DoH, perhaps you should do a little bit of research?

Private relay will egress from the same general region as the client source location. So if you’re in switzerland and hopping through a US exit point that is a bug. This is clearly explained in the wwdc video

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.

I don't believe that's the case. Just listened to Craig Federighi on Jon Gruber's podcast say that the intent is that the relay is regionalized. Your IP will be anonymized, but it will at least correspond to the general location you are in. Possibly this was just a bug in the beta?

It's very buggy so far.

Apple Beta's in July are still very early. If it still happened in late August I might be concerned.

Yep. I've found the setting seems to exist in two places, and it turns itself back on at times (that said, it's a beta):

1. Settings -> Apple ID -> Private Relay

2. Settings -> Network -> Use iCloud Private Relay

I'm more bemused as why it picked a US server in the first place, as the options panel screenshot suggests it should be presevering the rough location (i.e. pick Belgium or France or somewhere european).

Is private relay still in Beta? That might explain it if the serve side component only got deployed in one or two of Apple's US datacentres.

Yes, it is a macOS Monterey/iOS 15 feature and both are in early (!) Beta. Exit nodes may severly limited at the moment.

It did change a lot in the last few days. As of now I get some datacenter in Switzerland and Liechtenstein sometimes.

Which datacenters are they using? Could you provide IPs or ASNs?

Well as of now the traffic egresses with Cloudflare in Zürich or Bern with the IP 104.28.19.67 :-)

The laws specifically mention "at rest". Where your traffic goes while in flight is not regulated. Legally, the US service can't grab and store your data, but that doesn't mean they can't analyze and use your data as it flows through.

It is not clear what the laws say as FISA intrepretations are secret.

You're correct. I'm paraphrasing guidelines from a previous employer's legal department. The Ireland data center was our EU presence, and we needed to know the boundaries of "what happens in Ireland stays in Ireland", so to speak.

Just because the IP is assigned to the US, does not mean the node was in the US

> This is a really bad idea, as US is known to tap any data they can get on their soil.

I think you meant to say, the US is known to tap ALL data we can get our grubby little paws on. We don't care if it's on our soil or not.

AIUI, it's arguably harder if it's on our soil, as then we might be spying on US citizens which requires a touch more paperwork.

NOTE: I'm not condoning this behaviour, just stating my understanding of it.

Well Switzerland is not completely EU so I’m not sure if it has the same data protection laws.

We still have separate laws here. But we are moving towards the EU regulations in small steps.

In terms of privacy, the Swiss law is essentially equivalent to the GDPR.