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

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" <noloader@gmail.com> wrote:

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