zlacker

[return to "Apple Could Kill CAPTCHAs with Private Access Tokens"]
1. stevew+e3[view] [source] 2022-06-15 11:19:37
>>matthe+(OP)
I posted a comment a few days ago here (https://news.ycombinator.com/item?id=31670689#31671551) about my views about this “feature”, which I’ll repeat verbatim here. Needless to say, it’s something I don’t like.

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.

◧◩
2. nojito+a7[view] [source] 2022-06-15 11:55:06
>>stevew+e3
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-...

◧◩◪
3. 015a+9M[view] [source] 2022-06-15 15:13:55
>>nojito+a7
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".

[go to top]