[whatwg] Drag and Drop Security Model and current implementations
ian at hixie.ch
Mon Aug 24 22:01:07 PDT 2009
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
> 126.96.36.199 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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg