Clipboard actions BOF table at W3C TPAC

[Paul Libbrecht]

Hello webapp-aficionados,

I've just proposed a clipboard-actions BOF table for today noon here  
at the W3C Technical Plenary  in Mandelieu where I suppose some of you  
are.


It would be lovely to get some of the webapp folks there.

paul

smime.p7s
Description: S/MIME cryptographic signature

Re: Clipboard actions BOF table at W3C TPAC

[Paul Libbrecht]

thanks Ian,

this section has matured a bit... that's good.
What the copy-and-paste says is what the drag-and-drop says, just  
simpler, right?


I still have a hard time while reading to understand if content- 
authors have a possibility to offer alternative data flavours to  
users. I seem to read there only something about a "text/plain"  
translation but nothing about allowing something such as

  "the ICS equivalent of that div is this-or-that-or-at-this-url"
can you explain it better?

paul

Le 22-oct.-08 à 11:30, Ian Hickson a écrit :
I've just proposed a clipboard-actions BOF table for today noon  
here at
the W3C Technical Plenary in Mandelieu where I suppose some of you  
are.


In case I am not able to attend, I just wanted to mention this  
section in
the HTML5 spec that defines a copy-and-paste API in terms of the DnD  
API:


  http://www.whatwg.org/specs/web-apps/current-work/#copy-and-paste




smime.p7s
Description: S/MIME cryptographic signature

Re: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Paul Libbrecht]

Ian,

Can you please respond to my request "how to implement other flavour  
names"?


Also, I would like to see test-cases and reports for the  
implementations you indicate here.


paul




Le 22-oct.-08 à 17:02, Ian Hickson a écrit :

On Wed, 22 Oct 2008, Charles McCathieNevile wrote:
Ian, how stable do you think this bit of the HTML5 spec is? (I  
haven't

looked yet...)


Drag and drop is very stable, it's implemented in three browsers now.
There's some outstanding feedback, but not much. The implementation of
copy and paste in terms of drag and drop (a design motivated  
primarily by
accessibility and security concerns) is not widely implemented,  
though I

have no pending feedback regarding changes to that.




smime.p7s
Description: S/MIME cryptographic signature

Re: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Paul Libbrecht]

(cross-posting to member-math and public-webapps, sorry if this bothers)

Interesting, meeting really helped,

Yesterday, discussion with Chris Wilson and Adrian Bateman, of MSIE  
team, revealed that allowing arbitrary flavours would be a big  
security hole for Windows at least (I believe this is Windows only but  
can't confirm yet).


So it seems the list of safe encodings is something that would need to  
be worked out.
A safer approach may be to require that the browsers make sure the  
things sipped into the clipboard/drag-content are only safe things.


Safe things include html without scripts, all picture formats  
(postscript as well?)  and most media, but not html with scripts, not  
windows metafiles, not OLE or MS-office documents.


Adrian indicated method to convert html to safe-html seem to be there  
in MSIE 8 already. Sanitization is probably the right term here.


paul


Le 22-oct.-08 à 17:02, Ian Hickson a écrit :


On Wed, 22 Oct 2008, Charles McCathieNevile wrote:


Sorry, I missed this - I was otherwise occupied at lunch (I am here,
BTW).

Having hopefully pretty much shifted Progress Events off my plate, I
hope to move back to the clipboard API stuff now - and the HTML5  
draft

is indeed an important reference...

Ian, how stable do you think this bit of the HTML5 spec is? (I  
haven't

looked yet...)


Drag and drop is very stable, it's implemented in three browsers now.
There's some outstanding feedback, but not much. The implementation of
copy and paste in terms of drag and drop (a design motivated  
primarily by
accessibility and security concerns) is not widely implemented,  
though I

have no pending feedback regarding changes to that.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'




smime.p7s
Description: S/MIME cryptographic signature

Re: Next steps on Widgets testing?

[Paul Libbrecht]

Our experience in the math group with the testsuite has shown that  
long collaborative test-suite building, web-visible and referenceable  
as well as CVS built is really wishable. Eg. we experienced spec- 
change only after a given section had a test-case and that test-case  
was requested for implementation!


my 2p.

paul

Le 26-nov.-08 à 00:29, Charles McCathieNevile a écrit :


Also, would it be helpful if the tests were moved to the public CVS
server? should they sit in 2006/waf/widgets/tests/ if so?


I think it's better to have tests in CVS than to have them listed in  
an attachment in a mail archive. I am not fussed about where they  
go, but your suggestion seems as good as any. I presume that the  
groups will at some point go through the tests and decide whether  
they are happy with them all...




smime.p7s
Description: S/MIME cryptographic signature

Re: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

[Paul Libbrecht]

I found one test case:
  
http://ljouanneau.com/blog/post/2008/08/29/817-drag-and-drop-html5-dans-firefox
that is, a blog rejoicing about Mozilla nightly implementing it.

Issue?
(to my point of view): it doesn't go to the outside world.
Normal... because of the "local flavours" issues I suppose so it has  
to be accepted.


paul


Le 23-oct.-08 à 10:23, Ian Hickson a écrit :

Can you please respond to my request "how to implement other flavour
names"?


The getData() and setData() functions take arbitrary MIME types;  
does that

cover it?


Also, I would like to see test-cases and reports for the  
implementations

you indicate here.


Yes, that would be good. Implementors? Are there test cases for this
section?




smime.p7s
Description: S/MIME cryptographic signature

Re: Copyright license for ElementTraversal Java interface

[Paul Libbrecht]

I would like to add the wish to add this file as a jar within a W3C  
maven repository,


maven is a build system based on declarative dependencies marking.
The objective of a W3C maven repository would be to offer, in a way  
transparent to people that "just checkout souces", a linking to W3C  
code without this code being hosted at an external project such as the  
Apache Software Foundation.


I think what bothers several Apache developers is to have source code  
in their repository which is "not wished to be changed". Allowing  
download form W3C would prevent that common objection.


A very long discussion happened about W3C sources:

http://markmail.org/message/wqv6jo23gzyulvnf?q=w3c+legal-discuss+list:org%2Eapache%2Elegal-discuss+from:%22Benson+Margulies%22+type:general&page=1

In terms of organization, it is a very simple http directory layout,  
and the indication of the repository for the people using that  
deployment. All maven downloads are cached so there's really no  
performance penalty.


thanks in advance

paul





Le 12-janv.-09 à 05:58, Doug Schepers a écrit :



Hi, Cameron-

My opinion is that the editor of the Element Traversal spec simply
didn't know what he was doing (no offense).

I would suggest that a separate file be made with the appropriate Java
interface file, with the appropriate license, and that it be linked  
from

an errata (and later a second edition).

Would this work for you, and for the rest of the WebApps WG?

Regards-
-Doug

Cameron McCormack wrote (on 1/11/09 11:04 PM):

Hello WG.

A question[1] just came up within the ASF about the license under  
which

the ElementTraversal Java interface is made.

Unlike some other W3C specifications, where Java interface files are
made available as separate files (perhaps within a ZIP file) with a
header at the top that states that the file is licensed under the W3C
Software License[2], the Element Traversal specification includes the
Java interface inline.  The specification itself is licensed under  
the

W3C Document License[3], which likely isn’t suitable for inclusion in
ASF software distributions.

Some time ago, I added the Java interface to the Batik project’s
repository[4].  The main contents of that file do not exactly match  
the
text that is in the specification; the formatting is different.  I  
did

however add the Apache License header to the top of that file, as is
done with other non-external source code.  Given that the contents of
the file don’t exactly match the text in the spec (but is quite
similar), and could reasonably have been generated from the IDL,  
I’m not

sure if including that header was the correct course of action.

So my questions are:

1. Should I replace the ElementTraversal.java file in the Batik
repository with one that is identical to the text in the Element
Traversal spec, but with a W3C license header at the top, and if so,
which one?

2. Should the W3C be explicitly licensing the ElementTraversal.java  
file

under the W3C Software License?

Thanks,

Cameron

[1] http://markmail.org/message/lgqmiixh4l3bdugv
[2] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
[3] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
[4] 
http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/w3c/dom/ElementTraversal.java







smime.p7s
Description: S/MIME cryptographic signature

Re: [access-control] Rename spec?

[Paul Libbrecht]

Being external to it all, i.e. just reading the mailing-list with the  
spec-title mentioned just about everytime, it clearly seems like a  
good move to me: that specs starts to taste interesting whereas,  
before, it seemed to be unrelated to my tasks!


;-)

paul


Le 13-janv.-09 à 17:50, Anne van Kesteren a écrit :
I know some people (e.g. Ian) don't like the idea, but it seems the  
name "Access Control for Cross-Site Requests" confuses people,  
especially the "Access Control" part:


http://www.w3.org/2001/tag/2008/12/10-minutes#item03

'TBL: Calling it Access Control" is misleading. It's about privacy.'

Henri Sivonen suggested "Cross-Origin Data Sharing" on IRC the other  
day:


http://krijnhoetmer.nl/irc-logs/whatwg/20090112#l-139

Since it can be about more than just data, e.g. images, "Cross- 
Origin Resource Sharing" might be more appropriate. Keeping the  
header names the same seems fine, they're just opague strings, but  
at least making it more clear what the specification is about might  
help people.




smime.p7s
Description: S/MIME cryptographic signature

Re: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

[Paul Libbrecht]

A few ideas:

- one of the dangers is that flavours may be damageable... so the  
general practice would be that, unless we're in a de-sandboxed region  
(anything else than file://?) all flavours should be sanitized (e.g.  
no scripting, no relative reference, no embedding, except for pack- 
embedded data, no remote calls)


- another danger is that the clipboard should not be read without the  
user knowing, I would recommend, as Safari does, to only allow the  
standard gestures within the user-agent to be triggering clipboard  
operations which in turn, offer access to the clipboard.


To my knowledge, this is enough for a model that can be trusted to the  
users.


