[HN Gopher] Apple's "iCloud Private Relay" broke risk based auth...
___________________________________________________________________
Apple's "iCloud Private Relay" broke risk based authentication
Author : mffap
Score : 154 points
Date : 2021-07-07 12:37 UTC (10 hours ago)
(HTM) web link (zitadel.ch)
(TXT) w3m dump (zitadel.ch)
| jarym wrote:
| "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.
| ffo wrote:
| 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
| SahAssar wrote:
| 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.
| md_ wrote:
| 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.
| ffo wrote:
| 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.
| md_ wrote:
| 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.
| ffo wrote:
| 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 ;-)
| SahAssar wrote:
| 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.
| md_ wrote:
| > 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.
| SahAssar wrote:
| 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.
| ffo wrote:
| I think it is still there, even in Edge on Chromium. But
| still Chrome dropped the hidden support a while ago.
| SahAssar wrote:
| 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.
| ffo wrote:
| Ok, maybe I remembered wrong. This makes things even
| worse.
| kstrauser wrote:
| 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.
| vmception wrote:
| "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"
| meepmorp wrote:
| secure, httponly cookies exist and just might help in easing
| that pain point.
| ffo wrote:
| hey don't forget samesite ;-)
| meepmorp wrote:
| sigh.
| tyingq wrote:
| I would guess that the RIBA vendors will adjust as more people
| start using it.
| csunbird wrote:
| > 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.
| cratermoon wrote:
| 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.
| dannyw wrote:
| It is not clear what the laws say as FISA intrepretations are
| secret.
| cratermoon wrote:
| 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.
| zie wrote:
| > 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.
| snowwrestler wrote:
| 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).
| sneak wrote:
| I thought private relay was supposed to exempt TLS traffic,
| and serve to protect unencrypted HTTP and DNS?
| dividedbyzero wrote:
| 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.
| [deleted]
| snowwrestler wrote:
| GDPR covers processing and storage of personal data. Packet
| routing is neither.
| dehrmann wrote:
| > 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?
| djrogers wrote:
| Before calling private relay 'snake oil' and talking about
| DoH, perhaps you should do a little bit of research?
| [deleted]
| wyager wrote:
| 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.
| TheBill wrote:
| If you pay attention to the time those comments come out
| you'll see a specific pattern around european users
| coffee/lunch/evening times.
| csunbird wrote:
| 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.
| djrogers wrote:
| Thanks to the design of Private Relay, apple _can't_
| monitor a specific user's traffic.
| ffo wrote:
| 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.
| Forbo wrote:
| Until I see a subpoena that fails to yield any user
| information, I'll continue to be doubtful as to their
| claims.
| x4e wrote:
| Well Switzerland is not completely EU so I'm not sure if it has
| the same data protection laws.
| occamrazor wrote:
| In terms of privacy, the Swiss law is essentially equivalent
| to the GDPR.
| ffo wrote:
| We still have separate laws here. But we are moving towards
| the EU regulations in small steps.
| [deleted]
| danceparty wrote:
| 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
| xoa wrote:
| 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.
| ryanlol wrote:
| Actual egress location and locations returned by various
| geoip databases have little to do with each other.
| [deleted]
| ffo wrote:
| 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
| defaultname wrote:
| 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).
| 8note wrote:
| I'd assume apple can be required to relay any customer's
| traffic's into by the government.
| gomjabbar wrote:
| Only the ingress proxy is controlled by apple. The egress
| proxy is required to decrypt the URLs.
| Mindwipe wrote:
| > 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.
| tylrprtr wrote:
| 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?
| Mindwipe wrote:
| It's _very_ buggy so far.
| ykat7 wrote:
| 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
| coldcode wrote:
| Apple Beta's in July are still very early. If it still
| happened in late August I might be concerned.
| tehbeard wrote:
| 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.
| ffo wrote:
| It did change a lot in the last few days. As of now I get
| some datacenter in Switzerland and Liechtenstein sometimes.
| bauruine wrote:
| Which datacenters are they using? Could you provide IPs or
| ASNs?
| ffo wrote:
| Well as of now the traffic egresses with Cloudflare in
| Zurich or Bern with the IP 104.28.19.67 :-)
| mstolpm wrote:
| Yes, it is a macOS Monterey/iOS 15 feature and both are in
| early (!) Beta. Exit nodes may severly limited at the moment.
| snug wrote:
| Just because the IP is assigned to the US, does not mean the
| node was in the US
| [deleted]
| TurningCanadian wrote:
| 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.
| __david__ wrote:
| > 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.
| TurningCanadian wrote:
| How would that alternative way of proving their
| unmaliciousness/identity not be a reinvention of the
| peephole?
| 2OEH8eoCRo0 wrote:
| >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?
| cratermoon wrote:
| 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.
| meepmorp wrote:
| 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.
| wyager wrote:
| 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.
| cratermoon wrote:
| 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...
| adrianstoll wrote:
| This does not prevent geo-blocking, because the relay's
| IP is still in the same region as the user.
| TurningCanadian wrote:
| 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.
| soneil wrote:
| 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.
| patch_cable wrote:
| 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.
| nuker wrote:
| > someone that is blocking their caller ID.
|
| They do give you valid login and password, why is that not
| enough?
| cratermoon wrote:
| You've never had your credentials stolen, or lifted in
| any of the many widely-reported password store breaches?
| https://haveibeenpwned.com/Passwords
| djrogers wrote:
| 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
| TurningCanadian wrote:
| 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.
| frumper wrote:
| 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.
| TurningCanadian wrote:
| 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.
| cratermoon wrote:
| > 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.
| TurningCanadian wrote:
| 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.
| frumper wrote:
| 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.
| ffo wrote:
| Thank you, this really well summarises my article.
| cratermoon wrote:
| 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.
| donohoe wrote:
| 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?
| klohto wrote:
| How? The data stays in EU. Routing to US is clearly a bug (that
| violates it, yes)
| donohoe wrote:
| 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
| djrogers wrote:
| 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).
| donohoe wrote:
| 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.
| netr0ute wrote:
| > 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.
| tomjen3 wrote:
| Can you expand upon how it does that?
| donohoe wrote:
| 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.
| marcinzm wrote:
| 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.
| yunohn wrote:
| > 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
| cglong wrote:
| My guess is that they'll just say Safari isn't supported and
| push people to Chrome.
| djrogers wrote:
| 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.
| crooked-v wrote:
| Chrome on iOS is also Safari.
| r00fus wrote:
| Hmm - and alienate anyone on mobile Safari? I doubt it.
| zikduruqe wrote:
| And why no one will block the egress IP ranges.
| dlivingston wrote:
| 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.
| danudey wrote:
| 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.)
| dlivingston wrote:
| 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.
| cglong wrote:
| I didn't realize Private Relay was coming to iOS too. In that
| case, they'll probably push the app :)
| fps_doug wrote:
| 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.
| marcinzm wrote:
| 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.
| dannyw wrote:
| Etsy is a commercial marketplace, it's as free as your local
| Walmart is free.
| tinus_hn wrote:
| Just like no one will block gmail for sending spam, no one is
| going to block Apple
| Wowfunhappy wrote:
| 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).
| headmelted wrote:
| 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).
| fshbbdssbbgdd wrote:
| Apple's got their own authentication service now. Maybe Etsy
| will relax their IP restrictions for customers using that.
| o8r3oFTZPE wrote:
| The Apple private relay service only applies to Safari so
| Esty could require use of an app or different browser for
| iPhone users.
|
| More simply, why couldnt Etsy retain the system but create an
| exception for the list of private relay IP addresses.
|
| Finally, the HTTP passed through Apple's private relay will
| contain the name of the private relay proxy server so as to
| be easily identifiable. This is intentional.
| vinay_ys wrote:
| More likely to happen: Apple's IP addresses get allowlisted.
| knodi wrote:
| 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.
| Boerworz wrote:
| 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/
| banana_giraffe wrote:
| 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.
| marcinzm wrote:
| >(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.
| novok wrote:
| 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.
| barkerja wrote:
| How many average Etsy users do you think would know that
| iCloud Private Relay is the cause of their issues?
| danudey wrote:
| 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.
| user-the-name wrote:
| > 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.
| breakfastduck wrote:
| You would, sure.
|
| 99.9% of etsy userbase would not.
| katbyte wrote:
| You may be putting too much faith in non technical people
| googling their way to a solution you or I would easily
| find..
| ffo wrote:
| True it applies to other services as well.
|
| I just scoped my IMO to our Identity and Access Management
| World.
| aborsy wrote:
| 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.
| amazingman wrote:
| 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.
| tester89 wrote:
| > IMO = In My Opinion is a blog format where a author reflects
| his own opinion
|
| Did they just reinvent opinion pieces?
| tehbeard wrote:
| 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.
| ffo wrote:
| Exactly this is the intention!
| james_pm wrote:
| We're anticipating having to make some changes to our fraud
| scoring which uses things like location vs. credit card address
| as signals.
| wyager wrote:
| Good. I'm tired of wasting my time with dumb bullshit like
| vendors thinking my credit card billing address is "suspicious"
| somehow.
| grishka wrote:
| 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.
| cr1895 wrote:
| > it's a uniquely North American thing
|
| It's a thing in Europe as well.
| supertrope wrote:
| 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.
| wyager wrote:
| Hopefully this results in the elimination of credit cards.
| Vendors should ideally switch to lighting-based settlement
| or something.
| ratww wrote:
| 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.
| SheinhardtWigCo wrote:
| 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...
| supertrope wrote:
| 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.
| avh02 wrote:
| 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.
| mindslight wrote:
| 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.
| cratermoon wrote:
| > 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?
| liketochill wrote:
| 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
| cratermoon wrote:
| 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.
| mindslight wrote:
| 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.
| netr0ute wrote:
| That's typical if you have a VPN, which many people do.
| cratermoon wrote:
| 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.
| grishka wrote:
| You'd have 2fa for your online banking anyway.
| cratermoon wrote:
| And what if your bank only offers SMS for 2fa?
| jackson1442 wrote:
| 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.
| grishka wrote:
| 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.
| musicale wrote:
| Working as intended.
| outloudvi wrote:
| 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?
| matwood wrote:
| 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.
| r1ch wrote:
| 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.
| gregsadetsky wrote:
| 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.
| r1ch wrote:
| 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.
| ffo wrote:
| Maybe the sell there leftover ingress bandwidth to apple
| :-)
| matwood wrote:
| > 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).
| ffo wrote:
| 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.
| grishka wrote:
| Good. This will finally make everyone treat all IP addresses
| equally.
| astrange wrote:
| 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.
| codetrotter wrote:
| > 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.
| rhexs wrote:
| 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!)
| ffo wrote:
| Oh yes, they are hideous.
| peteretep wrote:
| 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
| gkop wrote:
| Author, since you "dearly recommend" a related blog post of
| yours, _please link to that post_.
| dmitshur wrote:
| I agree. FWIW, I think it's https://zitadel.ch/blog/imo-
| passkey-in-icloud-keychain/.
| ffo wrote:
| 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/
| ffo wrote:
| It is patched now.
| donmcronald wrote:
| 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!
| ffo wrote:
| Been there done that. Google flagged my account several times
| already, with nice captchas :-)
| rdudek wrote:
| They just wanted you to train their AI.
| ffo wrote:
| True :-)
| Spooky23 wrote:
| 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)
___________________________________________________________________
(page generated 2021-07-07 23:01 UTC)