Hostnames should cannonicalize to lowercase (to match every other browser)
Created attachment 81777 [details] Patch
Comment on attachment 81777 [details] Patch Clearing flags on attachment: 81777 Committed r78044: <http://trac.webkit.org/changeset/78044>
All reviewed patches have been landed. Closing bug.
This caused regressions and breakage in Safari extensions. Extension URLs (based on bundle identifiers) are allowed to have only case differences. But now with this change the extension URLs conflict and no longer uniquely identify an extension. I'd like to propose this change only apply to http, https and maybe file URLs. It seems wrong to assume lowercase is correct for all other URL schemes. Does that seem okay to you Eric?
Can you give an example of a Safari extension URL? Quoting from http://www.ietf.org/rfc/rfc2396.txt ---8<--- The URI syntax is dependent upon the scheme. In general, absolute URI are written as follows: <scheme>:<scheme-specific-part> An absolute URI contains the name of the scheme being used (<scheme>) followed by a colon (":") and then a string (the <scheme-specific- part>) whose interpretation depends on the scheme. The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI. However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This "generic URI" syntax consists of a sequence of four main components: <scheme>://<authority><path>?<query> each of which, except <scheme>, may be absent from a particular URI. For example, some URI schemes do not allow an <authority> component, and others do not use a <query> component. --->8---- In particular, the question is what sort of URI these things are.
They are hierarchical. safari-extension://com.apple.Safari.Test-8Y3CDS73R8/cf03fc47/test.html
Ok. We can change KURL to be more selective about which schemes it canonicalizes. However, please be aware that extensions whose authority differ only in case will not be properly isolated from each other by the web platform. In particular, they'll inhabit the same security origin, which means they can XSS each other. Also, they'll share persistent storage, such as localStorage. Another note: because you've reversed the dotted authority hierarchy, there could be serious negative security interactions with with cookies and document.domain (as well as other security features that attempt to understand the DNS hierarchy).
+sam because there are interactions with SecurityOrigin canonicalization too.
(In reply to comment #7) > Ok. We can change KURL to be more selective about which schemes it canonicalizes. However, please be aware that extensions whose authority differ only in case will not be properly isolated from each other by the web platform. In particular, they'll inhabit the same security origin, which means they can XSS each other. Also, they'll share persistent storage, such as localStorage. This is good to know, and may require us to make changes in Safari. > Another note: because you've reversed the dotted authority hierarchy, there could be serious negative security interactions with with cookies and document.domain (as well as other security features that attempt to understand the DNS hierarchy). We're aware of that, and are using SecurityOrigin's "domain relaxation forbidden" concept to try to head off problems here. (In fact, this is what that concept was added for.)
Filed bug 54271 about making a special case for safari-extension. I'll write up a patch tomorrow.
@abarth: Do we need to file bugs about the possible security issues with safari-extension? Would you be willing to file those bugs?
(In reply to comment #11) > @abarth: Do we need to file bugs about the possible security issues with safari-extension? Would you be willing to file those bugs? I don't know enough of the details to answer that question. If there's a problem, the solution is also likely to be in the Safari layer rather than the WebKit layer. I'll defer to folks who know more about these things to assess whether these issues are actually problematic.
I filed <rdar://problem/8988695> to cover the Safari issues.