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

[Hallvord Reiar Michaelsen Steen]

On Mon, Apr 20, 2015 at 11:01 PM James M. Greene 
wrote:

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

On Wed, May 6, 2015 at 8:18 PM, Daniel Cheng  wrote:
> I don't think I would feel comfortable with allowing web pages to place
> unsanitized RTF in the system clipboard. This would allow webapps to trigger
> exploits such as CVE-2014-1761.

Just to conclude here: I've been convinced that the possibility of
targeting exploits at local applications are too severe to allow JS to
write stuff labelled as RTF to clipboards. The plan is that RTF will
be considered a "custom" type so scripts can set (and get) RTF data,
but native applications will not see said data if they look for "RTF"
content on the clipboard.

I have not entirely made up my mind on how exposing RTF that other
applications have written to the clipboard to JS will work (the
"paste" / "read from clipboard" use case), but I think we'll just
expose it as usual in the items list with the RTF MIME type.
-Hallvord

[clipboard][DnD][DataTransfer] custom types and security

[Hallvord Reiar Michaelsen Steen]

Hi public-webapps, or the sub-set of your that are interested in
clipboard and DnD stuff: we've started an interesting thread regarding
DataTransfer, custom types and security here

https://github.com/whatwg/html/issues/1244

and implementor input is especially welcome. Allow me to paste parts
of my last comment, explaining a tricky issue I'd like a wider review
of:

Regarding the custom types: obviously, if we want to enable
interoperability between the same web apps running in different
browser engines, we need to spec a shared clipboard format for custom
data. This implies that other native software will also see a "Web
browser custom data" clipboard entry (by any description after some
bikeshedding) and potentially grow features that start making use of
said "Web browser custom data" on paste/drop.

If this is considered an extremely rare use case we should not cater
for, and custom data on the real OS clipboard is considered too risky,
we can of course spec that the browsers should keep custom data
somewhere internally and augment the DataTransfer object with the
internally stored custom data as if it were on the clipboard on the
next paste (unless the OS clipboard's contents changed meanwhile).
This seems harder to test and harder to get right, but it is a
judgement call.

-Hallvord

Re: Clipboard API: Proposal for asynchronous API

[Hallvord Reiar Michaelsen Steen]

Hi Gary,
good work! Some questions that have come up in discussion with
developers at Mozilla:

1) The existing DataTransfer API is purposefully designed to be used
for both copy/paste and drag-and-drop. If we add navigator.clipboard
to add asyncness to clipboard-style usage of the API, what about DnD?

2) If there are several large chunks of data on the clipboard, the
current navigator.clipboard proposal will probably still mean
shuffling lots of data around - if all those chunks need to be
processed before the promise callback. Have we considered a model
where DataTransfer itself is promise-ified? Something like
clipboardData.items[0].getAsPromise().then( ... )?

On Tue, May 17, 2016 at 12:17 AM, Gary Kačmarčík (Кошмарчик)
 wrote:
> I just sent a proposal to the WICG for an asynchronous Clipboard API:
> https://discourse.wicg.io/t/proposal-modern-asynchronous-clipboard-api/1513
>
> (yes, I know. Not the first time something like this has been proposed)
>
> This is a follow-up to an earlier thread
> Clipboard API: remove dangerous formats from mandatory data types
> where Chrome is unable to safely add clipboard support for a number of image
> formats.
>
> An async API would allow these image formats to be supported (because the
> sanitization could happen without blocking the main thread).
>

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

[Hallvord Reiar Michaelsen Steen]

Relevant to this thread - I've just reported an issue on making the
DataTransfer API safer:
https://github.com/whatwg/html/issues/1244

Input there would be great. I'm planning to look at how to add this to
the spec, but I'm not sure what exactly it should say.

I would still like comments from implementors on this question:

> Implementors? Can we rescue clipboardData.items.add(binaryImageData,
> 'image/jpeg') by mandating transcoding? :)
> Is the current Safari Mac behaviour a problem or is it safe enough to spec?

-Hallvord R

Re: [XHR]

[Hallvord Reiar Michaelsen Steen]

On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
 wrote:

> According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the
> chunked transfer coding”. The logical interpretation of this is that
> whenever possible HTTP recipients should deliver the chunks to the
> application as they are received, rather than waiting for the entire
> response to be received before delivering anything.
>
> In the latest version this can only be done for “text” responses. For any
> other type of response, the “response” attribute returns “null” until the
> transmission is completed.

How would you parse for example an incomplete JSON source to expose an
object? Or incomplete XML markup to create a document? Exposing
partial responses for text makes sense - for other types of data
perhaps not so much.
-Hallvord

Re: [clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm  wrote:

> Once I get back to work, I will start to program a version 5.0 of my editor
> that handles the new eventtype correctly.
>
> Anyone still not having upgraded from version 4.35, the editor doesn't end
> up doing crazy/uncontrolled stuff when receiving voice input. It simply does
> nothing on voice input

That's sort of the polar opposite of Gary's goal that new stuff should
"just work" :)

It also means that you do *not* consider it a goal of your spec
development to make it easier to handle stuff the developer hasn't
explicitly thought of - like IMEs, accessibility helpers and possible
future input stuff - in a way that would have a chance of "just
working"?

I'd consider it a brilliant technological achievement if voice input
fired key insertion beforeInput events (and potentially
keydown/up/press - why not? /me <3 back compat :-p) and your app "just
worked" with the new Apple device while you were scuba diving (and
more importantly: on the 10 000 sites that never bothered updating to
the new version of your JS lib at all).

Anyway - however much fun we can have imagining the future, this
discussion is sort of off-topic when we're arguing whether to replace
specialised paste and drop events with a general beforeInput
eventType=paste and eventType=drop approach.

Johannes also wrote:

>> Easier to read because there's less if() branching and switch()
>> statements.

> You mean in the JavaScript code? Well, it will be maybe three-four event
> more event handlers and then maybe 25 cases in the beforeInput/input event
> handler.

25 cases is a lot :)

>> Easier to debug because if you want to debug pasting, you ask your
>> debugger to break on a paste event.

> I assume you are here thinking of the debugging issues it gives in the
> browser code. This I know nothing about.

Not meant as boasting but just to explain where I'm seeing things
from: I've been debugging random issues on random websites for the
last 14 years or so, usually working on code I have not had the luxury
of prior knowledge of, I've been dissecting heavily obfuscated code at
least since GMail hit the web. 25+ cases inside one event handler
inside an obfuscated script is hard. 25+cases inside a non-obfuscated
script still means you might have to step over quite a few statements
to get to the code you want to see running.

> In the JS code I cannot see why this wouldn't be solveable by filtering
> through the events with a switch and then just debugging the part of the
> code that is executed for a specific action.

Browser people who advocate for this solution should be tasked with
creating a usable debugger UI for this :)
Most debuggers already have UI for breaking on a specific event type.
This is a solved problem. None have UI for creating conditional
breakpoints on a specific event type AFAIK - not saying it can't be
done, but it's harder.

-Hallvord

Re: [clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

> Just using mutation observers, one can see the change that was made, but
> doesn't really know what the user's intentions were, right?

I guess so, haven't used them for anything. Perhaps the "after the
fact" nature was a design flaw in Mutation Observers.

> The browser meeting also came up with the suggestion that drag-and-drop
> should have a beforeinput event [1].

I'd prefer not..

>> 1) Write code with lots of if(e.eventType === foo) and
>> switch(e.eventType) branching, which is hard to read
>> 2) Debug code that gets run a lot all the time - event loops that fire
>> often are annoying when debugging

> What's your proposed alternative?

My suggestion would be to use the existing stuff for clipboard and
DnD: a developer with a cE=events editing host who is interested in
enabling paste should listen to paste events. If she wants to enable
DnD she should listen to drop events. And of course a beforeInput
listener for the stuff that beforeInput does best.

> That one creates a three event listeners
> for the clipboard events +  one for beforeInput that covers most other
> operations + maybe one for drag and drop? I don't see how that be easier to
> debug or read, at least on the JavaScript side of things.

Easier to read because there's less if() branching and switch() statements.

Easier to debug because if you want to debug pasting, you ask your
debugger to break on a paste event. No scanning through lots of code
in a code base you may not even know to find the right beforeInput
method sub-branch to break on. Not breaking on beforeInput and
striving to trigger a paste without doing anything else that will
trigger the breakpoint set on an event that fires for quite a few
things. (Ever tried to debug a problem in a mousemove event handler? I
have..more than once.)

Using more narrowly scoped events for those things that require
special payloads or API just seems a lot better. I actually think you
should push back a bit against the browser devs who seem to think
beforeInput is the perfect hammer for anything that might or might not
resemble a nail..

(I'm responding to some of Gary's points in the next reply on this thread below)

On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик)
 wrote:

>> 1) Write code with lots of if(e.eventType === foo) and
>> switch(e.eventType) branching, which is hard to read
>> 2) Debug code that gets run a lot all the time - event loops that fire
>> often are annoying when debugging
>
> Yes, that's one of the trade-offs that needs to be considered when designing
> these APIs.

I agree it's a trade-off - in other words we're discussing shades of grey.

> There is a design tension between the 2 extreme approaches, each with pros
> and cons:
>
> (1) A single 'beforeinput' event that fires for all "input" activities.
> Pros: Developers only need to support this and don't worry about the
> details. Basic support for new input types just work without additional
> work.

I don't see how this logic holds if you add something like beforeInput
for paste. Suppose that I already wrote a beforeInput - based editor.
Suppose it's pretty good at handling the events I already know - I've
carefully implemented typing, deletion etc based on beforeInput
events. Now all of a sudden a modern browser is sending me beforeInput
with eventType set to "paste" and with an event.clipboardData property
I'd have to pull data from to insert into the DOM to make the paste
work. How is that something that will "just work" in my app? It
clearly won't.

> Cons: Developers that care only about a particular type need to filter out
> the other event types.



> (2) Problem with separate events: Many developers didn't support composition
> events because their native language didn't use them, so parts of the web
> were broken for CJK users. We don't want similar things to happen for voice
> or accessibility (or other) inputs. Note that this is part of the reason why
> 'keypress' was deprecated.

But the same thing can easily happen with a single-event model where
developers (naturally) "filter out" event types they believe they are
not interested in.. If four years from now browsers start sending me
"beforeInput" of type "voiceRecognition" I may have written lots of
code handling all the other already known input types and my app is
going to be broken when used with voice.

Now, of course I think the idea here is to up the semantic value of
the events so you get "this text is being inserted" semantics (even
for voice..) that's easy to handle compared to a "those keys were
pressed and we have a number that might look like a key you think you
know but might not and we won't tell you more" semantics of keypress.
But that's sort of independent of the question of whether to have a
single-event or multiple-events model. If you really want to be
backwards compatible you could spell out the letters of the words from
voice recognition and send keydown/up/press and good, old input and
change 

Re: [clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик)
 wrote:

> Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will
> receive a 'beforeinput' event just before any DOM update (with an option to
> cancel it), and you'll also receive an 'input' event just after the DOM was
> updated.  If you want to track all DOM updates, then you only need to listen
> to these two events.

In my personal (and humble) opinion it's not actually a benefit for
developers to have only one event that will fire a lot and indicate
lots of different things. I accept that library authors want a
convenient "point of overview" regarding what happens in the DOM (but
wasn't mutation observers supposed to do that job?). However, making
one single event type carry lots of different information and adding
stuff like clipboardData and/or dataTransfer (because drag-and-drop
changes the DOM too, right?) to the InputEvent interface seems like we
force authors to

1) Write code with lots of if(e.eventType === foo) and
switch(e.eventType) branching, which is hard to read
2) Debug code that gets run a lot all the time - event loops that fire
often are annoying when debugging

My five cents..
-Hallvord

Re: [clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

Hi Johannes,
thanks for commenting here. It was recently brought to my attention in
a GitHub issue that using the term "before* events" was misleading as
it sounds like I also mean beforeInput when the clipboard spec is only
about beforecopy, beforecut and beforepaste. I think you may also have
misunderstood this phrase and apologise for the confusion caused.

Some clarifications inline below:


On Mon, Mar 7, 2016 at 2:50 PM, Johannes Wilm  wrote:

> --  We use beforePaste and beforeCut events for clipboard related actions
> and  beforeInput events for everything else. (At the time it wasn't clear
> whether beforeInput would be fired in contentEditable=true)

I've reviewed your spec and there is some minor confusion because it
seems you consider the beforecopy, beforecut, beforepaste events as a
sort of "intent events" analogous to beforeInput. They are not, they
are weirder than that. On the other hand, we don't really have a
problem here because the copy, cut and paste events *are* in practise
intent events - they inform the JS of the user's intent to copy, cut
and paste respectively.

When I propose dropping "before"-events from the clipboard spec I mean
only beforecopy, beforecut and beforepaste. Naturally beforeInput will
not be affected :)

With this in mind, I think we'll ask you to change a few small things
in your specs:

1) under contentEditable -  "context menu"
https://w3c.github.io/editing/contentEditable.html#context_menu the text says
"`beforepaste`, `beforecut` and `beforeinput` events SHOULD be triggered"
Change "beforecopy", "beforecut" and "beforepaste" to simply "copy",
"cut" and "paste" respectively.

2) If it is not clear from other parts of the text you may want to add
that pasting and cutting is not enabled for those editing hosts. The
clipboard API spec text will only do the "modify the DOM"-parts if
we're dealing with "an editing host where cutting is enabled" and
pasting respectively - this was indeed added to integrate better with
your cE=events text.

> -- We updated the execCommand spec according to the wishes of the Clipboard
> API people, but do in general only maintain that spec with minimal effort
> for as long as browser makers don't want to change their implementations
> according to a standardized spec.

I also have a small correction for that spec, it's just some text in a
non-normative note where it says about the paste command:

  "will only give access to the contents of the real clipboard if the event is
  dispatched from an event that is trusted and triggered by the user, or
  if the implementation is configured to allow this."

