On Mon, Sep 15, 2014 at 5:26 PM, Hallvord R. M. Steen <[email protected]> wrote: >>> <http://dev.w3.org/2006/webapi/clipops/clipops.html> >> Please forgive my ignorance. But I don't see a requirement that data >> egressed from the local machine to be protected with SSL/TLS. > > I can certainly add a note *encouraging* encryption, but it's not something > we can "require" in a meaningful sense - it's several layers away from the > parts of the process the spec is about. > >> Also, if the origin uses a secure scheme like HTTPS, then shouldn't >> the script's also require the same? That is, shouldn't the spec avoid >> fetching from https://www.example.com and then shipping clipboard data >> off to http://www.ads.com? > > As an end user, I would go absolutely nuts if a computer was behaving > inconsistently in apparently random ways like that. I'm pretty sure that no > matter how security conscious you are, you probably copy and paste data > between HTTPS and HTTP pages several times every month.. Having the browser > block that because it pretends to know that some random data is important > when I know it's not doesn't sound user friendly at all.
Well, usually the attacker has to work for a downgrade attack :) Wouldn't it be better for the user if a consistent policy were applied across the board when handling their data? If one leg of the connection uses HTTPS, then all legs must use it. If I were a user and visited a site with HTTPS, then that's what I would expect when moving my data around. Proper handling of the data shifts the onus to the webmaster and developers, but webmasters and developers are in a better position to manage these sorts of things. Its not really a burden on the technology folks - they just have to pay attention to the details. I don't think that's asking too much. And the clipboard standard is new, so its a great opportunity to avoid the patching used to address gaps. If the gaps are addressed early, then they won't be an issue in the future.
