On 2/17/12 1:35 AM, Anne van Kesteren wrote:
Our proposal takes its cues and algorithms from the postMessage API,
and allows the source site to restrict drop targets to only those
origins which it trusts, and allows drop targets to see which origin
was the source of a drag. The majority of the
The security problems with drag-and-drop are significantly more
pronounced than just the banking scenario you are describing. Because
the drag-and-drop action is very similar to other types of legitimate
interaction (e.g., the use of scrollbars), many practical
content-stealing attacks have been
This proposal sounds reasonable.
On Fri, Feb 17, 2012 at 1:35 AM, Anne van Kesteren ann...@opera.com wrote:
Names are chosen to be compatible with those used by HTML5 Web Messaging.
dataTransfer.origin
Returns a DOMString consisting of the protocol, domain and optional port,
of
the
On Sun, Feb 19, 2012 at 2:28 PM, Charles Pritchard ch...@jumis.com wrote:
On 2/17/12 1:35 AM, Anne van Kesteren wrote:
Our proposal takes its cues and algorithms from the postMessage API, and
allows the source site to restrict drop targets to only those origins which
it trusts, and allows
On 2/19/2012 4:28 PM, Adam Barth wrote:
On Sun, Feb 19, 2012 at 2:28 PM, Charles Pritchardch...@jumis.com wrote:
On 2/17/12 1:35 AM, Anne van Kesteren wrote:
Our proposal takes its cues and algorithms from the postMessage API, and
allows the source site to restrict drop targets to only those
The feedback that follows is based on our implementation experience with
drag drop. The people that ought to be credited for the text below are
Paweł Stanek, Giorgi Chavchanidze, Wilhelm Joys Andersen, and anonymous;
i.e. not me.
This is a proposal for what we see as one of the most
