On Mon, Sep 15, 2014 at 5:26 PM, Hallvord R. M. Steen
<hst...@mozilla.com> 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.

Reply via email to