Re: img issue: should we restrict the URI

liorean wrote:
>> 1) Does the embedded content have a Window object?  If so:
> yes. But as I mentioned, fully isolated. Meaning NO contact with the
> browser or embedding page whatsoever.

OK, that's a pretty major special-case right there.  That's not how Window 
object work in general.  Same for window.print/window.open/window.parent.

>>   1d) window.location: should the embedded content be able to set it?
> possibly, not sure whether it makes sense or not to allow that. What
> are the security implications of allowing it?

Violation of expectations on the part of the embedding page.  Usually an 
embedded image can't just change what image is embedded.

>> 2) How are targeted form submits expected to happen?
> Targetted from the container to an img element: it's not a
> frame element.

Of course.  I was talking about the other direction.  From inside the <img>. 
Recall that forms can be submitted via script with no user interaction.

>> 3) Should form submits be allowed at all?
> In the contained image? Well, does submitting a form without having a
> possibility of user interactivity have any use cases?

You tell me; I'm the one failing to see any use cases for script in <img> in 
general.  ;)  For what it's worth, forms that are submitted without user 
interaction are pretty common on the HTML web.  And my point is that disallowing 
these requires a special-case.

>> 4) Should XMLHttpRequest be allowed?
> Similar non-scripted functionality is needed for the SVG support
> itself, no?

Not really, no.  I see nothing in SVG support that necessitates non-scripted 
arbitrary-method HTTP access, for example.  Or POST with arbitrary body, for 
that matter.

> Are there any security/privacy implications of allowing
> XMLHttpRequest that these other methods of including external
> resources would not already force?

Yes, see above.

> Well, it would be not for SVG in img specifically

Fine.  My point is that there is a _lot_ of special-casing that needs to happen 
to make this safe, thoughout the DOM implementation.  As a UA implementor, I'm 
not sure I can guarantee being able to do all the necessary changes (since 
almost every single DOM feature is impacted), so to accomplish the necessary 
sandboxing I'd just turn JS off in the image.

> User events are not passed into the embedded content. Interfaces to
> the browser or the container document are disabled. Internal
> modification through DOM or otherwise is allowed. I think it could be
> specced out.

Note that none of those statements cover the various issues I raised in my 
preceding e-mail.

It could be specced out, with some handwaving.  It would be a huge pain to 
implement.

And I'm still not seeing the benefit, to be honest.  What's the win?

-Boris

Received on Tuesday, 29 January 2008 23:18:19 UTC