I am not very comfortable with the suggestions of trust-level that  
João Eiras suggests (having played with them in MSIE always prompts  
the unknowledgeable user to boost things a bit more in case something  
doesn't work which I find a catastrophic attitude) although I fully  
agree that we are here talking of either the central user clipboard  
and or the content of a drag-and-drop feature (i.e. we are talking of  
acting with external applications as well).


paul




Le 09-mars-09 à 02:36, Web Applications Working Group Issue Tracker a  
écrit :
ISSUE-85 (clipops security practice): What are common sucrity  
practices for Clipboard APIs? [Clipboard Operations]


http://www.w3.org/2008/webapps/track/issues/85

Raised by: Charles McCathieNevile
On product: Clipboard Operations

What are the common security restrictions and considerations that  
should be listed in the clipboard apis spec?




smime.p7s
Description: S/MIME cryptographic signature

Re: Copy/Paste Events

[Paul Libbrecht]

Just to enhance a bit the comments here, all the implementations  
guides I've seen about drag-and-drop very quickly rely on the fact  
that a state is assigned with the drag-operations-sequence, e.g. to  
define acceptance or rejection and that this state is unique globally  
on the whole user-interface.


Much of the behaviours of many GUIs change while a drop is happening,  
Apple's exposé is another such: you can trigger it while dragging.


I am sympathetic to timeless's wishes but I have the impression  
they're not really realistic, I don't see normal mobile phone user  
able to copy-and-paste instead of drag-and-drop with a cursor if the  
page developer has not also thought of enabling copy-and-paste...


paul



Le 28-juil.-09 à 15:38, Sebastian Markbåge a écrit :


A similar issue has been brought to the WHATWG list:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021445.html

The spec doesn't define how the UA should select an element to do  
your drop without a mouse - because drop targets may not be focusable.


So, a copy/paste would not automatically be enabled for all drag/ 
drop operations anyway. By having a separate copy/paste API, an app  
developer would be required to provide a functional keyboard  
alternative.




smime.p7s
Description: S/MIME cryptographic signature

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

Le 13-août-09 à 13:34, Ian Hickson a écrit :


So I'm saying is that, regardless of whether you use voice, keyboard,
touch or mouse... There are two distinct concepts at play here.


I disagree. The drag and drop model allows the user to drag to the
clipboard and paste from the clipboard. This is exactly what copy-and-
paste simulates. I don't see why this is a problem. If the drag-and- 
drop
code doesn't support dragging to another app, then that's a problem  
with

the drag-and-drop code, and providing a second API to work around that
problem just for copy-and-paste doesn't help the people using the
drag-and-drop feature in that fashion


To me it is a problem to confuse the two operations:

- drag and drop allows a precise visual target identification thus may  
be considered safer (and this is actually implemented so: you can  
faster drag-and-drop URLs than copy and paste them). Copying, however,  
is simpler and better understood as long as the selection model is  
clear.


- copy-and-paste is aimed at long term storage: if you write to the  
clipboard you have to write all the flavours you think a recipient  
would ever make use of! The clipboard often survives computer-restarts.


- drag-and-drop is aimed at direct negotiations: generally, only at  
the end of the drag is the actual data produced. In case this is  
running over a network-based conversion this is significant I feel.


So I would insist to split the two set of events while keeping common,  
of course, some of the interfaces to denote what can be transferred.


paul

smime.p7s
Description: S/MIME cryptographic signature

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

Le 14-août-09 à 10:00, timeless a écrit :


Paul Libbrecht< wrote:
- drag and drop allows a precise visual target identification thus  
may be

considered safer (and this is actually implemented so: you can faster
drag-and-drop URLs than copy and paste them).

this isn't true.
depending on how friendly your drop target is, it theoretically could
be true, but in practice many apps do not make it easy to understand
precisely where you're dropping or precisely what effects a drop will
have.


I should have said "drag and drop can allow a precise visual..."

This is the app responsability. I'm claiming there are many apps that  
do so.
The MacOSX Finder is definitely one of them, most Cocoa based text- 
editing apps do so as well, most picture processing programmes as well.



sometimes your entire document is replaced by the thing you
thought you were dragging. sometimes you get something you didn't
think you were dragging.


that's when you can't identify the nature of things.
The story you are telling below is a simple confusion: the CD icon on  
the left of Finder windows is not the same as the on either the  
desktop or the "computer" view: if you drag out from these icons you  
do so as if you were dragging out of a dock which  has been much  
criticized, I know, it's just inaccomplished.



Unfortunately, the concept isn't as simple as that, it turns out (and
i finally understand it now [actually, i think i discover it ever
couple of weeks and then promptly forget), then there's a difference
between dragging the disk reference from the desktop to the trash and
dragging the item from a finder window's tray to the trash. the former
changes the trash to an eject icon and the latter doesn't. either way,
when you drag a usb volume to the trash, the volume disappears from
[]
Keep in mind that this drop target is supposedly *friendly* it tells
me if it's actually going to eject by changing the icon of the target,
and yet, i still don't manage to get it right most of the time
(probably because my desktop is typically obscured, so i couldn't drag
or see the volume on the desktop).


Apple has provided Exposé's "see desktop" to help you.




Copying, however, is simpler
and better understood as long as the selection model is clear.


yesterday i was merging two documents using a third window (a browser)
as a reference.

mostly this meant a was copying an annotation ("# UNUSED") from
old-document to new-document
and copying an identifier from new-document to cross reference to
verify whether the identifier was indeed unused.

I did this by having the browser (Camino.app) as approximately full
screen behind a text editor that supports multiple windows (XCode.app)
with two windows side by side.


you describe this very well: you wish it was DnD because you don't  
want long-term storage but you cannot do it because it's using the  
keyboard: typically the keyboard is preferrable for selection and text  
navigation and is often better preferred by people that already  
keyboarding: hence Copy-and-paste is often understood as a keyboard  
bound thing while DnD is not: you can't specify the exact target  
(unless you are simulating it all).



The process was basically:
* in right editor window (new-document)
1. use the down arrow to move to the next identifier
2. use alt-right to select the identifier
3. use cmd-tab to switch to Camino
* in Camino
4. double tap into the xref search field (this is about 10% down the
screen and 10% to the right of the left edge)
5. use cmd-v to paste
6. use enter to start the search
7. use cmd-tab to switch back to XCode.app
* in XCode
8. use cmd-` to switch to old-document
9. use cmd-c to copy "# UNUSED"
10. use cmd-` to switch to new-document
11. use cmd-left to go to the start of the line
12. use cmd-v to paste
13. loop

In this process, i have two things which have to be in my "clipboard",
obviously neither is in my clipboard as "long term storage", it's in
fact merely drag and drop, but the coordinates of my drag source and
drag targets are too disparate for me to use a mouse for most of them
(and if i was really a keyboard user, i might have arranged it so that
i could use a keyboard to focus the search field in the browser, or
used the urlbar. I'm a power user, not a keyboard user, so i used the
mouse for this step.

the fact is that this process is really drag and dropping between
three windows, i'm only using the keyboard because it's expensive to
retarget and focus each of these areas.


- copy-and-paste is aimed at long term storage: if you write to the
clipboard you have to write all the flavours you think a recipient  
would

ever make use of! The clipboard often survives computer-restarts.


That's a clipbook, not a clipboard. Most clipboards do not survive
restarts, heck half th

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

Le 22-août-09 à 07:51, Ian Hickson a écrit :


 copy-and-paste is aimed at long term storage: if you write to the
clipboard you have to write all the flavours you think a recipient  
would

ever make use of! The clipboard often survives computer-restarts.


Drag-and-drop can also be for long-term storage -- drag whatever it  
is you

were going to copy to your clipboard to your clipboard


erm... can you give me the pixel coordinates of my clipboard please?


... same result. And
with the DND model in HTML5, you have to "write all the flavours you  
think
a recipient would ever make use of" in the same way as you describe  
for

copy-and-paste.


To me, as a server implementor, this is a problem: I will not offer  
any expensive type for DnD then, while I could offer them if I knew  
the target wishes to get, say, a PDF of the formula that was just  
dragged.



DND in HTML5 generates the data at drag time, not drop time.


Well, this is the choice of HTML 5 I am debating, precisely.
It all comes (consistently) together as a problem.

So I would insist to split the two set of events while keeping  
common,

of course, some of the interfaces to denote what can be transferred.


I see no reason to split them.


Maybe a reasonable approach would be to have on "simplified" API that  
corresponds to this one which merges the two while a finer grained API  
would differentiate them?


paul

smime.p7s
Description: S/MIME cryptographic signature

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

timeless,

So, erm, your conclusion should be we follow MicroSoft Windows copy- 
and-paste?
I still find that the immediate-clipboard-data-delivery is a safer  
mechanism.

It's funny to fall on such a dichotomy!

Le 23-août-09 à 15:47, timeless a écrit :


http://msdn.microsoft.com/en-us/library/f427xyk8(loband).aspx
With the advent of OLE, there are two Clipboard mechanisms in Windows.
The standard Windows Clipboard API is still available, but it has been
[...]
Note that Windows really does lump clipboard and drag and drop  
together.


Wasn't it a person of MicroSoft that started that thread?

Thanks for the pointers. We now have more words: supply data on demand  
or supply data immediately is the crucial difference.


The on-demand situation means: the application still must live for its  
on-demand flavours to be available.


We're now porting it all to a web-browser: an application is a web- 
page, a document that is. So on-demand copy-and-paste would stop being  
available as soon the document is gone, i.e., as soon as the page is  
changed following a link or a back, right?


I would feel bothered as a user.

paul

On Sun, Aug 23, 2009 at 12:11 AM, Paul  
Libbrecht wrote:
I am sorry that's not true: a system clipboard is filled  
independently of

the application.


No, I'm sorry you're unaware of how other operating systems work.


See here:
 http://developer.apple.com/documentation/Cocoa/Conceptual/CopyandPaste/Articles/pbFundamentals.html#/ 
/apple_ref/doc/uid/TP40004254


http://msdn.microsoft.com/en-us/library/9s5z33c4(loband).aspx

How data is inserted into a data source depends on whether the data is
supplied immediately or on demand, and in which medium it is supplied.
The possibilities are as follows.

Supplying Data on Demand (Delayed Rendering)

In the Data on Demand/Delayed Rendering case, the data does not
survive app death (unless the app chooses to force the data onto the
clipboard immediately before death).




smime.p7s
Description: S/MIME cryptographic signature

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

While re-reading the spec:

http://dev.w3.org/html5/spec/Overview.html#drag-and-drop-processing-model
I seem to understand that "supply data immediately" is the alternative  
proposed currently by HTML5. Right?


If yes, then it's clear that most server-implementors will not be able  
to offer rich flavours as possible conversion targets since you don't  
want to wait on a network load for a drag-start to fire!


Honestly, I find the whole DnD and CnP treatment in HTML5 quite much  
ad-hoc. It's welcome to have such an addition but it makes too many  
arrangements and still is hard to read.


What I would wish, and I think many many many others is a readable  
specification for copy-and-paste that meets large implementations and  
maybe later something for drag-and-drop.


paul

Thanks for the pointers. We now have more words: supply data on  
demand or supply data immediately is the crucial difference.


The on-demand situation means: the application still must live for  
its on-demand flavours to be available.


We're now porting it all to a web-browser: an application is a web- 
page, a document that is. So on-demand copy-and-paste would stop  
being available as soon the document is gone, i.e., as soon as the  
page is changed following a link or a back, right?


I would feel bothered as a user.




smime.p7s
Description: S/MIME cryptographic signature

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

Le 31-août-09 à 04:44, Ian Hickson a écrit :


Honestly, I find the whole DnD and CnP treatment in HTML5 quite much
ad-hoc. It's welcome to have such an addition but it makes too many
arrangements and still is hard to read.


Yes, it's a horrible model. It's one that had been implemented  
multiple

times before the spec existed, and implementations trump pretty much
everything except security problems when it comes to deciding what the
spec should say.


could I request a pointer to implementations or, even better, test- 
cases ?


Maybe they could encourage or disappoint server implementors.
If it's what I know of MSIE then it will discourage us.
(as far as I recall: unstable because of lack of complete security,  
only three flavours)


paul

smime.p7s
Description: S/MIME cryptographic signature

Re: DnD vs CnP (was Copy/Paste Events)

[Paul Libbrecht]

Which of them supports to transfer arbitrary flavours?
Generic image formats along of markup?

thanks in advance

paul


Le 03-sept.-09 à 15:00, Ian Hickson a écrit :


Currently, Safari and IE support this API to some extent in their
respective shipping products, and Firefox either supports it in the
shipping version or in the next version, I don't recall (it's in the
nightlies, either way).




smime.p7s
Description: S/MIME cryptographic signature

Re: clipboard events

[Paul Libbrecht]

This would be really nice.
After a very quick read-through, here are three first reactions:

- this seems to support the insertion in the clipboard's data of other types 
than what is currently commonly supported by browsers and the minimum quoted 
there; this is good and important. I think, for example, that such data as the 
iCal format would fit very well and be very useful here. Probably RDF/XML and 
PDF would be safe as well. I don't know how a format could enter the arena of 
"safe" (or "sanitized") formats... maybe that should be included in media-types 
registration...

- there is a sanitization process for HTML whose basis is described. Vey 
useful. I can't unfortunately answer if it prevents against attacks, it seems 
so. Allow me to request, however, that you include consideration for all 
children of HTML5, i.e. also MathML and SVG within the process.

- the sanitization process seems to forget the embedded images that need to 
be... "embedded" within the clipboard (as data: attribute-values maybe?). This 
is the biggest risk of transferring any HTML or XML based formats, to my taste, 
after the script elements, and it includes also the "call" to any "related 
material" (DTDs, imported OWL ontologies, CSS stylesheets, ...).


Le 23 déc. 2010 à 16:35, Hallvord R. M. Steen a écrit :
> looking at what Opera needs to support I drafted a specish text for clipboard 
> events. Something for this WG?
> 
> -- 
> Hallvord R. M. Steen, Core Tester, Opera Software
> http://www.opera.com http://my.opera.com/hallvors/

Could I also request that Opera considers the chapter 6 of MathML which 
specifies a pure-markup-based method to indicate alternate clipboard formats?

thanks in advance

paul

Re: clipboard events

[Paul Libbrecht]

This would be really nice.
After a very quick read-through, here are three first reactions:

- this seems to support the insertion in the clipboard's data of other types 
than what is currently commonly supported by browsers and the minimum quoted 
there; this is good and important. I think, for example, that such data as the 
iCal format would fit very well and be very useful here. Probably RDF/XML and 
PDF would be safe as well. I don't know how a format could enter the arena of 
"safe" (or "sanitized") formats... maybe that should be included in media-types 
registration...

- there is a sanitization process for HTML whose basis is described. Vey 
useful. I can't unfortunately answer if it prevents against attacks, it seems 
so. Allow me to request, however, that you include all children of HTML5, i.e. 
also MathML and SVG.

- the sanitization process seems to forget the embedded images that need to 
be... "embedded" within the clipboard (as data: attribute-values maybe). This 
is the biggest risk of transferring any HTML or XML based formats, to my taste, 
after the script elements, and it includes also the call to any "related 
material" (DTDs, imported OWL ontologies, ...).


Le 23 déc. 2010 à 16:35, Hallvord R. M. Steen a écrit :
> looking at what Opera needs to support I drafted a specish text for clipboard 
> events. Something for this WG?
> 
> -- 
> Hallvord R. M. Steen, Core Tester, Opera Software
> http://www.opera.com http://my.opera.com/hallvors/

Could I also request that Opera considers the chapter 6 of MathML which 
specifies a pure-markup-based method to indicate alternate clipboard formats?

thanks in advance

paul

Re: clipboard events

[Paul Libbrecht]

Oh boy... indeed it's a crab's nest!

I think it's rather a good idea to whitelist and blacklist and get it richer as 
the browser makers' awareness grows into a catalog of tags, attributes, and 
properties that need to be sanitized out or may be kept.

I'd rather suggest to start smallishly so that the feature itself is kept (and 
not "disabled for security reasons by upgrade beta+0.003"; I believe this is 
what happened to MSIE's Clipboard APIs) and let it grow as the catalog grows.

paul


On 4 janv. 2011, at 03:01, Robert O'Callahan wrote:

> I specifically avoided the issue of whether to whitelist or blacklist :-).
> 
> Whitelisting is preferably for security, but it turns that the obvious 
> whitelists break things. For example, some HTML editors expect to be able to 
> get pasted HTML from Microsoft Word containing -mso styles, which they will 
> then process into something else. So a CSS whitelist would need to include at 
> least some -mso stuff, and who knows what else


