Yikes. Anyone trying to do any web scraping will be totally hosed. If this happens it could be one of the most bold gains by site-operators over web users ever.
The existence of the TPM is a terrifying capability that puts computing deliberately beyond the reach of the operator. It hands the computer over to coders. So many upsides for regular use, but what a sad sad sad forever ratcheting of the War on General Purpose Computing it enables.
I'm fairly convinced we should make TPMs that have a special lower rung security offering that lets them see and do whatever. Make the user have to boot a custom USB stick to access it, sign in in blood, whatever weird scheme you please, but locking users out of their own secrets absolutely seems malicious & malignant; this proposal is a great example of what a blood curdling infernal machine TPM can be.
Isn't there software emulated TPMs already? I think all this is doing is ensuring the cookies stay on the device that has the key (assuming a proper hardware TPM). If a site requires this, the underlying algorithm could be implemented in software using shared keys and it wouldn't do much to prevent scraping.
(a) an automated UA doing the scraping can implement DBSC.
(b) a semi-automated UA can implement DBSC, and allow the user to step in to interact when needed.
This proposal suggests that TPM is the right/correct way to implement it, but unlike Passkeys, doesn't seem to specify any way to mandate TPM via attestation.
IMHO, I think that if DBSC can be confined to short lifetimes (24h or a browser process lifetime), it's a net gain in security, without changing the privacy threat.
This proposal isn't meant for preventing scraping, and isn't useful in any way for that. The only TPM operations that it makes available are:
1. Create a new keypair on the client, and register the public key with the server.
2. Respond to a challenge from the server by signing a challenge string with the private key.
There's no attestation that the original key was created on a TPM. Nor is there any kind of support for non-signing TPM operations (like increment-only counters). Anyone trying to use this API for scraping prevention would be badly disappointed, they'd just find that a scraper could mint an unlimited number of keys very cheaply, and that those keys would be indistinfuishable from those created by real users.
5 comments
[ 3.2 ms ] story [ 27.8 ms ] threadI'm fairly convinced we should make TPMs that have a special lower rung security offering that lets them see and do whatever. Make the user have to boot a custom USB stick to access it, sign in in blood, whatever weird scheme you please, but locking users out of their own secrets absolutely seems malicious & malignant; this proposal is a great example of what a blood curdling infernal machine TPM can be.
(a) an automated UA doing the scraping can implement DBSC.
(b) a semi-automated UA can implement DBSC, and allow the user to step in to interact when needed.
This proposal suggests that TPM is the right/correct way to implement it, but unlike Passkeys, doesn't seem to specify any way to mandate TPM via attestation.
IMHO, I think that if DBSC can be confined to short lifetimes (24h or a browser process lifetime), it's a net gain in security, without changing the privacy threat.
1. Create a new keypair on the client, and register the public key with the server.
2. Respond to a challenge from the server by signing a challenge string with the private key.
There's no attestation that the original key was created on a TPM. Nor is there any kind of support for non-signing TPM operations (like increment-only counters). Anyone trying to use this API for scraping prevention would be badly disappointed, they'd just find that a scraper could mint an unlimited number of keys very cheaply, and that those keys would be indistinfuishable from those created by real users.