Re: [Clipboard] Web API for clipboard changes.

[James M. Greene]

Please share it with the rest of the group. Thanks!

Sincerely,
   James M. Greene
On Jun 15, 2015 5:48 PM, "Kelvin Poon"  wrote:

> Thank you for your interest Arthur.
> I have drafted up a more detailed implementation doc and shared it with
> you and Hallvord.
>
> Please feel free to take a look and comment.
>
> Kelvin
>
> On Thu, Jun 11, 2015 at 3:57 AM Arthur Barstow 
> wrote:
>
>> On 6/2/15 4:05 PM, Kelvin Poon wrote:
>> >
>> > Hi public-webapps
>> >
>> >
>> > We are exploring a new web API for content to be notified of clipboard
>> > changes and would like to discuss it here.
>> >
>> >
>> > The problem
>> >
>> > For certain classes of web apps, it is necessary to determine when new
>> > clipboard contents have been set, e.g. in order to fetch and display
>> > them, to update context menus, or synchronize the content with another
>> > application or device.
>> >
>> >
>> > The problem is that the web standard currently provides no explicit
>> > notifications when new content is copied from another application to
>> > the clipboard.  As a result, these web apps typically re-fetch the
>> > clipboard every time they regain focus, and only act on the contents
>> > if they have changed since last time (e.g. passing it to a remote
>> > system, updating context menu, etc).  This polling mechanism is
>> > generally inefficient, especially when the clipboard contains a large
>> > image file.
>> >
>> >
>> > We currently have interest from Citrix and Chrome Remote Experience
>> > teams in improving Chrome's clipboard support.
>> >
>> >
>> > The proposal
>> >
>> > Google propose to update the W3C Clipboard API and events
>> > specification <http://www.w3.org/TR/clipboard-apis/>with an
>> > onClipboardChangedevent on the document object.  The user agent should
>> > only signal the event if
>> >
>> > 1. a frame re-gains focus AND
>> >
>> > 2. the clipboard has changed since it last had focus.
>> >
>> >
>> > In addition, the user agent should not signal clipboard change events
>> > while a frame has focus.  This will relieve the web app from the
>> > burden of filtering out notifications in response to clipboard changes
>> > generated by the app itself.
>> >
>> >
>> > We think this new API will avoid fetching large clipboard content
>> > repeatedly and unnecessarily for clipboard changes.
>> >
>> > Does the community think this API would be useful?
>> >
>>
>> Hallvord, All - do you have any feedback for Kevlin?
>>
>> > We can go into more details and work on a detailed design together if
>> > the community is interested.
>> >
>>
>> Kelvin, if there is a resource that includes details, please let us
>> know. (I suppose another option is a Pull Request but it might make
>> sense to first wait for some feedback from the group.)
>>
>> -Thanks, ArtB
>>
>>
>>
>>

Re: Clipboard API: remove dangerous formats from mandatory data types

[James M. Greene]

On Jun 11, 2015 2:02 PM, "Elliott Sprehn"  wrote:
>
> I don't think the clipboard should forbid inserting image data, there's
so many ways to compromise desktop software. ex. pasting text/html into
Mail.app might even do it. This API shouldn't be trying to prevent that.

+1, thank you!

~~James

Re: Clipboard API: remove dangerous formats from mandatory data types

[James M. Greene]

I can make a plugins for legitimate text/image editors that would override
default behavior for paste operations to instead execute arbitrary
processes (e.g. recursively delete the entire working directory) unless the
parent application is well sandboxed.

Unless the vendors that establish a lightning fast sanity check for a
subset of binary data types, I really don't believe this is a positive
change.

While we're on it, how about the good ole harbinger of the unknown:
"application/octet-stream"? Where do we reasonably draw the line? Will that
MIME type be blocked? Doesn't seem like there would be any reasonable way
to scrub it.

Sincerely,
   James M. Greene
On Jun 11, 2015 3:14 AM, "Florian Bösch"  wrote:

> Oh, also while you're on crippling things, please also exclude copying any
> text that contains "http://:"; cause that borks skype.
>

Re: [clipboard API] platform integration stuff - in spec or out of scope?

[James M. Greene]

Any follow-up on this?

Sincerely,
James Greene


On Fri, Feb 13, 2015 at 1:46 PM, Ben Peters 
wrote:

