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

On Mon, Sep 15, 2014 at 9:06 PM, Daniel Cheng <dcheng@google.com> wrote:
> Again, what are you trying to defend against? Why is it beneficial to try to
> block this?
At minimum, its information leakage. If the data has value such that
at least one leg requires HTTPS, then traversing some legs with HTTP
is a security defect. That would be a CWE-311
(http://cwe.mitre.org/data/definitions/311.html).

The benefits are customary confidentiality and privacy protections. In
addition, unauthorized parties will be restrained from injecting into
the clipboard.

In a post-Snowden era, we have a good idea of how wide spread some of
these problems are. So addressing the problem is consistent with web
design principals. In particular, "3.1. Solve Real Problems".

I also believe it violates at least two web design principals. First
is "3.2. Priority of Constituencies" [1], and second is "3.3. Secure
By Design" [2]. It violates the first design principal because the
user asked for a specific feature, but it was not delivered. It
violates the second feature because its not secure by design.

To volley it back over the net, can you think of users or
organizations who classify their data as valuable, and then say its OK
to send it send it over HTTP? (I often use the contrapositive to
envision something in a different view).

And to be clear: I'm not begging for HTTPS everywhere (though I would
like to :). I ask if HTTPS is selected for on some legs, then it
should be used on all legs. Don't mix and match because a third party
cares less about the data than the user or organization.

> Again, what are you trying to defend against? Why is it beneficial to try to
> block this?

And to address the potential block: please don't do that because of
me. Move the security concerns along with the feature set.

[0] http://www.w3.org/TR/html-design-principles/#solve-real-problems
[1] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
[2] http://www.w3.org/TR/html-design-principles/#secure-by-design

> On Sep 15, 2014 3:18 PM, "Jeffrey Walton" <noloader@gmail.com> wrote:
>>
>> 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 Tuesday, 16 September 2014 12:23:49 UTC