- From: Aron Spohr <aron@aspohr.de>
- Date: Sat, 15 Aug 2009 07:33:53 -0700 (PDT)
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.
Received on Saturday, 15 August 2009 07:33:53 UTC