[whatwg] Javascript: URLs as element attributes

On Thu, Feb 10, 2011 at 10:43 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 2/10/11 1:38 PM, Adam Barth wrote:
>> The connection is that these features are unlikely to get implemented
>> in WebKit anytime soon. ?To the extent that we want the spec to
>> reflect interoperable behavior across browsers, speccing things that
>> aren't (and aren't likely to become) interoperable is a net loss.
>
> That's fine; I just think that if you mean "Don't specify this because we
> don't want to implement it and will refuse to do so" you should just say
> that instead of making it sound like there are unspecified security issues
> with the proposal.

To be clear, this is just my opinion.  Rather than flatly refuse to
implement the feature, I'm just sharing my perspective on why WebKit
behaves the way it does today and how it's likely to behave in the
future.  If someone turned up tomorrow with a patch that
re-architected how WebKit processes JavaScript URLs to make it
possible, e.g., to use JavaScript URLs in the src attribute of an
embed tag, I suspect there would be a lot of consternation within the
project about whether the benefits of the patch outweighed the
security risks.

If you look back in the bug tracker, you'll see that I tried doing
something along those lines (albeit on a more moderate scale) a while
back.  The result was roughly as I've described: we decided not to
accept the patches because of their security risk.

IMHO, data URLs cover these use cases much better than JavaScript
URLs.  The benefits of implementing JavaScript URLs are mostly to be
compatible with web sites that rely upon them.

Adam

Received on Thursday, 10 February 2011 11:54:53 UTC