>  I agree with James. The reason to have it in the list is to have a
> normalized name for it (instead of worrying about platform specific
> clipboard types). As long as the browser isn’t required to handle it or
> prevented from handling it, it can included to make it both readable and
> writable by script. I haven’t seen vender pushback, but I haven’t been
> involved for as long as some.
>
>
>
> *From:* James M. Greene [mailto:james.m.gre...@gmail.com]
> *Sent:* Wednesday, February 11, 2015 6:59 PM
> *To:* Hallvord Steen
> *Cc:* public-webapps; Paul Libbrecht
> *Subject:* Re: [clipboard API] platform integration stuff - in spec or
> out of scope?
>
>
>
> Allow me to clarify my position.
>
> My expectation is NOT for the browsers' default action on "copy"/"cut" to
> convert HTML into RTF. I do not see any such implication of that behavior
> in the spec language [1].
>
> Rather, I just want to ensure that browsers will honor/maintain that
> clipboard format/segment if it is set during a custom "copy" event handler
> using the `event.clipboardData.setData` method. The current language of the
> spec [2] leaves the possibility open for an implementor to choose to
> ignore/discard any data formats that are not on the mandatory data types
> list [1], and I find that worrysome.
>
> Is the problem that spec may be implying that the browser must know what
> to do with the data when PASTING from a clipboard segment associated with a
> mandatory data type? I could see that as more of a sticking point for
> implementors... but again, I really just want to ensure that the
> "application/rtf" clipboard segment is simply left intact bi-directionally.
> If the spec were to be updated to generally ensure that type of
> maintained/untouched transfer for data types that are NOT on the mandatory
> data types list (i.e. "custom data types"), then I would be fine leaving
> "application/rtf" OFF the mandatory data types list.
>
> Can we get some clarification on the vendor pushback reasoning in this
> regard?
>
> Thanks!
>
> [1]:
> http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types
> [2]:
> http://dev.w3.org/2006/webapi/clipops/clipops.html#writing-contents-to-the-clipboard
>
> Sincerely,
>James M. Greene
>
> On Feb 11, 2015 3:15 PM, "Hallvord Reiar Michaelsen Steen" <
> hst...@mozilla.com> wrote:
>
>   On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene <
> james.m.gre...@gmail.com> wrote:
>
>  We never really came to a decision on if RTF ("application/rtf") should
> be listed as a mandatory MIME type but the general consensus seemed to be
> leaning toward "yes":
>
>
> https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html
>
>
> There was some pushback from vendors - and I think their arguments were
> reasonable. Why should a web browser have to include code to generate RTF
> documents to write them to the clipboard? It's going to be a non-trivial
> amount of code, it will be rarely executed and could easily come with
> exploitable security vulnerabilities. It only makes sense to require this
> if there is a significant amount of software out there that supports
> pasting RTF data but does *NOT* support pasting HTML data - so that if we
> mandate support for writing HTML to the clipboard but leave RTF out, many
> users will have problems pasting text with formatting into another
> application. How many applications would have this issue on the various
> platforms? How widely are they used? Would users even expect to be able to
> preserve formatting on pasting into or copying from these applications?
>
> A reply from you in the earlier discussion of these questions is here:
> https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html
>
>
> -Hallvord, wearing an invisible clipboard spec editor hat
>
>

Re: Clipboard API: remove dangerous formats from mandatory data types

[James M. Greene]

Why we would exclude any data formats that the browsers currently already
support copying today? Definitely not a fan of that idea offhand.

Is it not possible for a malicious image to be displayed (or display as
broken) in Chrome and allow a user to choose "Copy Image" from that
element's context menu?

If not, how is that protection/prevention achieved today? Could the same
process to applied to outgoing copy/cut operations and incoming paste
operations?

Sincerely,
   James M. Greene
On Jun 9, 2015 2:19 PM, "Daniel Cheng"  wrote:

> I'm not against considering more formats to be dangerous. =)
>
> In particular:
> JS: I'm not support what context we'd ever want to support this, since we
> go out of our way to try prevent XSS in HTML pastes.
> XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
> bugs on a semi-regular basis.
>
> Daniel
>
> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay  wrote:
>
>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>> > Currently, the Clipboard API [1] mandates support for a number of
>> formats. Unfortunately, we do not believe it is possible to safely support
>> writing a
>> > number of formats to the clipboard:
>> > - image/png
>> > - image/jpg, image/jpeg
>> > - image/gif
>> >
>> > If these types are supported, malicious web content can trivially write
>> a malformed GIF/JPG/PNG to the clipboard and trigger code execution when
>> > pasting in a program with a vulnerable image decoder. This provides a
>> trivial way to bypass the sandbox that web content is usually in.
>> >
>> > Given this, I'd like to propose that we remove the above formats from
>> the list of mandatory data types, and avoid adding support for any more
>> complex
>> > formats.
>> >
>> > Daniel
>> >
>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>
>>
>> Why would text/html, application/xhtml+xml, image/svg+xml,
>> application/xml, text/xml, application/javascript
>> be any safer if the program which the data is pasted to has vulnerable
>> html/xml/js parsing?
>>
>>
>> -Olli
>>
>>

Re: [clipboard] Feature detect Clipboard API support?

[James M. Greene]

I haven't tested this out to see if it dispatches all the correct events in
order to be spec-compliant but Chromium just landed programmatic
copy-and-cut [with restrictions that require that there is an active,
expanded Selection/Range in the Document]:

http://updates.html5rocks.com/2015/04/cut-and-copy-commands

They used `Document#queryCommandSupported` and
`Document#queryCommandEnabled` for feature detection -- the latter
requiring that there is an active, expanded Selection/Range in the Document
in order to get a positive (`true`) indicator].

For better or worse, the time for spec changes may be fleeting

Sincerely,
   James M. Greene
On Apr 21, 2015 7:53 PM, "Ryan Seddon"  wrote:

