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

[Arthur Barstow]

On 9/15/14 4:27 AM, Arthur Barstow wrote:
If anyone has any comments or concerns about this plan, please let us 
know before the 18th.


Although there were some technical comments in reply to this PSA (and 
that's great, please keep the comments coming!), as we previously 
agreed, those comments did not block this proposal and a new WD was 
published today:


  

Thanks Hallvord!

-AB

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

[James M. Greene]

Regardless of protocol, a site that contains sensitive data should be
implemented such that it doesn't use this API nor include any unverified
3rd party libraries/extension that may. They should also only utilize a
feature such as this in obvious ways (i.e. by having the user click on a
"copy" button).

Beyond that, what you're suggesting renders a convenient feature
enhancement completely unusable for the majority of users and use cases. :-\

Sincerely,
James Greene
Sent from my [smart?]phone
On Sep 16, 2014 7:25 AM, "Jeffrey Walton"  wrote:

> On Mon, Sep 15, 2014 at 9:06 PM, Daniel Cheng  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"  wrote:
> >>
> >> On Mon, Sep 15, 2014 at 5:26 PM, Hallvord R. M. Steen
> >>  wrote:
> >> >>>   
> >> >> 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.
>
>

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

[Jeffrey Walton]

On Mon, Sep 15, 2014 at 9:06 PM, Daniel Cheng  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"  wrote:
>>
>> On Mon, Sep 15, 2014 at 5:26 PM, Hallvord R. M. Steen
>>  wrote:
>> >>>   
>> >> 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.

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

[Hallvord R. M. Steen]

> Wouldn't it be better for the user if a consistent policy were applied
> across the board when handling their data?

Not if the average user can't understand the policy that is applied, and the 
way it applies to what they are trying to achieve.

> 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.

But the policy would cause problems for the end users, only indirectly for 
webmasters and developers. We've been there, done that with for example 
draconian markup parsing - even though you would expect parsing failures to 
"shift the onus to" webmasters, and that they would give fixing a broken site 
really high priority, it turned out that the draconian parsing first and 
foremostly caused end users problems, and that the market pressure forced 
browsers to relax their draconian tendencies and find ways to parse broken 
markup reliably instead.

Lesson learned: draconian policies that cause problems for the end user AND 
require webmaster action to fix it, are NOT viable.

Webmasters simply won't start serving their site over https to enable users to 
paste data into it. They will simply say "use a different browser", and any 
browser trying to implement the proposed policy would loose users who perceived 
the policy as a bug.

> If I were a user and
> visited a site with HTTPS, then that's what I would expect when moving my 
> data around.

And I'm sure you can agree that very few users would share your expectation? 
Also, you make the fundamental assumption that *all* data on a HTTPS site is 
valuable and private. As a user, I'd like to be fully in control of what data I 
think is sensitive and what data I'll paste freely. For example, if I want to 
quote Techdirt.com articles on a personal blog right now, run a private 
Wordpress install on http, and use a browser implementing your suggested 
policy, I would have to retype every quote I want to use..


> And the clipboard standard is new, so its a great opportunity to avoid
> the patching used to address gaps.

The standard may be new, but the feature is not :) End users have been copying 
and pasting data for years and years, and are used to doing so.

-Hallvord

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

[Daniel Cheng]

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

Daniel
On Sep 15, 2014 3:18 PM, "Jeffrey Walton"  wrote:

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

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

[Jeffrey Walton]

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

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

[Hallvord R. M. Steen]

>>   
> 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.
-Hallvord

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

[Daniel Cheng]

I'm not quite sure what you're asking for here. The clipboard is system
global. Why should the spec disallow a user from copying from
https://www.example.com and pasting in http://www.ads.com?

Daniel

On Mon, Sep 15, 2014 at 11:19 AM, Jeffrey Walton  wrote:

> On Mon, Sep 15, 2014 at 4:27 AM, Arthur Barstow 
> wrote:
> > This is a heads-up Hallvord intends to publish a WD of "Clipboard API and
> > events" and he is targeting a publication date of September 18. The ED
> >
> >   
> >
> > If anyone has any comments or concerns about this plan, please let us
> know
> > before the 18th.
> Please forgive my ignorance. But I don't see a requirement that data
> egressed from the local machine to be protected with SSL/TLS.
>
> 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?
>
> Is these intended?
>
>

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

[Jeffrey Walton]

On Mon, Sep 15, 2014 at 4:27 AM, Arthur Barstow  wrote:
> This is a heads-up Hallvord intends to publish a WD of "Clipboard API and
> events" and he is targeting a publication date of September 18. The ED
>
>   
>
> If anyone has any comments or concerns about this plan, please let us know
> before the 18th.
Please forgive my ignorance. But I don't see a requirement that data
egressed from the local machine to be protected with SSL/TLS.

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?

Is these intended?

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

[Arthur Barstow]

This is a heads-up Hallvord intends to publish a WD of "Clipboard API 
and events" and he is targeting a publication date of September 18. The ED


  

If anyone has any comments or concerns about this plan, please let us 
know before the 18th.


-Thanks, AB