This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current draft notes that key material could be used as a supercookie, but does not offer any approaches to mitigate this problem. In the current environment, where every browser is attempting to distinguish itself by advertising its privacy bona fides, it seems highly ill advised to create yet another method of tracking users. Keys as cookies could be far more pernicious than other identifiers: users are less likely to clear their keys, since doing so can potentially lock the user out of access to important information. Some smart developer will hit upon the idea of giving users a UI where they can individually remove keys. Such a UI will quickly become entirely useless, much like the UI we have now that allows a user to individually delete cookies among a sea of thousands. The result will be to undermine the purpose of WebCrypto: rather than seeing WebCrypto as a boon to privacy, people will see it as a threat to privacy. Browsers will be asked to allow the option to disable WebCrypto keys and privacy conscious users will be encouraged to turn off key storage. There are a few possible options to mitigate the supercookie threat posed by WebCrypto: (1) remove 'extractable' flag for all keys. This is undesirable, since public keys are not that useful unless extracted. (2) prohibit key extraction from javascript run in an iframe. This is probably a good idea anyway, because it is hard to see any legitimate reason to allow key extraction in an iframe, but third-party tracking will soon be moving to server side APIs anyway. (3) allow extraction only of public keys, and require a user prompt when generating a key pair. This would limit tracking to public keys, allowing sites to freely use the other types of keys without worry of privacy issues. If the user must OK the creation of a public/private key pair, sites are unlikely to use this as a tracking mechanism since it would be prohibitively onerous if every website asked you to generate a key pair. Remember the 1990s?
On second thought, a tracker could simply import a key and then encrypt a challenge or generate a signing key and then sign a challenge. I suppose the only thing that can mitigate against keys as supercookies would be to require the user's consent before any key is saved in long term storage.
(In reply to elijah from comment #1) > On second thought, a tracker could simply import a key and then encrypt a > challenge or generate a signing key and then sign a challenge. I suppose the > only thing that can mitigate against keys as supercookies would be to > require the user's consent before any key is saved in long term storage. As mentioned on the mailing list, the concerns about Supercookies come from an earlier version of the draft that incorporated both key storage as well as inter-origin key sharing. As the WebCrypto API does not provide for any key storage, nor does it allow for inter-origin sharing, these concerns about supercookies (and extractability, which is entirely separate) are no longer relevant for the current API. These are only concerns when incorporating things like Key Discovery, which is a separate spec that is not part of the core Web Crypto API, and for which those security considerations should apply there.
https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b