Apple's “iCloud Private Relay” broke risk based authentication(zitadel.ch)
zitadel.ch
Apple's “iCloud Private Relay” broke risk based authentication
https://zitadel.ch/blog/imo-rba-is-broken/
210 comments
I 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 of that system.
They will be forced to.
That’s what’s different with iCloud relay - Apple’s weight to force changes upstream.
Either Etsy changes their policy now during the beta (my guess is they will), or they change it in a panic in November when iPhones can no longer access the site to buy anything.
(No-one is going to switch off private relay to convenience a single website).
That’s what’s different with iCloud relay - Apple’s weight to force changes upstream.
Either Etsy changes their policy now during the beta (my guess is they will), or they change it in a panic in November when iPhones can no longer access the site to buy anything.
(No-one is going to switch off private relay to convenience a single website).
>(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.
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.
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.
> They will google it
I'm sorry to tell you this, but sooo many people in the US alone are not technically literate enough to know how to debug an issue like this.
I'm sorry to tell you this, but sooo many people in the US alone are not technically literate enough to know how to debug an issue like this.
You may be putting too much faith in non technical people googling their way to a solution you or I would easily find..
> That said, the Etsy app won't be subject to Private Relay
Why? As far as I know it will apply to apps as well.
Why? As far as I know it will apply to apps as well.
Per the WWDC talk on it: https://developer.apple.com/videos/play/wwdc2021/10096/
> In iOS 15 and macOS 12, Private Relay will apply to all web browsing in Safari, all DNS name resolution queries, and a small subset of traffic from apps.
> Specifically, this will include all insecure HTTP traffic, such as TCP port 80.
This implies that app traffic won't apply to HTTPS traffic, which supports my assertion, but then later in the video:
> Not all networking done by your app occurs over the public internet, so there are several categories of traffic that are not affected by Private Relay.
> Any connections your app makes over the local network or to private domain names will be unaffected.
> Similarly, if your app provides a network extension to add VPN or app-proxying capabilities, your extension won't use Private Relay and neither will app traffic that uses your extension.
> Traffic that uses a proxy is also exempt.
So this says that HTTPS traffic will be included, which disproves my assertion, and seems more likely to be true.
> In iOS 15 and macOS 12, Private Relay will apply to all web browsing in Safari, all DNS name resolution queries, and a small subset of traffic from apps.
> Specifically, this will include all insecure HTTP traffic, such as TCP port 80.
This implies that app traffic won't apply to HTTPS traffic, which supports my assertion, but then later in the video:
> Not all networking done by your app occurs over the public internet, so there are several categories of traffic that are not affected by Private Relay.
> Any connections your app makes over the local network or to private domain names will be unaffected.
> Similarly, if your app provides a network extension to add VPN or app-proxying capabilities, your extension won't use Private Relay and neither will app traffic that uses your extension.
> Traffic that uses a proxy is also exempt.
So this says that HTTPS traffic will be included, which disproves my assertion, and seems more likely to be true.
Yeah, they are not being very clear, which is nothing new for Apple. But usually, you get closest to the truth if you look at what their intent is, and in this case, the intent is to limit the ability to track users, and there is no reason they would make a distinction between web users and app users there.
You would, sure.
99.9% of etsy userbase would not.
99.9% of etsy userbase would not.
If there’s one lesson I badly want to see all engineers learn is that odds are they haven’t the faintest clue what it’s like to be a typical user.
99% of computer users do not inhabit the same galaxy as you do when it comes to understanding and managing technical details.
99% of computer users do not inhabit the same galaxy as you do when it comes to understanding and managing technical details.
I feel you there. I’m a PO so have those kind of arguments regularly!
At the same time, 99% of computer users have no idea why we can’t just ‘slap x button there and make it do x’ and that is just as infuriating.
At the same time, 99% of computer users have no idea why we can’t just ‘slap x button there and make it do x’ and that is just as infuriating.
So true. And even other engineers too.
Etsy does something similar with vpns where they serve a blank page if you try to access it. They don’t even throw up an error message.
That prevents buyers from buying also.
Etsy will adapt, quickly.
That prevents buyers from buying also.
Etsy will adapt, quickly.
Apple’s got their own authentication service now. Maybe Etsy will relax their IP restrictions for customers using that.
More likely to happen: Apple's IP addresses get allowlisted.
There is no Apple's IP address with Private Relay. Apple is using 3rd part companies as its exit nodes to avoid this "whitelist apple ip addresses" concern.
The "Get ready for iCloud Private Relay" session[1] from this year's WWDC makes it seem like there will be a publicly available list of IP addresses used by Private Relay:
Private Relay guarantees that users can't use the system to pretend to be from a different region, so you can continue to enforce region-based access restrictions. Details about the proxy IP addresses will be available as an article associated with this session.
Though I haven't been able to find the aforementioned article.
[1]: https://developer.apple.com/videos/play/wwdc2021/10096/
Private Relay guarantees that users can't use the system to pretend to be from a different region, so you can continue to enforce region-based access restrictions. Details about the proxy IP addresses will be available as an article associated with this session.
Though I haven't been able to find the aforementioned article.
[1]: https://developer.apple.com/videos/play/wwdc2021/10096/
Here's the article:
https://developer.apple.com/support/prepare-your-network-for...
And their IPs, as mentioned in that article:
https://mask-api.icloud.com/egress-ip-ranges.csv
Seems to be mostly Fastly IP addresses right now, but I'm sure that'll change over time.
https://developer.apple.com/support/prepare-your-network-for...
And their IPs, as mentioned in that article:
https://mask-api.icloud.com/egress-ip-ranges.csv
Seems to be mostly Fastly IP addresses right now, but I'm sure that'll change over time.
I used to work on anti-hijacking "risk based analysis" at Google. Here's what's even more likely to happen: Apple's IP addresses get marked as VPN/Tor ranges and treated exactly the same way as other such ranges. This may trigger e.g. requirements to use two factor authentication on an account if you wish to log in from such ranges.
[deleted]
I personally would like the ability to—for example—disable logging into my password manager from outside the US. It's been a decade since I last left the country (no particular reason), and if that changes, I can change the setting before I leave.
Could an attacker use a VPN? Sure—and there are also plenty of evildoers in the US. But it's an extra barrier.
What I really don't want, however, is for my password manager (or any other service) to make these decisions for me. I will probably travel some day, and when I do, I don't want to be locked out of my account due to "unusual traffic" (yes, it is unusual for me to travel, that doesn't mean it won't happen).
Could an attacker use a VPN? Sure—and there are also plenty of evildoers in the US. But it's an extra barrier.
What I really don't want, however, is for my password manager (or any other service) to make these decisions for me. I will probably travel some day, and when I do, I don't want to be locked out of my account due to "unusual traffic" (yes, it is unusual for me to travel, that doesn't mean it won't happen).
> I find authentication the least problematic place where risk based on ip is used.
I’m not an expert on Risk Based authentication, but your Etsy example sounds exactly like RBA. They use IP address as a factor in determining the risk associated with allowing the login, and suspend accounts with random IPs to prevent the “attacker” from wreaking havoc.
RBA: https://en.wikipedia.org/wiki/Risk-based_authentication
I’m not an expert on Risk Based authentication, but your Etsy example sounds exactly like RBA. They use IP address as a factor in determining the risk associated with allowing the login, and suspend accounts with random IPs to prevent the “attacker” from wreaking havoc.
RBA: https://en.wikipedia.org/wiki/Risk-based_authentication
Just like no one will block gmail for sending spam, no one is going to block Apple
This was happening to me on Instagram as well. Using CloudFlare WARP+ and Instagram would deactivate my account arbitrarily. Figured it out only when I turned it off and the issues went away.
True it applies to other services as well.
I just scoped my IMO to our Identity and Access Management World.
I just scoped my IMO to our Identity and Access Management World.
Compared to Google, where you can't contact anybody at all if you're not on a payed account. Yes, it's free, why do you expect service, but they're still making money off me with ads etc., so locking an account down forever because of suspicious activity seems a bit over the top in that case.
Sometimes Etsy customer service will just say "we no longer have a business relationship and we cannot talk further<disconnect>". So it may be weeks using un-documented email addresses and escalation processes that you only learn about on unofficial subreddits.
Etsy is a commercial marketplace, it's as free as your local Walmart is free.
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 a no-brainer.
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 a no-brainer.
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.)
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.)
Maybe I’m missing something, but doesn’t your edge case validate my argument?
In other words, your comment reads as “if everyone stops visiting Etsy, then they will make $0”, which…yeah. Makes sense to me.
In other words, your comment reads as “if everyone stops visiting Etsy, then they will make $0”, which…yeah. Makes sense to me.
More like "if I can choose arbitrary values for my variables I can make the equation say whatever I want, regardless of what the real values should be".
This was a better comment than your original sarcastic comment - the internet’s got enough vitriol, please don’t add to it.
Except this formula is exactly how businesses determine what operating systems, browsers, and devices they support are.
They plug the numbers into the formula and see "If we block IE11 users from being able to use the site, we lose 1% of our traffic, which equates to X dollars. Is that a substantial amount? If so, we support IE11, if not, IE11 support goes out the door."
So yeah, you can plug in the numbers you did and try to negate his argument, but that doesn't make his argument wrong. Just means you understand the argument but fail to accept it.
They plug the numbers into the formula and see "If we block IE11 users from being able to use the site, we lose 1% of our traffic, which equates to X dollars. Is that a substantial amount? If so, we support IE11, if not, IE11 support goes out the door."
So yeah, you can plug in the numbers you did and try to negate his argument, but that doesn't make his argument wrong. Just means you understand the argument but fail to accept it.
1. It's weird that the values you pick lead to an example scenario where the person you're disagreeing with is even more right.
2. The point of the math was to show that it's a big deal for basically any reasonable values. It doesn't depend on the exact numbers.
2. The point of the math was to show that it's a big deal for basically any reasonable values. It doesn't depend on the exact numbers.
You can’t really do that for iOS. Sure, I mean you technically could, but mobile chrome usage is so low that the blowback would be enormous.
Chrome on iOS is also Safari.
I didn't realize Private Relay was coming to iOS too. In that case, they'll probably push the app :)
> 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 they can get on their soil.
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 they can get on their soil.
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).
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.
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.
[deleted]
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.
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.
[deleted]
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.
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?
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
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).
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).
Actual egress location and locations returned by various geoip databases have little to do with each other.
[deleted]
> 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.
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
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.
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.
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.
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.
[deleted]
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.
I 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 reject. If they're successful here, I'll have to consider buying a Mac purely for their VPN service.
Perhaps they'll take on CAPTCHAs next.
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 reject. If they're successful here, I'll have to consider buying a Mac purely for their VPN service.
Perhaps they'll take on CAPTCHAs next.
> 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?
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?
It was a nice temporary hack in the game of cat and mouse. Now a solution that doesn’t depend on that signal will be required.
My bank sends me a card with a grid of coordinates and I have to enter the character at the coordinate when I login, after entering my password, thereby proving something I know and something I have, without also requiring me to have a phone
My bank sends me a card with a grid of coordinates and I have to enter the character at the coordinate when I login, after entering my password, thereby proving something I know and something I have, without also requiring me to have a phone
Yes, that's great. It's also less convenient. Depending on the security threat model, users might tolerate it, or they might not. In the case of lots of money, it's a good practice.
People can start wanting to protect their privacy at any time. The situation you describe is more like you traditionally log in "from NYC", and then attempt to log in through a VPN which the snakeoil vendor calls "North Macedonia", and then you get discouraged as if it is a problem with the VPN. If website users could choose to opt in/out of such restrictions I'd see the utility, but that's not what's happening.
That's typical if you have a VPN, which many people do.
Presumably if you have a VPN your exit will appear to be the same place, or some small number of places, all the time. So again, a connection and authentication attempt from a different IP would be a signal to be concerned about.
You'd have 2fa for your online banking anyway.
And what if your bank only offers SMS for 2fa?
We're talking about how banks should be adapting away from this signal, so perhaps they should support WebAuthn and/or TOTP?
It would honestly be revolutionary for a bank to require hardware authentication and send a security key to every client upon registration.
It would honestly be revolutionary for a bank to require hardware authentication and send a security key to every client upon registration.
I was thinking the other day that at the pace at which all the AI stuff is advancing, including hardware accelerators in consumer devices, it won't be long until captchas become useless for their purpose of telling humans and machines apart. It's already at the point where captchas are increasingly frustrating and require way too much attention instead of the simple "enter these characters".
Also, yes, I really wish recaptcha dies a painful death because it often does discriminate me for my IP address and non-acceptance of third-party cookies.
Also, yes, I really wish recaptcha dies a painful death because it often does discriminate me for my IP address and non-acceptance of third-party cookies.
When Google Workplace locks users because of this, and I’m fairly sure they will because they’re super aggressive with IPs that change via VPN, they'll bounce incoming mail for that user.
Have fun everyone!
Have fun everyone!
IIRC that is a configuration choice by the company admin.
I can think of a few orgs that aggressively block VPN traffic from employees - in some cases the metadata leaked by the end user is a security risk. (Ie you’re doing work stuff in one tab and researching or doing related matters in another)
I can think of a few orgs that aggressively block VPN traffic from employees - in some cases the metadata leaked by the end user is a security risk. (Ie you’re doing work stuff in one tab and researching or doing related matters in another)
I was mostly complaining about the way locked accounts bounce mail. I've had accounts locked for "suspicious activity" which is really just logging in from an IP different than the one you normally use. IE: IPs with good reputation, but just not exactly the same IP all the time.
Good. As someone who moves around a lot esp to countries where I need to use a VPN, this bullshit is the bane of my life
Thank you. Can someone please break security questions next so I don’t have to store four passwords instead of one to login to my accounts?
Please kill opt-out-less 2FA while you’re at it. (Thanks Amazon, been enjoying that change!)
Please kill opt-out-less 2FA while you’re at it. (Thanks Amazon, been enjoying that change!)
Good. This will finally make everyone treat all IP addresses equally.
Which is bad if you ever wanted to make a service without user accounts.
Also a strange approach by Cloudflare, who sell IP based risk management.
Also a strange approach by Cloudflare, who sell IP based risk management.
> Also a strange approach by Cloudflare, who sell IP based risk management.
Is it though? To me it seems more like the iCloud Private Relay will make it harder for everyone else maybe but not necessarily much harder for Cloudflare themselves.
Is it though? To me it seems more like the iCloud Private Relay will make it harder for everyone else maybe but not necessarily much harder for Cloudflare themselves.
Private relay puts you behind 2 proxies (which is almost as good as 7 proxies) so Cloudflare doesn't see your IP either.
As an end user, I hate being discriminated by something I can't really change much. That's all.
And, yes, I do hate Cloudflare and other CDNs with burning passion because the internet is meant to be decentralized. But especially Cloudflare and their "one more step".
And, yes, I do hate Cloudflare and other CDNs with burning passion because the internet is meant to be decentralized. But especially Cloudflare and their "one more step".
Did it actually break risk based authentication though? Sure, legitimate users will be using Apple's Relay, but what's stopping attackers from using it? If the users of the service are choosing to be indistinguishable from attackers, then that's on them.
I think of it like reputation in real life. If you come knocking on my door, and I can see and recognize you, I'll open it. If you cover up my peephole or hide yourself so that I can't recognize you, why would I even let you know I'm home? Even if you tell me who you are, shouldn't I be worried that someone is impersonating you?
At the very least I'd expect users from anonymizing IPs to have to jump through some extra hoops like captcha and 2FA.
I think of it like reputation in real life. If you come knocking on my door, and I can see and recognize you, I'll open it. If you cover up my peephole or hide yourself so that I can't recognize you, why would I even let you know I'm home? Even if you tell me who you are, shouldn't I be worried that someone is impersonating you?
At the very least I'd expect users from anonymizing IPs to have to jump through some extra hoops like captcha and 2FA.
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 lost. Legit users and malicious parties become indistinguishable. The service can't tell if traffic from the relay is from a customer or an attacker.
What to do? Trust everything? Not good. Treat everything as potentially malicious? Safe, but makes the user experience worse.
To use your analogy, if you look through your peephole and can't tell if the person is your best friend or your worst enemy, how do you react? If you assume it's your best friend, you could be in trouble. If you treat the visitor like your worst enemy, you've pissed off your best friend.
However, with Relay, that signal is lost. Legit users and malicious parties become indistinguishable. The service can't tell if traffic from the relay is from a customer or an attacker.
What to do? Trust everything? Not good. Treat everything as potentially malicious? Safe, but makes the user experience worse.
To use your analogy, if you look through your peephole and can't tell if the person is your best friend or your worst enemy, how do you react? If you assume it's your best friend, you could be in trouble. If you treat the visitor like your worst enemy, you've pissed off your best friend.
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.
Many APIs can be spoofed. If a system is trusting a third party service for security purposes, that needs to be subject to some close scrutiny. Using location as one signal of many is reasonable, and in some legal regimes, at least for now, required. Using location as the sole signal is foolish, and never was sufficiently reliable for anything but the most casual security check. See for example https://splinternews.com/how-an-internet-mapping-glitch-turn...
This does not prevent geo-blocking, because the relay's IP is still in the same region as the user.
Except when it isn’t like in the OP’s article. Also, when datacentres inevitably go down, traffic will be rerouted, potentially to other countries.
Thank you, this really well summarises my article.
In my previous work we used the term "progressive authentication" for something similar. If the authentication attempt matched previous patterns, assume it's OK. If one or more of the signals is different but not obviously suspicious, present an additional challenge. This would be the case if the user lived in, for example, Seattle, and the login came from a place like the bay area, which they have previously visited. If it's clearly anomalous, provide all challenges and possible even block the attempt. This would be the case if, for example, an obvious bot script running coming from an address that resolved to an AWS instance in Hong Kong.
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.
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.
Whoah there Nelly! That’s a huge leap from ‘using built in privacy protection features of my phone’ to ‘choosing to be suspicious’.
Why should everyone between me and my data have access to an IP address that is tied to my personal data? And when did choosing to not allow that become a shady thing to do?
— edited autocorrect of ruins to features
Why should everyone between me and my data have access to an IP address that is tied to my personal data? And when did choosing to not allow that become a shady thing to do?
— edited autocorrect of ruins to features
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 real-life analogy would be having someone record everything that you do. We've come to accept that to an extent when going into stores, but probably wouldn't hang out with a friend that did that. I don't think the best solution to that is to put a bag over yourself and change your voice so that you're anonymous but still hang out with that friend -- I think it's to tell your friend that you don't want to be recorded. If some service is recording you too invasively, don't do business with them. If you don't know who is recording you, get your government to pass a law like GDPR.
If you want to live in a world without reputation, there will be drawbacks. Attackers will be indistinguishable from regular users, so you have to treat regular users as if they could be attackers; you can't have a tiered approach. The person banned for posting threats (or worse) or otherwise misbehaving on a message platform will be indistinguishable from a new account. The brute force attack will be indistinguishable from the legitimate user. Etc.
To throw out the whole concept of reputation so that you can be perfectly anonymous seems like the wrong solution to the problem.
I think everyone's view is tinted by the over-collection of data that some companies are doing. A real-life analogy would be having someone record everything that you do. We've come to accept that to an extent when going into stores, but probably wouldn't hang out with a friend that did that. I don't think the best solution to that is to put a bag over yourself and change your voice so that you're anonymous but still hang out with that friend -- I think it's to tell your friend that you don't want to be recorded. If some service is recording you too invasively, don't do business with them. If you don't know who is recording you, get your government to pass a law like GDPR.
If you want to live in a world without reputation, there will be drawbacks. Attackers will be indistinguishable from regular users, so you have to treat regular users as if they could be attackers; you can't have a tiered approach. The person banned for posting threats (or worse) or otherwise misbehaving on a message platform will be indistinguishable from a new account. The brute force attack will be indistinguishable from the legitimate user. Etc.
To throw out the whole concept of reputation so that you can be perfectly anonymous seems like the wrong solution to the problem.
Here’s the problem - my IP address should not signal reputation. They are fungible, and can change on your carrier’s whim. GEO-IP data is spotty at best. And that doesn’t even touch on how IaaS platforms handle IPs.
The only thing that should signal my reputation is my identity, and despite the best efforts of the adtech world, you can’t reliably correlate that to an IP address.
The only thing that should signal my reputation is my identity, and despite the best efforts of the adtech world, you can’t reliably correlate that to an IP address.
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.
The company challenging her beyond the normal experience is forced to because until she logs in, she is indistinguishable from an attacker. That's the price she's paying for perfect privacy.
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.
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.
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.
The difference between Apple and other anonymizing proxy/VPN services will be the size of the user base.
Websites will have to choose if they're willing to provide a worse UX to Apple customers.
Websites will have to choose if they're willing to provide a worse UX to Apple customers.
> Why would my visitor be surprised that I'm suspicious though? They're choosing to be suspicious.
I didn't say that. In the example I gave, you looked through your peephole and couldn't identify the visitor. Perhaps there's a problem with the peephole.
I didn't say that. In the example I gave, you looked through your peephole and couldn't identify the visitor. Perhaps there's a problem with the peephole.
In the Apple Relay case, the person is deliberately making it impossible for me to determine who they are. It isn't a problem with my peephole.
If there is a problem with my peephole, I'm still not trusting the person at the door until I can check it out and fix it.
If there is a problem with my peephole, I'm still not trusting the person at the door until I can check it out and fix it.
The person at the door is changing one aspect of many and it's not even one that the person may even have any understanding about. They are very clearly saying their name to you.
If not getting a source IP makes it impossible for you to determine who someone is, you really need to reevaluate your identity systems. IP addresses are not reliable indicators of anything, let alone identity.
> someone that is blocking their caller ID.
They do give you valid login and password, why is that not enough?
They do give you valid login and password, why is that not enough?
You've never had your credentials stolen, or lifted in any of the many widely-reported password store breaches? https://haveibeenpwned.com/Passwords
I get your point. No, I have nothing stolen, and I def will not enter my password on HIBP ever :). I think this IP based security checks should be on by default, yes, but with opt-out option. Im using VPN all the time and getting sick of “new device” emails.
Btw, none of Apple services complained yet about my vpn usage.
Btw, none of Apple services complained yet about my vpn usage.
>If the users of the service are choosing to be indistinguishable from attackers, then that's on them.
No. It's not on me to justify my use-case. How the hell did we get here?
No. It's not on me to justify my use-case. How the hell did we get here?
> If you cover up my peephole or hide yourself so that I can't recognize you, why would I even let you know I'm home? Even if you tell me who you are, shouldn't I be worried that someone is impersonating you?
Perhaps… but if the culture changes and _everyone_ starts covering the peephole, regardless of their intentions, you'll eventually stop looking because you know it's pointless. That doesn't necessarily mean you'll just open your door willy-nilly, it just means you'll come up with some alternative way of having your visitors prove their unmaliciousness.
Perhaps… but if the culture changes and _everyone_ starts covering the peephole, regardless of their intentions, you'll eventually stop looking because you know it's pointless. That doesn't necessarily mean you'll just open your door willy-nilly, it just means you'll come up with some alternative way of having your visitors prove their unmaliciousness.
How would that alternative way of proving their unmaliciousness/identity not be a reinvention of the peephole?
We're anticipating having to make some changes to our fraud scoring which uses things like location vs. credit card address as signals.
as someone who lived abroad but had a US based account i wanted to use to buy things with - "clever" moves like this were the bane of my existence.
Combine that with a bank that would freak out if you used the account from abroad it was often a multi-day operation to get a transaction to go through (between support calls to bank and merchant)
Though i guess a signal vs hard lock/logic.
Combine that with a bank that would freak out if you used the account from abroad it was often a multi-day operation to get a transaction to go through (between support calls to bank and merchant)
Though i guess a signal vs hard lock/logic.
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.
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.
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.
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.
If that happens then it's definitely an issue, but I've had a couple cards with 3D Secure for about 6-7 years and it's always 2FA using an app ("Did you really buy X at vendor Y?") or, before that, with a keychain hardware token.
I wonder if there's rules depending on which country. When I worked for a small-time credit card "vendor" we could put pretty much anything we wanted in our iFrame.
I wonder if there's rules depending on which country. When I worked for a small-time credit card "vendor" we could put pretty much anything we wanted in our iFrame.
3DS1 isn't because it leads to unacceptable cart abandonment rates, but 3DS2 is designed to address that problem by using SMS or app-based authentication for only high-risk transactions, instead of username and password for every transaction.
SCA is therefore likely to become a requirement in the US once it's reached maturity in Europe, as we saw with EMV.
Further reading: https://www.jonesday.com/en/insights/2020/12/strong-customer...
SCA is therefore likely to become a requirement in the US once it's reached maturity in Europe, as we saw with EMV.
Further reading: https://www.jonesday.com/en/insights/2020/12/strong-customer...
Hopefully this results in the elimination of credit cards. Vendors should ideally switch to lighting-based settlement or something.
I thought Private Relay will not change the geo-region of users (e.g., proxy to IPs of the same country) in order to let online streaming companies (e.g,. Netflix) happy. This is different from what said in this post. Is it no longer the case or never the case?
With the Developer Beta 2 it was more consistent in staying somewhat in the region. But still if you IP is consistently changing it is hard to adapt. Btw. Oftentimes Geo Databases are wrong as well.
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.
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.
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).
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).
Possibly supporting own relay is cheaper option than just accepting traffic from other companies' relay, but it depends on how they agreed peering to Apple.
Is it possible that the proxying is done via Cloudflare and Fastly's edge computing platforms? It'd be interesting to see where are the Relay requests coming from (i.e. what is the destination server seeing -- who's connecting to it?)
Great point about the ACL.
Great point about the ACL.
In Cloudflare's case they already have a consumer-facing product that supports relaying over their network (WARP, with separate IP range versus their reverse proxy service) so Apple is likely using a variant of that.
I was very surprised when I checked and saw Fastly on my iPad as I wasn't aware Fastly had any similar product, in my mind they are (were?) strictly a reverse proxy CDN.
I was very surprised when I checked and saw Fastly on my iPad as I wasn't aware Fastly had any similar product, in my mind they are (were?) strictly a reverse proxy CDN.
Maybe the sell there leftover ingress bandwidth to apple :-)
[deleted]
Well... Cloudflare Workers does enable you to bypass CAPTCHA walls.
https://www.freebuf.com/articles/web/267964.html (Chinese)
https://www.freebuf.com/articles/web/267964.html (Chinese)
Author, since you “dearly recommend” a related blog post of yours, please link to that post.
Whops, good catch! There is definitely the link missing. Going to correct that ASAP.
In the meantime: https://zitadel.ch/blog/imo-passkey-in-icloud-keychain/
In the meantime: https://zitadel.ch/blog/imo-passkey-in-icloud-keychain/
It is patched now.
I agree. FWIW, I think it’s https://zitadel.ch/blog/imo-passkey-in-icloud-keychain/.
“Welcome back! Hey looks like you are using a new device, how about we just ignore that greeting and use this other separate login process every fucking session”
[deleted]
It will be interesting to see if Apple allows hackers to freely abuse the system. If Apple bans end-users for abuse there will be far fewer problems.
This is the big one. But how can Apple ban users for abuse if they themselves cannot know which user is responsible for any particular request? If they can tie individual users to abusive activity then their claims of being a truly private relay service are bogus.
Great. RIBA is a really poor method that causes a lot of false positives for expats like myself. I'm really happy that more people will suffer this digital discrimination because it will mean it will go away.
I live in Spain, I'm from the Netherlands and have lived in Ireland as well, leading to tons of "soft block" nightmares.
I live in Spain, I'm from the Netherlands and have lived in Ireland as well, leading to tons of "soft block" nightmares.
I would guess that the RIBA vendors will adjust as more people start using it.
Not quite on topic of this post, but does anyone know how much Private Relay impact iPhone’s battery life?
OpenVPN has a noticeable impact.
OpenVPN has a noticeable impact.
So far it’s been completely unnoticeable. Browsing performance has mostly been within a few % as well - turns out having your traffic egress at a huge CDNs edge network isn’t a bad thing…
The battery impact should be entirely negligible. It's not encapsulating your traffic, it's just relaying it to different endpoints. It's not so much a VPN as a 2-tier proxy.
"But please stop relying on RIBA for the plain authentication of a user!"
Well I'm not sure everyone will be happy to do that. Tying session tokens to source IP addresses is usually not a bad practice and is rarely the only mitigation used.
Well I'm not sure everyone will be happy to do that. Tying session tokens to source IP addresses is usually not a bad practice and is rarely the only mitigation used.
Well, in the end channel binding would be the best option which really mitigates some threat vectors. For example MITM, secrets extraction out of the browser and so on. But the big issue is that this is not widely supported.
Using the IP as means is IMO nonsense with todays use of CG-NAT, VPN and so on. It does not rely help securing something.
But these are just my 2 cents ;-)
Disclaimer: I wrote the article
Using the IP as means is IMO nonsense with todays use of CG-NAT, VPN and so on. It does not rely help securing something.
But these are just my 2 cents ;-)
Disclaimer: I wrote the article
That’s a great practice as long as zero of your users are on phones — which will generally be the case if you deauthenticate them every time their IP changes and they stop using your site.
Token binding was a much better way to do this where you'd bind a cookie to a certain client TLS key. Unfortunately only MS implemented support, and that disappeared when they moved to chromium so I'm guessing it's dead.
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.
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.
To use ip binding as means already fails today. I mean CG-NAT and the slow adoption of ipv6 also did help dig that grave and I would argue that with that you can't rely on the IP because it is volatile anyway.
From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.
From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.
Agreed. And TB arguably could have supported hardware-backed key storage—but no implementations I am aware of did this.
My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
Totally agree with your point here. Would love to see a TB implementation depending on hardware keys. But yeah it is gone.
If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)
If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)
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.
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 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.
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.
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.
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.
Yeah, I think I agree with you there. The area for improvement for token binding or something like it is quite promising; not so for using IP signals.
I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.
I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.
I think it is still there, even in Edge on Chromium. But still Chrome dropped the hidden support a while ago.
Working as intended.
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?
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).
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.
Technically untrue, since you can add "strict source routing" as an IP packet option that specifies exactly where it will be routed.
Nope, you can’t actually do that on the internet at large. Yes, the RFC exists, but your ISP and their upstream will often ignore or even drop those packets.
Also, SSR doesn’t involve geography - IPs and ASNs can move.
Also, SSR doesn’t involve geography - IPs and ASNs can move.
I didn’t say it violates it - it does not.
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.
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.
I was replying to my posts parent who brought up the word violate, not your post.
No, I mean detection systems that trigger consent. Most systems look at IP address to determine if you are an EU user, then give you consent options.
Now there there is no reliable way to tell
Now there there is no reliable way to tell
It's not as if IP addresses were ever a reliable way to tell whether a data subject was physically located within the EU. VPNs and proxies have been around forever. Someone could be accessing your site through Tor Browser or I2P while located in the EU—and if so, these are the users who would be most interested in limiting processing of their personal data.
Just assume that no consent is granted. Access to the site or specific services cannot depend on granting consent, which implies that anyone who does grant consent probably failed to understand that it was optional, or did so only to avoid being harassed with further consent requests. The GDPR already makes the "consent" completely one-sided with no possibility of consideration; it might as well have disallowed the requests altogether and saved everyone a great deal of hassle.
Just assume that no consent is granted. Access to the site or specific services cannot depend on granting consent, which implies that anyone who does grant consent probably failed to understand that it was optional, or did so only to avoid being harassed with further consent requests. The GDPR already makes the "consent" completely one-sided with no possibility of consideration; it might as well have disallowed the requests altogether and saved everyone a great deal of hassle.
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.
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.
> IMO = In My Opinion is a blog format where a author reflects his own opinion
Did they just reïnvent opinion pieces?
Did they just reïnvent opinion pieces?