Re: PSA: publishing new WD of Clipboard API and events on Sept 18

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

Received on Monday, 15 September 2014 22:15:36 UTC