> If we did that, authors could not use synthetic clipboard events for
>> anything - right? I'm assuming that authors are going to find use cases for
>> it - for example a "cloud clipboard" implementation may want to fire actual
>> paste events so that data from the "cloud" is processed like data from the
>> local clipboard.
>>  -Hallvord
>>
>
> Yep thats a very valid point I wouldn't want to stop people being able to
> trigger synthetic events, not sure of an alternative.
>
>

Re: [clipboard] Add RTF to the "mandatory data types" list?

[James M. Greene]

Hallvord --

That behavior is really all I wanted, i.e. "don't let the browser
discard/ignore valid RTF clipboard data".

I would also echo Paul's thoughts: this sounds good but is there any
OS/browser-level sanitization process necessary?  I would be curious to
hear from Ben if Microsoft already has such things in place for IE.

Sincerely,
James Greene


On Mon, Apr 20, 2015 at 3:26 PM, Paul Libbrecht  wrote:

>
>
> On 20/04/15 22:11, Hallvord Reiar Michaelsen Steen wrote:
> > Would it be a possible compromise to let a script describe data as
> > RTF, and then put said data on the clipboard with the OS's correct RTF
> > data type labelling? And vice versa, if the script asks for RTF give
> > it any RTF contents from the clipboard as raw (binary) data? Products
> > and environments that desperately need clipboard RTF support could
> > then implement their own parsers and converters in JS and write/read
> > RTF - the rest of us avoid some browser bloat.. Is this level of
> > "support" reasonable?
> Is there any security consideration that we should be aware of here?
> (e.g. embedded content)
> If not, then I think there's no issue accepting this way.
> If yes, then I guess there should be some sanitization process happening
> since otherwise untrusted web-pages could insert in the clipboard
> RTF-content that would reference external stuff that would be fetched
> when pasted in.
>
> paul
>
>

Re: [clipboard] Feature detect Clipboard API support?

[James M. Greene]

Patrick Kettner offered up another idea for this as well on a related
Modernizr issue [1]:

Given the following
>
>1. we must not change the user's clipboard
>2. we must use a synthetic event
>3. synthetic event be able to actually work (clipboard poisoning, etc)
>
> is there any chance that a synthetic clipboard copy/paste could throw a
> unique err[or] that we could try/catch around and sniff for?
>


Ryan Seddon affirmed this idea in his response [2]:

That's a great idea, if we try to poison the clipboard with a synthetic
> copy event it should probably throw an UNSTRUSTED error or something
> along those lines.
>



What do others think of that approach?

I'm fine with it, and I'm guessing it would be easier for both browser
vendors and consumers to implement than other previously discussed
approaches.


[1]: https://github.com/Modernizr/Modernizr/pull/659#issuecomment-94606647
[2]: https://github.com/Modernizr/Modernizr/pull/659#issuecomment-94626893

Sincerely,
James Greene


On Mon, Apr 20, 2015 at 5:09 PM, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> On Wed, Feb 11, 2015 at 7:21 PM, James M. Greene  > wrote:
>
>> The current spec still leaves me a bit unclear about if implementors must
>> include the ability to feature detect Clipboard API support, which I think
>> is a critical requirement.
>>
>
> I agree it's a very important requirement. And it sucks that we're still
> struggling to find a good story..
> Here's one (semi-random) idea: the interaction with APIs like
> queryCommandEnabled() isn't really fleshed out yet. What if we mandate in
> the spec that calling queryCommandEnabled must fire the corresponding
> onbefore* event synchronously, and also recommend that this is only
> implemented when the support for the other parts is ready to go?
>
> The feature detection might then look a bit like this:
>
> var modernClipboardImplementation = false;
> document.onbeforecut = function(e){
> e.preventDefault();
> }
> try{
> if(document.queryCommandEnabled('cut')){
> modernClipboardImplementation = true;
> }
> }catch(e){
> modernClipboardImplementation = false; // yeah, likely not
> necessary..
> }
>
> In other words: if the onbeforecut fires and you can prevent the default
> action to tell the script using queryCommandEnabled() that cut is enabled,
> we assume the implementation is top-notch. It probably includes
> click-to-copy too.. ;)
>
> Maybe not super-elegant, but not too convoluted either - and no
> implementation I've tested so far does it.
> -Hallvord
>
>

Re: [clipboard API] platform integration stuff - in spec or out of scope?

[James M. Greene]

Allow me to clarify my position.

My expectation is NOT for the browsers' default action on "copy"/"cut" to
convert HTML into RTF. I do not see any such implication of that behavior
in the spec language [1].

Rather, I just want to ensure that browsers will honor/maintain that
clipboard format/segment if it is set during a custom "copy" event handler
using the `event.clipboardData.setData` method. The current language of the
spec [2] leaves the possibility open for an implementor to choose to
ignore/discard any data formats that are not on the mandatory data types
list [1], and I find that worrysome.

Is the problem that spec may be implying that the browser must know what to
do with the data when PASTING from a clipboard segment associated with a
mandatory data type? I could see that as more of a sticking point for
implementors... but again, I really just want to ensure that the
"application/rtf" clipboard segment is simply left intact bi-directionally.
If the spec were to be updated to generally ensure that type of
maintained/untouched transfer for data types that are NOT on the mandatory
data types list (i.e. "custom data types"), then I would be fine leaving
"application/rtf" OFF the mandatory data types list.