Here I suggest dropping the "dispatched from an event that is trusted
and triggered by the user" part - or at least change 'or' to 'and'. No
implementation will ever allow document.execCommand('paste') from a
user-triggered JS thread without further configuration.

> At the beginning of this year, the browser makers except Mozilla had an
> informal meeting about editing, and from what I gather, they did not know
> about this. So their proposals seems to include copy/paste in beforeInput
> and they have proposed another attribute to hold rich text content to be
> used for dragging/pasting.

Hm..? I don't know anything about this. No biggie, we'll figure this
out. What exactly do you mean by  "include copy/paste in beforeInput"
- that for example Ctrl-C according to their view should trigger not a
"copy" event but a "beforeInput" event? If anyone is arguing that it
seems a bit odd to me ;) And instead of a "drop" or "paste" event with
an event.dataTransfer or event.clipboardData property they suggest a
"beforeInput" event with inputType 'paste' and a brand new property to
carry a data payload? Again I'd be surprised if people really want to
reinvent those wheels..

> I am not sure what the best course of action is now. Given that beforeInput
> will fire also for contentEditable=true, it doesn't seem unreasonable to
> also have it work for paste/cut events.

I believe beforeInput will keep working fine with paste (and cut?) in
a cE=true context and run after the corresponding paste event when the
DOM is actually being modified. I don't think it makes sense to say
that copy/cut/paste events are replaced by "beforeInput
inputType=copy" etc in a cE=intents element - if for no other reason
that it will be a bit odd to require from script authors that they
listen to different events depending on whether an editing host is
TEXTAREA/cE=true or cE=events/caret/typing states.

Finally: we've been discussing how a JavaScript can enable the "copy",
"cut" and "paste" commands in the browser menus when they would
otherwise be disabled. For example, if you have a web app that
implements a custom "selected" state, that app wants to enable "copy"
and "cut" when something is "selected" even though there is no such
thing as a real text selection or an editing host. This usecase is in
fact what IE's old 

[clipboard] Sanitizing HTML content for security/privacy on copy or paste?

[Hallvord Reiar Michaelsen Steen]

Hi,
some discussion of how browsers can try to safeguard security/privacy
while copying/pasting HTML got tangled into the "remove dangerous
formats from mandatory data types" thread [1]. I think it will be
easier to follow with a separate thread.

Context: we're talking copy from any normal public or local web page,
to paste formatted text into an online rich text editor. The questions
are about the code the UA itself would insert into the rich text
editor if no script processing took place - the source code you expose
via clipboardData.getData('text/html') may be handled differently.

So - implementors: do you do any of the following currently, and does
it happen when content is written to the clipboard (copy) or read
(paste)? Do you care if it's a cross-site paste or a same-origin
paste?

* Change IMG src to inline images as data: URLs?
* If yes, for all images or just local ones?
* Change link HREFs to remove potential embedded session IDs?
* Remove javascript: URLs from the code?
* Remove event listeners from the code?
* Inline external stylesheets
* Remove SCRIPT elements
* Any other special precautions or processing I haven't thought of?

(I know some of these would be somewhat odd or weird to do - just checking..)

(Also, this is not quite in scope for my spec, but I keep being asked
to figure it out.. ;))
-Hallvord R

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html

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

[Hallvord Reiar Michaelsen Steen]

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem

I'm trying to handle this question on another E-mail thread so please
follow up there :)

>> JSON: nope, there's no such thing as "external inclusion" in JSON, and
>> there never will be.

> You can certainly exchange a Bookmark-list over json (e.g.
> http://kb.mozillazine.org/Bookmarks)... that would be a simple example of
> some JSON whose URLs you should not "GET" without some concerns (e.g.
> localhost servers).

But JSON as such has no concept of "URL" or a "URL" data type. To a
JSON implementation it's just a string, and I don't see any step of a
clipboard roundtrip doing anything magic to figure out what strings
are URLs or trying to process them :).

> Similarly XInclude-enabled XMLs or even other remote-including-XMLs (e.g.
> through DTD) should ask the users, deny, or inline.

Do you think we should not mandate support for writing XML to the
clipboard from JS, then?
Is this also a problem for MathML?

> For the unsafe formats, the warning could say that the UA-implementors
> should only support the flavour if they have a method to make this content
> safe so that local applications (which do not expect untrusted content)
> receive content they can trust when pasting. Methods to make the content
> safe include the following: transcoding a picture, inlining all external
> entities for html, xml, mathml, or rtf).

To make sure we understand each other: what you're saying here is that
if I do this in a JavaScript:

document.oncopy = function(e){
  e.clipboardData.setData('text/html', 'https://mozilla.org/images/logo.gif;>');
  e.preventDefault();
}

the data that actually ends up being written to the clipboard will be



I think that would be rather surprising behaviour, and would create
some attack scenarios if the attacker can predict the URLs of images
with private data inside them. On pasting they would then be data:
URLs without a concept of origin, the UA would no longer be able to
rely on mechanisms like CORS and/or session data to determine if it's
OK to show the image. If that image would be painted on a CANVAS after
pasting, the image data would now be accessible to JS without
tainting..

Is this really what you propose? :)

> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
>
> Please share the test, this is exactly the kind of things we need around to
> see how crooked one could touch upon.

I was playing around with the code the reporter of
https://bugzilla.mozilla.org/show_bug.cgi?id=860857 submitted - here's
an online version modified to also put image/tiff on the clipboard:
https://jsfiddle.net/gk3vm5L8/1/ (apparently this test was derived
from some Google Docs code).

>> So, the question (for recap) is: would it be OK to let JS write binary
>> data labelled as an image type if the browser was required to
>> transcode it to TIFF or DIB and only update the clipboard if such
>> transcoding succeeded?

> My answer is definitely yes as we should*assume that image transcoders
> should remove the dangers of flawed parsers as they could happen otherwise
> in other situations (e.g. in doing screenshots).

Implementors? Can we rescue clipboardData.items.add(binaryImageData,
'image/jpeg') by mandating transcoding? :)
Is the current Safari Mac behaviour a problem or is it safe enough to spec?
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Mon, Feb 8, 2016 at 7:45 PM, Wez  wrote:
> Hallvord,
>
> IIUC the issue is that while transcoding complex formats via formats that
> can be easily sanity-checked by the browser takes care of letting content
> set complex formats like JPEG, GIF while protecting local content, but it
> loses the ability for content to pass that content to other local
> applications losslessly.  e.g. transcoding to BMP would remove JPEG
> location, time/date, etc annotations.

There is an issue here. Would it be possible to add another clipboard
entry for metadata or something?

> The bug you refer to looks like it's talking about intra-Browser, i.e.
> content->content, copy/paste operations for arbitrary MIME-types?
>> https://bugzilla.mozilla.org/show_bug.cgi?id=860857


It's basically about being able to place content labelled as an
arbitrary MIME type on the clipboard (i.e.
clipboardData.setData('application/x-foo', 'my custom data')) but -
correct me if I'm wrong - I don't think the browser has any real,
cross-platform way to distinguish a MIME type the JS just invented and
a MIME type that is known to and used by some other application on the
system. Hence I think the discussions of writing "data in formats
native apps use" and "data in formats custom to the script creating
them" are not two separate discussions.

It may be possible to distinguish an "already registered" and a "not
known to system" type on Windows, but even that isn't really a
guarantee that some format description isn't used by other software -
and on Mac/nix it's harder because they have a different model than
Windows's "registered types" model.

If it is possible to draw such distinctions on all/some platforms
please enlighten me, and we can perhaps untangle this into two
separate topics again :)
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

BTW, we have a slightly related and interesting discussion regarding
custom data types going on here:
https://bugzilla.mozilla.org/show_bug.cgi?id=860857

I should try to sum up some of the arguments and proposals and present
them on this list but if anyone wants to chime in, I'd appreciate more
ideas in that bug too. I'll do my best to present them objectively and
fairly on the list :)
-Hallvord R

Re: [clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

On Thu, Feb 4, 2016 at 2:43 AM, Grisha Lyukshin  wrote:
>
> Killing them doesn't sound like the right course of action. We would have to 
> come up
> with another API  so we can have an alternative to what before cut/copy/paste 
> do.

True, it's a use case we should handle.

Options:
* automagically enable commands if there are corresponding event
listeners (Opera Presto model)
  * Pros: "just works", no extra APIs, page authors don't need to
learn nor do anything extra
  * Cons: registering event listeners is not "supposed to" have side
effects, W3C specs are not "supposed to" go into UX territory, web
apps may want to sometimes leave the commands disabled after all when
it doesn't make sense to execute them

* Add a new API method like document.setCommandEnabled('paste', false)
  * Pros: Simpler and more straightforward than the onbefore*
event-based model, can be integrated with queryCommandEnabled(), gives
web apps fine grained control of when to enable/disable stuff
  * Cons: I think the editing spec people are trying to move away from
those legacy document.* commands and may not be celebrating the
opportunity of adding a new one.. Also, we don't really want to let
sites disable these commands at will - we want them to *enable* them
when it makes sense but not *disable* them when the UA would otherwise
enable them, to prevent nuisance and "copyright protection"-style
abuse.

Are there any other options?

> Why can't we fire these events regardless of content editability and do 
> actual editability
> check during the execution of the execcommands?

That's the plan :) - the spec requires the browser to fire a paste
event if the user for example presses ctrl-v regardless of whether the
context can handle a paste or not. However, the *menu* command state
(and thus the user's actual ability to trigger the command any other
way than by shortcut keys) would depend on the onbefore* handling or
some equivalent API we'd have to invent. Or the magic solution ;)
-Hallvord R

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

[Hallvord Reiar Michaelsen Steen]

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht  wrote:

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem when
> pasting from a web-page (I believe "save as web page complete" also does a
> part of that).

I think the proposed solution may be worse for privacy than the
original problem: images you would "inline" might have sensitive data
in them.. AFAIK it's not common to do any image inlining or URL
mangling when pasting HTML copied from another site, is it?

>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>> most parsers would be safe.
>
> I think the danger lies beyond parsers.
> In XML, you would have XInclude which can be used in many tools to include
> content from outside.
> I believe I have seen JSON syntaxes that had external references as part of
> their specs but I can't remember which now.
> As long these formats are copied as is and parsed blindly the risk of
> external inclusion remains.

XML: good point.
JSON: nope, there's no such thing as "external inclusion" in JSON, and
there never will be.

>> For the unsafe formats, the warning could say that the UA-implementors
>> should only support the flavour if they have a method to make this content
>> safe so that local applications (which do not expect untrusted content)
>> receive content they can trust when pasting. Methods to make the content
>> safe include the following: transcoding a picture, inlining all external
>> entities for html, xml, mathml, or rtf).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding help
> guarantee against payloads that might trigger vulnerabilities in target
> software?
>
> All platforms I know of have some sort of transcoding of pictures (in Macs
> it is PDF as the central format).
> I think this is a very safe mechanism to rely on.

I've just done a small test in Safari on Mac. It allows writing a
random string to the clipboard and labelling it image/tiff (and
helpfully adds a "public.tiff" clipboard entry with the same random
data). There's no transcoding or similar.

> I expect it adds a significant hurdle against exploits, but I'd like input
> from Daniel Cheng and perhaps from people who have worked on image
> decoders..

I'd still like Daniel Cheng to chime in again if he has time :)
So, the question (for recap) is: would it be OK to let JS write binary
data labelled as an image type if the browser was required to
transcode it to TIFF or DIB and only update the clipboard if such
transcoding succeeded?

