- From: Nikos Mavrogiannopoulos <nikos.mavrogiannopoulos@esat.kuleuven.be>
- Date: Fri, 24 May 2013 15:45:55 +0200
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: <public-webcrypto-comments@w3.org>, danny de cock <danny.decock@esat.kuleuven.be>, Filipe Beato <filipe.beato@esat.kuleuven.be>
On 2013-05-23 14:11, Anders Rundgren wrote: >> A solution to that approach would be to offer high level API to >> handle >> the common of the expected use cases of the low level API, and that >> high >> level API will use standardized protocols, implemented in the >> browser. >> For example: >> * An API to upload an encrypted and authenticated file >> -> the browser uses the standardized procedure and the user is >> notified by the browser that his file will be encrypted prior to >> uploading > What you are indirectly saying is that there are cryptographic > methods > that can guide an average "neticen". Although I can't speak for the > WG (since I'm not a member), I don't think this is the general > feeling. > You essentially have to trust a web-site for "Doing the right > thing(tm)". > The specific use-case suffers from the fact that a user cannot know > how the encrypted document is dealt with _after_ it has been > received. I don't quite agree. I don't trust any website to implement its own secure communications protocol. For that I use TLS. I trust the site I visit for a specific purpose (e.g. to sell books), not for designing secure protocols. The current API cannot be used as is by an average web designer since it requires him to become a secure protocol designer and handle low level cryptographic aspects (which even cryptographers may get wrong). I'd really suggest the WG to think about the target-audience of this framework and offer an appropriate toolbox to them. regards, Nikos
Received on Friday, 24 May 2013 13:46:31 UTC