Can we get some clarification on the vendor pushback reasoning in this
regard?

Thanks!

[1]: http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types
[2]:
http://dev.w3.org/2006/webapi/clipops/clipops.html#writing-contents-to-the-clipboard

Sincerely,
   James M. Greene
On Feb 11, 2015 3:15 PM, "Hallvord Reiar Michaelsen Steen" <
hst...@mozilla.com> wrote:

> On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene  > wrote:
>
>> We never really came to a decision on if RTF ("application/rtf") should
>> be listed as a mandatory MIME type but the general consensus seemed to be
>> leaning toward "yes":
>>
>> https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html
>>
>
> There was some pushback from vendors - and I think their arguments were
> reasonable. Why should a web browser have to include code to generate RTF
> documents to write them to the clipboard? It's going to be a non-trivial
> amount of code, it will be rarely executed and could easily come with
> exploitable security vulnerabilities. It only makes sense to require this
> if there is a significant amount of software out there that supports
> pasting RTF data but does *NOT* support pasting HTML data - so that if we
> mandate support for writing HTML to the clipboard but leave RTF out, many
> users will have problems pasting text with formatting into another
> application. How many applications would have this issue on the various
> platforms? How widely are they used? Would users even expect to be able to
> preserve formatting on pasting into or copying from these applications?
>
> A reply from you in the earlier discussion of these questions is here:
> https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html
>
> -Hallvord, wearing an invisible clipboard spec editor hat
>

[clipboard] Feature detect Clipboard API support?

[James M. Greene]

The current spec still leaves me a bit unclear about if implementors must
include the ability to feature detect Clipboard API support, which I think
is a critical requirement.

In particular, I *need* to be able to detect support for the Clipboard API
(click-to-copy support, in particular) in advance and without the user's
interaction in order to know if I need to load a Flash fallback or not.

If this is even *possible* based on the current spec, the only way I can
see that might make that possible is if executing `
document.execCommand("copy")` synthetically (without user interaction) MUST
still fire the `beforecopy`/`copy` events [but obviously not execute the
associated default action since it must not be authorized to inject into
the clipboard].  However, I don't feel that the spec defines any clear
stance on that.

Example detection attempt (more verbose version on JSBin [1]):

```js
var execResult,
isSupported = false;

if (typeof window.ClipboardEvent !== "undefined" && window.ClipboardEvent) {
  var checkSupport = function(e) {
isSupported = !!e && e.type === "copy" && !!e.clipboardData && e
instanceof window.ClipboardEvent;
document.removeEventListener("copy", checkSupport, false);
  };
  document.addEventListener("copy", checkSupport, false);

  try {
execResult = document.execCommand("copy");
  }
  catch (e) {
execResult = e;
  }

  document.removeEventListener("copy", checkSupport, false);

  // Should I care about the `execResult` value for feature testing?
  // I don't think so.

  if (!isSupported) {
// Fallback to Flash clipboard usage
  }
}
```


This currently yields poor results, as well as arguably false positives for
`window.ClipboardEvent` (conforming to an earlier version of the spec,
perhaps?) in Firefox 22+ (22-35, currently) and pre-Blink Opera (<15).

It also causes security dialogs to popup in IE9-11 when invoking `
document.execCommand("copy")` if you do not first verify that
`window.ClipboardEvent` is present. That is obviously harmful to user
experience.

Can we agree upon some consistent feature detection technique to add to the
spec that can be guaranteed to yield correct results?  I would love it if
it were as simple as verifying that `window.ClipboardEvent` existed but, as
I mentioned, that is already yielding false positives today.



[1]: http://jsbin.com/davoxa/edit?html,js,output



Sincerely,
James Greene

Re: [clipboard API] platform integration stuff - in spec or out of scope?

[James M. Greene]

We never really came to a decision on if RTF ("application/rtf") should be
listed as a mandatory MIME type but the general consensus seemed to be
leaning toward "yes":
   https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html

Sincerely,
James Greene


On Sat, Jan 31, 2015 at 5:31 PM, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

>
> I don't know what these "map to" on platforms that do not use MIME types
> to describe clipboard contents. Should this information be dug up and
> included?
>
>
>> First request: can we add the three MathML media-types?
>>
>
> I know you've brought this up before, I haven't done anything about it and
> it's partly because I'm not actually sure myself what an implementation
> would have to do to "support" a data type..
>
>
>> I think I could help dig the names out by looking at the following
>> documents:
>>
>>
> That would be absolutely terrific Paul - maybe make a wiki page or
> etherpad somewhere? It would really help me - coming more from the
> JavaScript side of things I can figure out and describe how all the
> JavaScript stuff works, but it's much harder to determine how the platform
> side needs to be specified.
>
>
>> -
>> http://developer.apple.com/mac/library/documentation/FileManagement/Conceptual/understanding_utis/
>> -
>> https://msdn.microsoft.com/en-us/library/system.windows.dataformats.aspx
>>
>> Also, some specs and media-type-registration RFCs indicate the names in
>> the native formats.
>> I think this would be the right place to hunt too  (I know that MathML
>> and SVG do).
>> Probably it'll never be complete (e.g. I do not think
>> application/octet-stream can have a name on clipboards).
>>
>
> So..  If the most important platforms do not have a clipboard format or
> description for a specific MIME type, does that mean telling
> implementations to "support" it is meaningless? Sort of seems like it..
> -Hallvord
>