(Obviously we also need the reverse mechanism - on paste, if there's
TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
-Hallvord

Re: [clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

The use case these events were meant to fulfil is described here:
https://w3c.github.io/clipboard-apis/#determining-ui-state

In short: they allow you to tell the UA to enable copy/cut/paste commands
even when they would normally be disabled.

On Tue, Feb 2, 2016 at 11:48 PM, Gary Kacmarcik (Кошмарчик) <
gary...@chromium.org> wrote:

> I'm not very familiar with onbefore{cut|paste|copy}, but they sound like
> very specialized versions of the beforeinput event.
>
> What do these events provide that you don't get from handling beforeinput?
> (well, other than the upcoming context "I'm about to do a cut/paste/copy")
>
> On Tue, Feb 2, 2016 at 2:00 PM, Hallvord Reiar Michaelsen Steen <
> hst...@mozilla.com> wrote:
>
>> Hi,
>> there's some scepticism about implementing
>> onbeforecut/onbeforepaste/onbeforecopy in Gecko [1], IE's implementation
>> seems considerably more limited than I expected (maybe because of bugs?),
>> and it doesn't really seem like an elegant solution to the use case it is
>> meant to solve.
>>
>> Would anybody mind if we killed those events?
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=596764
>>
>> -Hallvord R
>>
>
>

[clipboard] kill onbefore* events?

[Hallvord Reiar Michaelsen Steen]

Hi,
there's some scepticism about implementing
onbeforecut/onbeforepaste/onbeforecopy in Gecko [1], IE's implementation
seems considerably more limited than I expected (maybe because of bugs?),
and it doesn't really seem like an elegant solution to the use case it is
meant to solve.

Would anybody mind if we killed those events?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=596764

-Hallvord R

Re: [clipboard] document.execCommand and clipboard actions

[Hallvord Reiar Michaelsen Steen]

On Thu, Aug 6, 2015 at 11:00 AM, yves.ko...@ysadi.be wrote:

 Hi,
 Sorry if I might be out of scope, I am quite new in this mailing list.


Welcome, and sorry that I'm late at responding.


 The clipboard is aimed to exchange any? data between any apps running on
 your computer. It is not a browser stuff, it is an OS stuff that any app,
 including a browser, may use. I would like to use it in such a way I could
 programatically cut/paste any (even not usual mime types) data, not only
 contenteditable items data.

 Now the problem is that the way a browser uses the clipboard has a lot of
 limitations due first to security reasons and secondly to the fact that no
 2 UA implement it the same way... Today it is really hard, IMHO, to write
 cut/paste code working on all UA in order to exchange data with the
 outside the browser world. If it is to cut/paste data inside my webapp
 then I would not use the clipboard...


Right now the goal is to make things work better across the board and make
things safe enough to enable certain clipboard functionality for *all
scripts* out there - even without security prompts and explicit
permissions. It's pretty obvious that we need quite a lot of limitations
for this to work (including a limitation on writing whatever types and data
you'd like to the clipboard).


 I agree with the need to define a new clean Clipboard API


But we'll get to that later - first we want implementations to support what
we've got at the moment, and the spec is still changing based on
implementor feedback like that from the Blink team saying allowing JS to
write binary image data directly is too dangerous. Since implementations
are in progress right now, we'll probably learn over the next year or so if
the current stuff is safe enough, and build an improved API from what we
learn.
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com 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.


Hi Daniel,
I've split the data type list (as suggested earlier) into one for reading
and one for writing. Please review and tell me what you think:
https://w3c.github.io/clipboard-apis/#mandatory-data-types-1

To support the copy images to clipboard use case, I'd like to extend the
DataTransferItemList.add() method.
https://html.spec.whatwg.org/multipage/interaction.html#dom-datatransferitemlist-add

Two suggestions, one slightly less verbose but with slightly more magic:
let add() take an element, prepare writing an image to the clipboard if the
element is IMG or CANVAS:

event.clipboardData.items.add(myHTMLCanvasElement);
event.clipboardData.items.add(myHTMLImgElement);

A more verbose way (but perhaps easier to understand) is to make add()
accept dataTransferItem objects and add a .toDataTransferItem() method to
IMG and CANVAS:

event.clipboardData.items.add(myHTMLCanvasElement.toDataTransferItem());
event.clipboardData.items.add(myHTMLImgElement.toDataTransferItem());

In either case, running the above two lines of code should end up with two
new items added to the DataTransfer item list, with kind set to file, type
string set to image/png or image/jpeg depending on what the source was
and/or what the UA transcoded the data to, and with data set to the image
data.

How does that sound?

To those of you who want support for reading and writing many more formats
(both common like RTF and esoteric ones): we're discussing what scripts
from the world wild web should be allowed to do, basically without any
permissions being granted (just something being clicked/touched in a page -
a pretty low bar..). I understand that you're impatiently looking forward
to all the great stuff you could do with full access to read and write
whatever, but please have some patience while we work out just how scary
(or not) various data types are..

-Hallvord

Re: [clipboard] document.execCommand and clipboard actions

[Hallvord Reiar Michaelsen Steen]

On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
 hst...@mozilla.com wrote:
  so I hit a bit of an issue: I've written some parts of the clipboard spec
  with the assumption that it will be invoked from a
  document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
  require some extra permission work which no UA but IE has attempted so
 far).

 So you're saying most of this is deployed and used by content?


Any editor which has copy, cut or paste buttons in its UI have
exactly two ways to implement those commands, document.execCommand() or
Flash. I haven't seen any editor use Flash for this, but they may exist.
The editors I have tested have a sort of fallback mode where they check
if the command is enabled, and if not tell the user to press Ctrl-C/X/V
instead - in the paste case they tend to pop up a specific dialog with a
rich text element for the user to paste into.

So yes, this is deployed and used by content but with a poor cross-browser
compat story that typically requires workarounds.



  Meanwhile, the editing task force has gathered feedback on developing
 editor
  features from implementors and drawn the conclusion that the current
 stuff
  including contentEditable=true and document.execCommand() is
 unsalvageable.

 It seems that's wrong at least as far as copy/paste is concerned,
 given our recent successes in getting Flash replaced by execCommand()
 calls.


I haven't been following discussions in that group, so I don't know how
many developers they consulted. I'm sure we all understand the frustration
with the contentEditable implementations out there - ensuring this feature
generates sane code has not exactly been a high priority for browser
vendors. Certain editors (with Google Docs being a very high profile case)
have been through a phase of using contentEditable and have simply moved on
to do various hacks where they fake selections and cursors by modifying the
DOM directly to avoid dealing with the serious inconsistencies of
cross-browser contentEditable implementations.



  Would implementors want to support [a new API]?

 I think we should first solve the hard problems around security and
 format interoperability. We can always add new APIs once the
 underlying primitives are well understood. Doing that before seems
 rather dangerous. And as you point, without respect for historical
 precedent showing it's a bad idea.


Makes sense to me.
-Hallvord

Re: W3C's version of XMLHttpRequest should be abandoned

[Hallvord Reiar Michaelsen Steen]

On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren ann...@annevk.nl wrote:

 According to Art
 https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
 maintained. It should redirect to https://xhr.spec.whatwg.org/
 therefore.


Well, I don't think he said exactly it's not maintained - he said:


 According to Art the plan of record is to still pursue
 https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html


And you correctly note


 but
 that was last updated more than a year ago. Last formally published
 a year and a half ago.


And that is mostly my fault. I intended to keep the W3C fork up to date (at
least up to a point), but at some point I attempted to simply apply Git
patches from Anne's edits to the WHATWG version, and it turned out Git had
problems applying them automatically for whatever reason - apparently the
versions were already so distinct that it wasn't possible. Since then I
haven't found time for doing the manual cut-and-paste work required, and I
therefore think it's probably better to follow Anne's advice and drop the
W3C version entirely in favour of the WHATWG version. I still like the idea
of having a stable spec documenting the interoperable behaviour of XHR by
a given point in time - but I haven't been able to prioritise it and
neither, apparently, have the other two editors.
-Hallvord

Re: [clipboard] document.execCommand and clipboard actions

[Hallvord Reiar Michaelsen Steen]

On Wed, Aug 5, 2015 at 2:34 AM, MOHAN ARUN mar...@gmail.com wrote:

 Would implementors want to support (writing stuff to the clipboard)?


Yes, we really, really want to allow that - at least for simple cases.
There are plenty of complex questions - for example what formats is it
safe to let JS place on the clipboard on any platform? but we start with
the easy ones and take it from there.
I'm afraid I didn't really understand your other points, but thanks for
responding.
-Hallvord

[clipboard] document.execCommand and clipboard actions

[Hallvord Reiar Michaelsen Steen]

Hi,
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
require some extra permission work which no UA but IE has attempted so far).

Meanwhile, the editing task force has gathered feedback on developing
editor features from implementors and drawn the conclusion that the current
stuff including contentEditable=true and document.execCommand() is
unsalvageable. So their aim is to deprecate and remove execCommand(). If it
were to be removed, I obviously can't expect it to be used for clipboard
actions. On the other hand, my expectation that I can build stuff on top of
execCommand() makes life more complicated for them when they aim to
deprecate it.. Some discussion ensues:

https://github.com/w3c/editing/issues/61
https://lists.w3.org/Archives/Public/public-editing-tf/2015Aug/0001.html

I'm not sure how to proceed. Now, the old stuff isn't good enough, let's
have a clean slate and do new and shiny things is an approach that hasn't
worked very well so far when writing specs for the web. This time might of
course be different. (Personally I doubt it though. I'm not even sure if
they developers who told them the old stuff is something we don't want to
touch, let's forget about contentEditable=true had given this enough
thought..)

It's also true that the current approach in the clipboard spec - especially
for writing stuff to the clipboard - is a bit hackish. Perhaps I (unlike
the Editing task force) have been *too* deferential to the existing
implementations, including stuff like onbefore* events that no browser so
far did a good job implementing. (Nope, not even IE although it was
invented there). I can see why Johannes Wilm suggests making a new API
instead..

If we came up with a completely new write to clipboard API - for example
something like

if(window.clipboard){
  var items = new DataTransferItems(); // ignore that we can't currently
construct this..
  items.add('text/plain', 'Hello world');
  items.add('text/html', 'pHello world/p');
  items.imageFromElement('image/jpeg', document.images[0]);
  window.clipboard.write(items).then(function(){
alert('Copied all parts to clipboard!');
  });
}

Would implementors want to support that?
- Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile 
cha...@yandex-team.ru wrote:

 I'm just thinking out loud here, but this problem is similar to one
 already faced by email clients, especially those which are web-based...

 On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen 
 hst...@mozilla.com wrote:

  So PNG, JPG et al go in the support
 reading from clipboard list, and the support writing starts out with
 text/plain, text/html and text/uri-list - although it would be nice if
 CSV was also considered safe enough.


 I'm not sure you should directly read image formats from the clipboard,
 especially if you don't know how they got there.


What are your concerns exactly? As Wez mentioned we may have to add some
transcoding - but if there's a chunk of binary data labelled as JPEG on the
clipboard, and the user wants to paste this into her blog editor, how would
we do that if web content shouldn't read image formats from the clipboard?


 You shouldn't write stuff there that can be dangerous, but you really
 shouldn't read it direct. So maybe what happens is that when stuff gets
 written, it goes through a process like painting it onto a canvas, and then
 being scraped back off as coloured pixels and safe metadata.


Indeed, if that's what it takes.. like the addImageFromCanvas() suggestion
below. Regarding that suggestion you asked:


 Is it more than syntactic sugar?


If we allow adding image data as blobs, the normal way with
clipboardData.items.add() it would be just a convenience method. Since
Daniel Cheng has serious concerns and good arguments against allowing that,
something like addImageFromCanvas() might be a workaround that would let
users put images on the clipboard in a safe way.. If we have neither, I
guess we'll see data:image/jpeg URLs placed on the clipboard as plain text.
-Hallvord R.

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com 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


Hi Daniel,
I've been pondering this a bit and I think a first step is to split the
list of mandatory data types into two: one list for types you must
support reading from the clipboard, and one (smaller) for types you must
support writing to the clipboard. So PNG, JPG et al go in the support
reading from clipboard list, and the support writing starts out with
text/plain, text/html and text/uri-list - although it would be nice if CSV
was also considered safe enough.

It would also be good if we could come up with an API for safely writing
images to the clipboard. Just playing:
event.clipboardData.addImageFromCanvas(canvasElm, 'image/png')

Hot or not?

-Hallvord R.

[clipboard] navigator.registerClipboardFormats( ... )

[Hallvord Reiar Michaelsen Steen]

Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our what about clipboard data from various native
applications? conundrum. The proposal is to let a page indicate what
native clipboard identifiers it is interested in handling:

registerClipboardFormats({
   application/vnd.mathsoft.equation+xml:[
XMCD Format, //Windows handle
MCD Format, //old Windows handle with the same format
XMCD_FORMAT, //Linux handle
com.mathsoft.xml], // OSX handle
   application/vnd.mathsoft.equation.meta+xml:[
Provenance Data, //windows handle
PROVENANCE_DATA, //Linux handle
com.mathsoft.pd] // OSX handle
});
//returns:
//{
//   application/vnd.mathsoft.equation+xml:true,
//   application/vnd.mathsoft.equation.meta+xml:true
//}

And my current understanding of how this work work is
https://github.com/w3c/clipboard-apis/issues/9#issuecomment-123829662 :

What happens under the hood here is basically:

The UA has a registry mapping the supported native clipboard types to the
MIME types used for the clipboard API. For example, on Windows one of the
entries is probably 'text/html' - 'CF_HTML'
When registerClipboardFormat() is called, for each MIME type (key) in the
dictionary, it will check with the OS if the native clipboard knows about
each format description on the list.
The first matching format description the OS has registered (if any) will
be added to the mapping table

On reading from the clipboard, all data with the descriptions given in our
mapping table will be exposed to JS with the corresponding MIME type.

On writing to the clipboard, all data with a MIME type listed in the
mapping table will be placed on the clipboard with the corresponding native
description.

Right?

I'm not sure if implementors are happy about this. There's some pushback
against allowing web contents to write binary data to the clipboard for
security reasons - if you have vulnerabilities in local software (which is
of course a when, not an if) an attacker can trick you into pasting some
exploit payload into the vulnerable software.

Also, I know that on Windows applications register their clipboard
formats - how does this work on other platforms? Will the OSX clipboard be
able to confirm that com.mathsoft.xml is a known type when the relevant
software is installed?

Comments welcome here or in the Github issue.
-Hallvord R.
editor of https://w3c.github.io/clipboard-apis/

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

[Hallvord Reiar Michaelsen Steen]

On Thu, Jun 11, 2015 at 8:57 PM, Elliott Sprehn espr...@chromium.org
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.


Well, the only *really* foolproof way to avoid software vulnerabilities is
not using a computer ;).
I'd still like to see concrete suggestions (like suggested algorithms or
clipboardData methods) that we might consider for a safer solution - if we
can come up with any.
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Thu, Jun 11, 2015 at 7:51 PM, Wez w...@google.com wrote:

 Hallvord,

 The proposal isn't to remove support for copying/pasting images, but to
 restrict web content from placing compressed image data in one of these
 formats on the clipboard directly - there's no issue with content pasting
 raw pixels from a canvas, for example, since scope for abusing that to
 compromise the recipient is extremely limited by comparison to JPEG, PNG or
 GIF.


Well, but as far as I can tell we don't currently *have* a way JS can place
pixels from a canvas on the clipboard (except by putting a piece of data
labelled as image/png or similar there). So if you're pushing back against
the idea that JS can place random data on the clipboard and label it
image/png, how exactly would you propose JS-triggered copy of image data to
work? Say, from a CANVAS-based image editor?
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com 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


Hi Daniel,
copying images to the clipboard is an important use case. Do you have any
suggestions for how we could meet this use case in a safer way? For
example, would it be safe and easy to add a little bit of magic to make

clipboardData.items.add(canvasElement)

put a PNG on the clipboard? Perhaps copying a rendered imgElement should
work too?
-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

On Wed, Jun 10, 2015 at 1:23 AM, Ashley Gullen ash...@scirra.com wrote:

 The browser could copy a terminal command to wipe the disk, and the user
 could run it. Or copy a URL to a web page that has a known security
 exploit, and then the user pastes it in to the address bar. Maybe we
 shouldn't allow copying anything at all?

 Actually I think this is just security by paranoia.


Developing web browsers and their specs means paranoia should be part of
your job description.
It is a concern and I'm not sure how to solve it.
-Hallvord

