Re: supercookies

On May 19, 2014 7:15 AM, "elijah" <elijah@riseup.net> wrote:
>
> The current draft notes that key material could be used as a
> supercookie, but does not offer any approaches to mitigate this problem.
>

These are out of date concerns from earlier drafts, where key storage was
an intrinsic part of the API and multi-origin key sharing was a possibility.

The remaining suggestions are thus unnecessary.

Sorry that an incomplete draft was sent to LC.

> 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 couple 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?
>
> -elijah
>
>