W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2012

Re: W3C Web Crypto API reaches FPWD - put it on your radar!

From: Christine Runnegar <runnegar@isoc.org>
Date: Tue, 2 Oct 2012 10:03:39 +0200
Cc: public-privacy@w3.org
Message-Id: <61894E59-A2B2-4B65-9EAB-A87D68A434E9@isoc.org>
To: Harry Halpin <hhalpin@w3.org>
Thank you Harry.

We will put this on the agenda for our next PING call - 18 October 2012 at the usual time.

Please let us know when you are ready to have a teleconference with PING concerning these issues.

Kind regards,
Christine and Tara

On Sep 24, 2012, at 11:23 PM, Harry Halpin wrote:

> The WebCrypto API has a number of privacy-related functionality that should be reviewed by the W3C Privacy IG, although a full detailed review will likely require the WD to be more mature  [1]. 
> 
> A number of privacy concerns have already come up on the mailing list as regards the current draft. Off the top of my head, one can also do possible finger-printing of browser types in the current spec by running through the operations allowed by the API in a given browser/JS environment, but that would likely only manage to figure out what browser (and possibly device, if the API wires into device or OS-specific crypto) the user is running by indirectly by seeing what crypto algorithms are supported. Another more important potential red-flag is the ability to import/export keys. Although the API obeys basic constraints like same-origin policy, one can imagine keys being created to identify browsers in the same manner of cookies. 
> 
> The real open issues are still not yet fully discussed by the WG and thus not in the FPWD, but will appear in later WDs. So while we'd like this to be on your radar, we think a thorough privacy review would be more useful in about 6 months. However, we wanted this to be on your agenda. Some of the possible features (tracked in our issue-tracker [2]:)
> 
> 1) How to do key identification (i.e. some want "Globally Unique IDs") (ISSUE-25)
> 2) User interaction with key (and possibly certificate) selection, given the usual issues that it is very difficult to standardize UI/UX in browsers (ISSUE-9)
> 3) Pressure to go beyond same-origin policy for keys for some use-cases, such as using pre-provisioned keys and keys previously generated and imported from the larger non-browser context. (ISSUE-26)
> 4) Requiring CSP or not (ISSUE-21)
> 
> 
> As for more possible future features that have not yet received open issues that will also have an impact on privacy, see the charter [3]. In particular secondary features:
> 
> "Secondary API Features that may be in scope are: control of TLS session login/logout, derivation of keys from TLS sessions, a simplified data protection function, multiple key containers, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption."
> 
> So I imagine simplified data protection, interactions with multiple key containers (including those of the API), digital signatures, and certificate support would all have privacy implications re fingerprinting, in particular any user interaction required around keys/certificates. 
> 
> We'd love a written commentary on the public-webcrypto-comments@w3.org and hopefully we can do a telecon with you at one of your future meetings in about 6 months. 
> 
>   cheers,
>      harry
> 
> 
> [1]http://www.w3.org/TR/WebCryptoAPI/
> [2]http://www.w3.org/2012/webcrypto/track/issues
> [3]http://www.w3.org/2011/11/webcryptography-charter.html
Received on Tuesday, 2 October 2012 08:04:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 October 2012 08:04:09 GMT