[clipboard] queryCommandEnabled() and before* events

[Hallvord Reiar Michaelsen Steen]

Hi,
I've just reported https://github.com/w3c/clipboard-apis/issues/4 - pasting
text below:

 Through onbefore* events, JS can ensure copy/cut/paste UI in the browsers
is enabled even if there is no selection or editable context. However,
unless we spec queryCommandEnabled() to fire onbefore* events and return
true if those are prevented, we risk that queryCommandEnabled() returns
false even when the UI gets enabled and the actions are in fact available.

Proposal: the clipboard-apis spec can write an enabledness check
algorithm which the editing spec
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#querycommandenabled%28%29
can hook into.

The enabledness check will be spec'ed roughly like this:
1) Fire one onbefore event on document
2) When any event handler(s) are done, check if the default action was
prevented/return value was false. If this is the case, return true for
enabledness check
3) Otherwise, fall back to the implementation's default logic.

Criticism welcome.
 -Hallvord

Re: [clipboard] Feature detect Clipboard API support?

[Hallvord Reiar Michaelsen Steen]

On Sun, Apr 26, 2015 at 4:32 PM, James M. Greene james.m.gre...@gmail.com
wrote:

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


Maybe it's as simple as that..? Test:
http://jsfiddle.net/670s9usk/ :)
-Hallvord

[clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks

[Hallvord Reiar Michaelsen Steen]

We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
running into some tricky questions I'd like to discuss here.

Basically, on Windows IE and other apps that write HTML to the clipboard
use the CF_HTML format. This format is simply described as

 headers (name:value meta data)

 htmlhead/head
 body
 !--StartFragment--HTML!--EndFragment--
 /body
 /html

where the StartFragment / EndFragment comment tags are inserted by
implementations writing HTML to the clipboard to show where the actually
selected content starts and ends. Several very common implementations
(including I believe Microsoft Word's) will add tags like STYLE outside of
the StartFragment/EndFragment tags and add rules that may be significant
for rendering the content of the fragment correctly. Also noteworthy is
that the meta data may include a SourceURL property showing the URL of the
page you copied from.

So, because of the significance of the STYLE information and other stuff
outside Start/EndFragment, certain browsers return the full document
including the Start/EndFragment comment tags when a script does
getData('text/html'). This is obviously very useful when there's important
stuff outside these tags. It still means scripts have to do extra work to
find those comments and extract the content inside them to know what data a
user actually intended to paste. This also adds a risk that scripts will be
tested only on Windows and authored to require those comments and fail if
they aren't there on other platforms.

Should we, then, standardise returning the full document including
Start/EndFragment comments (basically requiring or encouraging other
platform implementations to start using those comments when serializing
HTML for the OS clipboard) - or should getData() return only what's inside
the Start/EndFragment tags? Are any other important platforms already using
CF_HTML conventions, or would their developers balk at being encouraged to
do so?

On a related topic, I see SourceURL as useful (could be used to properly
attribute citations automatically and such) - it would be nice to
standardise DataTransfer.sourceURL or something like that, to be set when
available.
-Hallvord
(editor of https://w3c.github.io/clipboard-apis/ )
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=586587

Re: [clipboard] Feature detect Clipboard API support?

[Hallvord Reiar Michaelsen Steen]

(Aside: I was testing the queryCommandEnabled()/onbefore* idea with this
script: https://gist.github.com/hallvors/59a90f2e3816cb57f044 )

On Tue, Apr 21, 2015 at 7:29 AM, James M. Greene james.m.gre...@gmail.com
wrote:

 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?


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

Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

[Hallvord Reiar Michaelsen Steen]

On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard gl...@zewt.org wrote:

 Hallvord: By the way, please add the editor of the HTML spec to the
 beginning of the list in your references.  It's strange to list a bunch of
 author names, but not the person who actually writes the spec.


Is anything incorrect here? https://w3c.github.io/clipboard-apis/#references
I think these are from ReSpec.js 's bibliographic database actually.




 On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.com
 wrote:

 This kind of copy does not implicitly have anything to do with Selection,
 unless we continue to have its default action be copying the currently
 selected text.  It is substantially more likely to be used for custom text
 insertion.


 I'd assume something like:

 // Copy text:
 window.copyToClipboard(hello);
 // Copy HTML text:
 span = document.createElement(span);
 span.innerHTML = bhello/b;
 window.copyToClipboard(span);
 // Copy an image from a CanvasImageSource:
 window.copyToClipboard(canvas);
 window.copyToClipboard(img);
 // Copy the selection:
 window.copyToClipboard(window.getSelection());
 // Copy HTML text with plaintext alternative:
 dt = new DataTransferItemList();
 dt.add(hello, text/plain);
 dt.add(span.innerHTML, text/html);
 window.copyToClipboard(dt);


This looks like a pretty usable API to me. One of the main simplifications
is that it drops certain limitations that we've added to lock down the
API - for example the way clipboardData and its methods is only available
to an event listener's thread. So .. it depends on whether that's what we
want.
-Hallvord

Re: [clipboard] Feature detect Clipboard API support?

[Hallvord Reiar Michaelsen Steen]

On Wed, Feb 11, 2015 at 7:21 PM, James M. Greene james.m.gre...@gmail.com
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 events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Hallvord Reiar Michaelsen Steen]

  In addition, from a security perspective, what stops a malicious website
 from embedding something like img src=file:///etc/passwd
 style=display:none/img in the markup?

 We disallow this on copy by stripping such references.


Hi Ben,
picking up this old thread..

So we need to add a sanitize local references step/algorithm somewhere
when JS writes data to clipboard? It would be great if you could have a
look at
https://w3c.github.io/clipboard-apis/#dfn-writing-contents-to-the-clipboard
and suggest some text - maybe even in the form of a GitHub pull request? :)
(I assume you strip *all* local references, not just specific blacklisted
stuff like /etc/passwd - this probably needs testing with various types of
slashes etc..)

Do you have any other safety measures when data is written to the clipboard?
-Hallvord

Re: XMLHttpRequest and timing of upload events

[Hallvord Reiar Michaelsen Steen]

Hi Anne,
sorry to be late at responding - just going through some E-mail I didn't
have time to understand and respond to before..

On Tue, May 20, 2014 at 2:55 PM, Anne van Kesteren ann...@annevk.nl wrote:

 Because redirects are atomic, we cannot dispatch loadend events and
 such on the XMLHttpRequestUpload class.


Does this change mean we can no longer send 'loadend' on the upload object?
How is a script supposed to know when the upload phase is finished, then?
Isn't this a functionality we should try to keep - or am I just
misunderstanding what you meant here..?
-Hallvord

Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Hallvord Reiar Michaelsen Steen]

So, the E-mail to Ben Peters bounced - he's no longer at Microsoft? Is
there anyone on the IE team present on the list who is able to comment on
this?
-Hallvord R

On Mon, Apr 20, 2015 at 10:38 PM, Hallvord Reiar Michaelsen Steen 
hst...@mozilla.com wrote:


  In addition, from a security perspective, what stops a malicious website
 from embedding something like img src=file:///etc/passwd
 style=display:none/img in the markup?

 We disallow this on copy by stripping such references.


 Hi Ben,
 picking up this old thread..

 So we need to add a sanitize local references step/algorithm somewhere
 when JS writes data to clipboard? It would be great if you could have a
 look at
 https://w3c.github.io/clipboard-apis/#dfn-writing-contents-to-the-clipboard
 and suggest some text - maybe even in the form of a GitHub pull request? :)
 (I assume you strip *all* local references, not just specific blacklisted
 stuff like /etc/passwd - this probably needs testing with various types of
 slashes etc..)

 Do you have any other safety measures when data is written to the
 clipboard?
 -Hallvord

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

[Hallvord Reiar Michaelsen Steen]

I assume that mandating all engines have built-in RTF parsers/converters to
translate back and forth between RTF and HTML is going too far.. Apparently
IE did / does just that, but even so it seems like RTF is generally fading
away.

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?
-Hallvord R

On Wed, Aug 20, 2014 at 8:49 PM, James M. Greene james.m.gre...@gmail.com
wrote:

 On Aug 20, 2014 4:19 AM, Daniel Cheng dch...@chromium.org wrote:
 
  On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen 
 hst...@mozilla.com 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: [clipops][editing] document.execCommand('copy', false, 'some data') ?

[Hallvord Reiar Michaelsen Steen]

On Sat, Apr 11, 2015 at 8:16 PM, Aryeh Gregor a...@aryeh.name wrote:

  element.onclick = function(){
  document.execCommand('copy', false, 'foo');
  }

 Is this really copying?


As in an operation that places some data on the system clipboard, yes ;)
but I see your point of view.


 I think a new function for set clipboard
 contents to specified value would make more sense than overloading
 execCommand(copy) to mean something more than the standard
 text-editor meaning of copy.  Besides, execCommand() is awful and we
 should prefer other APIs when possible.


So.. are you suggesting something like

window.Clipboard.setData('text/plain', 'foo') ?
-Hallvord

Re: [XHR] UTF-16 - do content sniffing or not?

[Hallvord Reiar Michaelsen Steen]

 Which MIME type did you use in the response? BOM sniffing in XML is
 non-normative IIRC. For other types, see below.


It's text/plain - seems I definitely need one test with an XML response
too.. and one with JSON.



 [[
 If charset is null, set charset to utf-8.

 Return the result of running decode on byte stream bytes using fallback
 encoding charset.
 ]]


Heh, I stopped reading here.. Assuming that using fallback encoding
charset would actually decode the data per that charset..


 https://encoding.spec.whatwg.org/#decode

 [[
 For each of the rows in the table below, starting with the first one and
 going down, if the first bytes of buffer match all the bytes given in the
 first column, then set encoding to the encoding given in the cell in the
 second column of that row and set BOM seen flag.
 ]]

 This step honors the BOM. The fallback encoding is ignored.


That's cool because it means the test is correct as-is. Somewhat less cool
because it means I need to report another bug..
-Hallvord

Re: [XHR] UTF-16 - do content sniffing or not?

[Hallvord Reiar Michaelsen Steen]

On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote:

 On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen 
 hst...@mozilla.com wrote:


 Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
 send charset=UTF-16 in the Content-Type header - should the browser
 detect the encoding, or just assume UTF-8 and return mojibake-ish data?



 What is your test doing? From what I understand of the spec, the result is
 different between e.g. responseText (honors utf-16 BOM) and JSON response
 (always decodes as utf-8).


It tests responseText.

[XHR] UTF-16 - do content sniffing or not?

[Hallvord Reiar Michaelsen Steen]

Hi,
I've just added a test loading UTF-16 data with XHR, and it exposes an
implementation difference that should probably be discussed:

Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
send charset=UTF-16 in the Content-Type header - should the browser
detect the encoding, or just assume UTF-8 and return mojibake-ish data?

Per my test, Chrome detects the UTF-16 encoding while Gecko doesn't. I
think the spec currently says one should assume UTF-8 encoding in this
scenario. Are WebKit/Blink - developers OK with changing their
implementation?

(The test currently asserts detecting UTF-16 is correct, pending discussion
and clarification.)

-Hallvord

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

[Hallvord Reiar Michaelsen Steen]

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] platform integration stuff - in spec or out of scope?

[Hallvord Reiar Michaelsen Steen]

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: Clipboard API: Default content in copy/cut handlers

[Hallvord Reiar Michaelsen Steen]

On Fri, Jul 12, 2013 at 1:22 AM, Daniel Cheng dch...@google.com wrote:

 I've noticed that the way that drag-and-drop processing model is written,
 the default content that would be in the drag data store is available in
 the dragstart event.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model
  specifies
 that the drag data store is populated before dispatching the dragstart
 event.

 Would it make sense to do something similar for
 http://dev.w3.org/2006/webapi/clipops/#processing-model? Right now, as I
 read it, we don't populate the clipboard until after the copy/cut event has
 been cancelled.


That's true, because the (legacy) model is that you only write to the
clipboard by cancelling the default action of copying whatever is selected
to the clipboard. This is probably mostly intended to be consistent with
other DOM events, but it's a somewhat strange gotcha for authors and I've
even made the mistake of forgetting to call preventDefault() myself.

Regarding the question: I'm not sure what exactly you're asking for with
something similar and what effect it would have. Is it about reading from
clipboard (for example, since you mention  DnD of files, like reading
pasted file references in a paste event)? Writing to the clipboard? Is
there any change the clipboard spec should make to make pasting
files/folders easier to implement? If yes, how and why?

Thanks in advance for any elaborations, but please note that my current
E-mail address will stop working. Just send replies to the list and I'll
find them.
-Hallvord


 It'd be nice to make it consistent with drags... the main problem is I'm
 not sure if this will break compatibility with sites that didn't expect
 this.

 Daniel

Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren ann...@annevk.nl:

 On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
 hallv...@opera.com wrote:
 So creating a new tri-state property in the XHR spec should also simplify 
 integration with the Fetch spec.
 
 Agreed. The question is, if we take it as a given that we're going to
 get a new API (that uses futures, deals with tainted requests, etc.)
 is it worth expanding the older API too?

It will not come as a surprise to you that I vote yes to this question, but 
let me try to add some reasoning:

* From a developer point of view, I doubt it will matter very much, but it 
seems that we should fix the older API. There is known demand for the 
non-credentials request to origin server use case, and the spec already 
serves it in a somewhat messy way. If we leave the spec as it is, developers 
risk having to implement the messy way first and later a cleaner way for Fetch 
(while having to keep supporting the messy way for legacy content? The web 
rarely forgets your spec mistakes once implemented..)

* It could be considered a selling point for the new API, but it's not a big 
one. What you quote above, futures and such, are big selling points. This 
doesn't make the list. 

* Given that it's not a selling point, I think consistency from the old to the 
new API is more important to normal developers. If you do not fix the old API 
we risk fielding questions like Wot? Where did my anonymous mode go? and for 
a feature that may have security implications, causing developer confusion is 
certainly not a good idea.

