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.
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.
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.
> 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.
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.
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.
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).
> 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.
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.
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.
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.)
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".
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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 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?
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.
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.
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.
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.
> 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?
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
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.
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.
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.
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.
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 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.
I’m fine with 2FA, but let’s please kill 2SA (two step authentication) which appears to be, “Let’s take your long high entropy pass-string and ensure its irrelevance with much easier to compromise SMS or email codes”.
> 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.
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".
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.
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.
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...
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.
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?
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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)
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.
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.
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.
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.
So many companies insist I provide them a "billing address", except I don't have one, it's a uniquely North American thing. Filling that form with gibberish usually does the trick for me.
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.
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.
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?)
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.
“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”
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.
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, 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.
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.
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.
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.
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 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.
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.
Every source I could find said that it was not carried over to chromium-edge and considering how little use it got (because of poor browser support) I'm not surprised.
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?
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).
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.
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.
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.
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.
Given how many acronyms get slung around on the broader web with 0 context, are you really going to nitpick on one that's labelled in a byline? It just explains the prefix of the blog.