On 4 janv. 2011, at 06:51, Robert O'Callahan wrote:
> Probably not. One problem is that if some implementation supports 
> CSS-triggered scripts via some CSS extension, then ideally other 
> implementations would ensure that those extensions are stripped. E.g. Opera 
> doesn't support IE's expression() CSS extension, but if an Opera user pastes 
> untrusted HTML into a Web site, IE users may become vulnerable.
> Maybe your spec should just mention that something needs to be done here and 
> move on. This is a rather tough issue and it wouldn't be fair to make you 
> responsible for solving it :-).

Re: clipboard events

[Paul Libbrecht]

Hello,

sorry to be slow.


Le 31 janv. 2011 à 11:39, Daniel Cheng a écrit :

>>> Platform capabilities vary.
>>> - Windows will be unhappy if you use up all the custom clipboard formats
>>> (~65535 or so). There is no way to release formats once registered.
>>> - Mac uses UTIs which are strings but not MIME types.
>>> - GTK+ seems to support arbitrary MIME types.
>>> So for push support, Windows will be unable to natively support arbitrary
>>> string types.
>> Thanks. Do you think it is OK to say that we allow arbitrary strings but it 
>> may not be available on all platforms, and recommend that script authors 
>> stick to known MIME types?
> I'd go one step further and say that there should be some agreement on what 
> MIME types ought to be supported to try to insure somewhat consistent 
> behavior across different platforms.

Some types will be predefined but the door should stay opened for others.

> The way I'm working on implementing it (for drag and drop, though it applies 
> to copy and paste as well), arbitrary strings would not be accessible from a 
> non-DOM application, e.g. a native app like Word or Photoshop. Only a set of 
> known MIME types would be automatically converted to the corresponding native 
> type.

This is really really a hard task that I wish neither the spec nor browsers 
implement. Here's a use case that I would find usefully implemented by this 
spec. 

A website maker for, say, a shop for furnitures that knows they can go into "my 
home plan maker" through the clipboard will want to be able to produce and 
export a clipboard flavor that is unknown to both browser implementors and spec 
makers now.
Provided the user may say that the format is "safe" (safe as a picture for 
example), he would be able to drag-and-drop the furniture and get a 3D view 
inside "my home plan maker".

Such a scenario (there are zillions such) requires:

- arbitrary flavor strings

- knowledge of the flavor strings only from the web-site makers and other 
software vendor

- agreement on safety (that may be the hard part)

And unfortunately, arbitrary flavor strings cannot be MIME-types only.


Le 26 janv. 2011 à 06:26, Hallvord R. M. Steen a écrit :

> It intends to, but this has two open issues:
> * I assume that many OS clipboard implementations have an enumerated list of 
> "known" formats,

Just a few of them. (I'm trying to maintain pointers to that here: 
http://eds.activemath.org/transfers-literature )

> I'm not sure if all OSes can handle a request to push "text/foobar" data to 
> the clipboard.

Not an arbitrary mime-type, an arbitrary flavour conforming to the platform's 
specifics.

> Does anyone know if we can rely on such functionality being truly 
> cross-platform?

Do you mean a mapping from mime-type? No they are unfortunately extremely 
platform specific.

> 
> * There is not yet a clear way to push multi-part or alternate formats to the 
> OS clipboard from JS.

I don't think this should be needed.

> To use something like iCal, I guess best practise would be to push one 
> human-readable text/plain string for target software without iCal support, 
> and one alternate entry in iCal format.

Absolutely.

> I guess that can be done with 
>  DataTransferItem add(in DOMString data, in DOMString type);
> 
> I.e. spec for copy event would be
> * default action: copy any document selection
> * if default action is prevented: push data in drag data store (as 
> manipulated by setData() or items.add()) to clipboard, probably mapping 
> certain known values to native clipboard formats while doing so.

I think that this is good.

paul

Re: clipboard events

[Paul Libbrecht]

Le 31 janv. 2011 à 18:09, Ryosuke Niwa a écrit :
>> A website maker for, say, a shop for furnitures that knows they can go into 
>> "my home plan maker" through the clipboard will want to be able to produce 
>> and export a clipboard flavor that is unknown to both browser implementors 
>> and spec makers now.
>> Provided the user may say that the format is "safe" (safe as a picture for 
>> example), he would be able to drag-and-drop the furniture and get a 3D view 
>> inside "my home plan maker". 
> How do we make sure it works across different platforms?

Not *we* the spec-chatters, nor the browser implementors.
The web-developers or some library for them should make it work across 
different platforms.

>  I don't think we should be encouraging authors to create website that only 
> works with applications on a particular platform.

I disagree here: we have to accept that the clipboard data is reaching the end 
of the pure web hence we have to make the web-developers able to "speak the the 
language of the platform".

We sure should support standard formats when there are some but we should allow 
non-standardized formats to emerge.

> This is the problem.  If the format is platform-specific, we'll be exposing 
> platform-dependent API to the Web.  If we are to allow arbitrary data types, 
> then I would really like to provide an abstraction around it so that the Web 
> authors don't have to detect platform and do different things for each 
> platform.  And if that's unpractical or impossible, then we shouldn't allow 
> arbitrary data types.

I am convinced it is unpractical at this stage.
I am trying to encourage media-types writers to include statements about the 
clipboard names of their media-types. This could maybe be used one day but thus 
far there's very little (MathML and SVG only I think).

paul

Re: clipboard events

[Paul Libbrecht]

I am not sure I am entitled to any influence, except my registration to the 
mailing-list but I would insist to not limit in this way.

The clipboard or drag-and-drop transfers are the way to go from the web into 
something else.

They could maybe also be used to go from one site to another but the security 
concerns would be exactly the same. Wouldn't they?

paul



Le 31 janv. 2011 à 20:28, Daniel Cheng a écrit :

> I think there's value in exposing arbitrary MIME types. However, my proposal 
> is to effectively limit them to a web sandbox so it's only visible from HTML 
> pages for the reasons that you listed. Exposing arbitrary types between HTML 
> and the native OS has potential security issues as well--a page could access 
> some data that it shouldn't see (e.g. filesystem paths) and it could write 
> malformed data into the clipboard that could crash/corrupt other programs.
> 

Re: Overview of W3C technologies for mobile Web applications

[Paul Libbrecht]

Dominique,

I definitely agree this is a useful deliverable; I wish more EU projects be as 
careful in their survey as that!

I was looking to see if MathML was mentioned (I think it should as a future 
technology but it has almost zero coverage on the mobile world yet). But I 
realize that HTML is also not decomposed there. It seems to be assumed and 
mentioned in many places.

Am I right?
I would think a feature-by-feature analysis of what's in HTML4/5/XHTML and 
works on mobiles would be rather useful.

paul


Le 24 févr. 2011 à 16:03, Dominique Hazael-Massieux a écrit :

> (bcc to public-html and public-device-apis; please follow-up on
> public-webapps)
> 
> Hi,
> 
> As part of a European research project I'm involved in [1], I've
> compiled a report on the existing technologies in development (or in
> discussion) at W3C for building Web applications and that are
> particularly relevant on mobile devices:
> http://www.w3.org/2011/02/mobile-web-app-state.html
> 
> It is meant as a picture of the current state as of today, based on my
> own (necessarily limited) knowledge of the specifications and their
> current implementations.
> 
> I'm very much looking for feedback on the document, the mistakes it most
> probably contains, its overall organization, its usefulness.
> 
> I can also look into moving it in a place where a larger community could
> edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is
> interested in contributing.
> 
> I'll likely publish regular updates to the document (e.g. every 3
> months?), esp. if it helps sufficiently many people to understand our
> current ongoing activities in this space.
> 
> Thanks,
> 
> Dom
> 
> 1. http://mobiwebapp.eu/
> 
> 
> 

Re: clipboard data types registry?

[Paul Libbrecht]

Hallvord,

my belief is that such a registry is useful, but that it is ok to keep it 
minimal until the spec is released.

I tend to believe that this information is bound to the spec so I prefer to 
have it inside.
I would also prefer that for its authority value.

paul


Le 22 mars 2011 à 09:51, Hallvord R. M. Steen a écrit :

> The logical conclusion is that to write a really implementable spec with 
> complete information, we need some kind of registry, mapping MIME/clipboard 
> types to filtering algorithms..
> 
> This "registry" might be as simple as a  inside the spec itself, or it 
> might be something maintained outside of it. I guess it will be considered 
> too application-specific for the common MIME type registry, though?
> 
> Thoughts and views? Is a registry overkill, or useful? Should it be in-spec 
> or a separate entity with individual updates? If separate, does the W3C have 
> infrastructure for such stuff or do we put the information somewhere else?

Re: CfC: new WD of Clipboard API and Events; deadline April 5

[Paul Libbrecht]

Is the process currently requesting us to publish a draft so that comments can 
be gathered from the public?

paul

Le 29 mars 2011 à 13:37, Arthur Barstow a écrit :

> This is a Call for Consensus to publish a new Working Draft of Hallvord's 
> Clipboard API and Events spec:
> 
>  http://dev.w3.org/2006/webapi/clipops/clipops.html
> 
> If you have any comments or concerns about this proposal, please send them to 
> public-webapps by April 5 at the latest.
> 
> As with all of our CfCs, positive response is preferred and encouraged and 
> silence will be assumed to be agreement with the proposal.
> 
> Please note that during this CfC, Hallvord will continue to edit the ED and 
> will create a Table of Contents before the spec is published in w3.org/TR/.
> 
> -Art Barstow
> 

Re: CfC: new WD of Clipboard API and Events; deadline April 5

[Paul Libbrecht]

Well, so here are my comments:

---
I would reformulate:

> 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. Also, the 
> XML source could be placed in the clipboard with the appropriate 
> transformation occurring when pasting.


into:

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

> Also, the XML source could be placed in the clipboard with the appropriate 
> transformation occurring when pasting.

this is great!


---

Since the API should be that of HTML5, I think it is important to have a more 
direct link to the appropriate HTML5 section.
I also think the parameter names and arity should be repeated.

--

I believe an example of typical data-types really is needed (yes to one of the 
question there!).

HTML5 leaves it open to use native types or mime's media-types, but warns about 
spaces... it seems quite fussy.

Hence best practice is wished.

---

Le 29 mars 2011 à 16:46, Arthur Barstow a écrit :

> For this particular spec, it has been a very long time (2006) since it was 
> lasted published in /TR/ and since that version has no link to the latest ED, 
> one could easily conclude no work has been done on that spec. However, the 
> reality is Hallvord has done significant work on the spec and as such, it 
> facilitates "setting expectations" for us to publish a new WD.

Please receive my personal approval to publish as a WD, even with none of my 
issues addressed.

it's great to see it evolving.

paul





Le 29 mars 2011 à 13:37, Arthur Barstow a écrit :

> This is a Call for Consensus to publish a new Working Draft of Hallvord's 
> Clipboard API and Events spec:
> 
>  http://dev.w3.org/2006/webapi/clipops/clipops.html
> 
> If you have any comments or concerns about this proposal, please send them to 
> public-webapps by April 5 at the latest.
> 
> As with all of our CfCs, positive response is preferred and encouraged and 
> silence will be assumed to be agreement with the proposal.
> 
> Please note that during this CfC, Hallvord will continue to edit the ED and 
> will create a Table of Contents before the spec is published in w3.org/TR/.
> 
> -Art Barstow
> 

Re: paste events and HTML support - interest in exposing a DOM tree?

[Paul Libbrecht]

Hallvord,


Le 2 mai 2011 à 09:00, Hallvord R. M. Steen a écrit :
>> I am not at all against your proposal but I tend to see two reasons 
>> "against" it:
>> - I expect mostly the server to be providing the HTML, the javascript code 
>> does probably not need to process it further (they trust each other!)
> 
> I don't really understand this comment. We're talking about HTML that comes 
> from the clipboard, not from the server.

I think this is not at all contradictory. In many of the scenarios I have 
working for, the content to be put on the clipboard would come from a "luxury" 
knowledge structure on the server, one that has access to some semantic source 
and can infer useful representations out of it; these get put to the clipboard. 
An offline HTML would also be an example of it.

Hence... I would not really need a DOM representation.

(however, I wonder if a timer is going to be honoured for such a query to be 
finished somehow).

>> - I suppose the security processing may be done under an optimized 
>> processing which is not really necessarily DOM-exposed
> 
> Maybe, maybe not. To sanitise something that will be inserted into a DOM 
> structure, I would think the safest thing would be processing it according to 
> DOM algorithms while sanitising too.

Sure.

paul

Re: paste events and HTML support - interest in exposing a DOM tree?

[Paul Libbrecht]

Le 3 mai 2011 à 12:20, Hallvord R. M. Steen a écrit :
>> Regarding simplifying the pasted html to remove stuff that could be 
>> malicious, consider a rogue app that injects a script in the clipboard and 
>> expects the user to hit paste on his bank site.
> 
> Well, I've never seen a bank site with a rich text editor / 
> contentEditable-based feature customers are meant to use ;-)

"write a message to us" ??
Seems like a function an e-banking site offers and could support html one day.
Your other use case remains strong.

One thing that I like in the DOM exposure of the HTML flavour is that it 
prevents an amount of the threats related to parsing and that is good. In 
MathML (as in any xml fragment), the only dangers are, I believe:
- parsing time: related files inclusion (schema and dtd notably)
- image and/or style embedding
The first danger is eliminated if the fragment is exposed as a DOM fragment 
(provided the reference is removed of course).
The second danger is eliminated by the same techniques as those with HTML.