That's my 5 cents as of this Sunday evening..
Hallvord R

Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

  Now, if you are still not convinced this is a good change my plan B is to 
  suggest a credentialsPolicy property so we'll find an agreement anyway. 
  :-) But maybe explaining that no quirky getter magic is required helps you 
  see the proposal in a new light?
 
 Whatever we're doing here is going to result in a lot of confusion.
 There's already lots of existing code, tutorials and documentation
 that treats this property as a boolean property. At best we'd not
 break existing code, but cause a mix of code/documentation which some
 treats it as a boolean and others as a string.
 
 Hence my statement that there's no way that we can create a clean
 solution while reusing the existing property.
 
 So my objection still stands. Creating a new property seems to have
 much fewer downsides.



OK then - Anne and others, what do you think about creating a new tri-state 
xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ?


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

  OK then - Anne and others, what do you think about creating a new tri-state 
  xhr.credentialsPolicy property and discouraging usage of 
  xhr.withCredentials ?
 
 I think I'd prefer removing the constructor flag and leaving new

 features to the API for Fetch.


Sorry, I don't understand what you meant by this sentence.


Fetch already has the required underpinnings for this tri-state flag:
http://fetch.spec.whatwg.org/#concept-request-omit-credentials-mode


A request has an associated omit credentials mode, which is one of always, 
CORS, and never.


which maps exactly to credentialsPolicy:


omit credentials mode: always == credentialsPolicy: never 
(naming can be discussed, withCredentials='never' would be more intuitive but 
as we're not redefining withCredentials.. Maybe credentialsPolicy = 
'nocredentials' ?)


omit credentials mode: CORS == credentialsPolicy: 'samedomain'


omit credentials mode: never == credentialsPolicy: 'always'


So creating a new tri-state property in the XHR spec should also simplify 
integration with the Fetch spec.


 Also, we still need to nail down the
 details of withCredentials. Questions raised in
 http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0499.html
 have gone without conclusive answers.



I'm afraid I have no idea what the answers are..



-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

I proposed that we
  modify withCredentials to take three values: samedomain (default), 
 always and never. For backwards compatibility with earlier versions of 
 the spec, setting withCredentials=true maps to always and 
 withCredentials=false maps to samedomain.

But Jonas replied:
 I'm opposed to this change. Trying to modify a boolean value into a
 tristate can't be done fully backwards compatibly. Specifically, I
 don't see a way to define this new behavior in such a way that reading
 from withCredentials behaves in a backwards compatible way.

Just to clarify if it was unclear in any way: the suggested back-compat 
measures were limited to what happens when the property is set. I made no 
attempt at handling getters in a backwards compatible way. The property should 
return a string reflecting the state it is in, by default samedomain. Hence, 
it should not cause any headache or require magic behaviour to *implement* its 
getter. 

The obvious question is: will that be *sufficiently* compatible with existing 
content? How much compat pain would the first implementor feel? My gut feeling, 
for what it is worth, is that compat problems would be limited:

1) it is a fairly new API feature, not widely used yet and not even required 
for many CORS use cases out there. 

2) its main use case is fulfilled by setting, not reading, the value.

2) using CORS for third-party resources that require cookies sounds like a 
setup that would require some regular maintenance anyway, and require a 
developer with a pretty good understanding of how things work. If something 
breaks, evangelizing the right solution may be simpler for these reasons.

Now, if you are still not convinced this is a good change my plan B is to 
suggest a credentialsPolicy property so we'll find an agreement anyway. :-) 
But maybe explaining that no quirky getter magic is required helps you see the 
proposal in a new light?

 At least
 not while keeping the API sane.
 
 I'd instead prefer to define a new property.
 
 / Jonas

Re: Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

[Minor edit: fixed your true/false typo]
 
 * If we had a better way of controlling the option to deny sending credentials
 in a way that kept compatibility with legacy webpages (eg. a tristate flag 
 like
 you suggest in [6]), I agree it would be better than to have two different 
 flags
 which may be confusing to developers and which may disagree with each other. 

I agree (naturally) - now, just to be very clear: your needs are met if the API 
lets you control *credentials* - right? Does Caja currently attempt to suppress 
Referer: and/or Origin: headers? Do you consider it a requirement to be able to 
do so?

 * In Google AppScript and on Google Sites, we execute a code on the same 
 domain
 sandboxed using Caja.  In this case, Caja  relies on withCredentials 
 defaulting to
 false and prevents sandboxed guest code from setting it to true.  In this way,
 we're able to work around the difficulties posed by the API that you point 
 out.
 We are nevertheless forced to either proxy or deny requests to the same 
 origin since
 the CORS anon flag appears not be reliably supported on all browsers (and 
 withCredentials does not apply to same-origin).  


It sounds like making withCredentials a tri-state thing (i.e. with values 
'samedomain', 'always', 'never') would work better for you :) - depending of 
course on how you respond to the above question, that is..

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen   
hallv...@opera.com wrote: 


 Given that many services do (mistakenly or not) use Origin and/or Referer to 
 make
 security choices, all these headers along with the cookie header ought to be
 considered credentials.


Can you give any specific examples of services that use *and* rely on Origin 
and/or Referer to make security choices? For example if there is some backend 
code hosted on GitHub that I could consider to understand this issue better?


It might also help if you're able to point me to some documentation on how 
AppScript and Sites work exactly. My understanding is that you run untrusted 
scripts inside a trusted context (sandboxed), and need to make sure these 
scripts can not 
1) load sensitive data from the origin server
2) cause side effects on the origin server


Your origin server obviously needs to verify incoming requests, using any or 
all of 
* Cookies (ambient)
* Tokens
* Origin: / Referer: headers (ambient)


and that you make sure untrusted scripts that want to make same-origin requests 
use a cross-origin proxy to omit cookies and make sure these requests are thus 
not verified as trusted. Is this accurate? 


Now, if you have any service that's *only* verifying requests by Origin: / 
Referer: I'm pretty sure your service has a glaring security hole..? If 
suppressing Origin/Referer is a requirement for Caja, can you sketch some 
realistic demo where an otherwise safe service becomes unsafe when this feature 
is missing?

 I do not have a strong opinion on what the API ought to be -- just that
 the feature is a necessary one.


And I fully accept that for Cookie/HTTP auth/SSL session credentials, but I 
would like to see some real code evidence that omitting Origin: and Referer: is 
necessary too. In theory sites might use them as credentials as you say, but 
in practise I don't see how that can work and be safe on the web.


If we ship XHR with an anonymous flag removing Origin: and Referer: and call 
it a security feature, wouldn't that *encourage* sites to validate requests by 
Origin: and Referer:? Aren't we basically pushing snake oil security measures 
if we do so?


 That said using two boolean flags (withCredentials and anon) to 
 represent what is at least currently a tri-state value does (as you
 point out) run the risk of confusing developers who set the flags
 to conflicting values.
  
To be fair: as the spec is written, it's not supposed to be possible to set 
them to conflicting values. Implementations may of course be buggy..



I hope you don't mind me going on and on about this.. I think we may still have 
time to improve the spec here and make implementations support Caja's use cases 
better, so your input is very useful.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

Anne wrote:

 I don't really feel it's responsible to remove this feature at this
 point without anyone involved in the original discussion speaking up.

Hi all,
you were involved in a discussion [1] regarding UMP and CORS back in 2010. I 
know, it's a while ago, and apparently you had already been discussing this for 
*quite* a while. However, as the saying goes: no good deed goes unpunished, and 
I'd like wider feedback on an issue I've been discussing with Anne - so here's 
another chance to exercise those arguments. My apologies :-o..

I've been working on the XHR test suite, and thus been looking at the spec from 
a JS developer's perspective. From this perspective, I found that the 
withCredentials / anonymous flag features were somewhat confusing, to be more 
specific it was hard to figure out what the point of the anonymous flag really 
was. Some very close reading of the spec helped me figure out that the 
anonymous flag would:

* Disable Origin: and Referer: headers

* Send same-origin requests as if they were cross-origin: require preflights 
where CORS requests require preflights, and the same-origin server must opt-in 
with Access-Control-Allow-Origin and such.

Now, I read through the old thread [1] - all of it, the UMP spec and some other 
related stuff, but still couldn't quite figure out what use cases this was 
meant to solve - so I questioned why we should have the anonymous flag at all 
in [2], [3] and [4]. (Sorry for referencing only my arguments, the interleaved 
E-mails are easy to find from there).

So far in the discussion, I still think we should drop the anonymous flag 
feature from the spec. Some more thoughts beyond the arguments in the 
referenced E-mails:

* On the web, the most widely used authorization models are cookies and SSL 
sessions. Authority is rarely if ever defined by Origin and/or Referer - and 
rightly so, since they can easily be faked in server-to-server requests. Some 
sites have traditionally whitelisted certain sites based on Referer to avoid 
hotlinking of images, but hacking around such measures is hardly a use case 
we should try to cater for.

Hence, I don't even see much of a theoretical benefit to suppressing Origin.

* On the web, we usually value security-in-depth, i.e. several layers of 
security checks. The UMP model seemed to argue strongly in favour of a single 
point of failure - a token in the URL or in the body of a POST request. It 
seems to me that most services that need securing would want to also check 
Origin, check cookies and/or SSL data. On the surface this is an argument *for* 
the anonymous flag: given the assumption that valuable services do layered 
security, having credentials dropped in requests that may be risky is a Good 
Thing (TM). However, the problem is we put the burden on developers to *set* 
the anonymous flag, to foresee what requests might be risky and take 
precautions, to opt-in to a mode where even same-origin requests become much 
more cumbersome to complete and where their *own* layered security measures 
will fail. This feature is IMHO very hard to use correctly, and can
easily cause unexpected and hard to understand failure modes if used 
incorrectly.

* If we can't easily explain to authors what a feature is for, it won't get 
used.

* Having both withCredentials and anonymous flag is confusing and can give a 
false sense of security as explained in [6].

My preferred solution (which may be a little too magic) is to turn 
withCredentials into a sort of tri-state flag, where setting 
withCredentials=false disables using cookies/HTTP Auth/existing SSL sessions on 
both same-origin and cross-origin requests, setting withCredentials=true 
enables it for both, and not setting it will leave the default behaviour to use 
authentication on same-origin and omit it for cross-origin requests. (Then drop 
the anonymous flag and ignore any requests for being able to suppress 
Referer: and Origin: (unless documented by use cases we want to support).)

Another option might be to drop anonymous flag, deprecate withCredentials and 
define a new property called sendCredentials, taking values sameorigin, 
always and never, with sameorigin being the default value. Too bad I'm 
2-3 years late with that suggestion, I think it would have been clearer. 

(Obviously, if we think existing content using withCredentials is written in a 
way that would let us get away with redefining it to being a string, use values 
sameorigin, always and never and throw in a small hack translating true 
when set to always, that would be totally sweet :-D.)


Further, I think that as an extra security precaution, the spec should make it 
absolutely clear that if a CORS-request where withCredentials is *not* set to 
true/always gets redirected to a same-origin URL, credentials must *not* be 
sent while requesting the redirect target. This should close one of the 
existing potential holes and make XHR and CORS a tad more safe by default.

Now, from my 

Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

  BTW - have you considered allowing setting withCredentials to false for 
  same-origin resources?
 

 I suspect that would break sites.


Possibly, but I find it unlikely - if it's set, it's most likely usually set to 
true, not false, and it's also most likely rarely set for same-origin 
requests. Wonder how hard it would be to ship a test in some beta- or preview 
build of some browser..? 8-)


 Making a boolean a tri-state with a
 default depending on an external variable is also super confusing.


To whom? Defaults to true for same-origin, false for cross-origin, can be set 
to override seems to give authors a behaviour that's relatively intuitive. 
(Authors would not really have to consider the odd tri-state underpinnings, it 
still looks like a boolean except with a variable default behaviour).


It might be weird and confusing to implement though.. 
-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

  Making a boolean a tri-state with a
  default depending on an external variable is also super confusing.

 

  To whom?


 It seems confusing to anyone who reads the value.


Good point.


 What would it return
 in the various situations? I.e. before and after .open() has been
 called, and if .open() was called with a cross-origin URL or not.



Simplest possibility seems to be undefined if not set, true or false 
respectively if it was set. Of course this doesn't reflect whether credentials 
will be sent in the request or not - but that doesn't really happen today 
either, we don't automagically make it return true for same-origin and 
false for cross-origin requests, so it's not much of a change. Most 
capability detection I've seen uses the sensible 'withCredentials' in xhr 
form which will still work.


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: RE: [XHR] readystatechange for multiple open calls

[Hallvord Reiar Michaelsen Steen]

 I just noticed that the topic has been discussed in another thread early
 this week. Sorry for rushing around after all that. BTW, what was the
 conclusion?



The conclusion is this commit:
https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640

which seems reasonable to me (but then, it aligns the spec with both old Opera 
and Chrome/Chromium/new Opera, so I'm sort of naturally biased to think it 
makes sense).


Also, kudos for reviewing the test changes so closely that you pointed out this 
issue and it's non-alignment with the spec as it was without being aware of the 
discussion. :-)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

 Does anyone have real, non-contrived use cases for the anonymous flag?



 The basic idea was preventing confused deputy attacks by not exposing
 any information that could be used as such. So no credentials and no
 data about where the request originated from, forcing the architecture

 to be token-based effectively.

 I think the strongest use-case that I've been able to think of is to
 enable a website to take a URL from an untrusted source and then
 interact with that URL over HTTP.



I can see this as a conceptual or theoretical use case, but I'm not sure I can 
come up with a real-life scenario where one might want to do this. I can see 
some non-XHR use cases for expecting users to supply an un-trusted URL (Over 
there is the custom style sheet or background image I want on my blog), but I 
can't see any realistic XHR-based use case.


