- From: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Date: Fri, 10 Feb 2012 23:22:14 +0100
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: public-webapps@w3.org, "Daniel Cheng" <dcheng@chromium.org>
> > * 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. Possibly, right here I was mainly documenting what browsers already do (on Windows). Current implementations resolve on paste by my testing. The CF_HTML format includes some meta data that makes this possible. > No parsing needed for that though, the URLs are already resolved in the > DOM so it's just a matter of serialising them. We are not able to rely on this because content might get copied from other applications that do not resolve URLs on copy. It's still a good idea to recommend serializing with fully resolved URLs and it should probably be mentioned somewhere (not quite in scope for what I'm specifying though). > > * 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? We can only do this safely if the clipboard has enough meta data to distinguish content from online sources and from local applications. If you mean hostile applications *running locally*, then I'd say all bets are off already. However, we may have an issue with semi-trusted local applications like browser widgets. Once widgets can manipulate the data on the clipboard we have to decide whether we trust them as much as local apps or not.. > > * 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. Certainly a good thing to add. What about dragging a chunk of text from elsewhere into the browser, from a source application that makes an HTML representation available? -- Hallvord R. M. Steen Core tester, Opera Software
Received on Friday, 10 February 2012 22:23:56 UTC