paul

copy events and content from server

[Paul Libbrecht]

Hello list,

As noted in the thread about security started by Halvord:

> In many of the scenarios I have working for, the content to be put on the 
> clipboard would come from a "luxury" knowledge structure on the server, one 
> that has access to some semantic source and can infer useful representations 
> out of it; these get put to the clipboard. 
> An offline HTML would also be an example of it.

but I am realizing that this is probably not possible to do because the only 
way to do obtain something from the server is to wait until a callback is 
called (and this is good so) at which time the copy event might be long gone 
already.

Would it be thinkable to *lock* the copy event until either a timeout occurs or 
an unlock is called? 

This way the script in the client would be able to fetch rich transformations 
from the server.

thanks in advance.

paul

PS: I would expect the same could be needed for the copy event which could want 
to write to the server.

Re: copy events and content from server

[Paul Libbrecht]

Ryosuke,

Le 3 mai 2011 à 21:15, Ryosuke Niwa a écrit :
>> Would it be thinkable to *lock* the copy event until either a timeout occurs 
>> or an unlock is called?
> No.  We definitely don't want to lock a local system resource for some random 
> web service that may potentially fail to release the lock.


I am not sure I made this clear.
The intent is to let javascript operate a lock.

Locking the system resource? Who spoke about that?
That'd lock maybe some of the continuation of a script in that page... nothing 
else. 
It could start to operate on the clipboard only after the unlock has occurred 
(or a focus-lost has happened which would have declared that the copy operation 
is aborted).

The random web-service in question is the web-server the user is currently 
using which could have delivered the information in question before, just did 
not because it did not know which information the user intended to copy!

If you look at desktop apps, there are many apps that do very rich copy 
operations and these take time with a modal dialog sometimes displayed.

paul

Re: clipboard events

[Paul Libbrecht]

Le 10 mai 2011 à 00:18, João Eiras a écrit :

>> I would just model the 'copy' (and 'cut') events exactly as a 'dragstart'
>> event, ideally so much so that you can literally use the same function for
>> both. (Canceling 'cut' would prevent the default deletion of the
>> selection, canceling 'copy' has no effect.)
> 
> Shouldn't canceling 'copy' prevent the data from being placed in the 
> clipboard ?

I am not sure of the above. I feel it should either be:
A- this (stop the copy, triggering an error)
B- or remove all of the script's modifications of the clipboard data and leaves 
it to the "native copy" 

The advantage with B is that it prevents scripts that would try to prevent a 
copy which is important I feel.

> That way a script can instead explicitly set the contents of the clipboard, 
> if some sanitization needs to be done.

I do not think this should be possible since writing to clipboard should only 
be doable with a copy event triggered by the environment (typically at the 
invocation of the standard gesture).

paul

Re: clipboard events

[Paul Libbrecht]

Le 10 mai 2011 à 09:13, Daniel Cheng a écrit :

> I would expect scripts to want one of two things when they're preventing the 
> default action:
> 1. They want to set their own data in the clipboard instead of what the 
> browser would normally provide by default--for example, a document editor 
> that does its own layout instead of using contenteditable.

That sure is desirable. I am not clear between "instead" or "on top of" (or 
both).

> 2. They don't want to allow someone to copy data--perhaps it's data on a 
> sensitive page.
> I think it's important to enable both.

I would be fierciely opposed to allow this and I remember Jonas Sicking was so 
as well.
This would certainly be a loss of freedom from users which I believe is not 
really nice.

But I realize that allowing 1 simply allows 2 as a special case.
We should make it more clear that sites that do that should ponder twice the 
loss of freedom thus removed.

paul

Re: clipboard events

[Paul Libbrecht]

Can you expand on what kind of protection this was?
Isn't it simply the same as a "copy static content", "copy text", or "really 
copy" kind of command?

paul


Le 10 mai 2011 à 09:41, timeless a écrit :

> Note that we only recently added protection for users against 'what
> you see is not what you copy' (serializers are now fairly css aware).

Re: copy events and content from server

[Paul Libbrecht]

Hallvord,


you seem to have not included João Eiras' answer:

Le 5 mai 2011 à 04:34, João Eiras a écrit :
> A synchronous XHR solves this use case and there are no magic locks.


Although I haven't explicitly tried to implement it and clearly feel it a 
synchronous XHR can block the UI in an ugly way, it can indeed be sufficient.


But, couldn't a better solution, not involving locks, be a variation of what 
you suggest:?

  event.clipboardData.pushDataFromRequest(flavour, xhr)

The big difference is that there is a chance for the user-agent to display that 
his copy action is being process. I think the flavour must stay in the hands of 
the script (as the map media-types -> flavors is currently very partial).

I'm surprised to be the only one pushing this considering the huge wealth of 
desktop-like services. Use cases such as copy-a-pdf-fragment from Google Docs 
Drawing, generate a complex ICS, or produce a good raster image from a 
graph-display...

paul

Le 17 mai 2011 à 02:30, Hallvord R. M. Steen a écrit :

>>> In many of the scenarios I have working for, the content to be put on the 
>>> clipboard would come from a "luxury" knowledge structure on the server, one 
>>> that has access to some semantic source and can infer useful 
>>> representations out of it; these get put to the clipboard.
>>> An offline HTML would also be an example of it.
>> 
>> but I am realizing that this is probably not possible to do because the only 
>> way to do obtain something from the server is to wait until a callback is 
>> called (and this is good so) at which time the copy event might be long gone 
>> already.
> 
> Indeed.
> 
>> Would it be thinkable to *lock* the copy event until either a timeout occurs 
>> or an unlock is called?
> 
> It sounds like a quite "advanced" use case. I briefly considered something 
> like event.clipboardData.pushContentsOfURL('/foo/bar') but that would be way 
> to limited in options - POST/GET, post data etc. I would like to defer this 
> to later and see if we get more demand for it. Overall, the push for web 
> applications is a lot about removing logic from the server and adding more on 
> the client's side, so I'm unsure how common this state (when the server knows 
> significantly more than the client-side logic about what should be placed on 
> the clipboard) is and will be going forward.

Re: risks of custom clipboard types

[Paul Libbrecht]

Hallvord, 
The risks is latent but it should be possible for a user to accept that a given 
site produces a given type. I do not think it is thinkable to avoid 
platform-dependent code when going to a platform specific OS. 

Everyone knows platform specific code is harder to maintain and should be 
avoided as much as possible, nonetheless, lots of it happens. I feel there is 
no chance, before everyone agrees on a mapping between clipboard flavors and 
media-types, that platform specific code in scripts for a rich copy and paste 
can be done.

I don't fear for Linux clipboards, they are almost web-like so they have a much 
better chance than any other OS.

Ryosuke,
why would sensitive information be readable or writable?

paul


Le 17 mai 2011 à 06:34, Hallvord R. M. Steen a écrit :

>> Some types will be predefined but the door should stay opened for others.
> 
> I think what you are asking implies that the UA should "get out of the way" 
> and just pass the arbitrary string the script gives it to the OS.
> 
> Then you risk that script authors need to
> a) start writing platform-detection and OS-specific code
> b) be forced to handle cases like a Windows OS whose list of possible 
> clipboard types is full
> 
> I think in particular a) is a very bad consequence. Browser sniffing is an 
> awful failure, holding the web back, preventing compatibility and 
> competition. We should certainly avoid specifying something that will be even 
> worse if we can. (I see scripts detecting Windows and Macs only and not fall 
> back to anything but broken clipboard support for other platforms if we go 
> down this route).


Le 17 mai 2011 à 07:57, Ryosuke Niwa a écrit :

> I'm also concerned that website may access sensitive information such as 
> local file path and user name via clipboard if we allow arbitrary format.

Re: Filtering clipboard MIME types (was: Re: clipboard events)

[Paul Libbrecht]

Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :

> To get a table started in the spec, could you give me a small list of (MIME) 
> types one should mandate the UA to be aware of and be able to "roundtrip" 
> to/from native clipboard types? Just off the top of your head? The typical 
> Web MIME types would of course be something along the lines of
> 
> text/plain
> text/html
> image/jpg
> image/gif
> image/png
> application/xhtml+xml
> image/svg+xml

I would like to add all of the 3 MathML flavors:

- application/mathml-presentation+xml
- application/mathml-content+xml
- application/mathml+xml

> What about e.g. RTF?

I feel it fits.

paul

Re: risks of custom clipboard types

[Paul Libbrecht]

Le 17 mai 2011 à 09:21, Ryosuke Niwa a écrit :

> On Tue, May 17, 2011 at 12:11 AM, Paul Libbrecht  wrote:
> Ryosuke,
> why would sensitive information be readable or writable?
> 
> Because it has been available through clipboard.  e.g. a popular productivity 
> application puts a local file path in link elements whenever you copy & paste 
> table cells.

Interesting.

A "link" in the sense of a web-link with appropriate media-type or flavour is, 
to my understanding, something ok. It's a path only (it's not access to that 
path) and it is even formulated for "web purpose". I agree it's a risk but 
since it's only when the user pastes intentionally, I don't think it is a risk 
to be excluded.
Actually, if on my Mac now, I copy a file from the Finder and paste plain text 
in jEdit, I get the file-name, that's ok I think.
 
A "link" in the OLE sense has no way to be allowed.

You did mean the first form, did you not?

paul

Re: risks of custom clipboard types

[Paul Libbrecht]

Le 17 mai 2011 à 18:20, Ryosuke Niwa a écrit :

> On Tue, May 17, 2011 at 12:26 AM, Paul Libbrecht  wrote:
> I agree it's a risk but since it's only when the user pastes intentionally, I 
> don't think it is a risk to be excluded.
> 
> I don't think it's okay.  I didn't even save the file and file path was 
> invisible to a user.  As a user, I would have never guessed that I was 
> revealing my local file path and thereby my user name when I pasted the 
> content.

On my mac, as far as I know, this can only happen if I copied the the file 
explicitly (as a file, not as a content). Pasting in some web-page means I want 
to transmit the information of the clipboard to the page.

paul

Re: risks of custom clipboard types

[Paul Libbrecht]

Le 17 mai 2011 à 18:39, Boris Zbarsky a écrit :
>> On my mac, as far as I know, this can only happen if I copied the the
>> file explicitly (as a file, not as a content). Pasting in some web-page
>> means I want to transmit the information of the clipboard to the page.
> You want to transmit the file contents.  You don't want to transmit the 
> location of the file on your disk.  Certainly most users don't.
> To be clear, we (Mozilla) would consider this an unacceptable privacy breach. 
>  This is why we (and other browsers) don't send the full path for file inputs 
> too... this case is no different.

So you (Mozilla) would not accept to include URL-list as acceptable flavor to 
be read from the clipboard at paste time if that URL-list contains file URLs. 
Correct?

Ryosuke, do you see other possible flavor exploits with local-paths?
(you seemed to have something more precise in mind)

paul

Re: Filtering clipboard MIME types (was: Re: clipboard events)

[Paul Libbrecht]

Le 17 mai 2011 à 19:06, Daniel Cheng a écrit :

> I would like to add all of the 3 MathML flavors:
> 
> - application/mathml-presentation+xml
> - application/mathml-content+xml
> - application/mathml+xml
> 
> paul
> 
> I don't think we need all 3. Why not just application/mathml+xml?

Daniel,

you do mean all three MathML flavors, right?

The reason they are each useful is that:

some applications can do MathML-presentation and not content (example: MS Word)
some applications can do MathML-content and would loose information by 
receiving presentation (example: Maple, with a limit expression, I think a 
spreadsheet could also)
some applications just do not know or care, for them the generic flavor is ok
some applications will do a conversion content-to-presentation in a way better 
than others, in particular if the language context is properly considered (e.g. 
considering the varying numbers' syntax)


paul

Re: risks of custom clipboard types

[Paul Libbrecht]

Le 17 mai 2011 à 19:14, Daniel Cheng a écrit :

> I actually did implement reading arbitrary types from the clipboard/drop at 
> one point on Linux just to see how it'd work. When I copied a file in 
> Nautilus, the full path to the file was available in several different 
> flavors from the clipboard X selection. In order to prevent attacks of this 
> sort, we'd have to determine the full set of types that file managers and 
> other programs could potentially populate with file paths and then explicitly 
> try to clean them of file paths. It's much easier to just go the other 
> direction with a whitelist.

This was certainly at least copied in plain-text as well, or?
The risk is here today then already, correct? (even with traditional forms and 
a quick onchange that makes it invisible).

paul

Re: risks of custom clipboard types

[Paul Libbrecht]

Le 17 mai 2011 à 19:31, Daniel Cheng a écrit :

> On Tue, May 17, 2011 at 10:18, Paul Libbrecht  wrote:
> 
> Le 17 mai 2011 à 19:14, Daniel Cheng a écrit :
> 
>> I actually did implement reading arbitrary types from the clipboard/drop at 
>> one point on Linux just to see how it'd work. When I copied a file in 
>> Nautilus, the full path to the file was available in several different 
>> flavors from the clipboard X selection. In order to prevent attacks of this 
>> sort, we'd have to determine the full set of types that file managers and 
>> other programs could potentially populate with file paths and then 
>> explicitly try to clean them of file paths. It's much easier to just go the 
>> other direction with a whitelist.
> 
> This was certainly at least copied in plain-text as well, or?
> The risk is here today then already, correct? (even with traditional forms 
> and a quick onchange that makes it invisible).
> 
> It is not because Chromium specifically clears the plain text type if it 
> detects a file drag.

So file-flavour is something special that should be always filtered??
(in DnD or in CnP), which should be warned against in the spec?

Ryosuke, can you confirm this is the only risk you were talking about?

paul

Re: risks of custom clipboard types

[Paul Libbrecht]

Le 17 mai 2011 à 20:05, Ryosuke Niwa a écrit :

> So file-flavour is something special that should be always filtered??
> (in DnD or in CnP), which should be warned against in the spec?
> 
> Ryosuke, can you confirm this is the only risk you were talking about?
> 
> No.  There are some applications that embed sensitive information such as 
> local file path and user name inside a content put into clipboard without 
> notifying the user.  As far as I'm concerned, giving websites access to such 
> information is not acceptable.
> 

Please be more precise with "some applications".

There could be some applications that put the email of the user (or the sender 
of the mail being read) in the plain text variant without the user knowing!

paul

Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)