Re: do not deprecate synchronous XMLHttpRequest

[James M. Greene]

Here is an additional past discussion of this topic:
   https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0232.html

Sincerely,
James Greene


On Fri, Feb 6, 2015 at 9:54 AM, Florian Bösch  wrote:

> I had an Android device, but now I have an iPhone. In addition to the
>> popup problem, and the fake "X" on ads, the iPhone browsers (Safari,
>> Chrome, Opera) will start to show a site, then they will lock up for 10-30
>> seconds before finally becoming responsive.
>
>
> Via. Ask Slashdot:
> http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser
>
> Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 /
>> SeaMonkey 2.27), synchronous requests on the main thread have been
>> deprecated due to the negative effects to the user experience.
>
>
>
> Via
> https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
>
> Heads up! The XMLHttpRequest2 spec was recently changed to prohibit
>> sending a synchronous request whenxhr.responseType is set. The idea behind
>> the change is to help mitigate further usage of synchronous xhrs wherever
>> possible.
>
>
> Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
>
>
>

Re: [Custom]: Rename "createdCallback" to "created"

[James M. Greene]

I admittedly haven't been following the Custom Elements spec, so forgive if
my point of view has already been discussed and rejected but... I
definitely agree that this naming seems very inconsistent with the rest of
the Web Platform.

I would have expected to have these handlers configured via
`addEventListener` calls.  For example:

```js

var XFooPrototype = Object.create(HTMLElement.prototype);

XFooPrototype.addEventListener("create", function( /* event */ ) {
  this.textContent = "I'm an x-foo!";

  // OR:
  // event.target.textContent = "I'm an x-foo!";
};

XFooPrototype.foo = function() {
  console.log("foo() called");
};

var XFoo = document.registerElement('x-foo', {
  prototype: XFooPrototype
});

```

This only thing about this approach that is *slightly* inconsistent with
the rest of the Web Platform is assuming that the `this` context within the
handler will be set to the element, rather than being forced to grab it via
`event.target`.

Even `XFooPrototype.oncreate = fn;` would be more consistent than
`XFooPrototype.create`, `XFooPrototype.created`, or
`XFooPrototype.createdCallback`.

The same thoughts also hold true for the other Custom Element lifecycle
hooks as well, of course.

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: [clipboard] Semi-Trusted Events Alternative

[James M. Greene]

We did some user research on this feature when we were building our most
recent flagship product a few years back. Our users' reactions to a sane
site enhancing their clipboard data were unanimously delighted rather than
upset/offended/horrified.

As Hallvord said, sites have been able to do this for 5+ years using Flash
and it hasn't caused any issues/uproar that I've heard of since they fixed
the security model to Flash 10 to match what has been proposed here: the
clipboard injection is only allowed in direct response to a user's
click/keyboard action. (In Flash < 10, the Flash developer could inject
custom contents into the user's clipboard at any time... bad idea.)

Sincerely,
James Greene
Sent from my [smart?]phone
On Sep 16, 2014 4:30 AM, "Hallvord R. M. Steen"  wrote:

> > a page can wipe out my
> > entire clipboard history if I move my mouse over it.
>
> Not quite :) Check the list of events - mousemove isn't included:
> http://www.w3.org/TR/html5/browsers.html#allowed-to-show-a-popup
>
> I agree that all the concerns you listed are real. I recall an article
> I've seen about a court case against a teacher because a school computer
> was infected with malware and happened to display some porn during this
> teacher's class. I think this was in the U.S. or UK, so even the countries
> we tend to think have the most developed legal systems have problems with
> basic tech literacy! It's a sad fact that the web is implemented in such an
> imperfect world..and we should definitely keep that in mind.
>
> However, I hope that checking the list of events will help - the policy
> has more limitations than you seem to think. I still think that the popup
> precedent gives us reason for some optimism - it also shows that if an
> aspect of web technology is abused and causes nuisance, browser vendors
> will step up to implement limitations. I think in the long run, this is
> also the case with clipboard APIs - we're spec'ing something trying to
> balance the usability and trust issues, if we get it right we've enabled
> some more functionality for web apps without too much nuisance and abuse -
> if we get it wrong, we probably have to revisit this and lock it down with
> site whitelists and such. Keeping in mind that Flash has had similar
> policies for a while and "some site put weird stuff on my clipboard" hasn't
> been a frequent complaint so far (and AFAIK hasn't been needed as defence
> in court yet), I think and hope we're shipping a reasonable and balanced
> policy here.
> -Hallvord
>

Re: =[xhr]

[James M. Greene]

I just figured handling the Java2Script (Java to JavaScript) conversion
into an ES6 module format would be substantially easier as the syntax is
much more similar to Java's own than, say, AMD.

