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

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: 
> ) 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       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 10 February 2012 21:36:29 UTC