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

2016-02-08 Thread 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


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

2015-10-18 Thread 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

2015-10-18 Thread 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: Clipboard API: remove dangerous formats from mandatory data types

2015-08-29 Thread 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 p...@hoplahup.net
 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: Clipboard API: remove dangerous formats from mandatory data types

2015-08-17 Thread 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

2015-06-13 Thread 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 dch...@google.com
 mailto:dch...@google.com wrote:

 Currently, the Clipboard API [1] mandates support for a number of
 formats. Unfortunately, we do not believe it is possible to safely
 support writing a number of formats to the clipboard:
 - image/png
 - image/jpg, image/jpeg
 - image/gif

 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

2015-06-09 Thread 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 o...@pettay.fi
 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

2015-06-09 Thread 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

2015-06-09 Thread 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 p...@hoplahup.net
 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 o...@pettay.fi
 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

2015-06-09 Thread 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 p...@hoplahup.net
 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] Add RTF to the mandatory data types list?

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

2015-01-31 Thread Paul Libbrecht

On 31 janv. 2015, at 14:48, Hallvord Reiar Michaelsen Steen 
hst...@mozilla.com 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] Semi-Trusted Events Alternative

2014-09-16 Thread Paul Libbrecht

On 16 sept. 2014, at 02:36, Brian Matthews (brmatthe) brmat...@cisco.com 
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://insert unsavory domain of
 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] Clipboard API Mandatory Data Types

2014-06-25 Thread 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 ben.pet...@microsoft.com 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 API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-24 Thread 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 API: Default content in copy/cut handlers

2013-07-12 Thread 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: Fetch: HTTP authentication and CORS

2013-05-08 Thread 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: MathML and Clipboard API and events

2013-04-12 Thread 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: Clipboard API: Stripping script element

2013-03-29 Thread 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:
 
 div
 script~/script
 spanhello/span
 style
 div {
 color: red;
 }
 span:nth-child(2) {
 color: green;
 }
 /style
 /div
 
 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: Call for Editor: URL spec

2012-11-06 Thread 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: informal survey - on spec philosophy

2012-04-10 Thread 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=7030to=7031
 
p class=noteThis specification does not define the precise
+  algorithm to use when scaling an image when the code
+  
 title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code
+  attribute is set to true./p
 
 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: [Clipboard] Processing model feedback (and other)

2012-02-19 Thread 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 hallv...@opera.com 
 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: (aside) MIME type (was Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard)

2012-02-18 Thread 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

2012-02-18 Thread 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

2012-02-18 Thread 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

2012-02-18 Thread 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] checking if implementation allows reading/writing a given type to the OS clipboard

2012-02-17 Thread 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

2012-02-17 Thread 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

2012-02-17 Thread Paul Libbrecht

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

 On Fri, Feb 17, 2012 at 10:10 AM, Paul Libbrecht p...@hoplahup.net 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: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)

2012-02-10 Thread 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 (img src=file://..) 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] Event definition

2012-02-09 Thread 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 
 http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface,
  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 
 http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events.
 
 HTH
 Ms2ger
 




Re: Installing web apps

2012-02-01 Thread 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

2012-02-01 Thread 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: Obsolescence notices on old specifications, again

2012-01-23 Thread 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: CfC: new WD of Clipboard API and Events; deadline April 5

2011-09-07 Thread 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

Copy prevention... up-and-running

2011-09-05 Thread 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

2011-09-05 Thread 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 hallv...@opera.com 
 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)

2011-09-05 Thread Paul Libbrecht

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

 On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht p...@hoplahup.net 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: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)

2011-05-19 Thread 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


Re: copy events and content from server

2011-05-17 Thread 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

2011-05-17 Thread 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)

2011-05-17 Thread 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

2011-05-17 Thread Paul Libbrecht

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

 On Tue, May 17, 2011 at 12:11 AM, Paul Libbrecht p...@activemath.org 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

2011-05-17 Thread Paul Libbrecht



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

 On Tue, May 17, 2011 at 12:26 AM, Paul Libbrecht p...@activemath.org 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

2011-05-17 Thread 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)

2011-05-17 Thread 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

2011-05-17 Thread 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

2011-05-17 Thread Paul Libbrecht

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

 On Tue, May 17, 2011 at 10:18, Paul Libbrecht p...@hoplahup.net 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

2011-05-17 Thread 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: clipboard events

2011-05-10 Thread 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

2011-05-10 Thread 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

2011-05-10 Thread 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: paste events and HTML support - interest in exposing a DOM tree?

2011-05-03 Thread 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

2011-05-03 Thread 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

2011-05-03 Thread 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: paste events and HTML support - interest in exposing a DOM tree?

2011-05-02 Thread 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: CfC: new WD of Clipboard API and Events; deadline April 5

2011-03-29 Thread 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

2011-03-29 Thread 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: Overview of W3C technologies for mobile Web applications

2011-02-25 Thread 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 events

2011-01-31 Thread 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

2011-01-31 Thread 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

2011-01-31 Thread 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: clipboard events

2011-01-04 Thread 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

2010-12-26 Thread 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/cbapispec.html

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

2010-12-26 Thread 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/cbapispec.html

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: DnD vs CnP (was Copy/Paste Events)

2009-08-26 Thread 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)

2009-08-23 Thread 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  
Libbrechtp...@activemath.org 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)

2009-08-22 Thread 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 the time they don't survive apps quiting.


I am sorry that's not true: a system clipboard is filled independently  
of the application.

See here:
  http://developer.apple.com/documentation/Cocoa/Conceptual

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

2009-08-22 Thread 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)

2009-08-13 Thread 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: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

2009-03-10 Thread 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: [access-control] Rename spec?

2009-01-14 Thread 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: Copyright license for ElementTraversal Java interface

2009-01-12 Thread 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:generalpage=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: further with transfers (Re: Clipboard actions BOF table at W3C TPAC)

2008-10-23 Thread 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


Clipboard actions BOF table at W3C TPAC

2008-10-22 Thread 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

2008-10-22 Thread 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