Re: [whatwg] Drag and Drop Security Model and current implementations
Hi Oliver, I agree as I'm unsure what else *could* be safely exposed before the drop event -- realistically anything beyond the types seems risky: ignoring the obvious risks of exposing actual content, exposing any form of URI may lead to unintended information leaking (you have to assume that people are dragging random private files, urls, etc across windows and do not intend to drop them) I generally agree. However in this particular case (which is currently implemented in the latest versions of Firefox and Google) full access is only granted if the original and the target page are the same. For instance: If you drag something from http://www.mywebapp.com/ to another window serving http://www.mywebapp.com/. Only in this particular case the target application or page has access to all the data during a dragover event (and other events). I believe that makes sense as it is literally the same application which created and stored the data to the dataTransfer object in the first place. It's just using multiple browser-windows. As you can see this wouldn't work if people drag private files, urls from other sources across.. Aron
[whatwg] Drag and Drop Security Model and current implementations
Hi Ian et al, I've been playing with some of the current implementations of the Drag and Drop feature described in section 7.10 of the spec. The current security model seems a bit too strict in my opinion and needs some tweaking. Please find below my two proposals for changes in section 7.10.3 and 7.10.7. Any comments very much appreciated. Aron during the dragover event: Full access to the dataTransfer object should be granted if the dragover event gets fired on a page with the exact same location as the location from where the dragstart event originated from. With location I mean at least full hostname and port (or default), not necessarily the protocol. This precise behaviour is currently implemented in Google Chrome 2.0.172.40 and Firefox 3.5, whereas Internet Explorer always grants full access regardless of different hostnames in the location between the originating dragstart and dragover events, so it would be compatible with this change. I believe this behaviour makes a lot of sense for a Web-Developer of a complex Web-Application which works over more than one browser-window as it would give him much more flexiblity on what can be done and previewed and decided on during a dragover operation before an actual drop event happens. Personally I'd guess the reason for this being implemented in Chrome and Firefox already is because their development-labs requested it. 2nd proposal during the dragover event: Access to the readonly attribute 'types' of the dataTransfer object should always be granted during a dragover event to allow the potential target element to response accordingly. The current spec doesn't allow a potential target element to decide during a dragover event based on the dragged data if it wants to accept a potential drop of that data or not. It always has to accept potential drops by preventing the default behaviour of the dragover event even if it can't process the data during a drop event. This can give the wrong indication to the user of the user agent if it turns out the element can't process the data when the drop event gets fired. Obviously it makes a lot of sense from a security perspective to restrict the access to the dataTransfer object during a potentially meaningless dragover event. However some indication on what type the data is should be given during the dragover event. The best compromise I believe would be to allow exclusive and read only access to the 'types' attribute of the dataTransfer object so that it can find out of what type the data is which can be potentially dropped upon it. All current implementations don't transfer any sensitive or confidential data in the types attribute. And obviously by definition of the current spec the 'types' attribute is not meant to be used for user data as it has to be used to specify the data types exlusively. Maybe to discourage abuse of the types attribute the length of each item should be limited as well as the characters it can hold. For instance I don't think it should accept any newline or linebreak characters.
Re: [whatwg] Accessibility for Drag and Drop
Hi Ian, firstly thanks for your comments. --- Ian Hickson i...@hixie.ch wrote on Tuesday, 28. July 2009: Whether draggable elements can be focused or not is up to the user agent. It's much like links -- in some browsers, whether they are focusable or not depends on the operating system accessibility preferences. I agree. It's the same case here. Just like with 'a' elements that have an href attribute we should also add elements that have a draggable attribute set to true to the list of elements that should be made focusable by the user agent at the bottom of section 7.5.1 of the spec. Btw. there is no information on what criteria the qualification is made for the elements in that should list in the spec. Maybe that should be added as well. The user agent can actually find where drops can occur by just acting as if the user had tried to drop everywhere. I'm not really sure how we could make an attribute work for this, since the model allows any element to be a drop target already. Fair enough. I thought it might come in handy some day to identify both draggable elements as well as elements that can receive drops without the use of scripting. E.g. in a parser or for search spiders to creater indexes for that faster... Aron
Re: [whatwg] Drag and drop - keyboard support
Hi Ian, --- Ian Hickson i...@hixie.ch wrote on Thu, 16.7.2009: The drag-and-drop model described in the HTML5 spec is input-device- agnostic. If implementations don't support keyboard drag-and-drop (e.g. copy-and-paste) then you should bring this up with the relevant vendors. I don't think the spec for Drag and Drop is fully agnostic as it stands right now. A lot is obviously up to the vendor how and how much functionality they want to implement in their user agent. But I believe that there is a minimum set of requirements we should consider to make Drag and Drop truly agnostic. When you find the time I'd really appreciate your comments on this post: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020981.html Thanks Aron
Re: [whatwg] hash sum tags of binary files and code blocks?
Hi Christian, have you ever considered just making the md5 (or maybe just a shorter CRC) part of the filename of the file you want to cache? Then you can send Expiry headers for 6 months or a years time for those files and you'll get the same behaviour. Aron
[whatwg] Accessibility for Drag and Drop
Hi everyone. I’m new to this list and I’ve got some ideas to make the Drag and Drop feature more accessible. Accessibility for drag and drop can mean different things: Obviously if the user can’t or doesn’t want to use a mouse pointer to perform a drag and drop operation and also making drag and drop more accessible for automated robots and browser plugins. I’ve been working with prototype implementations of Drag and Drop in different browsers for a few years and my ideas are based on the gaps we found in the current specification. I hope you find them useful. 1. Every Element with the draggable attribute set to true should be focusable by default. I know that tabindex=n would make almost any element focusable but I think making draggable elements focusable is something that shouldn't be left to best practises for webmasters and should be defaulted to by spec. An element that can have a focus usually indicates to the user that it supports some kind of interaction. That is definately the case for elements with the draggable attribute set to true. If they can be focused a user could use the Tab-Key to focus a draggable element and then press the context-menu key in order to get a copy function offered by the user agent. Maybe elements with draggable attribute set to true can be added to the list in section 7.5.1 (Sequential focus navigation) so that they get focused by default. I think this should only apply to elements which have the draggable attribute set to true explicitly (and not to auto). That ensures that the pre-existing default behaviour of user agents doesn't change when working with ‘a’ and ‘img’ elements. i.e. ‘a’ elements are already focusable and allow this type of behaviour already, img wouldn’t unless the draggable attribute has been set to true explicitly. 2. On the opposite side it’s actually pretty undefined how the user can “find” an area where something can be dropped. It’s obviously very much up to the webmaster if the content on the page indicates that something can be dropped somewhere. And that’s probably ok to some degree. However for accessibility it’s suboptimal. Similar to the draggable attribute, which indicates that something can be dragged away I believe it would be very useful to have the opposite, which does indicate that an element can accept drops. Not sure what the best name for such an attribute would be. I’m going with “dropallowed” for this email. If such a “dropallowed” attribute is set to true on any element this could result in this behaviour for the user agent: Make the element focusable by default (and maybe only then make it possible to trigger the ‘drop’ event for strictness). That way again, the element can be reached via the keyboard and a context menu can be opened solely with the keyboard in order to perform a “paste” operation. Special user agents (like screenreaders) could also easily indicate that something can be dropped onto (or pasted into) the element if the attribute was set. Search spiders or maybe even browser plugins may find it very useful to easily find all areas on a page which can accept a “drop”-like operation. With such an attribute this would be relatively simple and wouldn’t even need scripting capabilities. If such an attribute existed some elements like ‘textarea’ or ‘input’ would probably have it set to true (or auto) by default. Aron Spohr