[Paul Libbrecht]

Le 19 mai 2011 à 02:11, João Eiras a écrit :

> getData and setData must work outside clipboard events, like when clicking 
> paste/copy/cut buttons on a toolbar. The clipboardData object needs to be 
> exposed on the window, like in IE.

I fully disagree here.
This is exactly what has made the CnP API of MSIE a plague with a very bad 
press coverage.

getData and setData can only be used within the event processing which must be 
triggered by the user-agent at a user-recognizable invocation of the copy/cut 
or paste command.

That some browsers allow differently for "trusted sites" is ok to me but should 
not be an essential focus of this spec I find.

> To handle the getData case, I've thought of adding a proxy clipboard per 
> browsing context. Read operations read from the proxy clipboard, write 
> operations write to the proxy and system clipboards. User initiated actions 
> like dropping, or pasting would update the proxy clipboard with the system 
> clipboard contents, prior to the event being dispatched on the webpage.

I *think* that is a good strategy.

paul

Copy prevention... up-and-running

[Paul Libbrecht]

While the discussion about preventing abuse in clipboards is happening, allow 
me to suggest something I recently found:

In the page below is a fairly simple script that succeeds in preventing the 
user to select with the mouse, hence copy, in Firefox 6, Safari 5.1, and a few 
others.

http://www.diakadi.com/guadeloupe/feroce_d_avocat.htm

The workarounds include: use Camino, print-preview and select there, use select 
all.

Can something be done to prevent this prohibition?
Do we want that?

paul

Re: CfC: new WD of Clipboard API and Events; deadline April 5

[Paul Libbrecht]

Le 5 sept. 2011 à 16:50, Glenn Maynard a écrit :

> On Mon, Sep 5, 2011 at 6:13 AM, Hallvord R. M. Steen  
> wrote:
> Pretty much everything in this spec can be abused to cause nuisance.
> 
> Personally, I'm less than thrilled to see an API giving sites more ability to 
> mangle what I copy.  Clipboard hijacking scripts that add "read more at..." 
> spam to copied text make it painfully clear that sites will actively abuse a 
> clipboard API; I'd sooner see sites have less control, to prevent this gross 
> abuse, not more.  Browsers should copy only what I tell them to copy.

Glenn,

there was a long thread about that at the TAG mailing list.
  http://www.w3.org/mid/affab130-b693-4ac9-91e6-b6834e57b...@w3.org

Unfortunately, there is no way to discriminate a page that tries to be useful 
and a page that tries to lower your actions (as the other one I just sent the 
webapp mailing list which, btw, uses no clipboard API).

Such a lack of discrimination was also there for JavaScript which could create 
DoS attacks easily. You can disable javascript but then, who does? It did not 
become so fashionable anymore... same for applets, flash, ...

Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash 
advertisement 100% cpu) and I am confident they will not that some pages mingle 
with their copy ability or actually provide a service to do so.

I'd love to hear your feedback but that's how I feel things and I think we just 
have to accept it: new technology, new risks, positive and negative.

paul

Re: riks of the new clipboard operations API (was: Re: CfC: new WD of Clipboard API and Events; deadline April 5)

[Paul Libbrecht]

Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit :

> On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht  wrote: 
> Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash 
> advertisement 100% cpu) and I am confident they will not that some pages 
> mingle with their copy ability or actually provide a service to do so.
> 
> Sorry, I'm having trouble parsing this.
> 
> My experience so far is that people are aggravated by pages that insert ads 
> into copied text, but not quite enough to stop them from using a page.  They 
> grumble and delete the ad.  That's the most annoying category of abuse, in my 
> opinion: not bad enough to strongly discourage its use, causing it to spread, 
> but bad enough to continuously annoy users.

They will provide feedback and/or prefer sites that do not do that.
The offer is diverse enough for this.
That's what the paragraph above says.

I agree that the API indeed brings in new possibilities of abuse and new 
utilities, they cannot be discerned except by an end user.

You are are right we need to be aware of the risks.

The tracker injection is, to my taste, relatively mild.
Hidden anchors would be considerably worse.

paul


> 
> I'd love to hear your feedback but that's how I feel things and I think we 
> just have to accept it: new technology, new risks, positive and negative.
> 
> It's acceptable for new technologies to have negatives, of course; the 
> positives need to balance the negatives.
> 
> To be clear, I don't mean that this abuse is newly exposed by this API.  It's 
> an abuse that's been spreading lately, using hacks with existing APIs.  I 
> meant that it shows that people will broadly abuse anything that lets them 
> fiddle with the clipboard; in other words, this isn't a theoretical problem.
> 
> I'd hoped to see browsers adjust behavior so clipboard copying happens before 
> anything else (before firing DOM events at all), making it more difficult for 
> pages to fiddle with the selection before the copy occurs, but this API makes 
> that approach useless; it officially blesses the entire category of 
> messing-with-what-the-user-copies, so it'd never be fixable.  That's 
> frustrating.
> 
> (As an aside, it would still be possible to do this sort of clipboard 
> hijacking even if that was done, by fiddling with the selection when the 
> selection change happens instead of waiting for the copy.  From my 
> experiments, though, that approach is much more brittle, which is a deterrent 
> in and of itself.)
> 
> We can't stop pages from being annoying, but we should definitely keep in 
> mind the annoying things that are actually being done in the wild today, and 
> be aware of the things a new API might exacerbate.
> 
> -- 
> Glenn Maynard
> 

Re: CfC: new WD of Clipboard API and Events; deadline April 5

[Paul Libbrecht]

Le 7 sept. 2011 à 09:43, Hallvord R. M. Steen a écrit :
> What helps "average" users is IMO mostly a UI question ;-)
> 
> I'd predict that this will be handled much like popup windows. They became a 
> nuisance for users, so UAs evolved to develop popup blocking, various types 
> of UI for opt-in enabling et cetera. If clipboard event abuse becomes a 
> severe enough problem, UAs will respond. Also, nothing stops UAs from giving 
> the user opt-in measures before enabling this functionality in the first 
> place, and some UAs already have opt-in mechanisms when scripts want to use 
> the OS clipboard that could or should be extended to also enable/disable 
> clipboard events. Doing this in a user-friendly way is a fair playing field 
> for UAs to compete on, and not something we should figure out now and put in 
> the spec.

I'd like to agree but we have to be a bit more nuanced.
I think we should avoid the historical errors of MSIE. Though I may have a 
biassed view of history, here's how I see that.

The MSIE API for clipboard has been there since IE 6, long long long ago. But 
it was very quickly pointed to as a very evil feature (allowing web-pages to 
read clipboard without asking) and became limited to "trusted sites"; it was 
not really made useful.

By now, we know how to avoid the aforementioned problem but there are 
suspicions of other problems.

If we do not convince someone like Glenn, we run the risk of the same failure, 
so we have an interest to do so.

Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit :
> To be clear, I don't mean that this abuse is newly exposed by this API.  It's 
> an abuse that's been spreading lately, using hacks with existing APIs.  I 
> meant that it shows that people will broadly abuse anything that lets them 
> fiddle with the clipboard; in other words, this isn't a theoretical problem.
> 
> I'd hoped to see browsers adjust behavior so clipboard copying happens before 
> anything else (before firing DOM events at all), making it more difficult for 
> pages to fiddle with the selection before the copy occurs, but this API makes 
> that approach useless; it officially blesses the entire category of 
> messing-with-what-the-user-copies, so it'd never be fixable.  That's 
> frustrating.


As said earlier, the "fiddle" is expected to be useful... we can't remove it.

To the risk of an annoying clipboard service of the web page, I would propose 
the solution of Jonas Sicking: a "copy text command" (CTRL-SHIFT-C maybe?) that 
would ignore the scripts.
I note that it's not the spec's job to specify such.  It's the job of informal 
material around the spec, such as this list, to suggest workarounds to 
recognized risks.

paul

Re: Obsolescence notices on old specifications, again

[Paul Libbrecht]

Tab,

Le 23 janv. 2012 à 22:03, Tab Atkins Jr. a écrit :
> We have repeated evidence that pretending these specs aren't obsolete
> and useless hurts web implementors and authors.  We're targeting the
> web with our specs, so that's extremely relevant for us, more so than
> non-web industries dealing with personal regulatory issues.

I personally agree that developers need to be directed to the latest spec.
Some warning should be there.
But a person outside the W3C should not be expected to be taken to some draft 
document for its implementation.

The word obsolete about a spec that has no REC-status replacement really gives 
outsiders the impression that "the whole thing is obsolete" (there would be no 
recommendation of the W3C for my purpose? I thought they did).

Another formulation needs to be found, even something such as "about to be 
obsoleted".

> Ignoring the regulatory issues for a moment, the non-web industries
> harm themselves (or rather, the down-level authors writing content for
> the things those industries are producing) by attempting to use these
> obsolete specs as well, since they'll be producing things that don't
> match the public web.

To my personal taste this feels in line with the craze of running after the 
latest update all the times.

The way Chrome does it without warning you and Firefox screams to update to a 
new version every other month has the reasons to destabilize people!
How can I be sure that my neighbours' website is going to play tomorrow?
(he doesn't follow the latest trends yet, he'll learn)

A good example of such craze is the Flash player: no RECs here, just one 
proprietary implementation.
Flash upgrades have killed old deployments!
Adobe or MacroMedia can't be blamed... no promise was made, no standard was 
declared to be followed (at least recently).

paul

Re: Installing web apps

[Paul Libbrecht]

Le 1 févr. 2012 à 20:03, Ian Hickson a écrit :
>>  - a calendar client
> 
> There are lots of calendar clients written on the Web today.
>>  - an IMAP client
> There are lots of mail clients written on the Web today.

These are not web-apps that can work offline longer than 2 minutes.
Android's GMail app is getting to be as bad.

But otherwise, many imap clients exist as desktop or in-device applications.
I think Tim is asking for something in the middle and the distance is pretty 
big.


>> As a user when I install an app, I want to be able to give it access to 
>> a selection of:
> 
> Providing access to these things when the app is installed is IMHO a net 
> worse security model than granting access to these things implicitly when 
> the feature is needed.

And this is the reason the normal model has been: no security model at all.
Desktop applications have been living well with some web interfacing... 
installing a web-app could start where desktop applications are then gradually 
go less demanding?

Android goes somewhat in this direction with its app-security model...

> Of the things you list, the following are already possible without an 
> up-front permission grant, in a manner more secure than an up-front grant:
> 
>> - Program storage, to a limit
>> - Whether it is permanently available or downloaded or cached for a while
>> - Access to RAM at runtime, to a limit

I don't know how well such limits are handled by browsers, I've seen a lot of 
browser crashes for these reasons. Pointer?

>> - CPU time when in background, to a limit

Same thing, the user-warning on slow script is not that limit!

>> - Access to the net, maybe to a bandwidth limit

really?

>> - Ability to access anything on the web
> 
> What's the use case for this?

An editor importing a web-page?

>> (I'll want to sync its local and shared data storage between all my 
>> devices too)
> 
> That's possible without the site knowing anything about it. Chrome already 
> does it to some extent.

Typical state of a young feature: Chrome does it without asking me, Firefox 
asks me if I want to use my own server ;-).

>> If I can't give power to apps, then the web app platform cannot compete 
>> with native apps.
> 
> There's plenty of things we can do to make the Web platform more 
> compelling and a better competitor to native apps, but adding "installing" 
> isn't one of them. That would in fact take one of the Web's current 
> significant advantages over native apps and kill it.


when you consider the success of app-stores, I think that I do not share this 
view.

paul

Re: Installing web apps

[Paul Libbrecht]

Le 1 févr. 2012 à 21:03, Boris Zbarsky a écrit :

>> Android goes somewhat in this direction with its app-security model...
> 
> With all due respect, the app-security model on Android is a joke. Everyone 
> just clicks through the permissions grant without even reading what's being 
> requested, because _every_ app asks for a bunch of permission grants up front 
> and won't run until you grant them.  Any random game wants permission to do 
> arbitrary internet access (as mentioned earlier on this thread, already a 
> security hole if you happen to be behind a firewall when you run the game), 
> listen to your phone conversations, read your addressbook, etc.  Perhaps they 
> do have some sort of rarely-used features that require such access, but the 
> model forces them to ask for all the permissions immediately... and the user 
> is trained to just accept.

