[whatwg] Drag and Drop Security Model and current implementations

[Ian Hickson]

On Sat, 15 Aug 2009, Aron Spohr wrote:
> 
> 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.

I've made the "types" list visible during all the events, but I'm 
skeptical about making everything available. We'll probably revisit this 
in a few years when we have a test suite for this. (I probably need to 
rewrite the way this section is written before making any more significant 
changes.)


> 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.

I've done this, though without the suggested restrictions.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'