Re: img issue: should we restrict the URI

Dr. Olaf Hoffmann wrote:
> Sounds more like a security problem of the cookie method or of the
> concept used by MySpace

One could argue that.  But the fact is, that's a very common thing to do on the 
web.  Website authors do it all the time.  So no UA that doesn't want to be 
blacklisted by sites can ship active <img>.

> Could be a security problem of the script language itself, not of the
> general concept of having scripts inside an embedded document.

These are inseparable.  If we had a mythical perfectly secure Web scripting 
language, we could ditch the same-origin policy as well.  What we in fact have 
is what UAs implement.

Again, we're not specifying HTML in a vacuum.  Standard-setting in a vacuum just 
leads to unimplementable standards.

> To disable the scripting in the SVG by the viewer only hides
> some consequences but does not remove the causes of the problem.

The cause of the problem being that people are including the image, period? 
You're right, that this is not removed.  But removing that is undesirable.

> If current behaviour is not useful at all, it is obviously a good idea to
> start to do it better.

Not if "better" breaks the web, sorry.  Where "breaks" == "causes financial or 
personal harm to people" in this case.

> And in many discussions I have seen so many pages broken by current
> behaviour by browsers

Really?  Can you actually cite some numbers here?  What fraction of the pages on 
the web are broken by the current handling of <img>?  What fraction are "broken" 
by your definition?  What is your definition?  What is the total audience of 
those pages?

Not all web sites are created equal, keep in mind.  Breaking a site with 10 
visitors a day is a lot more palatable to UAs than breaking, say, 
<http://irs.gov/> or <http://www.amazon.com/>.

>> Or viewed another way, all the UAs who're implementing SVG in <img> are
>> disabling scripting.  Have you stopped to wonder why?  If the spec doesn't
>> allow this, can it become a REC?
> 
> I have switched off scripting by default, therefore I cannot see a difference.

That's not answering my question, now is it?

> However if there is a difference for users/authors with scripting switched
> on, this is an implementation gap, maybe related to security problems of
> the browser, but this does not change the basic fact of an incomplete
> (or unsecure?) implementation.

Security is not an absolute.  It's all about guarantees.  The security system 
makes certain guarantees, and the actors perform actions they deem safe given 
those guarantees.  Including random HTML in your web page is not safe, given the 
guarantees browsers provide now.  Including an image is safe.  You propose to 
make the latter just as unsafe as the former: removing an existing security 
guarantee.  That breaks everyone who was relying on that guarantee.

Note that it's not a browser security problem per se that's the issue here, but 
rather the interaction of browser guarantees and web site author expectations. 
Any time there's a mismatch, the result is a security problem.  Introducing such 
mismatches is therefore not an option.

Put another way, a UA must be as secure as web site authors typically expect it 
to be.  Being less secure than that is a bug.  You're trying to enshrine this 
bug in a specification, if I understand your point correctly.

>> Then why exactly do you care what behavior is specified for <img>, exactly?
>>  You keep using <object>, and live with the security issues.
> 
> If there is audio, video in the draft, there should be for sematical reasons
> an image/img element with the same functionality as object

That doesn't follow, for <img>, because there is an existing <img> element with 
certain semantics.  Those semantics can't be changed in a backwards-incompatible 
way.

I have no problem with an <html5-img> or <img2> or <immg> or whatever element 
that has the behavior you describe.  It just can't be called <img>.

For what it's worth, I think this thread has reached the point of diminishing 
returns.  I see your point of view, and I've given up on you actually seeing the 
UA implementor point of view here, so there's not much point continuing this 
dicussion...

-Boris

Received on Tuesday, 29 January 2008 17:32:30 UTC