No, no app has yet demanded me my addressbook access and some apps add 
advertisement: and hey, I do not need network.

That's the general problem with demanding permissions... I agree it's in 
infancy.

However this is for an APP download, where you expect some level of trust 
(basically the essence of an app store's objective?).

If a random web-page starts to ask me the same, I would surely be talking 
differently!


Tim, did you say any reasons why the current widget model that can be installed 
as a sort of app on mobile devices is not an approximation of your desires?

paul

Re: [clipboard] Event definition

[Paul Libbrecht]

Ms2ger,

the same old issue with referencing a released spec or not... that was heavily 
discussed!
Or am I wrong?
Is there any reason that makes that sentence obsolete in DOM 2?
I would have no issue that the clipboard document references both but it would 
become unreleasable if it had to rely on specifications that are not released.

MathML for CSS had to suspend its becoming of a REC because CSS 2.1 and 3 
weren't released yet... and this sounds like normal. It did not take very long 
in this case.

I like Hallvord's response to this.

paul


Le 9 févr. 2012 à 13:26, Ms2ger a écrit :

> Hi Hallvord,
> 
> At 
> ,
>  a reference to DOM *2* Events is made; it should be updated.
> 
> Also, the initClipboardEvent method should be removed in favour of a 
> constructor, as described at 
> .
> 
> HTH
> Ms2ger
> 

Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)

[Paul Libbrecht]

This discussion seems to raise the issue of what happens to URLs to images (or 
other embedded objects) that are unresolved but become resolved when pasted.

E.g. file:///Users/anton/Library/AddressBook
(if that ever made sense)

Should these also be sanitized away so that they do not, suddenly become 
attempted?

Paul


Le 10 févr. 2012 à 22:36, Ian Hickson a écrit :

> On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote:
>> 
>> Now, I don't think that was the question Daniel Cheng was asking. If you 
>> look at the HTML/XHTML specific instructions for the paste event (in the 
>> processing model section: 
>> http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see 
>> that it specifies quite a bit of parsing and such. The goals are:
>> 
>> * Resolve URLs and links - the page script won't know the base URI to 
>> resolve against (on Windows this is in the CF_HTML format's meta data 
>> and the page script doesn't get access to it)
> 
> Well presumably all the URLs should be made absolute in the copy/drag 
> code, not the paste/drop code. The paste/drop code has no context.
> 
> No parsing needed for that though, the URLs are already resolved in the 
> DOM so it's just a matter of serialising them.
> 
> 
>> * Make it possible to paste HTML from a local application that embeds 
>> local resources () and enable page scripts to 
>> process and upload said resources
> 
> How would you distinguish this case from a hostile app tricking the user 
> into copying HTML that has pointers to sensitive local files?
> 
> 
>> * Optionally do extra privacy or security-related filtering if the UA 
>> implementor considers it useful
> 
> I wouldn't do this via parsing, but DOM filtering. That's the semantic 
> layer. A whitelist DOM filter will ensure that only the stuff the browser 
> thinks is safe can get through.
> 
> 
>> So, I think the question Daniel is asking, is: why don't we process URLs and
>> local resources this way if HTML data is drag-and-dropped to a page? Should
>> this processing be moved to the DnD spec?
> 
> I guess we could say that HTML dragged from the page could have URLs 
> "absoluted" in the serialisation. The other stuff doesn't seem necessary.
> 
> -- 
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 

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

[Paul Libbrecht]

Hello Hallvord,

I think it is a very good idea if such a method would be available from the 
point of view of a web-app author.

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.


Le 17 févr. 2012 à 18:53, Ryosuke Niwa a écrit :
> I like the idea of letting authors dynamically detectthe supported mime 
> types. But providing methods on the interface object seems rather unusual.

It sounds like ok to me. An alternative would be to have a Capabilities 
object...

> Also, I'm thinking if there are cases where the supported mime types change 
> dynamically without reloading the page.

(I hope I patched correctly)

Yes, it does happen: I think I know that in Windows the supported flavour-names 
depend on the launched applications. On Mac it depends on the applications 
whose descriptor has been loaded (by the Finder I think, it might also be those 
that have been launched once). 
At least an application download and launch can cause a change in the supported 
media-types of the OS.

However, would the browsers be informed of such a change?
Would they be able to consider a given type as being safe and not needing a 
sanitization?

paul





Le 17 févr. 2012 à 14:23, Hallvord R. M. Steen a écrit :

> Hi,
> I have an open issue noted in the spec - seems no implementor has worked on 
> this yet so I'm throwing it out here to see what you all think.
> 
> Given that
> a) We can't give a random script access to every format on the clipboard for 
> security/privacy reasons (per earlier feedback from Chrome/WebKit devs and 
> common sense)
> b) Certain clipboard formats have meta data or special formatting 
> requirements that mean the implementation needs to do a bit of processing on 
> reading/writing (thinking of Windows' CF_HTML)
> c) Text may apparently be placed on the clipboard in different encodings, an 
> implementation may have to do conversions
> d) Clipboard contents can also be file references, in which case we'll make 
> the *file* and not the actual clipboard data available
> 
> - it's obvious that the implementation needs to do a bit of work to "support" 
> reading/writing given types of data from/to the native clipboard.
> 
> Hence, there should be a way a script can check if a clipboard format is 
> registered and whether the implementation allows writing this format to the 
> clipboard.
> 
> My idea (at the moment) is to define a method on an interface (not on 
> instances, on the interface object itself) like this:
> 
> ClipboardEvent.isTypeSupported('mime/type')
> 
> or, perhaps:
> 
> DataTransfer.isTypeSupported('mime/type')??
> 
> (but it's more clipboard-specific and maybe it's confusing to mix it with the 
> DnD stuff?)
> 
> An application can then for example do something like
> 
> if( ClipboardEvent.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
>   // prepare fancyformat content and place on clipboard
> }else{
>   // fall back to for example put xml-data-as-plain-text or 
> json-data-as-plain-text
> }
> 
> I'm suggesting to define this method on the interface object because it helps 
> web applications do feature detection early.  It could of course be defined 
> on instances
> 
> addEventListener('copy', function(e){
>   if( e.isTypeSupported( 'vnd.supersoft/fancyformat' ) ){
>   // prepare fancyformat content and place on clipboard
>   }else{
>   // fall back to for example put xml-data-as-plain-text or 
> json-data-as-plain-text
>   }
> })
> 
> but then a feature/compatibility test would have to be deferred until a point 
> where the user potentially has done a lot of work in the web application.
> 
> Thoughts?
> 
> -- 
> Hallvord R. M. Steen
> Core tester, Opera Software
> 

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

[Paul Libbrecht]

Le 17 févr. 2012 à 19:23, Daniel Cheng a écrit :
> Any MIME type support restrictions that apply to clipboard MIME types will 
> almost certainly apply to DnD MIME types as well. Therefore, it wouldn't make 
> sense to tie it to ClipboardEvent.

Not sure to understand what "lie" means.
Maybe you mean that it is a lie to use flavour names that are native names?
Can you please explain?

> Also, what does it mean to be "supported"? In new versions of Chrome, any 
> kind of MIME type is supported in the sense that you can set data for any 
> arbitrary type, and it can be understood by any browser that uses the same 
> native conventions (I'd be happy to work with any other developers interested 
> in making sure this works across different browsers on the same computer).

This sounds like a huge security leak.
What if trusted web-site docs.google.com receives a paste of easy.cms.com that 
just got hacked with a hack that a kind html containing a script that reads the 
cookie when executed?

paul

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

[Paul Libbrecht]

Le 17 févr. 2012 à 19:25, Ryosuke Niwa a écrit :

> On Fri, Feb 17, 2012 at 10:10 AM, 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.
> 
> Realistically, I don't think we'll ever let the wild Web get/set arbitrary 
> data like that. But maybe we can do that for privileged websites (ones that 
> the user trusts).

I'm easy here. I sure do not want to slow down progress of this spec.
I think it makes sense but well...
(I find UTIs rather sexy since they have inheritance which media-types do not 
have).

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

> Yes, it does happen: I think I know that in Windows the supported 
> flavour-names depend on the launched applications. On Mac it depends on the 
> applications whose descriptor has been loaded (by the Finder I think, it 
> might also be those that have been launched once). At least an application 
> download and launch can cause a change in the supported media-types of the OS.
> 
> Right. These will become problems if we decide to expose all platform types.
> 
> However, would the browsers be informed of such a change? Would they be able 
> to consider a given type as being safe and not needing a sanitization?
> 
> I don't think that's possible without some sort of pre-knowledge about how 
> the data is processed. In practice, we always hard-code this kind of 
> information somewhere so I'm even not sure if such an elaborate behavior can 
> be implemented.

If anyone is willing to consider trusted web-sites (and MSIE already does?) 
then it is worth included.

paul

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

[Paul Libbrecht]

WHEN I registered a media-type on the ietf list I have been quite much hit as 
the first comment "one says media-type nowadays". And indeed MIME is meant for 
email originally.

So I guess politically media-type is a requirement.
Should I dig for a formal requirement?

paul


Le 18 févr. 2012 à 00:54, Hallvord Reiar Michaelsen Steen a écrit :
>> 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: (aside) MIME type

[Paul Libbrecht]

>> WHEN I registered a media-type on the ietf list I have been quite much hit 
>> as the first comment "one says media-type

sorry for the capitalization

>> nowadays". And indeed MIME is meant for email originally.
>> 
>> So I guess politically media-type is a requirement.
>> Should I dig for a formal requirement?
> 
> HTML and other specifications use MIME type.

Well, I think it's the duty of the W3C to use the vocabulary of the people that 
define this kind of thing.
Do you have a pointer to a recommendation usage of mime-type?

> Media type is ambiguous with CSS.

Why?

paul

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

[Paul Libbrecht]

Does this include an ability for a page to say that a media-type is supported?
(does it not appear natural?)


I won't brag about native type names. 
I still find they're good but they're really not well ruled so it's ok.

paul


Le 18 févr. 2012 à 01:16, Hallvord Reiar Michaelsen Steen a écrit :
> 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
> 
> 
> 
> 
> 
> 

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

[Paul Libbrecht]

Le 18 févr. 2012 à 16:25, Hallvord R. M. Steen a écrit :

>> Does this include an ability for a page to say that a media-type is 
>> supported?
>> (does it not appear natural?)
> 
> Hm.. you mean a page should be able to say "Hello web browser, I just lve 
> processing application/pdf data from the clipboard" ? I don't see the use 
> case for that. If I'm misunderstanding you please clarify :-)

It means that if pdf is in the clipboard the paste command can stop being 
greyed out!
Otherwise the user is left to try and be told by the web-page: please please do 
it!

Similarly, shouldn't something such as
> if(event.clipboardData.isTypeSupported('foo/bar')) ...

be callable before the event is triggered?
This way the page can display the necessary invites to the user to make it 
clear that something can be copied?

paul

Re: [Clipboard] Processing model feedback (and other)

[Paul Libbrecht]

Le 19 févr. 2012 à 10:46, Anne van Kesteren a écrit :

> On Sat, 18 Feb 2012 16:45:07 +0100, Hallvord R. M. Steen  
> wrote:
 "Firing an event" surely should be specified elaborately elsewhere. I 
 added another reference to DOM2-Events (though "fire" probably is used 
 without being precisely spec'ed there..).
>>> 
>>> Yes, you need to reference DOM4. Otherwise EventInit and such are undefined 
>>> too.
>> 
>> Oops, haven't fixed this yet. What is the best (most stable) URL for DOM 
>> Core / DOM 4 / whatever it's called nowadays?
> 
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's called DOM4.

That's a moving target, from reading the URL.

> Why do you also reference DOM 2 Events? That's confusing and not needed.

Anne, please do not prevent this.

I think Hallvord is trying to keep away from the hot debates and referencing 
one stable and one moving target, and he tries to be somewhat compatible with 
both at least at time of issuing.

paul

Re: informal survey - on spec philosophy

[Paul Libbrecht]

Le 10 avr. 2012 à 22:25, Karl Dubost a écrit :
> A recent example from Canvas specification.
> http://html5.org/tools/web-apps-tracker?from=7030&to=7031
> 
>This specification does not define the precise
>+  algorithm to use when scaling an image when the +  
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled
>+  attribute is set to true.
> 
> It all depends on what you mean by interoperability and the expectations of 
> users. I'm pretty sure that graphics designers will have a very strong 
> opinion about smoothing being exactly the same for all browsers.

I'm sure to be alone, but for the bitterness, here's another such story we had 
till two weeks ago: 

The upgrade to iOS5 broke, for all iPad users, the search function on our 
website, www.curriki.org. It took us several weeks of debugging, not 
understanding the single message of debugging inside the console: "undefined is 
not an object" (no location).

At the end it turned out that the iOS5 upgrade had changed the way javascript 
parses Date.parse(). 
Suddenly, the result was undefined and the subsequent printf, given an 
undefined, sent that odd message.

Anywhere you look, Date.parse is "left to browser interpretation" with the only 
available standard, ISO-8601, not even being fully implemented in the modern 
browsers. The very informal w3c note is implemented, while this standard is too 
big.


Does HTML5 change this? I'd be glad to hear this.

Is there a way to flag things so that developers routinely protect against 
unpredictability?

paul

Re: Call for Editor: URL spec

[Paul Libbrecht]

Ian,

Could be slightly more formal?
You are speaking of "hypocrisy" but this seems like a matter of politeness, 
right?
Or are you actually claiming that there's a license breach?

That there are different mechanisms at WHATWG and W3C is not really new.

Paul

Le 6 nov. 2012 à 02:42, Ian Hickson a écrit :

>>> In the meantime, W3C is copying Anne's work in several specs, to
>> 
>> It seems like W3C groups copying WHATWG's work has been ongoing for 
>> several years (so I think this is "old news", especially since, AFAIU, 
>> it is permissiable, perhaps even encouraged? via the WHATWG copyright) 
>> ;-).
> 
> In the past (and for some specs still today), it was done by the editor 
> (e.g. me), as dual-publication.
> 
> What's "new news" now is that the W3C does this without the editor's 
> participation, and more importantly, while simultaneously decrying the 
> evils of forking specifications, and with virtually no credit to the 
> person doing the actual work.
> 
> It's this hypocrisy that is new and notable.

