Earlier quoted context omitted.
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.
Apple's “iCloud Private Relay” broke risk based authentication
141–150 of 211 posts
Re: Apple's “iCloud Private Relay” broke risk based authentication
#142Earlier quoted context omitted.
It comes back to reputation. In the real world, we build up a reputation and people can choose to trust us based on it. That also means that they get to know us. I personally like being able to interact with people that I've built up a positive relationship with. Why doesn't that carry over to the virtual world though? I think everyone's view is tinted by the over-collection of data that some companies are doing. A r…
I understand what you're saying, but my mom sure will think its frustrating that a company she does business with is going to challenge her beyond the normal experience because apple lets her protect her privacy. After all, she's telling the company who she is by logging in.
They're not doing it because they want to annoy anonymous users; they're doing it because they're not getting any signal that they can trust this connection. That's the price you pay for removing reputation, and no number of Apple Relay users can change that. Website operators can't simply start trusting completely anonymous connections simply because there are a lot of them.
That's why I say Apple should be communicating this to users: there's a price to pay for anonymity. You may see more captchas, you may get challenged with 2FA more often, etc. Not to mention, you might be making it easier for actual criminals to hide amongst the other traffic.
When she logged in, the privacy issue becomes moot of course, yes. At that point her credential can be trusted the same way as before.
Re: Apple's “iCloud Private Relay” broke risk based authentication
#143Good. This will finally make everyone treat all IP addresses equally.
Also a strange approach by Cloudflare, who sell IP based risk management.
Re: Apple's “iCloud Private Relay” broke risk based authentication
#144I find authentication the least problematic place where risk based on ip is used. Etsy, for example, will suspend your seller account if it sees too many logins from different IPs or if it's from an IP it has flagged before. It also has terrible seller customer service so it could take weeks to get it un-suspended. Heard of some people using Private Relay getting hit by this during the beta so hopefully Etsy gets rid…
My guess is that they'll just say Safari isn't supported and push people to Chrome.
Re: Apple's “iCloud Private Relay” broke risk based authentication
#145I hadn't known there was a term for this braindead idea that websites should hassle you based on your IP address. Of course there has to be a term, compartmentalization is necessary for getting good people to do bad things. It's fantastic that Apple is continuing to mitigate commercial surveillance. It's easy to discriminate against us lone individuals who hide our IP addresses, but Apple's market is too big to rejec…
> this braindead idea that websites should hassle you based on your IP address So if you only ever log in to your financial institution from NY city, they shouldn't be suspicious if they see an attempt to log in from North Macedonia?
Re: Apple's “iCloud Private Relay” broke risk based authentication
#146Earlier quoted context omitted.
Good. I’m tired of wasting my time with dumb bullshit like vendors thinking my credit card billing address is “suspicious” somehow.
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.
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.
Re: Apple's “iCloud Private Relay” broke risk based authentication
#147Earlier quoted context omitted.
IIRC, in one of the WWDC talks, Apple's advice is stop relying on IP address as a signal of the user's location. Either make use of the location APIs on the platform or work out something different.
Trusting location APIs is also silly, as those can be spoofed easily. What Apple is really doing here is subverting the entire concept of geo-blocking services, which is great.
Re: Apple's “iCloud Private Relay” broke risk based authentication
#148Just 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?
How? The data stays in EU. Routing to US is clearly a bug (that violates it, yes)
Now there there is no reliable way to tell
Re: Apple's “iCloud Private Relay” broke risk based authentication
#149Earlier 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).
I meant that most consent systems that companies add to their site to determine if a user is in EU or not (and hence covered by GDPR) won’t work reliable with Apple users.
Most of their geolocation relies on IP addresses.
Re: Apple's “iCloud Private Relay” broke risk based authentication
#150Earlier quoted context omitted.
Hmm, I'm not convinced it's better—but it depends a lot on your threat model. For preventing malware from using stolen cookies on a botnet, it's reasonable to argue that it's easier for the malware to steal the TLS client cert (which is no less accessible than the cookie jar itself) than it is for the malware to maintain access to the "good" client IP. As silly as IP-binding of sessions is.
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.
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 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.
Yes, but, bizarrely, IPs actually provide more security against some threats, as I noted. I don't think this is because IPs are a great security measure--they're not!--but because token binding as implemented was pretty weak.