Say, for example, OpenID is a setup where the user might provide an untrusted 
URL to a third-party web site (Here's the service that can authenticate me), 
and XHR might be involved - but the Open ID *provider* would of course want to 
know what site it is interacting with, to present some information about what 
authenticating means to the user..
 
 By removing both user credentials and website credentials the website
 doesn't have to worry about confused-deputy problems. I.e. if website
 A gets a URL from untrusted source B, A can then interact with that
 URL without having to worry about that the server that it's
 interacting with will think oh, this request is coming from A, it's
 fine to trust it then. I.e. it doesn't have to worry about B tricking

 it into taking actions which A has access to, but that B doesn't.


Let's call the third party site C, to go with the alphabet. C serves resources 
with Access-Control-Allow-Origin: A.


B wants to either carry out an action or get content which B is not 
authenticated to do, but C might be set up to allow for requests originating 
from A. A already knows that B's cookies/HTTP auth/SSL credentials won't be 
sent by default with the XHR request to the foreign URL. However, we expect A 
to figure out and implement that it should also add an anonymous flag to its 
XHR requests, to preemptively avoid attacks against C. How do you even start 
explaining to authors when to use anonymous mode? Why doesn't the attacker B 
simply type or paste a bookmarklet that triggers a non-anonymous XHR (or trick 
the authenticated user of A into pasting one and sending the results)? Why 
doesn't B just write a PHP script that fakes the Referer and Origin headers in 
a request to C without involving A at all?


 This doesn't need to be obviously harmful permanently delete files
 types of actions. For those A would likely need to include some form
 of credentials anyway since any server-to-server communication can
 claim to be from A using origin/referer headers.



Indeed. 


 It can also be simpler things like throttling bandwidth if it's

 getting too many requests from a particular source.


AFAIK here your assumption is that 
- C is getting too many requests from B, starts blocking/throttling
- C still accepts requests from A (but not anonymous requests)
- A lets some user input a URL that it will *hammer* with XHR requests
- The developer working on A realises there is an exploit potential and 
preemptively adds an anonymous flag
 - C no longer accepts the requests B makes A make


Yay, all problems are resolved!? Hm.. My assumptions: 


- Quite likely some or all of the resources A want to fetch are now unable to 
detect that requests come from A, and hence stop serving them (or don't know 
what value to put in the Allow-Origin header, amounting to the same thing), 
- A's service becomes crippled.
 - A developer gets support requests, regrets, and removes the anonymous flag


If C accepts anonymous requests in the first place, B can do anonymous requests 
from its own site when C starts throttling based on origin. Or indeed do 
backend requests with fake headers.


As far as I can tell, the problem we're trying to solve with the anonymous flag 
is for all practical scenarios already solved by withCredentials. Any service 
that's only protected by checking Referer and/or Origin header is already 
really flawed and vulnerable to server-to-server attacks. These are much easier 
to carry out than a try to find a web site that accepts third-party URLs for 
XHR requests and has access to the 'protected' resources scheme. 
Server-to-server attacks would not care about Access-Control-Allow-Origin 
limitations either (indeed might just use the value as a source of information 
when implementing the attack). 


An {anonymous:true} flag in A's JS code is simply the wrong place to attempt to 
fix any such vulnerabilities. We pay implementation complexity and gain, IMHO, 
no protection.


Finally, I believe it's going to be virtually impossible to teach developers 
how to use the anonymous flag, if our understanding of realistic (ab)use 

Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

 Yes. It was added to address: http://www.w3.org/TR/UMP/
 We could revisit
 http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg171
 I suppose. Apparently at least Jonas changed his mind since then.

I didn't know the UMP spec. Reading it, it seems to me that the fundamental 
stuff the UMP spec was attempting to do has been fulfilled in CORS (making 
cross-origin accessibility a feature of the resource rather than a property of 
the requesting user, yet have some protection against cross-site exploits by 
making CORS limited by default, opting in to credentials++ using 
.withCredentials and special HTTP headers.)

What the UMP-inspired anonymous flag adds on top of what CORS already has 
seems to be two things:

1) A way to disable sending Origin: and Referer: header in CORS requests.

Why? Because we fear that some resource behaves differently depending on 
Origin/Referer of request AND we want to allow webmasters to hack around that? 
(Isn't Origin added precisely to make sure the other site has reliable 
information on what site the request comes from? Isn't that by design an 
important and legitimate factor in whether a resource allows access or not?)

 2) A way to send same-origin requests as if they were other-origin requests, 
ignore cookies and make same-origin resources inavailable unless they respond 
with the correct CORS headers.

Why? A webmaster is worried about XSRF-attacks against own site, yet allows 
users to supply URLs that will be fetched through XHR? So the solution is to 
engineer this site (where we're so concerned about XSRF attacks) with CORS 
headers that makes resources globally accessible?? That seems like a fragile 
and highly contrived way to do it.

I guess UMP attempted to solve two opposite problems (some resources that want 
to be globally accessible are not accessible enough, while some resources are 
inadvertently usable from other sites from where they are not expected to be 
used) and the design got a bit muddled as a result. One might want to use CORS 
ideas to solve the XSRF problem though - having the Origin: header is of course 
a good mitigating factor that the backend can make use of.



Does anyone have real, non-contrived use cases for the anonymous flag?


If not, I suggest dropping the anonymous flag feature from XHR.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

[XHR] question about spec text and tests for double open() calls

[Hallvord Reiar Michaelsen Steen]

Small question regarding these tests:
open-send-open.htm
open-sync-open-send.htm

Test topic: how many readystatechange events are sent if a script in one single 
script thread does xhr.open(...);xhr.send();xhr.open(...)?


Test expectation: one single event, with readyState 1. Both Opera (Presto) and 
Chrome pass the test, however, I don't see how this can be expected by 
*reading* the spec. 


Firstly, the test tests a race condition - it is unlikely to cause problems in 
practice though (the result of the request *might* just come quickly enough 
that it has changed to for example readyState 2 and fired another 
readystatechange event before the second open() call, but it's unlikely).


Secondly, by reading the spec I'd expect the second open() call to fire another 
event. The open() method, steps 15 and 16:

15  Change the state to OPENED. 
16  Fire an event named readystatechange.

Doesn't imply that if the state is already OPENED, no new event is expected to 
fire. Does any other part of the spec indicate this?

PS: http://xhr.spec.whatwg.org/#event-xhr-readystatechange - is this 
description still true? It doesn't really give much information and I thought 
the messy parts were cleaned up anyway.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [XHR] question about spec text and tests for double open() calls

[Hallvord Reiar Michaelsen Steen]

  Secondly, by reading the spec I'd expect the second open() call
  to fire another event. The open() method, steps 15 and 16:
 
  15  Change the state to OPENED.
  16  Fire an event named readystatechange.


  Doesn't imply that if the state is already OPENED, no new event
  is expected to fire. Does any other part of the spec indicate this?



 Yeah, it seems two events should dispatch per current text. If
 browsers do not do that maybe there should be a state check there and

 those steps should become substeps.


Well, obviously Chrome is the major implementation that does that.


Firefox is different (it fires an event with readyState 1 for the first open(), 
one event with readyState 1 for the send(), one with readyState 4 and one with 
readyState 1 for the second open()). I have not tested IE - do you have an IE 
version that can handle 
http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/open-send-open.htm
 ?

-- 
Hallvord R. M. Steen
Core tester, Opera Software

[XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

If create an anonymous XHR request, rig it to GET a same-origin resource and 
set a custom header, it will trigger a preflight and the same-origin resource 
will have to opt in to receiving that custom header? Expected?


var xhr=new XMLHttpRequest({anonymous:true})
xhr.open('GET', '/')
xhr.setRequestHeader('X-foo', '')
xhr.send() // fails unless same-origin server has CORS enabled and opts-in to 
X-foo header


At least by my reading of the current spec.
-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl:

 On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
 hallv...@opera.com wrote:
 If create an anonymous XHR request, rig it to GET a same-origin resource and 
 set a custom header, it will trigger a preflight and the same-origin 
 resource will have to opt in to receiving that custom header? Expected?
 
 Yes. It was added to address: http://www.w3.org/TR/UMP/

I'm not sure what use cases having this feature in XHR solves.. So I would 
support removing it, unless we can demonstrate its value.

 
 However, Gecko currently implements a mozAnon thingie that only omits
 credentials and does not do the origin/referrer source nullifying. It
 also hasn't gained any traction beyond that with implementers so maybe
 it should be removed for now. Dunno.
 
 
 --
 http://annevankesteren.nl/

Re: Re: [XHR] test nitpicks: MIME type / charset requirements

[Hallvord Reiar Michaelsen Steen]

  It seems strange the spec would require a case-sensitive value for

  Content-Type in certain circumstances.

 There's only two things that seem to work well over a long period of
 time given multiple implementations and developers coding toward the

 dominant implementation (this describes the web).
 
 1. Require the same from everyone.
 

 2. Require randomness.


We're discussing the case of a MIME type parameter sent from a client to a 
server, the question is basically where to draw the line between what we spec 
and what we leave up to the implementation. 


Currently, according to the spec the charset param is expected to be sent in 
lower case if the charset the JS sets matches (case insensitively!) the charset 
the implementation sends data in, and the JS used lower case (i.e. 
text/plain;charset=utf-8 will send charset=utf-8), in upper case if the 
implementation rewrites any charset parameter (text/plain;charset=foo = 
text/plain;charset=UTF-8 and perhaps least expected 
text/plain;charset=utf-8;charset=foo = 
text/plain;charset=UTF-8;charset=UTF-8). So per the spec itself the value may 
sometimes be lower cased, sometimes upper cased, and it may sometimes be 
transformed to upper case even if it was originally given in lower case.


We have no evidence that servers require or prefer a certain case. Servers 
(like Apache, IIS and Nginx) are generally written by professionals who 
understand case insensitivity. Server-side scripting, on the other hand, is not 
necessarily of high quality and might end up requiring a certain case. If such 
scripts exist, and if it's not documented what case is expected, we will end up 
with one of those small gotchas that are so harmful to cross-implementation 
compat. (On the other hand, if we already have a state where a variety of input 
is accepted and narrow down what is considered legal, content may well follow - 
this risks creating one of those backwards incompatibilities that annoy users 
with older devices and versions. IMO as spec authors we should also keep 
backwards compatibility in mind and not diverge from existing implementations 
unless we have good reasons.)


TL;DR: I'm not aware of evidence that spec'ing this is required for compat, I 
do buy the argument that precision might cause better future compat, I'm 
however concerned about back compat and find it surprising that a strictly 
spec'ed implementation detail will sometimes transform the case the script 
actually used.



'HR
 Anything else is likely to lead some subset of developers to depend on
 certain things they really should not depend on and will force
 everyone to match the conventions of what they depend on (if you're in
 bad luck you'll get mutual exclusive dependencies; the web has those
 too). E.g. the ordering of the members of the canvas element is one
 such thing (trivial bad luck example is User-Agent).
 
 
 --
 http://annevankesteren.nl/

-- 
Hallvord R. M. Steen
Core tester, Opera Software

[XHR] test nitpicks: MIME type / charset requirements

[Hallvord Reiar Michaelsen Steen]

Two of the tests in 
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htm
 fails in Firefox just because there is a space before the word charset.



Aren't both text/html;charset=windows-1252 and text/html; 
charset=windows-1252 valid MIME types? Should we make the tests a bit more 
accepting?



Also, there's a test in 
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-charset.htm
 that fails in Chrome because it asserts charset must be lower case, i.e. test 
script sets charset=utf-8 and charset=UTF-8 on the wire is considered a 
failure. Does that make sense?



-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Fetch: HTTP authentication and CORS

[Hallvord Reiar Michaelsen Steen]

 I had a discussion with Hallvord on IRC about the exact semantics we
 want for HTTP authentication in the context of CORS (and in particular
 for XMLHttpRequest, though it would also affect e.g. img
 crossorigin).



So me and Anne have been going a bit back and forth on IRC, we agree on some 
stuff and disagree on other points - and we fundamentally agree that some 
implementor review and input would be valuable to really settle a conclusion on 
how this murky little intersection of specs should work..


So the basic issue is HTTP authentication (cached and/or supplied by JS) with 
XHR, and its interaction with CORS and other stuff like the anonymous flag and 
withCredentials.

 Username/password can be passed via open() or the URL. In that case we
 first check if the server challenges us (do a request without

 Authorization that results in a response with status 401).


So far I agree :)


 For CORS, we'd return to the caller right there.



Here I don't agree anymore. If I want to retrieve a HTTP auth-protected 
resource with XHR from a CORS-enabled server, the natural thing to do seems to 
try to pass in the user name and password in the XHR open() call. If the script 
author supplied user/pass and the server says 401 on a request without 
Authorization: surely the natural next step is to re-try with Authorization:?


Granted, my scenario takes a little bit more work before we reach this point: I 
think that if user/pass are supplied in open() or URL for a CORS request, the 
implementation must detect that the request requires preflight, and send 
Access-Control-Request-Headers: Authorization as part of that preflight.


Now, this is most definitely a corner case, me an Anne are both concerned about 
implementation complexity but we seem to draw different conclusions - I think 
that most of the infrastructure here is going to be in place already and making 
special XHR-CORS exceptions might be just as complex as implementing 
retry-with-Authorization, whereas I believe Anne thinks I'm prescribing too 
much complexity for too little gain. 
 
 If the Authorization header is set via setRequestHeader() we'd treat
 it as any other header. We assume the developer already checked if he
 was challenged or not, etc.



I agree with that :)
 
 If an Authorization header was cached for the URL in question

 (previous visit) we'd never reuse that under CORS.


This *might* be a case for withCredentials - but it doesn't make much sense 
given that a JS author can't be expected to know if there are cached 
credentials for some other site, so we've dropped that. However, most browsers 
prompt for user/pass if XHR (or IMG) requests are challenged - so we need a 
loophole that make sure the cached credentials from a request *triggered by* 
XHR *are* used (this is one place that gets overly complex - I'd definitely 
love to nuke the whole prompts-for-user/pass in response to JS/inlines 
misfeature. Anyone else agrees we can kill it without too much compat pain..?)
 I'd be great to know if there's consensus on this. General not caring works 
 too.



Implementor views most welcome, including I don't really care, either way 
works for us :-)