Re: Clipboard API: Stripping script element

[Paul Libbrecht]

Nice catch for this example you provide below.
The "solution" to this issue would be to simply empty the script element 
instead of stripping it away. Right?

In your original mail, however, you write:
> It would be great to mention what kind of manipulations user agents are 
> allowed to do to make the pasted content secure.


I think this claim is exactly why Halvord has removed the sanitization section. 
It seems highly implementation dependent to decide on the security of a 
fragment of content. 
I feel the section on the sanitization should be expressed with "should" 
expressing recommendations such as that of emptying script elements or 
replacing object  or embed elements by a corresponding images.  I'm pretty sure 
conservative approaches will start by doing a similar replacement with video 
elements, for example, but might include them after some other introspection 
(e.g. that it is not pulling from a streaming source).

Paul


> The particular case I had in my mind was something like:
> 
> 
> ~
> hello
> 
> div {
> color: red;
> }
> span:nth-child(2) {
> color: green;
> }
> 
> 
> 
> If we had striped the script element, the hello will be shown in red instead 
> of green. We ought to define what UAs are allowed to do (e.g. strip script 
> element) even if we couldn't specify the exact algorithm so that authors 
> won't be surprised by some UAs stripping script elements and others emptying 
> out the text nodes within it.
> 
> FWIW, stripping script element appears to be the nominal behavior both among 
> browsers and various mail apps (e.g. Gmail, etc…).
> 
> - R. Niwa
> 

Re: MathML and "Clipboard API and events"

[Paul Libbrecht]

Hey Paul,

nice to hear you raise this!

I fully agree it should be possible for some JS code such as MathJax to copy 
MathML to clipboard.
The reason it is not listed as a mandatory data type, I believe, is that I, at 
least, have been unable to demonstrate the zero risk of doing so. 
I believe I have tried, although this spec has been running since quite long 
and things maybe have been changed.

Putting html in the clipboard is a requirement and there's a subtle and 
unspecified (yet) way of "sanitizing" the fragments so that it does not 
represent a risk when inserted in another context. Recent discussions have 
emerged about this. All of the browsers which implement html-copying have their 
own implementation.

Doing the same for MathML, e.g. removing maction, or, at least, any 
html-sensitive things should be needed. I do not know it is done.

Halvord Steen, the editor of this spec, and others might correct me but I 
interpret that this is the reason it is not in the required types.

I would be happy if we can formulate such a thing in a convincing way.

Paul




> 10. Mandatory data types
>  
> I am surprised not to see a MathML type in this list. I suppose MathML could 
> be typed as application/xml but SVG gets its own image/svg+xml type so I 
> would expect MathML to be treated in an analogous manner. I will admit to not 
> knowing the ramifications of this.
>  
> I also want to mention MathJax (www.mathjax.org). MathJax is an open source 
> JavaScript engine for rendering MathML and LaTeX in browsers. It could be 
> looked at as a polyfill for the current lack of good browser support for 
> MathML. However, it also has its own UI and processes LaTeX so it will 
> definitely have a place even after browsers routinely render MathML.
>  
> I mention MathJax here as it is a good use case for the clipboard API. It 
> transforms MathML or LaTeX in the web page to a chunk of renderable HTML, 
> CSS, SVG, or even MathML if the browser supports it natively. The user would 
> like to be able to select, cut, copy, and paste a mathematical expression 
> rendered this way as if it was a single object. It sounds like MathJax should 
> be able to do this using this clipboard API, though it does not address the 
> selection aspect. Taking this a step further, someday we might hope to allow 
> the user to select sub-expressions of a mathematical equation for the purpose 
> of cut and copy.
>  
> Paul Topping
> Design Science, Inc.

Re: Fetch: HTTP authentication and CORS

[Paul Libbrecht]

On 7 mai 2013, at 02:23, HU, BIN wrote:
> Because "nonce" is needed to generate the appropriate digest, the 401 
> challenge is required.

So the lesson here is: any developer that intends to use authenticated XHR 
should always start with an XHR that is a simple ping-like GET, then do the 
real things. Right?

Paul

Re: Clipboard API: Default content in copy/cut handlers

[Paul Libbrecht]

Daniel,

I personally think it is not at all a good idea to populate the "clipboard" 
when starting the drag!
It makes sense when a "copy" operation is triggered, as the application may be 
vanishing.
Most desktop DnDs I have observed only operate the transformation when the drop 
has occurred (hence a flavour is identified). A good way to test this is to 
take a heavy piece in a graphics programme and drop it outside.

Those two specs have evolved independently and I always sow clipops to be a 
more refined version of html5's DnD but there you have spotted a non-extension 
point.

Is there any reason to justify the requirement to populate before the dragstart?

Paul


On 12 juil. 2013, at 00:22, Daniel Cheng 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. 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: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

[Paul Libbrecht]

James,

I personally think it would be a really good idea. But I am not a browser 
implementor.

Overall, I agree with you that writing to the clipboard, only within a click or 
key event processing maybe?, is likely to be a non-concern on privacy. I would 
love to hear others' feedback.

Is maybe a first step something such as a browser-extension?
Did you hear brags about users of websites that allowing copy was not a good 
idea?

(I heard a brag close to it by TimBL and J Gruber about the usage of "clipboard 
injection": http://lists.w3.org/Archives/Public/www-tag/2010Jun/0007.html are 
we close to that? I think not but maybe can such a feature get close to it?)

Paul

On 12 juil. 2013, at 21:57, James Greene wrote:

> It appears that the only way to trigger a `copy` event programmatically is to 
> use `document.execCommand('copy')`, which most browsers prevent:
> 
> http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events
> 
> What about enabling so enabling semi-restricted programmatic clipboard 
> injection on a page if the user grants their express permission via a 
> once-per-domain security prompt (similar to the Geolocation API)?  IOW, given 
> a user's express permission to the origin and following a user's pointer 
> event or keyboard interaction, I would like to be able to simulate the `copy` 
> event (and the `beforecopy` event, if practical).
> 
> I'm not quite sure how far this will go as "clipboard poisoning" is always a 
> real concern.  In fact, I understand that better than most, since my desire 
> to get such an adaptation to the Clipboard API spec is the direct result of 
> my work as the co-maintainer of the popular ZeroClipboard library (used by 
> GitHub, bit.ly, and many other sites).  Jon and I would like nothing better 
> than to eliminate ZeroClipboard's dependency on Flash but that is 
> unattainable given the current restrictions of this spec.
> 
> If Flash doesn't live on for anything else, it may well live on longer than 
> it should for its unmatched ability to do programmatic clipboard injection 
> after a user's click or keypress.  :(
> 
> Thoughts?
> 
> 
> Sincerely,
> James Greene
> http://jamesgreene.net/

Re: [clipboard] Clipboard API Mandatory Data Types

[Paul Libbrecht]

While I do not know the Safari-Desktop-implementation right now, I know that 
Apple's UTI has a URL type.
See here:

https://developer.apple.com/library/ios/documentation/miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html
It would be interesting to see a statement of Apple somewhere committing to 
these types but I can't find that.

paul


On 25 juin 2014, at 07:37, Ben Peters  wrote:

