This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html Multipage: http://www.whatwg.org/C#potentially-cors-enabled-fetch Complete: http://www.whatwg.org/c#potentially-cors-enabled-fetch Comment: <track> data: URLs should be supported Posted from: 2001:4c28:a030:30:450a:b4aa:b818:bf52 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.64
Using <track src="data:...."> currently seems to fail at the "resource sharing check" since there's no Access-Control-Allow-Origin header. To make data: URLs function like same-origin for <track>, I think the potentially CORS-enabled fetch algorithm should have an entry point as "If URL is a data: URL" at the top, and then skip the resource sharing check if URL is a data: URL and instead just set result to success.
This bug was cloned to create bug 18295 as part of operation convergence.
I've added data:, javascript:, and about:blank. For the current uses of the algorithm, I'm 80% sure this is safe in all cases. We'd better be careful with future uses of this algorithm though.
javascript: shouldn't be supported generally. Opera deliberately only supports it where it is needed for compat. I don't know for sure what the full list is right now, but <a href>, <area href>, <form action>, <iframe src> and <frame src> are allowed.
So Opera supports javascript: in browsing contexts and in navigations of browsing contexts. <object src=javascript:> is not supported because it's not a browsing context when the fetch happens. However an <object> that is a browsing context can probably navigate to a javascript: URL. Additionally, I'm not sure about:blank should be supported here. I think it makes more sense for each thing that uses CORS-enabled fetch and wants to support about:blank to special-case it. (Currently it seems useless for everything that uses CORS-enabled fetch.)
I don't see much point in not supporting javascript: and about:blank in these cases.
We want to limit javascript: as to not increase sites' attack surface. As for about:blank, what's the use case?
How does javascript: increase attack surface? about:blank is there just for consistency. The three groups of URLs are treated similarly throughout.
Sites that use blacklist-based content filtering get increased attack surface when browsers execute scripts in new places.
Sites that use blacklist-based security are doomed. It's dumb for us to try to help them. It just makes them feel safer than they are.
When I looked at this my conclusion was that javascript: should be done during navigation. The others should be supported by fetching, but not after redirects. See also: http://wiki.whatwg.org/wiki/URL#Schemes
Ok, for javascript: let's move this to bug 20990. That's the only thing left that people want changing for <track>, right? So we can close this bug?
See comment 12.