[whatwg] Drag and Drop Security Model and current implementations

[Aron Spohr]

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.