> The Clipboard API spec has a section on Mandatory Data Types [1]. It
> says "The implementation must recognise the native OS clipboard format
> description for the following data types", and contains a list of 14
> mime types. Most of them have clear purposes, but a few seem arbitrary
> to me. Since I haven't been around the group long enough to know all
> the history, can someone help me clear these up?
> 
> text/uri-list :
> This seems like a Windows specific data type. Does Mac or Linux have a
> "OS clipboard format description" for this?
> 
> text/css, application/javascript, application/json :
> What is the use case here? Why would there be code on the clipboard in
> it's own format instead of just text/plain that happened to be code?
> 
> Separately, do we want to apply this to Drag and Drop as well?
> 
> Thanks!
> Ben
> 
> [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
> 

Re: [clipboard] Semi-Trusted Events Alternative

[Paul Libbrecht]

On 16 sept. 2014, at 02:36, Brian Matthews (brmatthe)  
wrote:
> And again what about the naïve user that doesn’t even know what an extension 
> is or read
> somewhere that they’re “bad”, or will even understand what happened when
> their wife/husband/parent/child finds http:// your choice> in their clipboard or browser history?


There's a zillion such pollution that can happen today.

- Popups are an example (if private browsing is not on): they pollute the 
history
- An easy example is the download (with content-disposition not being inline) 
of random files (e.g. executables, pictures, pdfs) when you navigate to a site. 
This happens at really poor sites in an unintentional way.

The poorness of the site is the users' experience.


This function can positively affect people that employ a website that is sane 
and offers the function of copying an element of the site (e.g. with a button 
in a rollover…). Using websites that are not sane can happen, but generally, 
one tends to go away from them! The whole web has grown this way.

paul

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

[Paul Libbrecht]

On 31 janv. 2015, at 14:48, Hallvord Reiar Michaelsen Steen 
 wrote:

> If yes, do any of the other "mandatory" types have gotchas like Windows "HTML 
> Format" - on any platform? The mandatory types currently are:
> text/plain
> text/uri-list
> text/csv
> text/css
> text/html
> application/xhtml+xml
> image/png
> image/jpg, image/jpeg
> image/gif
> image/svg+xml
> application/xml, text/xml
> application/javascript
> application/json 
> application/octet-stream
> 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?
(those are: "application/mathml-presentation+xml", 
"application/mathml-content+xml", "application/mathml+xml")

I think I could help dig the names out by looking at the following documents:

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

Shall I just make the suggestions as a table per (html?) mail?

paul

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

[Paul Libbrecht]

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

paul



signature.asc
Description: OpenPGP digital signature

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

[Paul Libbrecht]

Daniel,

this does not make sense to me.

All these image parsers exploits can be triggered by an img tag, or?
Similarly for XML using an XHR or some particular XML formats (RSS, SVG,
XHTML, ...) in markup.

There's absolutely no difference in the mistrust we should have between
content brought by an HTML page and content brought by a JavaScript, or?
Hence we should just not accept the reason of knowing of broken parsers
to be a reason to change the standards!

If, as a president, you need to decide to change the roads because a
particular car was built massively and needs a particularirty of your
roads, you would also find it nonsense, or? You're making me feel like
France which did this for a particular type of trains which required to
change all platforms because their ordered trains were already built too
wide

Paul

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



signature.asc
Description: OpenPGP digital signature

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

[Paul Libbrecht]

Daniel,

I understand now that the mistrust is about parsers that are even
further and I understand it's an added risk.

So the solution is to require that browsers that make known media-types
in the clipboard actually parse it for its value? That sounds doable
(and probably even useful: e.g. put other picture flavours in case of a
pictures).

Paul


On 9/06/15 22:20, Daniel Cheng wrote:
> On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  <mailto:p...@hoplahup.net>> wrote:
>
> Daniel,
>
> this does not make sense to me.
>
> All these image parsers exploits can be triggered by an img tag, or?
> Similarly for XML using an XHR or some particular XML formats
> (RSS, SVG, XHTML, ...) in markup.
>
>
> Sure. That's why Chrome only decodes images in sandboxed processes
> like the renderer.
>  
>
>
> There's absolutely no difference in the mistrust we should have
> between content brought by an HTML page and content brought by a
> JavaScript, or? Hence we should just not accept the reason of
> knowing of broken parsers to be a reason to change the standards!
>
>
> The difference is that "copy image to clipboard" never writes a
> GIF/JPG/PNG to the clipboard. The trusted browser process grabs the
> raw decoded bitmap from the renderer, validates the size information
> and some other stuff, and then writes it to the clipboard as a bitmap
> of the appropriate format.
>
> On the other hand, supporting this from JS means the untrusted
> renderer would get to control and place arbitrary GIF/JPG/PNG into the
> clipboard. It's not really feasible to do any corresponding validation
> that the data isn't bad.
>  
>
>
> If, as a president, you need to decide to change the roads because
> a particular car was built massively and needs a particularirty of
> your roads, you would also find it nonsense, or? You're making me
> feel like France which did this for a particular type of trains
> which required to change all platforms because their ordered
> trains were already built too wide
>
>
> It's unfortunate, but I doubt any native apps attempt to securely
> decode images. Previously, it didn't matter, since the clipboard
> content came from other native apps, and if you can't trust other
> native apps, you're kind of hosed anyway. However, going from web
> content -> native crosses a security boundary, which means these sort
> of issues need to be taken into consideration.
>
>
>
>
> Paul
>
>
> On 9/06/15 21:15, Daniel Cheng wrote:
>> I'm not against considering more formats to be dangerous. =)
>>
>> In particular:
>> JS: I'm not support what context we'd ever want to support this,
>> since we go out of our way to try prevent XSS in HTML pastes.
>> XML: I wouldn't mind getting rid of this. XML parsers seem to
>> have RCE bugs on a semi-regular basis.
>>
>> Daniel
>>
>> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay > <mailto:o...@pettay.fi>> wrote:
>>
>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>> > Currently, the Clipboard API [1] mandates support for a
>> number of formats. Unfortunately, we do not believe it is
>> possible to safely support writing a
>> > number of formats to the clipboard:
>> > - image/png
>> > - image/jpg, image/jpeg
>> > - image/gif
>> >
>> > If these types are supported, malicious web content can
>> trivially write a malformed GIF/JPG/PNG to the clipboard and
>> trigger code execution when
>> > pasting in a program with a vulnerable image decoder. This
>> provides a trivial way to bypass the sandbox that web content
>> is usually in.
>> >
>> > Given this, I'd like to propose that we remove the above
>> formats from the list of mandatory data types, and avoid
>> adding support for any more complex
>> > formats.
>> >
>> > Daniel
>> >
>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>
>>
>> Why would text/html, application/xhtml+xml, image/svg+xml,
>> application/xml, text/xml, application/javascript
>> be any safer if the program which the data is pasted to has
>> vulnerable html/xml/js parsing?
>>
>>
>> -Olli
>>
>



signature.asc
Description: OpenPGP digital signature

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

[Paul Libbrecht]

On 9/06/15 23:08, Daniel Cheng wrote:
>
> So the solution is to require that browsers that make known
> media-types in the clipboard actually parse it for its value? That
> sounds doable (and probably even useful: e.g. put other picture
> flavours in case of a pictures).
>
> I don't think I understand what this means.
Since the browser is what would act on behalf of JS when putting a given
data into the clipboard, it could check that this data is well formed
and maybe matches the patterns of known exploits.

paul


signature.asc
Description: OpenPGP digital signature

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

[Paul Libbrecht]

But then it goes even further with just about any type for which broken
parsers exists.
HTML is certainly a good example since its very diversely implemented.

An application that lives on a desktop and fails on some images would be
exposing its user if the user downloads a content and opens it with the
application.  Is the difference that the browser warns the user that the
picture has been downloaded? I've never seen a warning about a
downloaded picture.

Paul



On 9/06/15 23:25, Wez wrote:
> IIUC that approach won't help, because the problem here is not
> necessarily invalid/malformed data, but even valid data that some
> decoders fail to handle gracefully.
>
> On 9 June 2015 at 14:13, Paul Libbrecht  <mailto:p...@hoplahup.net>> wrote:
>
> On 9/06/15 23:08, Daniel Cheng wrote:
>>
>> So the solution is to require that browsers that make known
>> media-types in the clipboard actually parse it for its value?
>> That sounds doable (and probably even useful: e.g. put other
>> picture flavours in case of a pictures).
>>
>> I don't think I understand what this means.
> Since the browser is what would act on behalf of JS when putting a
> given data into the clipboard, it could check that this data is
> well formed and maybe matches the patterns of known exploits.
>
> paul
>
>



signature.asc
Description: OpenPGP digital signature

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

[Paul Libbrecht]

Hello all,

I think a good solution would then be that UAs do a transcoding, or?
(so the spec should recommend doing it)

I understand that the right-menu "copy image" function has the same
problem except if that one does transcoding (and it probably does, to
offer more native flavours).

That would work fine against attacking pictures that would overflow some
older picture processors.
For those graphic freaks which need the exact bytes (e.g. with a
particular profile etc), I think they can expect the web-app to offer a
download for which there's enough dialogs and protection.

Whether an unfiltered picture file should be expected by copy after some
security-dialog-confirmed process, I do not know. Maybe using
octet-stream is the solution?

thanks

Paul

On 11/06/15 08:31, Hallvord Reiar Michaelsen Steen wrote:
> On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng  > wrote:
>
> Currently, the Clipboard API [1] mandates support for a number of
> formats. Unfortunately, we do not believe it is possible to safely
> support writing a number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gif
>
> 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



signature.asc
Description: OpenPGP digital signature

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

[Paul Libbrecht]

Hallvord,

do you not want to split the writable types list in safe and non-safe
ones and let browsers how they deal with unsafe ones? Here's an idea:

html, xml, and picture formats should be in the unsafe ones. I guess
json too (but both XML and JSON are too generic to my taste).
Similarly, I'd like to add things such as MathML ones
(application/mathml-presentation+xml, application/mathml-content+xml,
application/mathml+xml) and rtf.

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

What do you think?

Paul

Hallvord Reiar Michaelsen Steen wrote:
> 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..

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

[Paul Libbrecht]

Hello Hallvord,

> Hallvord Reiar Michaelsen Steen <mailto:hst...@mozilla.com>
> 27 août 2015 18:32
> On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht  <mailto:p...@hoplahup.net>> wrote:
>
> do you not want to split the writable types list in safe and
> non-safe ones and let browsers how they deal with unsafe ones? 
>
>
> No, absolutely not. If we leave such things up to the browser we end
> up with implementations that do wildly different things and web
> developers suffering new levels of incompatibility pain.
I mean, let them decide if they support it or not.
>
> Here's an idea:
>
> html, xml, and picture formats should be in the unsafe ones. 
>
>
> If we can help it, HTML should not be unsafe. It's the web's primary
> format, and if we class it as unsafe we basically prohibit scripts
> from being able to export formatted text to the clipboard.
>
> I do however know it takes a bit of a leap of faith to believe that
> it's safe enough, given that HTML parsing was a bit of a dark art for
> many years. Today we can at least hope a lot of software that consumes
> HTML has been updated to use HTML5 algorithms.
HTML5 has changed the parsing algorithm indeed.
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 guess json too (but both XML and JSON are too generic to my taste).
>
>
> 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.

However, it is true that I do not know of applications that receive
application/xml or text/json without being web-aware or even developer
aware... I am not sure what to suggest here.
(sniffing xml or json in the plain text is commonly done in many apps is
actually much worse in terms o security).
>  
>
> 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 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..
> -Hallvord
Yes, comments would be helpful.

paul

Re: App-to-App interaction APIs - one more time, with feeling

[Paul Libbrecht]

Daniel,

as far as I can read the post, copy-and-paste-interoperability would be
a "sub-task" of this.
It's not a very small task though.
In my world, E.g., there was a person who inventend a "math" protocol
handler. For him it meant that formulæ be read out loud (because his
mission is making the web accessible to people with disabilities
including eyes) but clearly there was no way to bring a different target.

Somehow, I can't really be convinced by such a post except asking the
user what is the sense of a given flavour or even protocol handler
which, as we know, is kind of error-prone. Agree?

paul

PS: I'm still struggling for the geo URL scheme to be properly handled
but it works for me in a very very tiny spectrum of apps (GMaps >
Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand).
This is certainly a good example of difficult sequence of choices.

> Daniel Buchner 
> 14 octobre 2015 18:33
>
> Hey WebAppers,
>
>  
>
> Just ran into this dragon for the 1,326^th time, so thought I would do
> a write-up to rekindle discussion on this important area of developer
> need the platform currently fails to address:
> http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/.
> We have existing APIs/specs that get relatively close, and my first
> instinct would be to leverage those and extend their capabilities to
> cover the broader family of use-cases highlighted in the post.
>
>  
>
> I welcome your ideas, feedback, and commentary,
>
>  
>
> - Daniel
>

Re: App-to-App interaction APIs - one more time, with feeling

[Paul Libbrecht]

Anders Rundgren wrote:
> Unless you work for a browser vendor or is generally "recognized" for
> some
> specialty, nothing seems to be of enough interest to even get briefly
> evaluated. 
Maybe the right thing is assemble "user representative" groups and be
enough heard on such places as this mailing list?

However, the problem with a question as the one of this thread is that
the answers can be hugely multi-facetted.

I do believe that the W3C process is sufficiently open to let each user
speak out loud and be heard on this mailing list (public-webapps@w3.org)
even if there are side actions trying to make things more friendly (such
as the WhatWG) or there are people believing that the W3C is too much
corporations oriented.

paul

Re: App-to-App interaction APIs - one more time, with feeling

[Paul Libbrecht]

Hello Daniel,

Maybe things can be said like this: copy and paste lets you choose where
you paste and what you paste, protocol handlers don't. Here's a more
detailed answer.

With a mathematical formula information at hand, you can do a zillion
things, assuming there's a single thing is not reasonable, even
temporarily. For example, a very normal workflow could be the following:
copy from a web-page, paste into a computation engine, adjust, derive,
paste into a dynamic geometry tool, then paste one of the outputs into a
mail.
Providing configurable protocol handlers, even to the finest grade, is
not a solution to this workflow I feel.

Providing dialogs to ask the user where he wants the information at hand
to be opened gets closer but there's still the idea of selection and
cursor which protocol handlers do not seem to be ready to perform.

However, I believe that copy-and-paste (and drag-and-drop) is part of an
app-to-app interaction APIs.

Paul


> Daniel Buchner <mailto:dabuc...@microsoft.com>
> 20 octobre 2015 18:36
>
> I’m trying to understand exactly why you see your example /(“//there
> was a person who invented a "math" protocol handler. For him it meant
> that formulæ be read out loud (because his mission is making the web
> accessible to people with disabilities including eyes) but clearly
> there was no way to bring a different target.”) /as something this
> initiative is blocked by or cannot serve.
>
>  
>
> If you were to create a custom, community-led protocol definition for
> math equation handling, like web+math, apps would send a standard
> payload of semantic data, as defined here: http://schema.org/Code, and
> it would be handled by whatever app the user had installed to handle
> it. Given the handler at the other end is sending back data that would
> be displayed in the page, there’s no reason JAWS or any other
> accessibility app would be blocked from reading its output – on either
> side of the connection.
>
>  
>
> I can’t really make sense of this part of your email, can you clarify?
> à“Somehow, I can't really be convinced by such a post except asking
> the user what is the sense of a given flavour or even protocol handler
> which, as we know, is kind of error-prone. Agree?” Asking the user
> what sense of a given protocol? Are you saying we can’t ask users what
> apps they want to have handle various actions? If so, we do this all
> the time, in every OS on the planet, and I wouldn’t say that simple
> process is error prone. Maybe I am misunderstanding you?
>
>  
>
> - Daniel
>
>  
>
> *From:*Paul Libbrecht [mailto:p...@hoplahup.net]
> *Sent:* Sunday, October 18, 2015 9:38 AM
> *To:* Daniel Buchner 
> *Cc:* public-webapps@w3.org
> *Subject:* Re: App-to-App interaction APIs - one more time, with feeling
>
>  
>
> Daniel,
>
> as far as I can read the post, copy-and-paste-interoperability would
> be a "sub-task" of this.
> It's not a very small task though.
> In my world, E.g., there was a person who inventend a "math" protocol
> handler. For him it meant that formulæ be read out loud (because his
> mission is making the web accessible to people with disabilities
> including eyes) but clearly there was no way to bring a different target.
>
> Somehow, I can't really be convinced by such a post except asking the
> user what is the sense of a given flavour or even protocol handler
> which, as we know, is kind of error-prone. Agree?
>
> paul
>
> PS: I'm still struggling for the geo URL scheme to be properly handled
> but it works for me in a very very tiny spectrum of apps (GMaps >
> Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand).
> This is certainly a good example of difficult sequence of choices.
>
>
>  
>
> Paul Libbrecht <mailto:p...@hoplahup.net>
> 18 octobre 2015 18:38
> Daniel,
>
> as far as I can read the post, copy-and-paste-interoperability would
> be a "sub-task" of this.
> It's not a very small task though.
> In my world, E.g., there was a person who inventend a "math" protocol
> handler. For him it meant that formulæ be read out loud (because his
> mission is making the web accessible to people with disabilities
> including eyes) but clearly there was no way to bring a different target.
>
> Somehow, I can't really be convinced by such a post except asking the
> user what is the sense of a given flavour or even protocol handler
> which, as we know, is kind of error-prone. Agree?
>
> paul
>
> PS: I'm still struggling for the geo URL scheme to be properly handled
> but it works for me in a very very tiny spectrum of apps (GMaps >
> Hand-edited-HTML-in-Mail

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

[Paul Libbrecht]

(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
)

cool!
>> 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?

It's the way it currently works on FF apparently (tested MacOSX 10.11
and Windows 7) and on Safari: all images are converted to data-urls.
I don't really see why it would be worse.
Would sensitive data be something such as the metadata? That could
certainly be stripped by transcoding.
>>> 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.
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).
Similarly XInclude-enabled XMLs or even other remote-including-XMLs
(e.g. through DTD) should ask the users, deny, or inline.
>>> 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.
Please share the test, this is exactly the kind of things we need around
to see how crooked one could touch upon.
E.g. MS Office documents nowadays display a "kind" of mistrust so the
user can bless if macros should be run. This kind of mistrust is
probably the future.
However, going as far as refusing any picture you
right-click-copy-picture from a web-browser because it is unsafe is far
from being what the users expect nowadays.
>> 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?
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).
> (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).
yes

Paul