Apple Could Kill CAPTCHAs with Private Access Tokens
appleinsider.com
appleinsider.com
Original comment follows:
In my view, this would just DRM-ize everything on the web. Of course, Cloudflare and Fastly don't talk about this much, and Cloudflare keeps assuring you'll still get captchas if device attestation fails or is unsupported. But realistically, once all Microsoft, Google and Apple implement it in their devices, there isn't much of a reason to keep accepting non-attested devices. You can already see where this is starting to go - if you're using Linux/BSD or another niche OS, congratulations, you can't submit forms any more. And since device verification would become extremely cheap to perform this way, you'd also see websites protected entirely by this tech, effectively locking out Linux/BSD users. The Cloudflare article also talks about how, at least in the case of Apple, they'd run something like a posture assessment to confirm that your device components are genuine. I can also see this new tech locking out users of non-OEM repairs. This is a much bigger deal than what it seems like on the surface, and I'm genuinely scared about how this one simple move dwarfs all of the "evil" things that big tech has done so far.
https://www.ietf.org/archive/id/draft-private-access-tokens-...
I don't meant to sound negative but wouldn't bots just be able to abuse any FLOSS implementation since they can then fake certain interactions with CloudFlare in the background?
Now there’s a bunch of crypto to prevent the identification of an individual device, but websites would still be able to track your actions even if you disabled cookies, localStorage etc. (apart from the current ways such as like Etag tracking or browser fingerprinting) except that you can’t really mitigate it in any way. Whichever way you put this, PATs are not something that would preserve users’ security or privacy.
I also disagree with you that this isn’t a form of DRM - you’d still need some kind of TPM or another embedded electronic device that helps with these attestations. However, once attackers try to buy thousands of such devices to attack/scrape websites, websites would naturally use the originating vendor as the basis for allowing/denying actions. Which ultimately comes down to DRM - you’d see Windows, Android and Apple devices being allowed - and Linux/BSD/rooted Android/custom ROMs being left out to dry.
The website doesn't receive any info other than the URL you are visiting and the fact you have an authenticated PAT.
Not entirely sure where you’re getting your information from.
> There is nothing stopping the Spam/Bot community from implementing something similar.
I am a full time linux user, but I can guarantee you that if the bigcorps are going through with this it absolutely is going to lock out linux users, because the goal is to stop bots.
Evil.
We shouldn't fight bots. We should use trust instead. Not global trust, it must be subjective. I trust A, B, C. B trusts D, E. E trusts F. It should be weighted. There's small world effect [2]. There's just a few hops between any two people in the world. It solves SPAM, it solves reviews, scam, news and maybe politics. Somebody please get it done already.
1. https://duckduckgo.com/?q=phone+farm+bots&t=ffab&iar=images&...
Since I wrote it I became confident that algorithm which is used for cumulative trust computation should be up to each node (instead of using zk-SNARks for example). If you trust somebody, you trust them to compute it as they wish. And I would drop dimensionality at least in the beginning. Probably using multiple identities in place of it.
Once it is implemented in windows it will quickly, if not immediately, be followed by locked bootloaders on any device available in brick and mortar stores or the big online sellers and being locked out from using attestation if you are not using an OS from Apple, MS or Google. We may see a brief window where some select linux distros get to grovel to MS to get signed, but that will quickly go away.
If it's not only technical (e.g: you must be a verified token provider), then it will stop Linux/BSD communities, just like it's today near impossible to open a community mail server.
"Anti-cheat" and "bots" are literally the same reasoning.
And I think the big take-away is: anti-cheat systems' decision to do this hurts more real people than it does bots. Its idiotic, and anyone with half a brain recognizes that, but statistics are on their side. If 1% of both Windows & Linux players cheat, but 90% of all computer users are on Windows, then banning the 10% who aren't easily kills some number of bots. Its not many, but its nonzero.
What we're talking about with PATs is a multi-party established trust system. You're right; maybe the linux community could/will become an issuer of these tokens. I'm not sure its relevant. Any of these systems could be "compromised" to be leveraged by bots (compromised is NOT the right word, but its probably the word the people building this would use). So, being a mediator or site operator, you have to decide which issuers to trust. Apple probably, Microsoft and Google as well, they're big and represent a lot of users. But its SO EASY to just say "nah we're not going to trust Canonical". After all, there are bots on linux! Granted, there are bots everywhere, but jeeze so few real users would be impacted, we could paint with a big brush and just solve X% of the problem right now.
I don't feel this is fearmongering; I think its a legitimate concern. The reason being: the PAT attestation from the issuer is pretty black-boxed, technically. Apple just asserts to Cloudflare: we think this device isn't a bot. On Apple's end, there will be lots of device & geolocation heuristics, they probably check "hey you signed in with Apple? good, botscore *= 0.9", etc. Cloudflare (or any intermediary/site operator) needs to trust that the validator is doing a "good job" of checking for bots, and the statistical qualifications for "doing a good job" are only going to increase over time. Apple has tons of heuristics they can use; Microsoft probably has a bit less; Linux has very few, by design. Its very easy to imagine a situation where linux's solution to this isn't recognized by Large Service Providers as "up to snuff"; and they get cut off.
But, ok, lets actually fearmonger. There's been some rumblings in the anti-cheat community that one of the signals some anti-cheat systems use is: the amount of money you spend on their in-game store. Its probably a good signal: cheaters tend to cycle through accounts as they get banned, they'd lose all their cool stuff if an account is banned, so they spend less money. Imagine a reality where Apple uses spending heuristics as a signal to determine if a device is real; your account is on the verge of suspicion, and the final data point against you is that you aren't subscribed to Apple One, because per our statistical research 98% of confirmed bots aren't subscribed to Apple One.
Look: some bank and education sites have been doing a small time idiotic version of this, often via useragent parsing. It doesn't really work all that well; but it should signal that the desire for something more functional exists. This solution won't actually be more functional, in a form which allows legitimate non-Big-Tech-Users equitable access. Thus, it'll trend, slowly, toward "trusting the vendor", which also won't work all that well, but no one cares because "at least we're doing something". I think, at the end of the day, the entire domain of "bot mitigation" is misguided; they can't be stopped, you install captchas and you get warehouses of people paid pennies solving them, or you get better AI to solve them. You trust the device, attackers buy the devices. Its a treadmill that literally only serves to reduce access to computing services for minorities (differently-abled people who can't pass captchas, linux users, etc).
We need to, as an industry, take a giant step back and reframe this from "how do we stop bots" to "how do we live with bots".
...and if you are someone who actually works on this stuff for a living, perhaps you should reconsider and think about what your work is driving society towards. This isn't just the "keeping users addicted" work that often gets discussed here on HN; it's far far worse.
Apple and Google charging 30% for all business instructions running on their hardware and being 99% of the market is also unfree. (No, Google's unfriendly process and scare tactics around APKs do not make that platform open and broadly accessible.)
Maybe Google, gateway to the entire web, shouldn't be allowed to make a browser and set the rules in a way that favors itself at the expense of the rest of us.
Computing shouldn't be a set of four or five companies that control the entire platform and have everyone else beholden to their rules and taxation. We need to make these giants smaller and remove their grip on computing so that competition can flourish.
Every startup founder and free software advocate should want this. Everyone protective of their privacy should worry that in the future only Big Brother signed (and tracked) browsers will work.
We're experts and have a say in how our industry functions. Call your representatives and teach them about this problem. Tell them how it's going to cause everything to stagnate and suck and prevent new businesses from arising.
Also, vote. Big Tech has grown enough power to be a government itself, but not one we voted for. Hopefully the ones we can vote for, can at least restrain some of that power.
By Linux, the OP was simply referring to an OS that is solely under the control of the user and gives the user full freedom. Not the locked-down versions of Linux like Android and no doubt whatever else will appear as the "officially sanctioned Linux(es)."
Your fake drivers license isn’t snitching on you when the bouncer looks at it.
It’s only snitching if you’re trying to get away with something and pretend you’re running unmodified Windows/macOS when you’re not.
What sort of snitching?
Running Linux? Rooted Android? Anything else weird? If this gets popular, you might not be able to access most of the web with it, at least not without constantly filling in CAPTCHAs.
Cloudflare does not know what device you're using.
Besides it's an open standard. https://www.ietf.org/archive/id/draft-private-access-tokens-...
The actual workflow here is an open standard, but I'm having a hard time understanding why sites won't just require that you use Mediators/Issuers that were written by one of the big tech companies and then block everything else.
Not saying that will absolutely be the case, I'm just saying that I don't understand why I shouldn't be concerned -- I've seen these exact arguments get used in the past for systems that absolutely shut out independent browser/hardware/OS/ROM development.
I mean... CAPTCHA is effectively an Open Standard, even if it doesn't have a draft that I'm aware of. But that doesn't mean much when so much of how it works is rolled up in an unstandardized implementation and when website operators are ultimately in charge of choosing CAPTCHA providers, not users. Is the same thing going to happen with PATs?
If it is what you meant, I don't quite know how to respond except that I disagree vehemently.
You'll note that no-one from Mozilla has their name attached to that RFC draft.
Its not relevant because: Apple devices only run "trusted" code. Cloudflare then says "hey, any PAT which originates from Apple is probably generated by trusted code, we know what heuristics we use, we trust those heuristics, lets approve it."
But extend the same theory to more open devices. There are two outcomes:
(1) Services trust the PAT itself. This would be pointless from a bot-mitigation angle, because anyone could just mint and submit a PAT. But, it would be "open".
(2) Services trust the PAT issuer. Implicitly, this means, they trust all the code which the issuer uses to generate the PAT, probably using device heuristics of some kind.
The second outcome is far more likely. Conways Law: these systems were built by teams with one goal: to stop bots. (1) wouldn't actually stop bots. Similar to SSL certs: We don't just trust any valid SSL cert; we only trust ones that are issued by known trustworthy third parties.
But there's no way to trust code running on open systems. They can't trust the heuristics, because they could be faked. Even if a solution evolved which looked like "the linux kernel has this built in" or "canonical distributes a known good binary which contains good heuristics algorithms", it doesn't matter, because there's no way to cryptographically validate it. We can modify the code, run whatever, and suddenly that Issuer (Linux, Canonical, whoever) can't be trusted. Only issuers which operate their heuristics in locked-down environments can be trusted.
Also similar to SSL certs: they'll say "we'll always have captchas as a fallback"; "you don't need HTTPS, HTTP is always there". It's bullshit scrying from people who can't think more than one quarter ahead. In the case of SSL, its reasonable bullshit, there's strong arguments for it, it made deploying websites slightly harder but not insurmountably. PAT is another step beyond that, and I don't see a situation where this technology is both Useful and Open. I really hope we decide to sacrifice its usefulness; but the Powers That Be probably won't.
I for one am certainly saying that this is bad if it means that you need approval from one of Apple, Google, or Microsoft to participate in financial transactions. That would be a giant step backward compared to the status quo.
> company's solution to a problem caused by the same company
The “company” needed a solution to a problem caused by bad actors in the network.
Whether or not a company’s solution causes someone else to have a problem is a different matter.
Like DDoS, bots become the problem of all users when they slip through.
Fair enough to disagree with the mitigation strategy. I suppose most web services wouldn't care to differentiate you from a bot.
It instantly narrows your identity down to an owner of a particular batch of hardware and will force you to have an OS owned by one of the big 3 tech companies installed (which will spy on you constantly) to function.
The same goes for privacy. Attestation requires hardware batches be made large enough to provide some privacy protection, and different people seem to interpret the implications of that differently. A couple of people have pointed out, this effectively means you can't revoke a single attestation token without blocking every single person from that hardware batch. It also means that using attestation signals still reveals what batch you're a part of, which is absolutely a fingerprint vector.
There's a lot of conflicting information I see about how this is supposed to be helpful, and I'm constantly wondering if I don't understand it, but I'm also constantly wondering if the push for attestation isn't fueled by a little bit of wishful thinking and willful ignorance of the downsides.
In this very comment section I'm seeing people claim that this could be easily implemented in Linux, but... how? If the point of an attestation token is that it verifies a human is involved in the process, then it kind seems like it defeats the point to have it in an Open Source implementation that any ROM/OS can be built around. Most other systems I've seen that work this way in the wild don't work in community-run codebases; indie browsers don't get to implement EME in a way that lets them stream Netflix shows.
Maybe I'm misunderstanding something, but I've never had attestation explained to me in a way where the claims around what it's capable of and why it can't be abused actually make sense. It feels like a really flawed DRM scheme -- okay, I'll log into a website and the website author will know I'm on an unmodified iOS client from one of X batches of iPhones. That's DRM, how is it not DRM? It's a system for verifying that a local client is unmodified, based on the faulty premise that bots/automation can't be used to send the request from the client.
It's middlemen rolling out DRM (which has always been about control and killing competition and not about piracy) to permanently force themselves into every online transaction or interaction.
With a side benefit of completely eliminating any sort of privacy you might still have.
It's fueled by corporate authoritarianism, nothing more and nothing less.
IF you've noticed that if you are signed into google with an account in good standing (or even if you're not signed in, but have spent time being signed in) the captcha is pre-filled.
this is the same thing, but with apple. they will be harvesting your every web move. That's great assuming they actively invest and look after privacy. However given their history, that can't be assumed.
What I'm against is the breathless "APPLE SAVES THE OPEN INTERNET WITH PRIVACY" which has never been the case. Apple is riddled with trackers, and collects huge amounts of private information.
The difference between apple and google is that apple has a better PR system.
The amount and quality of data that Google and Apple collect are vastly different. This has been measured and confirmed on several occasions.
The differences are far different than PR spin.
You owning a Mac does not mean your comment isn’t FUD.
It is.
I mean the metadata kinda indicates otherwise: https://developer.apple.com/news/?id=huqjyh7k
I have three issues with that design: 1) privacy, 2) Apple banning your iCloud account for some reason without recourse, 3) and this further gives BigTech more control to wall off part of the web.
And it looks like they went and did this with CloudFlare and Fastly without requests for comments like most web standards?
https://www.ietf.org/archive/id/draft-private-access-tokens-...
They're bad enough for able-bodied users, and I can only imagine how annoying and discriminatory they are for users of assistive technologies. There really ought to be some sort of law to get rid of them, or at least significantly restrict their use.
Google does the same to block scrapping of search results.
Google, of all companies, should be capable of coming up with a better way to detect and prevent web scraping. Broadly-targeted CAPTCHAs are extremely lazy.
The thing that strikes me is that they bring up Privacy Pass (https://privacypass.github.io/) as related work, and while I've never been completely, totally on board with Privacy Pass, I also feel like the reliance on hardware/OS verification checks here is strictly worse than what Privacy Pass is offering?
Forget the user experience for a second and privacy implications (Privacy Pass at least seems to be mostly hardware independent and can work on any device/browser that implements an extension, which has comparatively fewer negative implications for a competitive indie web ecosystem) -- speaking purely as a website operator, hardware checks seem strictly easier to game than a CAPTCHA. So even if I'm not a user trying to use a device that doesn't have these attestation schemes built into it, if I'm an operator wouldn't I prefer to have a protection that's harder to bypass by a click farm?
I'm not saying I would be completely thrilled with Privacy Pass either (CAPTCHAs in general are accessibility problems). But should I be thrilled about a version of Privacy Pass that (as far as I can tell) inherently must be more invasive to my hardware, and that isn't guaranteed to work on every device/browser that I use?
hCaptcha.com has a "privacy pass", where if you create a user at hCaptcha.com, you can get passes to bypass the captcha itself (because you've already verified through other methods). This is not often used, because guess what? Not many people were bothered by captchas enough to create a user, because no one wants to create another user and be tracked (via privacy pass, across captcha-protected sites) through their user. This was mostly used by disabled users who couldn't pass hCaptcha's offerings.
Personally, I'm not interested in "logging in" or passing my "realness" via API from my device(s), as that's just another token to track an individual and their behaviors. Which is also why I haven't created any user for privacy pass myself, and would generally recommend that you not do so in any Apple, Google, etc., related system (not even hCaptcha, unless you're disabled and can't do the captcha itself).
I don't know what hCaptcha is doing nowadays.
But unless you're disabled, I wouldn't sign up or agree to pass this information from Apple, Google, etc.
I'm sure it's definitely just to weed out those bad actors and their dirty DDoS ways though.
ReCaptcha already doesn't require entering a captcha in 90% of the cases. Adding a man-in-the-middle to avoid captchas is not the solution, improving captcha technology is.
ReCaptcha requires neither of these privacy-invading or gatekeeping things.
If this becomes standard, this is the end of the open web as we know it, because you will only be able to access many websites if you are using an approved, locked-down browser in a locked-down computing environment, backed by a tech giant who can provide the attestation and ID service.
If you care at all about the open web, this must be resisted at all costs.