BTW, here's a sort of (amateur) flow chart for what I'm proposing - after 
accepting some of Anne's feedback:
https://www.w3.org/Bugs/Public/attachment.cgi?id=1359


I just noticed I have omitted same-origin requests with anonymous flag set - if 
these get a 401 response we should probably go straight to Done, content 
denied.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Fetch: HTTP authentication and CORS

[Hallvord Reiar Michaelsen Steen]

 Here I don't agree anymore. If I want to retrieve a HTTP auth-protected 
 resource
 with XHR from a CORS-enabled server, the natural thing to do seems to try to 
 pass
 in the user name and password in the XHR open() call. If the script author 
 supplied
 user/pass and the server says 401 on a request without Authorization: surely 
 the
 natural next step is to re-try with Authorization:?
 
 If the caller to the XHR.open() call provided a username and password,
 then shouldn't the implementation send that information in the *first*
 request rather than waiting for a 401?



I'd like to do that, but Anne thinks it violates the HTTP protocol (and 
apparently is hard to implement on top of certain networking libraries?).


Any networking devs who would like to comment on that?

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: Fetch: HTTP authentication and CORS

[Hallvord Reiar Michaelsen Steen]

  Here I don't agree anymore. If I want to retrieve a HTTP auth-protected 
  resource
  with XHR from a CORS-enabled server, the natural thing to do seems to try 
  to pass
  in the user name and password in the XHR open() call. If the script author 
  supplied
  user/pass and the server says 401 on a request without Authorization: 
  surely the
  natural next step is to re-try with Authorization:?
  
  If the caller to the XHR.open() call provided a username and password,
  then shouldn't the implementation send that information in the *first*
  request rather than waiting for a 401?
  

 I'd like to do that, but Anne thinks it violates the HTTP protocol


Replying to self, this would break the authentication method negotiation that 
HTTP allows (i.e. selection of basic, digest, and more proprietary stuff like 
NTLM). Hence we should wait for a 401 challenge. 


(Could we however fix this in CORS so that the WWW-Authenticate header could be 
included in a preflight response where applicable?)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: RE: MathML and Clipboard API and events

[Hallvord Reiar Michaelsen Steen]

 I suspect that the MathML community would be eager to help define
 what needs to get stripped out of MathML to maintain security.
 However, speaking for myself, I do not know what kinds of things
 are considered dangerous. For example, MathML has markup that lets
 a math expression act as a hyperlink. Do we need to strip that out
 completely or is that dependent on the url?


See the initial list of bad stuff in 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21700


Basically, the attack scenario is: trick a user into trying to copy something 
from an attacker's site to a rich text element on a target site. If this 
process can make some code execute inside the target site, the attack can 
succeed. 


(There is also some scope for doing malice with CSS and form elements, but 
probably much less.)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: MathML and Clipboard API and events

[Hallvord Reiar Michaelsen Steen]

Hi Paul, thanks for your comments.
 
 Mathematical information
 
 This section says MathML often needs to be transformed to be
 copied as plain text, for example to make sure to the power of
 is shown with the caret ^ sign in a formula plain-text input.
 Such a transformation should not be part of a normal copy operation
 since that would transfer MathML. My concern is that readers get the
 idea that x 2 should always or often be transformed to x^2.


What about saying something like 


Some applications may want to place plain text alternatives along with MathML 
formulas on he clipboard, for example to make sure .. ?


  10.  Mandatory data types
 
 I am surprised not to see a MathML type in this list


Well, since you mention it.. I've filed a bug ( 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21698 ) in response to your 
question. If you have comments or information please add (either by replying 
here or in the bug). Would be great if you could help me understand whether 
allowing an application to write MathML to the clipboard could expose an app to 
attacks if the MathML markup is pasted without further processing - see also 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21700


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Clipboard API: Stripping script element

[Hallvord Reiar Michaelsen Steen]

 The current clipboard API specification mentions security risks
 of copy  paste but doesn't seem to explicitly mention methods by
 which user agents deal with such security risks.



Hi Ryosuke,
I did remove the section on cleaning up content because it was not implemented 
by anyone and seemed unlikely to be - but there is some advice in section 8.1 
(Security risks). It mentions The user might paste malicious JavaScript into 
a trusted page. among the risks and suggests (in the table) that the UA may 
sanitize content that comes from a different origin. I assume you want some 
more details added here, right?


 In particular, WebKit has been stripping script element from the
 pasted content but this may have some side effects on CSS rules.]



AFAIK (without re-testing right now), WebKit's implementation is: 
* rich text content that is pasted into a page without JS handling it is 
sanitized (SCRIPT, javascript: links etc removed)
* a paste event listener that calls getData('text/html') will get the full, 
pre-sanitized source


If that's correct I can add a short description of this to the spec, in the 
informative section.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Clipboard API: Stripping script element

[Hallvord Reiar Michaelsen Steen]

On 03/28/2013 10:36 AM, Hallvord Reiar Michaelsen Steen wrote:
  In particular, WebKit has been stripping script element from the
  pasted content but this may have some side effects on CSS rules.]

  AFAIK (without re-testing right now), WebKit's implementation is:
  * rich text content that is pasted into a page without JS handling it is 
  sanitized (SCRIPT, javascript: links etc removed)
  * a paste event listener that calls getData('text/html') will get the full, 
  pre-sanitized source
 
 
  If that's correct I can add a short description of this to the spec, in the 
  informative section.
 

 Why would this be informative?


Mainly because it seems like spec'ing it is a bit out of scope for this spec - 
I'm trying to spec how clipboard events should work as seen from the JS side. 
Implementation details like how data is pasted when there is no JS or event 
handling involved don't seem to belong here, and IMO the interop issues are 
far-fetched (though the XSS risks aren't).


Now, if there is interest in implementing this among other vendors, and general 
agreement that we should have this in the clipboard events spec, I'm happy to 
say something about this in normative prose. In other words, I'll just play 
this ball right over to the Mozilla and Microsoft representatives: do you 
currently implement, or do you plan to implement what WebKit does here?


 It seems quite possible to construct 
 interop problems stemming from different implementations here e.g. a 
 site that assumes that there will never be script elements in pasted 
 text, or a site that assumes it can get scripts in the result of 
 getData(text/html). Therefore the exact behaviour of the platform in 
 this respect needs to be normatively defined.



The latter aspect should be normatively defined already, in so far the 
normative getData('text/html') stuff doesn't spec any sanitization. So I think 
the interop is taken care of. As an anti-XSS measure, how to handle pasting of 
potentially risky content might be covered for example in specs for rich text 
editing.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Moving Clipboard API spec forward

[Hallvord Reiar Michaelsen Steen]

Hi Art, slightly late response because I've been away.
CCing public-webapps on this reply, in case anyone knows more that should be 
done.


 I would like to know your thoughts and plans for the Clipboard API spec. 
 Here's a short summary as I see it ...
 
 * The last publication of Clipboard API was February 2012
 
 * I just ran a diff [1] and it indicates the spec hasn't changed much in 
 the last year



True.
 
 * Test suite: about 170 files 
 http://dev.w3.org/cvsweb/2006/webapi/clipops/testsuite/. Are these all 
 good and useful?



I assume so - would be good if someone reviewed them I guess. The test suite is 
not quite complete either, though it mainly lacks coverage of certain corner 
cases like clipboard content with formatting that embeds other clipboard 
content.
 
 * Bugs: no Bugzilla bug component but Tracker has two 4-year old Issues 
 ;-) http://www.w3.org/2008/webapps/track/products/14. Perhaps these 
 Tracker bugs be closed and a new Bugzilla component created?



Issue 84 can be closed, it's resolved. 85 comes with a proposal for more 
granular security settings ( 
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0685.html ) which 
I'm undecided about.

 It would be nice to understand what needs to be done to get the spec to 

 Last Call.


Plan:
* Find a way to test the clipboard-content-that-embeds-other-clipboard-content 
scenario (do any other types of software even place such content on the 
clipboard?) and make sure the spec is sane. In practise, this is mainly about 
HTML content that embeds IMG not linking to a file:// or web URL.


* Clarify the intention that document.execCommand() can be used to trigger real 
paste / copy actions (with due limitations for security and privacy reasons) - 
I think the spec fails to state this clearly enough


* Remove the cross-origin HTML paste sanitization algorithm and all 
references to it (lacks implementation)


* Calling setData() without calling preventDefault() has no effect, even if 
there is no selection - the default action is to do nothing - this is a rather 
silly gotcha.. It would be more user/dev-friendly if setData() or other 
manipulation automatically prevented the default action of copy..


* Consider if more MIME types need to be mandatory, resolve the other issues 
noted in the spec.


None of this is time-consuming (except maybe the first point) - just a few 
hours of work.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Broken Links

[Hallvord Reiar Michaelsen Steen]

 There are references to this URL in the Clipboard API and events draft:
   http://www.w3.org/TR/html5/dnd.html#the-datatransfer-interface



Thanks, seems it should be updated to refer to 
http://www.w3.org/TR/html5/editing.html#the-datatransfer-interface 


I'll get that done, but not today.
-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Allow ... centralized dialog up front

[Hallvord Reiar Michaelsen Steen]

On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com wrote:
  I would propose to centralize this and make it an up-front dialog remembered
  for a site such that:
 
 That kind of bulk approach does not work. Users don't understand

 what's going on.


To what extent are we sure users understand a prompt about for example web 
storage?


 (This has been discussed in the past too, I suggest
 you read the archives of this list, public-web-notifications maybe,
 and probably public-device-apis.)


It certainly has been discussed but not really resolved - also, UI paradigms 
and usability research evolve, so I guess it's natural to revisit this 
discussion now and then. It does of course lie somewhat outside of the scope of 
most W3C work, given that it is about a specific aspect of browser UI, which 
might be one of the reasons why it's so hard to find good solutions.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Keyboard events for accessible RIAs and Games

[Hallvord Reiar Michaelsen Steen]

 What/where would be a good place to put the API for say queryKeyCap(code) ?  
Given that the implementation will have a KeyboardEvent property specified on 
the global object (i.e. window) I'd propose 


window.KeyboardEvent.queryKeyCap(code)


which returns a string with the symbol shown on the key. 



I.e. 


On QWERTY:
KeyboardEvent.queryKeyCap('Digit2') === '2' // true


On AZERTY:

KeyboardEvent.queryKeyCap('Digit2') === 'é' // true


etc.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: CfC: publish WD of XHR; deadline November 29

[Hallvord Reiar Michaelsen Steen]

 Are you claiming that the W3C is in the business of plagiarizing?
 
 I'm saying that the W3C (and this working group in particular) is
 taking Anne's work, without his permission, and passing it off as its

 own. 


Speaking as one of the W3C-editors of the spec: first I agree that crediting 
needs to be sorted out, and that Anne should be credited in a way that better 
reflects his contributions. I appreciate that Ms2ger points this out during the 
RfC.


Secondly, I think it's a bit harsh to say that we take his work without his 
permission - legally I believe the WHATWG deliberately publishes under a 
licence that allows this, and on a moral and practical basis as W3C-editors 
intend to collaborate with Anne in the best possible way under a situation 
that's not really by our design, we involve him in discussions, appreciate his 
input, I've also sent pull requests on GitHub to keep the specs in sync and 
intend to continue to do so. I hope that claiming that we act without Anne's 
permission depicts a working environment that's less constructive than what 
we're both aiming for and achieving.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: CfC: publish WD of XHR; deadline November 29

[Hallvord Reiar Michaelsen Steen]

 I would think that listing Anne as Editor or Former Editor and
 listing Anne in an Acknowledgments paragraph should be entirely
 consistent with all existing W3C practice.
But it's not consistent with that existing W3C practice to get all the text for 
a spec from a document edited outside the WG. Hence, it's a fair suggestion 
that we have a new look at how authors and editors are credited.



(Of course the current W3C-editors also intend to contribute whatever we can to 
the spec, test suite and process, and I think this discussion risks 
manufacturing a conflict that doesn't really exist.)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

[XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

[Hallvord Reiar Michaelsen Steen]

I'm taking a back-channel discussion on-list per Anne's suggestion. We are 
trying to clarify some text in section 4.6.1, The open() method which is 
meant to describe how an XMLHttpRequest instance is associated with a specific 
document. (This association is important for origin checks, security etc.)


The current text says:


Let *document* be the document associated with the global object for which the 
XMLHttpRequest interface object was created from which this XMLHttpRequest 
object was created.


This is quite convoluted, but precise. The last object could perhaps be 
instance to make it clearer? However, my proposal is to move this text to the 
constructor section (4.2 Constructors), for example as a new 3rd step in the 
first numbered list, and simplify it to read:


Let document be the document associated with the global object of the 
XMLHttpRequest interface object.



Anne responded:
 
 You cannot just move it to the constructor without introducing some
 other XHR-wide variable.


Sorry Anne, you could probably edit the XHR spec asleep but however obvious it 
may be to you, I need some more details here ;). We're defining an instance 
variable called *document* and discussing whether we should define it when the 
instance is constructed or when the open() method is called. I don't understand 
what state we would need another XHR-wide variable to track if we move it. As 
far as I can tell, nothing can be done after constructing an instance but 
before calling open() that would require *document* to be unset, or require 
knowing if it is set or not.


 But yes, there's an open issue about whether
 we should maybe do that. I'd prefer discussion on a public list.

Hereby implemented, Sir ;-)

  I also believe the implementation difference can not be observed from JS.
 
 Not if you make the same requirements, no...


I believe both the old text and the proposal would end up with *document* 
referencing the same document, even in corner cases. If I'm missing something 
please explain, thanks.


(Just for the record, the corner cases we need to consider here include stuff 
like 
var xhr=new iframe.contentWindow.XMLHttpRequest()


XMLHttpRequest.prototype.open.call(xhr, ...)


iframe.contentWindow.XMLHttpRequest.prototype.open.call( xhr=new 
XMLHttpRequest, ... )


and possibly other weirdness. The spec needs to dictate a consistent and 
compatible way to reference the correct document..)


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

