W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25799] New: supercookies

From: <bugzilla@jessica.w3.org>
Date: Mon, 19 May 2014 08:19:51 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25799-7213@http.www.w3.org/Bugs/Public/>

            Bug ID: 25799
           Summary: supercookies
           Product: Web Cryptography
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: elijah@riseup.net
                CC: public-webcrypto@w3.org

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?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 19 May 2014 08:19:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC