W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] <object> behavior

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 18 Oct 2009 19:48:02 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0910181947540.26598@hixie.dreamhostps.com>
On Sun, 18 Oct 2009, Ola P. Kleiven wrote:
> On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie <benl at google.com> wrote:
> > On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Fri, 16 Oct 2009, Ben Laurie wrote:
> > > > > On Thu, 6 Aug 2009, Andrew Oakley wrote:
> > > > >>
> > > > >> - Should the type attribute take precedence over the Content-Type
> > > > >> header?
> > > > >
> > > > > No, I believe what the spec says here is the preferred behaviour.
> > > > > Unless this is incompatible with legacy content, we should try to move
> > > > > towards this behaviour.
> > > > 
> > > > I realise this is only one of dozens of ways that HTML is unfriendly to
> > > > security, but, well, this seems like a bad idea - if the page thinks it
> > > > is embedding, say, some flash, it seems like a pretty bad idea to allow
> > > > the (possibly untrusted) site providing the "flash" to run whatever it
> > > > wants in its place.
> > > 
> > > If the site is untrusted, yet you are letting it run flash, then you've
> > > lost already. Flash can inject arbitrary JS into your page.
> > 
> > Perhaps I am failing to understand, but if I embed anything from an
> > untrusted site, then it can choose what type it is - so how would I
> > prevent it running Flash?
> 
> Running Flash and allowing the same Flash to script your page are two
> different things. Flash needs allowscriptaccess="always" to script if it is
> loaded from a different domain. This may not be true for all plug-ins though.

Ah, good to know.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 18 October 2009 12:48:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC