Apple's “iCloud Private Relay” broke risk based authentication • Hacker News Board

Re: Apple's “iCloud Private Relay” broke risk based authentication

#151

Post by donohoe » Wed, Jul 07, 2021, 7:47 PM UTC

tomjen3 wrote: post #37

donohoe wrote: post #32

Just occurred to me that Apple’s upcoming iCloud Private Relay will break nearly all GDPR solutions. Am guessing this has been written up already be someone. Any good perspectives?

Can you expand upon how it does that?

Most consent systems that companies add to their site (to determine if a user is in EU or not) rely on IP address to determine if in EU jurisdiction.

If the IP address can’t be reliably used then many EU users are going to appear to be in the US and their data collected without consent. The opposite may happen too.

This is not Apples fault and Apple aren’t violating GDPR. I’m just flagging that it creates downstream problems and headaches.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#152

Post by danudey » Wed, Jul 07, 2021, 8:01 PM UTC

barkerja wrote: post #111

marcinzm wrote: post #93

Earlier quoted context omitted.

>(No-one is going to switch off private relay to convenience a single website) If you're a seller and a decent chunk of your income comes from Etsy you definitely would. They already do that with avoiding VPNs to not get suspended.

How many average Etsy users do you think would know that iCloud Private Relay is the cause of their issues?

They will google it and find a forum result somewhere that says "If you have iCloud, try turning off Private Relay. This solved the problem for me!" followed by a dozen other people saying 'Thanks so much, this fixed it for me too!"

At least, it would if their Etsy accounts weren't getting locked until they can contact support.

That said, the Etsy app won't be subject to Private Relay, so if the functionality is there then a lot of users won't have to worry about it as much.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#153

Post by netr0ute » Wed, Jul 07, 2021, 8:05 PM UTC

djrogers wrote: post #94

klohto wrote: post #36

Earlier quoted context omitted.

How? The data stays in EU. Routing to US is clearly a bug (that violates it, yes)

Doubt it violates anything - the packets may route through a US based relay, but they’re encrypted when they do, and don’t expose any data. The very nature of the internet makes it impossible to guarantee that none of your packets ever route through a specific country (especially one as connected as the US).

> makes it impossible to guarantee that none of your packets ever route through a specific country

Technically untrue, since you can add "strict source routing" as an IP packet option that specifies exactly where it will be routed.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#154

Post by danudey » Wed, Jul 07, 2021, 8:05 PM UTC

dlivingston wrote: post #113

cglong wrote: post #78

Earlier quoted context omitted.

My guess is that they'll just say Safari isn't supported and push people to Chrome.

They absolutely will not. Let’s say ~30% of Etsy.com views are through Safari (iOS + macOS; ignoring that Chrome on iOS is a viewframe around WebKit anyway). Of those, 25% have iCloud+. Let’s say they did this and 50% of people did visit the site through Chrome. That’s ~4% less revenue for them. I don’t know what Etsy makes per year, but ~4% of whatever that is will be on the order of millions of dollars. So, this is…

This is an interesting breakdown, but here's my analysis:

Let's say that ~100% of Etsy.com views are through Safari. Of those, 100% have iCloud+.

Let's say they did this and 0% of people visit the site through chrome.

That's 100% less revenue for them. Pretty amazing that this one feature could completely kill Etsy's revenue stream.

(For what it's worth, I agree with you that Etsy is not going to tell Safari users to pound sand, but your arbitrary numbers don't make an actual point unless they're based in facts and figures.)

Re: Apple's “iCloud Private Relay” broke risk based authentication

#155

Post by gomjabbar » Wed, Jul 07, 2021, 8:14 PM UTC

8note wrote: post #130

defaultname wrote: post #21

Earlier quoted context omitted.

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 r…

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.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#156

Post by sneak » Wed, Jul 07, 2021, 8:14 PM UTC

snowwrestler wrote: post #50

csunbird wrote: post #4

> As of writing this blog I was in Switzerland and the IP used to egress my traffic was in a region located in the US. If this also tends to change a lot and fast you can basically throw away IP addresses as data of your RIBA. Wait, so my data will be routed to US servers, as an EU resident, where the data protection laws are not as strong as where I live? This is a really bad idea, as US is known to tap any data the…

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 o…

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

Re: Apple's “iCloud Private Relay” broke risk based authentication

#157

Post by matwood » Wed, Jul 07, 2021, 8:20 PM UTC

r1ch wrote: post #76

matwood wrote: post #73

Earlier quoted context omitted.

It's buggy, but I've noticed the location has settled down and has me located in my same city now. Initially my IP was showing up all over the US. My guess is they were working on the logic and adding more CDNs. So far I've seen Cloudflare and Fastly.

How on earth are they proxying through Fastly? I would expect Fastly only sends requests to their customers origins, yet Apple is proxying requests through them to arbitrary websites. I wonder if you could abuse this to bypass ACLs on Fastly customers that block direct origin traffic.

> How on earth are they proxying through Fastly?

Money solves a lot of problems. Fastly already has a geographically diverse set of servers, so I could see them building a feature like this just for Apple (at least initially).

Re: Apple's “iCloud Private Relay” broke risk based authentication

#158

Post by SahAssar » Wed, Jul 07, 2021, 8:25 PM UTC

md_ wrote: post #150

SahAssar wrote: post #59

Earlier quoted context omitted.

It can be made much less accessible because it's not meant to be shared with the remote side. A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.

> It can be made much less accessible because it's not meant to be shared with the remote side. Can be, indeed, but was not in existing implementations, to my knowledge. My point (perhaps I was more clear in my followup comment) was that we shouldn't shed too many tears given the actual implementations did not provide the promised security gains. Were they stepping stones? Maybe. But they didn't (yet) deliver. > A cl…

I feel like your comparison is not fair. IP-based threat detection is still not defending against malware or bad browser extension, and it basically cannot be improved since it relies on something that is not a security mechanism but rather a fundamental part of internet routing. It does not cooperate well with mobile roaming, VPNs, NATs or other routing mechanisms as TFA pointed out.

You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#159

Post by soneil » Wed, Jul 07, 2021, 8:27 PM UTC

TurningCanadian wrote: post #74

cratermoon wrote: post #60

Earlier quoted context omitted.

It broke it in the sense that it removed a signal that would allow the service to distinguish legit users from possibly malicious ones. In the case of a legit user that has in the past always authenticated from an IP address or address block geolocated to say, Seattle, the service can look at any authentication attempt from elsewhere as anomalous and raise additional challenges. However, with Relay, that signal is lo…

Why would my visitor be surprised that I'm suspicious though? They're choosing to be suspicious. Another analogy I could make is someone that is blocking their caller ID. Should they be surprised that fewer people will take their call? They're lumping themselves in with spammers. I think Apple -- and anonymizing proxy/VPN services in general -- should be communicating that to their customers.

This is what Private Relay changes. They're not choosing to be suspicious. Right now, if you're eligible, you're opted in by default. So you end up either deciding that mac/ios users are suspicious by default, or you need to redefine suspicious.

Re: Apple's “iCloud Private Relay” broke risk based authentication

#160

Post by supertrope » Wed, Jul 07, 2021, 8:31 PM UTC

ratww wrote: post #146

supertrope wrote: post #104

Earlier quoted context omitted.

Vendors do that because they’re left holding the bag in chargebacks. Addresses are de facto knowledge based authentication questions in lieu of dynamic credit card codes.

Isn’t 3d Secure a thing in the US? I have a little app in my phone from my credit card company where I confirm when I am really buying something and it looks more secure than relying on fraud detection.

3D Secure trains customers to type their bank login into popups!

It shifts fraud loss liability onto the customer who is even less prepared to deal with it than the merchant. Only a few merchants tried it like Newegg.com. It flopped because the hit to conversion was more than the fraud prevention. It usually fails open (allows transaction to proceed). Merchant side fraud detection is inherently inferior to the bank doing fraud filtering, but banks don't care. Not their liability not their problem.