[Hallvord Reiar Michaelsen Steen]

  Let document be the document associated with the global object of the 
  XMLHttpRequest interface object.
 
 You'd also need to check the JavaScript global environment.



Thanks for responding. How?
 
 What I mean is that var-variables are scoped to the algorithm they
 are used in. So you need to re-introduce dfn
 title=concept-XMLHttpRequest-documentdocument/dfn or some such.



Ah, OK. We already have an instance property named referrer source, which is 
a somewhat obscure name but does reference the document. Can we just re-name 
referrer source = associated document or something, and set it in 
constructor, then use it for the not fully active check etc in open() ?


(Naming it referrer source re-uses terminology from CORS or Workers? I 
believe it will always refer to a document - in web worker mode the document 
associated with the script - and we can say use associated document as 
*override referrer source* when referencing CORS algorithm. IMO this is easier 
to understand in the context of this spec.)


  (Just for the record, the corner cases we need to consider here include 
  stuff like
  var xhr=new iframe.contentWindow.XMLHttpRequest()
 
 This is not a corner case in actual content. If it was we would made
 it work the same way it does in Workers.



The precise definition of corner case is a hair I have no intention of 
helping you split :-)


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Event.key complaints?

[Hallvord Reiar Michaelsen Steen]

I wrote:


 Hence, what I think would be most usable in the real world would be
 making event.key a mapping back to un-shifted character values of a
 normal QUERTY (en-US) layout. Authors are asking for stable reference
 values for identifying keys, and that's the most stable and widely
 known reference keyboard layout.


Gary responded:

 The main problem with using unmodified 'en-US' values is that it doesn't 
 define values for keys
 that are not found on US keyboards. So, it's great for US keys, but 
 completely ignores
 the rest of the world. 


Yep, and the solution to that is listing those keys and figuring out what their 
preferred key name should be. An implementation may still run into keys that 
have no identifier per the spec (so the spec says that implementations that 
are unable to identify a key must use the key value 'Unidentified') - but we 
should do a bit of work here to make sure as few keys as possible end up in 
this state.


Thanks for coming up with your list :-)


 Consider the following problems with using 'en-US':
 * What should the 'key' value be for the B00 key (located next to the left 
 shift - see
 the ISO/IEC9995-2 spec[1])? This is used in UK, Italian, Spanish, French, 
 German and many other keyboards.


Several layouts place  here, some others , \ or -. AFAIK the most common 
seems to be , which also does not collide with any en-US unshifted key.


* What should the 'key' value be for B11 key (next to the right shift)? This 
is used on Brazilian and Japanese keyboards.


Seems Brazilian layouts have / and Japanese \ here, however these already exist 
on US layout. I guess event.key could be '/\' (only half-serious here). Any 
other proposals?


 * And C12 (tucked under Enter key when Enter takes 2 rows)? Keyboards with 
 B00 usually have C12 as well.


Go with UK and make event.key # ?


 * And E13 (between += and Backspace)? Found on Japanese (Yen key) and 
 Russian keyboards.


With apologies to Russia, we might make event.key be ¥ for this one. (Seems 
some Russian layouts have \ here - but then, the Russian layout documened by 
Microsoft on http://msdn.microsoft.com/en-us/goglobal/bb964651.aspx had no less 
than two other keys for \).


 * For B00, the USB code = 0x64, name = Non-US \ and |.
 * For B11, the USB code = 0x87, name = International1.
 * For C12, the USB code = 0x32, name = Non-US # and ~.
 * For E13, the USB code = 0x89, name = International3.


I guess names like International1 could be used if we struggle..
 
 As for the solution we need to come up with, it doesn't matter to me if it's:
 * encoded in the current 'key' field, or in a new field (although it'd be 
 nice to have
 the 'key' field do the right thing).


Sure, if we can agree on what that thing is :-)


 * a numeric value or a string (although I think a numeric value is preferable 
 to avoid
 confusion with the 'char' value).


Hm.. Personally I think a numeric value would be too easily confused with the 
keyCode value (which authors are used to), and in many cases it would actually 
be the very same value. If we want to make .key a number it's tempting to 
suggest throwing out .key and standardising .keyCode properly instead. (Some 
legacy issues will make this somewhat less reliable as an identify the key on 
the keyboard solution, e.g. A's keycode moving around on the keyboard when 
switching from QUERTY to AZERTY).


 * the exact USB codes or something similar that we derive from them.


IMO it's nicer and more author-friendly to have some abstraction if we can make 
it easier to use..
 
  But, we do need it to:
 * be able to uniquely identify each key on the keyboard.
 * be useful for all keys on all keyboards (and not just those that map nicely 
 to 'en-US')
 * be straightforward to implement on all platforms.
 
I don't think we can fulfil all three - particularly not the latter. That's 
just the way it is :-( 

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: [Clipboard API] The before* events

[Hallvord Reiar Michaelsen Steen]

  
It's not only about the context menu (which could be scoped to whatever 
element was targeted by a right-click), it's also about the Edit menu or the 
inline commands in Chrome's normal application menu. Enabling the menu 
entries all the time breaks with existing UI conventions.

  
But that's the point: if you do this, then a page adding a capturing listener 
on window or document will cause all of these things to happen up for every 
element on the page, because a capturing listener might affect anything.  It's 
the same problem see if an event handler is registered-type solutions always 
cause.


Glenn, I think we both fully understand the way this works and fails - the UI 
quirks and why they happen. Do you have any further thoughts on the 
navigator.setCommandState() proposal? Would this be better somewhere else in 
the API (some new execCommand() argument, perhaps?)? Do you think we loose 
anything if we don't spec before* events?


(Sorry about any mangled quoting of previous messages - using a work webmail 
and I don't really trust its formatting..)


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [Clipboard API] The before* events

[Hallvord Reiar Michaelsen Steen]

  On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen  
hallv...@opera.com wrote: 
  
The most IMHO elegant solution is what we implemented in Opera: we simply keep 
relevant menu entries enabled if there are event listeners registered for the 
corresponding event. This sort of goes against the registering event listeners 
should not have side effects rule, but it's a UI effect the page can't detect 
so I guess it's ok. 
 

 This doesn't really work when pages put their event listeners further up the 
 tree, eg. capturing listeners on the document and other event delegation 
 tricks, right? 
  
Why not? The UA can tell if there are copy/cut/paste listeners registered 
anywhere in the document. Besides, we have no way to tell whether the author's 
styling is implementing some faux object focus stuff, so we don't know where 
the user thinks the focus is.


-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [Clipboard API] The before* events

[Hallvord Reiar Michaelsen Steen]

  It should work just fine if you check the whole eventtarget chain (from the 
target to the window object).

 But that means adding a capturing listener on the window would apply this 
 affect
 to every single element on the page.  If that's an acceptable result, then 
 just
 add the menu item all the time and forget about the event handler logic.



It's not only about the context menu (which could be scoped to whatever 
element was targeted by a right-click), it's also about the Edit menu or the 
inline commands in Chrome's normal application menu. Enabling the menu 
entries all the time breaks with existing UI conventions. Even when using 
Opera's implementation, most pages do of course not add copy/cut/paste event 
listeners in the first place, so on most sites the menu is only enabled when 
there is a selection, the way users expect. And integrating well with what 
users expect from the native UI seems to be important for web apps. I believe 
that for example Google Docxs maintains a selection in a hidden IFRAME with 
editable content in order to manipulate the enabledness of copy/cut menu 
entries. This is of course a horrible hack and 
navigator.setCommandState('copy', true) would be much better.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: [Clipboard API] The before* events

[Hallvord Reiar Michaelsen Steen]

Den 1. nov. 2012 kl. 19:38 skrev Ojan Vafai o...@chromium.org:

 I agree that this use case is not very important and possibly one we 
 shouldn't bother trying to solve. Hallvord's initial point, I think is that 
 there's really no use case for the before* events. We should kill them.

Makes it easier to ship my spec if we get a general agreement on this, so I 
won't exactly object to it :-) The potentially important part of the use case 
here is however not about *dis*abling copy/cut/paste menus. It is useful to be 
able to *en*able them when they would otherwise be disabled, say when there is 
no selection but the app/script fakes a selection of some entity or object it 
wants to let the user copy.

The most IMHO elegant solution is what we implemented in Opera: we simply keep 
relevant menu entries enabled if there are event listeners registered for the 
corresponding event. This sort of goes against the registering event listeners 
should not have side effects rule, but it's a UI effect the page can't detect 
so I guess it's ok. 

It might not be a solution we can put in the spec though..  So do we want to 
handle this use case or ignore it for now?


 *If* we want to meet the use case those events purported to meet (not 
 displaying cut/copy/paste in menus), we should design a better API. It sounds 
 like noone especially cares for that use case though. I don't hear web 
 developers clamoring for it.
 
 
 On Thu, Nov 1, 2012 at 11:12 AM, Travis Leithead 
 travis.leith...@microsoft.com wrote:
 You are right, that it doesn’t solve the “disabling the option in the browser 
 chrome” case—but is that really necessary? Why would a site want to do this?
 
  
 
 The only reason I can imagine is the old “we want to prevent the casual user 
 from copying this image because it is copyrighted” scenario. In the cut/paste 
 interaction, there are other ways to handle this such as making the control 
 read-only, or stoping the action at the keyboard event level.
 
  
 
 IE10 (and other UAs) have another solution—allow more fine-grained control 
 over the management of selection (css property, and example usage). I can 
 imagine a similar model for specific control over cut/copy/paste from certain 
 parts of the page if this is a hard requirement. The CSS property means that 
 the developer’s request can be honored by the user agent without script 
 getting in the way of (and possibly delaying) the action.
 
  
 
 From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
 Sent: Thursday, November 1, 2012 4:38 PM
 To: Travis Leithead
 Cc: Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel 
 Cheng; Bjoern Hoehrmann; Sebastian Markbåge
 
 
 Subject: Re: [Clipboard API] The before* events
  
 
 On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead 
 travis.leith...@microsoft.com wrote:
 
 I'm looking at the beforecut, beforecopy and beforepaste events. I don't 
 entirely understand their intent, it seems even more obscure than I 
 expected..
 
  
 
 I’m not sure that the use case that these events were originally designed for 
 (which have been obscured by time), are at all relevant to site content any 
 more. The use case of hiding the cut/copy/paste menu options, can be 
 fulfilled by replacing the contextmenu with some custom one if desired.
 
  
 
 You don't want to disable the other items in the context menu though. This 
 also doesn't solve disabling cut/copy/paste in non-context menus, e.g. Chrome 
 has these in the Chrome menu.
 
  
 
  
 
 From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
 Sent: Wednesday, October 31, 2012 10:21 PM
 To: Hallvord R. M. Steen
 Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; 
 Sebastian Markbåge
 Subject: Re: [Clipboard API] The before* events
 
  
 
 On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.com 
 wrote:
 
 I'm looking at the beforecut, beforecopy and beforepaste events. I don't 
 entirely understand their intent, it seems even more obscure than I expected..
 
 Nothing in the official MSDN documentation [1] really explains the 
 interaction between beforecopy and copy (given that you can control the data 
 put on the clipboard from the copy event without handling beforecopy at all, 
 the demo labelled this example uses the onbeforecopy event to customize copy 
 behavior doesn't really make sense to me either.)
 
 I was under the impression that you could handle the before* events to 
 control the state of copy/cut/paste UI like menu entries. However, when 
 tweaking a local copy of the MSDN code sample [2], I don't see any difference 
 in IE8's UI whether the event.returnValue is set to true or false in the 
 beforecopy listener.
 
 Another problem with using before* event to control the state of 
 copy/cut/paste UI is that it only works for UI that is shown/hidden on demand 
 (like menus) and not for UI that is always present (like toolbar buttons). 
 I'm not aware of web 

Re: RE: RE: [XHR] Open issue: allow setting User-Agent?

[Hallvord Reiar Michaelsen Steen]

The point is that a browser can act as if every single server response
included Vary: User-Agent.  And perhaps should.  Intermediary caches
_certainly_ should.
  
  
  
  Good suggestion.
 
 

 But my concern was even if browser acts as such, intermediary caches would 
 still return forged content


I guess UAs *could* add a Cache-control: no-cache request header when getting a 
resource that was previously retrieved with a different UA string - this is 
getting very fiddly though.

-- 
Hallvord R. M. Steen
Core tester, Opera Software

(aside) MIME type (was Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard)

[Hallvord Reiar Michaelsen Steen]

 Hallvord, it should be called media-types btw, or?


IMHO the term MIME type is more widely used and also less ambiguous than 
media type, so I'd definitely prefer using the former if I can get away with 
it :)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard

[Hallvord Reiar Michaelsen Steen]

Having thought about this some more, I see that there is a fingerprinting 
concern if we tie this closely into the available applications/OS capabilities. 
Also I understand that the API would be relevant for drag and drop (thought I'm 
not quite sure how it would work). Hence I think the method should be on the 
DataTransfer.prototype object, and usable only inside event handlers:



if(event.clipboardData.isTypeSupported('foo/bar')) ...


Supported means: if you give me data labelled as this type, I know the OS 
description and (if applicable) the relevant meta data and formatting for this 
type, and can write it to the clipboard so that other native apps can make use 
of it. If data labelled with the OS's native name or constant for this type is 
on the clipboard, I can map it to the mime type and extract the data in a way 
the script can use. Additionally, if a blob of data in this format is dropped 
on my window, I'll know what to do about it, and if you drag this data *from* 
my window to another application on the system, I can format and label it in a 
way the targe app will understand.


Paul Libbrecht wrote:
  
 I have one concern: media-types are likely to be insufficient
 and flavour names, whatever they are on the host platform
 should be allowed I think. Almost arbitrary strings on Windows
 and Uniform Type Identifiers on Mac should be allowed, I think.

No, I really don't think it is a good idea to make scripts on the web have to 
sniff the OS to determine what argument to pass to isTypeSupported().. If MIME 
types aren't sufficient, maybe we need to mint more MIME types as we go? :)

-- 
Hallvord R. M. Steen
Core tester, Opera Software