But yes, it does add another layer of indirection via transpilation.


Sincerely,
James Greene



On Fri, Sep 5, 2014 at 7:47 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  FWIW I do not think ES6 modules are a good solution for your problem.
> Since they are not in browsers, you would effectively be adding a layer of
> indirection (the “transpilation” James discusses) that serves no purpose
> besides to beta-test a future platform feature for us. There are much more
> straightforward ways of solving your problem, i.e. I see no reason to go
> Java -> JavaScript that doesn’t work in browsers -> JavaScript that works
> in browsers. Just do Java -> JavaScript that works in browsers.
>
>
>
> *From:* James M. Greene [mailto:james.m.gre...@gmail.com]
> *Sent:* Friday, September 5, 2014 05:09
> *To:* Robert Hanson
> *Cc:* David Rajchenbach-Teller; public-webapps; Greeves, Nick; Olli Pettay
> *Subject:* Re: =[xhr]
>
>
>
> ES6 is short for ECMAScript, 6th Edition, which is the next version of the
> standard specification that underlies the JavaScript programming language.
>
>
>
> All modern browsers currently support ES5 (ECMAScript, 5th Edition) and
> some parts of ES6. IE7-8 supported ES3 (ES4 was rejected, so supporting ES3
> was really only being 1 version behind at the time).
>
>
>
> In ES6, there is [finally] a syntax introduced for importing and exporting
> "modules" (libraries, etc.).  For some quick examples, you can peek at the 
> ECMAScript
> wiki <http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples>.
>
>
>
> A transpiler is a tool that can take code written in one version of the
> language syntax and convert it to another [older] version of that language.
>  In the case of ES6, you'd want to look into using es6-module-transpiler
> <http://esnext.github.io/es6-module-transpiler/> to convert ES6-style
> imports/exports into an AMD (asynchronous module definition)
> <https://github.com/amdjs/amdjs-api/blob/master/AMD.md> format.
>
>
>
> That is, of course, assuming that your Java2Script translation could be
> updated to output ES6 module syntax.
>
>
>  Sincerely,
> James Greene
>
>
>
> On Thu, Sep 4, 2014 at 4:55 PM, Robert Hanson  wrote:
>
>  Can you send me some reference links? "transpiler"? "ES6 Module"? I
> realize that what I am doing is pretty wild -- direct implementation of
> Java in JavaScript -- but it is working so fantastically. Truly a dream
> come true from a code management point of view. You should check it out.
>
> As far as I can see, what I would need if I did NOT implement async
> throughout Jmol is a suspendable JavaScript thread, as in Java. Is that on
> the horizon?
>
> Bob Hanson
>
> ​
>
>
>

Re: =[xhr]

[James M. Greene]

ES6 is short for ECMAScript, 6th Edition, which is the next version of the
standard specification that underlies the JavaScript programming language.

All modern browsers currently support ES5 (ECMAScript, 5th Edition) and
some parts of ES6. IE7-8 supported ES3 (ES4 was rejected, so supporting ES3
was really only being 1 version behind at the time).

In ES6, there is [finally] a syntax introduced for importing and exporting
"modules" (libraries, etc.).  For some quick examples, you can peek at
the ECMAScript
wiki .

A transpiler is a tool that can take code written in one version of the
language syntax and convert it to another [older] version of that language.
 In the case of ES6, you'd want to look into using es6-module-transpiler
 to convert ES6-style
imports/exports into an AMD (asynchronous module definition)
 format.

That is, of course, assuming that your Java2Script translation could be
updated to output ES6 module syntax.

Sincerely,
James Greene



On Thu, Sep 4, 2014 at 4:55 PM, Robert Hanson  wrote:

> Can you send me some reference links? "transpiler"? "ES6 Module"? I
> realize that what I am doing is pretty wild -- direct implementation of
> Java in JavaScript -- but it is working so fantastically. Truly a dream
> come true from a code management point of view. You should check it out.
>
> As far as I can see, what I would need if I did NOT implement async
> throughout Jmol is a suspendable JavaScript thread, as in Java. Is that on
> the horizon?
>
> Bob Hanson
>
> ​
>

Re: =[xhr]

[James M. Greene]

True that ES6 Modules are not quite ready yet but the existing transpilers
for it also convert to asynchronously loading AMD syntax, a la RequireJS.

Still seems a perfect fit for this use case, and Robert may not be aware
that such functionality is forthcoming to solve his issue (and obviously
hopefully is delivered long before sync XHRs become volatile).

Sincerely,
James Greene
Sent from my [smart?]phone
On Sep 4, 2014 7:42 AM, "David Rajchenbach-Teller" 
wrote:

> On 04/09/14 14:31, James M. Greene wrote:
> >> The sole reason for these sync
> > XHRs, if you recall the OP, is to pull in libraries that are only
> >> referenced deep in a call stack, so as to avoid having to include
> >> *all* the libraries in the initial download.
> >
> > If that is true, wouldn't it better for him to switch over to ES6 Module
> > imports and an appropriate transpiler, for now?
> >
> > I'm a bit confused as to why it doesn't appear this idea was ever
> mentioned.
> >
>
> I believe it's simply because ES6 Modules are not fully implemented in
> browsers yet. But yes, with the timescale discussed, I agree that ES6
> Modules are certainly the best long-term choice for this specific use case.
>
> Cheers,
>  David
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
>
>

