Apple Could Kill CAPTCHAs with Private Access Tokens(appleinsider.com)
appleinsider.com
Apple Could Kill CAPTCHAs with Private Access Tokens
https://appleinsider.com/articles/22/06/14/how-apple-could-kill-captchas-with-private-access-tokens
120 comments
People were predicting such things would happen ever since the start of all the "trusted computing" shit back in the late 90s/early 2000s. Stallman's "Right to Read" was only the beginning. Remote attestation is the enemy of our freedom. We must fight this "technical authoritarianism" as much as we can.
...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.
...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.
Maybe the other way to fight this is by breaking up the monopolies vying for it. They shouldn't have this level of unilateral control in the first place.
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.
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.
Call your representatives and teach them about this problem.
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.
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.
[deleted]
Yeah, in some areas we're basically already there with Android's attestation (or something like that). Most finance-related apps simply don't work with custom ROMs anymore. Some checks can be bypassed with Magisk, others are virtually impossible
THis "you're approved by one of the big 5" before you get to use the web is just fucking awful. Logins (or security tokens) should be kept to a minimum for things like banks, customized web apps, etc where they have an actual -need- to know who you are and you have actively agreed to it. Forcing cloudflare to verify every web site access would be awful via tokenization. Maybe on the upside it would result in more content available via a more distributed web.
I don't want my bank making rules about what OS and web browser I can use for online banking. I'd like them to use TOTP though.
Many banks used to, at least in the US. Had to run some version of internet explorer. Sometimes a specific version or you could not access the bank website. It's creeping back now as more sites are not working correctly with Firefox for me.
Even at Apple, plenty of developers run on Linux. I would be surprised - after resisting to use OSX - that they will be ok to create a system that will prevent them from using linux
Apple has 12k+ engineers, I doubt they won’t find a few thousands to just do it.
With macOS running on Unix, Microsoft releasing WSL, and Google running Android on Linux... not to mention all the data centers they all have that rely on Linux... I can't imagine they would just collectively "forget" about Linux and screw over the communities they all rely on. From a consumer perspective, it's not a big group, but it's a really important group.
It's worth remembering that the Linux kernel is already infected with things like secure boot.
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)."
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)."
[deleted]
This isn't DRM. A party is verifying your actions as legitimate and not a bot. There is nothing stopping the Linux/BSD community from implementing something similar.
https://www.ietf.org/archive/id/draft-private-access-tokens-...
https://www.ietf.org/archive/id/draft-private-access-tokens-...
If it's only technical, then bots can implement it too.
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.
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.
You're out of your fucking mind if you actually think that.
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.
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.
[deleted]
Did you mean to say this?
> 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.
> 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.
It won't stop bots. Have you seen phone farms [1]? Attackers are getting clever (and lazy maybe). They use physical devices. Old ones are cheap, can have broken screens etc. And you can't lock out users with old devices.
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&...
2. https://en.wikipedia.org/wiki/Small-world_experiment
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&...
2. https://en.wikipedia.org/wiki/Small-world_experiment
This is known as https://en.wikipedia.org/wiki/Web_of_trust
I'm sorry for not inventing a different name but what I have in mind is very different. Main difference is that it queries recursively automatically, and it is weighted. Weights are very important. This is old version where I had put my ideas [1]. I have no chance touching it anytime soon - it requires focus and solving hard problems (some of which sound lame like usability and bootstrapping). I write these comments hoping that maybe somebody decides to try it. Chances of bootstrapping it are slim (but could start in some niches), but the payout (I mean positive change in society, there's no money to be made here) is huge enough that I think it's worth trying.
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.
1. http://comboy.pl/wot.html
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.
1. http://comboy.pl/wot.html
Presumably there would be some sort of trust anchor that would need to be run by the alternative community and which would need to be accepted by others, which means it would have to play by their rules whatever their rules are. This still forces an authority on users of alternative platforms.
I really disagree, and you don't have to look further than the video game community to see where this is headed. Most triple-A video games explicitly ban Linux devices from accessing their services, under the excuse of anti-cheat. They're extremely strict; a game could work totally fine under Proton, but still be dysfunctional because if (os == "linux"). Even Windows VMs are oftentimes banned.
"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".
"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".
> There is nothing stopping the Linux/BSD community from implementing something similar.
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?
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?
That would still introduce an asymmetric work aspect (presuming that Pat's are cheap to verify, difficult to mint, and single use only). Many bot-based attacks in the wild today rely on the fact that it is much cheaper for a client to send a request than it is for a server to handle one. A well-designed Pat system could flip that imbalance.
[deleted]
[deleted]
[deleted]
Just like they were able to with Encrypted Media Extensions, right?
Thanks for providing the original RFC, though reading it I find it to be much worse than I thought because of its ability to detect actions per client.
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.
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.
> 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.
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.
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.
Terrible idea. No matter how much time it would save me, I do not want “my” computer doing any work designed to snitch on me.
It already does. That's what browser profiling is for.
So lets start by NOT adding more things that snitch.
Reframe it and it’s not so bad. It’s presenting a tamper evident ID card to a website that’s minted by the manufacturer of your device.
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.
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.
Reframe it again, I'm running a modified OS that is free of spyware and respects my freedom, but the corporate bastards don't want that.
Will you forego acquiring an Apple if you don't want it, or acquiring a smartphone at all if they all have it? If not, well, your voice doesn't matter. Sorry. Not trying to be depressing or annoying, just that your/our levers aren't big enough to shift things.
>The server doesn't know anything about the device or the person accessing it.
What sort of snitching?
What sort of snitching?
It snitches regarding what kind of device and operating system you're using. It currently seems to be limited to Apple devices, but this is the sort of thing I could see Microsoft and Google going for. Put another way, if everyone running unmodified corporate operating systems proves it as a matter of course, it effectively snitches on anyone who isn't.
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.
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.
PATs are not an Apple technology, they just implemented it first. Once this is on Android, Windows, Mac, Linux and iOS the only thing they will be able to determine is that you're using a computer.
None of this is true.
Cloudflare does not know what device you're using.
Cloudflare does not know what device you're using.
Cloudflare knows you're using a device that supports this feature. If a majority of internet users are eventually using devices that support it, some sites will probably deny service to those that do not just as some Android apps refuse to run on devices not using a factory OS.
Which is a good thing.
Besides it's an open standard. https://www.ietf.org/archive/id/draft-private-access-tokens-...
Besides it's an open standard. https://www.ietf.org/archive/id/draft-private-access-tokens-...
Remember back to EME, an Open standard doesn't necessarily mean Open implementation.
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?
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?
Apple attests that some iOS device is being operated by a real human. They accomplish this attestation through device heuristics; I believe the plan is, to run these heuristics on-device, then communicate them to Apple for signing/validation/whatever. Or, maybe it all happens on device, its not really relevant.
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.
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.
You appear to be writing that it would be a good thing if browsing most of the web was not possible from Linux. If that's not what you meant, please clarify.
If it is what you meant, I don't quite know how to respond except that I disagree vehemently.
If it is what you meant, I don't quite know how to respond except that I disagree vehemently.
It's a good thing only if you are Apple, Google or Microsoft, or a shareholder of them.
You'll note that no-one from Mozilla has their name attached to that RFC draft.
You'll note that no-one from Mozilla has their name attached to that RFC draft.
So I can just write a linux kernel module to assert I'm a Real Person™ and all will be fine?
OP is mad into scalping.
I doubt anyone is saying that this is bad if you're using a web app for financial transactions like buying tickets. This proposal however is to basically force everyone on the web to use an ID that can be traced back to them for all usage. This is great for advertisers and even better for government spying
> I doubt anyone is saying that this is bad if you're using a web app for financial transactions like buying tickets.
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.
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.
This protocol is designed to not send any data that can be used to identify you directly or fingerprint your identity.
It's designed to gatekeep access to the Internet. This is a company's solution to a problem caused by the same company and we are all forced to participate.
As far as I understand, the problem is caused by massive networks of malware ridden computers and bots.
The problem is caused by other peoples reactions to computers and bots. Bots are the servers problem, not mine, my machine should not be involved in solving it. Same reason I block ad/tracking scripts, it's no my responsibility to ensure other peoples advertising contracts are upheld, that's their problem, if they can't solve it without involving me, too bad.
That seems like saying that DDoS is the server's problem and that it doesn't affect you and that the issue is the server's response to bad actors, not the bad actors.
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.
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.
Sure but, what about for instance bots on Twitter created to push all kind of agendas into our own country?
My comment was to point out what I think was an incorrect characterization in these words:
> 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.
> 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.
That's so wrong it's barely worth responding to.
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.
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.
Whenever I look into attestation, there seems to be an equal mix of people saying that it will kill CAPTCHAs and an equal mix of people saying, "you know that it's not hard to automate a Yubikey, right?"
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.
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.
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.
It's fueled by corporate authoritarianism, nothing more and nothing less.
It's fueled by corporate authoritarianism, nothing more and nothing less.
The answer to that is easy. Any claims about stopping bots or preserving privacy are bald faced lies.
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 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.
Its basically the same as "sign in with google"
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.
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.
Did you read how this works? They authenticate a token. Apple doesn’t know what domain or url you’re going to.
> Apple doesn’t know what domain or url you’re going to.
I mean the metadata kinda indicates otherwise: https://developer.apple.com/news/?id=huqjyh7k
I mean the metadata kinda indicates otherwise: https://developer.apple.com/news/?id=huqjyh7k
But then He couldn’t spread His anti Apple FUD, and that’s no fun
Its not anti apple. I have an iPhone and mac.
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.
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.
This is objectively not true whatsoever.
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.
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.
Also google sells it to everyone. Apple uses it for their company sure, but they aren't selling it. The day they do I'm selling all my apple stuff, just like I got off the google train.
Why does this need iCloud and not just use the client?
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?
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?
There's a (draft) RFC with contributions from four companies. It's not, despite what this dumpster fire of an article implies, some kind of Apple-specific innovation.
https://www.ietf.org/archive/id/draft-private-access-tokens-...
https://www.ietf.org/archive/id/draft-private-access-tokens-...
Yet Fasty and Cloudlfare are using this while it’s still in Draft?
This is related to the Privacy Pass protocol that Cloudflare has been working on for a while. Their current implementation uses a browser extension. https://blog.cloudflare.com/privacy-pass-v3/
CAPTCHAs are really getting out of control. While some uses are understandable (want to edit this wiki? prove you're not a robot!), they seem to be popping up on even the most mundane of websites (want to see the results of this google search? prove you're not a robot!)
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.
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.
Cloudflare uses captchas for proving you’re not a bot under certain circumstances. Like when someone from your IP trips DDoS protection.
Google does the same to block scrapping of search results.
Google does the same to block scrapping of search results.
> "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.
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.
Don't they only do that if you've clicked the box for it though? I don't blame this on cloudflare any more than I would blame them for allowing open text ftp connections. This is on the websites who are the end point.
Somewhat ironically Google doesn't use recaptcha on the Google Account signup page, it's some other internal captcha (the warped-text kinda).
I'm nervous about how these technologies impact public computing like public libraries or other shared networks. We still occasionally run into sites flagging our network as spam and requiring additional attestation (something your average public library user can't really understand or even sometimes cope with) and further barriers make it harder to work around at point of need and more challenging for administrators. I completely understand how this happens, but it's also another way we widen the digital gap with good intentions.
How would this work if it's open source hardware? Then it's not bound to any authority that can prove that you're a human with a real device.
I'm looking through the official draft for this more (https://www.ietf.org/archive/id/draft-private-access-tokens-...)
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?
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?
Used to work for hCaptcha.com, my thoughts:
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.
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.
So we'll get robots operating iPhones.
Click farms with humans operating fleets of phones has been a thing for years. I’m sure industrial automation will happen to that industry at some point.
lol old iPhones will hold their value for much longer.
This is not killing CAPTCHA at all. This is instead using DRM to silently run a CAPTCHA in the background all the time ("[...] can recognize if the client device is following typical user patterns [...]").
Is it just me, or is this a move towards pay per visit in the future?
If I could trade making micro payments per visit and have NO advertising and NO tracking and NO cookie config popups, I would take that deal. When I click on some obscure site to read one story, a site I may never visit again, I would much rather toss a tip in the jar to support their efforts than to fill out forms and be prompted to turn off an ad blocker, etc....
In reality, there would be no such trade. You would have micro payments per visit AND advertising AND tracking AND tracking popups. Because they can and what are you going to do about it anyway?
True enough. Perhaps a standard or a reg could require no ads or tracking if a site accepts micro payments. Maybe the browser could enforce the reg or standard.
See https://blog.cloudflare.com/eliminating-captchas-on-iphones-... for some details.
and purely by coincidence, it provides a solution to the ever-increasing use of VPNs for sidestepping geofenced services like TV Streaming.
I'm sure it's definitely just to weed out those bad actors and their dirty DDoS ways though.
I'm sure it's definitely just to weed out those bad actors and their dirty DDoS ways though.
The only thing this will kill is privacy, as Apple and the rest of the tech gang are only battling over the right to own your identity online, not over your dignity - the basis of privacy.
I don't know why I've never been curious about what CAPTCHA stands for, but now that I know I regret those many years of ignorance.
Yay, let's put even greater parts of the www behind doors controlled by a handful of megacorps.
Captcha is an integral part of Google's business, I don't see them giving it up easily. They get free labor from significant chunk of the world's population with all that image tagging.
Well at least I wont have to spend hours trying to pass Google's I'm not a Robot test in an attempt to get a passport and out of the UK.
I'm all for anything that gets rid of those annoying "Click all of the..." CAPTCHAs.
Even if it means you have to register with one of the big 5 tech companies to verify who you are for every single internet connection so they can track your internet behavior and history?
It will kill captchas the same way it killed non USB-C USB ports when apple forced them on Mac.
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 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 is already a man-in-the-middle for any non-Google property. This is just switching to another “man” that is less annoying.
No, it is fundamentally different, because firstly, it requires the client device to be locked down enough - and to monitor your activity enough - that it can provide attestation that the user is human, and secondly, it ties that attestation to an Apple ID so Apple knows exactly which Apple ID accessed which website at what time.
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.
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.
It is not true that Apple will know what web sites were visited. The article states “the device manufacturer or attester only knows the minimum amount of device data required for attestation. It doesn't know the destination URL or the user's IP address.”
That's assuming that the issuer, mediator, and destination are all distinct entities who don't communicate with each other except as described in the protocol. If they are the same entity, or they collaborate, all those nice privacy guarantees disappear. And the destination—not the user—decides which issuers & mediators they accept.
It's adding rather than switching. I doubt Apple has services present on most website, but Google definitely does even without ReCaptcha, such as Analytics, Adsence, etc.
>It's adding rather than switching. I doubt Google has a device present in most peoples' pockets, but Apple definitely does even without iCaptcha, such as the iPhone 13, iPad Air 5th gen, etc.
Hum, Android has a 71.45% market share for mobile devices, versus only 27.83% for iOS...
[deleted]
And so it begins, The start of another arms race.
AOL was ahead of its time, I see.
Coming from Apple it only could be bad. One more thing to keep people glued to Apple products.
It's not "from Apple". They just appear to be the first to actually implement the proposal from IETF.
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.