17461 2012-06-11 10:41:00 +0000 CORS-enabled fetch supports javascript: and about:blank 2013-04-09 18:18:25 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#potentially-cors-enabled-fetch P3 normal Unsorted 1 contributor ian annevk ian mathias mike zcorpan contributor oldest_to_newest 68910 0 contributor 2012-06-11 10:41:00 +0000 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 68911 1 zcorpan 2012-06-11 10:45:59 +0000 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. 71056 2 contributor 2012-07-18 17:59:49 +0000 This bug was cloned to create bug 18295 as part of operation convergence. 72998 3 ian 2012-08-29 20:27:45 +0000 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. 73050 4 zcorpan 2012-08-30 06:58:30 +0000 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. 73052 5 zcorpan 2012-08-30 08:45:05 +0000 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.) 73635 6 ian 2012-09-11 22:07:03 +0000 I don't see much point in not supporting javascript: and about:blank in these cases. 73700 7 zcorpan 2012-09-12 16:16:09 +0000 We want to limit javascript: as to not increase sites' attack surface. As for about:blank, what's the use case? 74715 8 ian 2012-09-28 03:51:25 +0000 How does javascript: increase attack surface? about:blank is there just for consistency. The three groups of URLs are treated similarly throughout. 74762 9 zcorpan 2012-09-28 08:46:53 +0000 Sites that use blacklist-based content filtering get increased attack surface when browsers execute scripts in new places. 74833 10 ian 2012-09-28 19:52:06 +0000 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. 80210 11 annevk 2012-12-14 22:36:58 +0000 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 83112 12 ian 2013-02-13 18:12:47 +0000 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? 85814 13 ian 2013-04-09 18:18:25 +0000 See comment 12.