Re: =[xhr]

[James M. Greene]

> The sole reason for these sync
XHRs, if you recall the OP, is to pull in libraries that are only
> referenced deep in a call stack, so as to avoid having to include
> *all* the libraries in the initial download.

If that is true, wouldn't it better for him to switch over to ES6 Module
imports and an appropriate transpiler, for now?

I'm a bit confused as to why it doesn't appear this idea was ever mentioned.

Sincerely,
James Greene
Sent from my [smart?]phone
On Sep 4, 2014 7:19 AM, "Robert Hanson"  wrote:

> SO glad to hear that. I expect to have a fully asynchronous version of
> JSmol available for testing soon. It will require some retooling of
> sophisticated sites, but nothing that a typical JavaScript developer of
> pages utilizing JSmol cannot handle.
>
> I still have issues with the language in the w3c spec, but I am much
> relieved.
>
> Bob Hanson
>
>
> ​
>

Re: [clipboard] Add RTF to the "mandatory data types" list?

[James M. Greene]

On Aug 20, 2014 4:19 AM, "Daniel Cheng"  wrote:
>
> On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen  wrote:
>
>> I don't have "input" as such, but I have a few questions:
>> Is there any widely used software that writes RTF data to the system
clipboard but *not* HTML?
>
> I'm curious about the answer to this as well. I haven't seen any examples
raised outside of TextEdit. While TextEdit is widely deployed, is it
actually widely used as a rich text editor? I know I just use it as the
occasional scratch pad. If there aren't any good examples, I don't think it
makes sense to make RTF a mandatory data type. If there are, I still think
it'd make more sense to push those editors towards supporting HTML rather
than trying to make browsers support RTF.

Another likely "scratch pad" editor that only supports RTF is Windows
WordPad.

A real and [surprisingly still] popular editor that only accepts RTF pastes
-- at least as of its fairly recent X5 version (now on version X7) -- is
WordPerfect.  I learned this in the past few years while building a very [
*very*] premium product for a legal research/workflow solutions company.
 When I created the rich copy functionality [using Flash], we were required
to support plain text, HTML, and RTF for the clipboard injection as
WordPerfect X5 couldn't consume the HTML clipboard segment when pasting but
could consume RTF.  Not sure if that has changed in X6 or X7 as I no longer
work for that employer.

Re: [clipboard] Add RTF to the "mandatory data types" list?

[James M. Greene]

Does anyone else have input for/against this? Please chime in. Thanks!

Sincerely,
James Greene



On Thu, Oct 17, 2013 at 6:57 AM, James Greene 
wrote:

> Oh, and I should also mention that the Flash Player clipboard (which we
> are trying to kill) supports plain text, HTML, and RTF, as well as custom
> "application-defined" data types.
>
>
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html
>  On Oct 17, 2013 5:44 AM, "James Greene"  wrote:
>
>> Would it be possible to add RTF (MIME type of "application/rtf") [1] to
>> the "mandatory data types" [2] list?
>>
>> While it is a proprietary file format held by Microsoft, it also has
>> public specs [3][4] and is designed for cross-platform interchange of text
>> and graphics.
>>
>> More importantly, I speculate that it is one of the top three types of
>> text formats that people copy-and-paste: plain text, RTF, and HTML. It is
>> also supported, or at least readable, by almost every word processing
>> application ever made: Microsoft Word, WordPerfect, WordPad, OpenOffice,
>> FreeOffice, LibreOffice, etc. This is not limited to desktop office
>> application either, however, as RTF is also supported by online solutions
>> such as Google Docs, Zoho Docs, etc.
>>
>> With all that in mind, it definitely seems like it should be on the
>> "mandatory data types" list.
>>
>> Are there any legal roadblocks to making a proprietary data format a
>> mandatory type? Are there any other reasons why people think that RTF
>> should be excluded from the list?
>>
>> Please let me know and/or discuss.  Thanks!
>>
>> [1] http://en.wikipedia.org/wiki/Rich_Text_Format
>> [2] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>> [3] RTF spec v1.8
>> http://www.microsoft.com/en-us/download/details.aspx?id=7105
>> [4] RTF spec v1.9.1
>> http://www.microsoft.com/en-us/download/details.aspx?id=10725
>>
>>
>> Sincerely,
>> James Greene
>>
>>

RE: [selection] Selection.setBaseAndExtent

[James M. Greene]

For consistent terminology with the rest of the API, shouldn't it be
`setAnchorAndFocus`?

Sincerely,
James Greene
Sent from my [smart?]phone
On Aug 5, 2014 5:54 PM, "Ben Peters"  wrote:

>  I have added proposed text to this bug. Any objections to this?
>
>
>
> Proposed text, based on the text for collapse():
>
>
>
> void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node
> extentNode, unsigned long extentOffset);
>
>
>
> The method must throw an IndexSizeError exception if offset is negative or
> longer than node's length ([DOM4]). Otherwise, it must create a new range,
> set ([DOM4]) its start to (baseNode, baseOffset) and its and end to
> (extentNode, extentOffset), and set the context object's range to the
> newly-created range.
>
>
>
> *From:* Ben Peters
> *Sent:* Tuesday, May 20, 2014 11:37 AM
> *To:* Ben Peters; Ryosuke Niwa; public-webapps@w3.org
> *Subject:* RE: [selection] Selection.setBaseAndExtent
>
>
>
> I have filed a bug to track this issue [1].
>
>
>
> Ben
>
>
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831
>
>
>
>
>
> *From:* Ben Peters [mailto:ben.pet...@microsoft.com
> ]
> *Sent:* Monday, May 5, 2014 11:28 PM
> *To:* Ryosuke Niwa; public-webapps@w3.org
> *Subject:* [selection] Selection.setBaseAndExtent
>
>
>
> I noticed that some websites use selection.setBaseAndExtent [1]. According
> to what limited documentation I could find, it works similar to
> selection.extend. Is there any intention to standardize this, or is it made
> obsolete by selection.extend?
>
>
>
> Ben
>
>
>
> [1]
> http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
>

Re: =[xhr]

[James M. Greene]

>
> HOWEVER, I am getting the distinct impression that even though I find
> synchronous xmlhttprequests extremely useful in some situations to prevend
> DB corruption--usually I avoid these situations, due to the negative
> impacts you have all described so well in your emails.


While I personally agree with you that synchronous XHRs have their rare but
distinct uses, preventing DB corruption doesn't seem like a realistic one
as the synchronicity of an XHR only affects the single client who is making
the request.  If your intranet app has more than 1 client, you would still
need to guarantee clean DB operation queuing on the backend.

Sincerely,
James Greene



On Mon, Aug 4, 2014 at 8:29 AM,  wrote:

> You are acting as though I have to choose one or the other and stick with
> it.  Async has it's uses, especially for GET operations.  However, many
> (not all) POST operations require only 1 channel to be active at a time,
> especially in intranet applications.  No user wants to be given the freedom
> to accidentally screw up.
>
> The problem with recent developments in the web browser world, it seems
> that things that are useful are deprecated then disappear, even if useful
> for one purpose or another and that is my request.  There seems to be some
> confusion and everyone is acting as if I only wish to use synchronous
> xmlhttprequests.  If async were to be deprecated, I would complain as much
> as I am or more.
>
> HOWEVER, I am getting the distinct impression that even though I find
> synchronous xmlhttprequests extremely useful in some situations to prevend
> DB corruption--usually I avoid these situations, due to the negative
> impacts you have all described so well in your emails.  That said, there
> are times when it is the only option.  Everyone in your group seems to have
> taken the attitude that I am mistaken, confused, or stupid.  I am only
> requesting for synchronous xmlhttprequests NOT to be deprecated and NOT to
> be eliminated from the specification.  It's pretty clear to me now that my
> request will not be considered.  Thank you all for your responses.
>
>
>
> From:Austin William Wright 
> To:Glenn Maynard ,
> Cc:nmork_consult...@cusa.canon.com, "Tab Atkins Jr." <
> jackalm...@gmail.com>, public-webapps 
> Date:08/02/2014 02:11 AM
> Subject:Re: =[xhr]
> --
>
>
>
>
> On Fri, Aug 1, 2014 at 2:01 PM, Glenn Maynard <*gl...@zewt.org*
> > wrote:
> On Fri, Aug 1, 2014 at 8:39 AM, <*nmork_consult...@cusa.canon.com*
> > wrote:
> Spinner is not sufficient.  All user activity must stop.  They can take  a
> coffee break if it takes too long.  Browser must be frozen and locked down
> completely.  No other options are desirable.  All tabs, menus, etc. must be
> frozen.  That is exactly the desired result.
>
> My browser isn't yours to lock down.  My menus aren't yours to freeze.
>  You don't get to halt my browser, it doesn't belong to you.
>
> In this case, a freeze on all browser operations is desirable.
>
> It may be desirable to you, but it's never desirable to the user, and
> users come first.
>
>
> This seems rather cold (I wouldn't presume that the described usage is
> actually bad for the users, not having seen the program in question),
> though assertion is technically correct (if users are at odds with
> development of a technical report, users come first). I would point out:
>
> It may be cheap for the developer to use synchronous mode, but it's not
> the UI event loop works, and as such it's almost always a bad proposition
> for the user. It's not a sustainable coding pattern (what if you want to
> listen for two operations at the same time?), it's generally a hack all
> around. It doesn't negate the need for your application to perform sanity
> checks like "Is the data loaded? Does performing this operation make
> sense?", even if using synchronous mode *seems* to let you avoid such
> checks.
>
> Maybe there's another reason: Good idea or no, removing this feature DOES
> break reverse compatibility with the de-facto behavior of many Web
> browsers. I'm not sure that's reason enough to standardize on the behavior,
> though. However, it may be enough a reason to file a bug report if the
> behavior ever breaks (though if they come back and say "it was never
> standardized behavior to begin with, you shouldn't have been using it in
> production", I can't really blame that either).
>
> Austin Wright.
>