We had a look at this in the Web Platform Security and Privacy reviews. Thanks for clarifying that the proposed change is just for parsing. Then I believe that this is fine in principle, but I am not totally sure about the actual changes needed in the code: I just fear we might have some piece of the codebase which assumes that it will never get as input a non-special URL (since it used to be invalid), and changing that might become a security issue? Could you explain in more detail what you are going to change? Maybe you even have a draft CL?
On Wed, Mar 15, 2023 at 6:56 AM Jiacheng Guo <[email protected]> wrote: > Thanks for the review! > > The proposed change would just be parsed. The navigation behavior will > remain the same. > > Jiacheng Guo > > On Wed, Mar 15, 2023 at 9:35 AM Charlie Reis <[email protected]> wrote: > >> [-CSA, +security-dev] >> >> On Fri, Mar 10, 2023 at 3:31 AM 'Jiacheng Guo' via blink-dev < >> [email protected]> wrote: >> >>> I added the security team to ask for their comments as well. >>> >> >> Thanks, but moving to the external security-dev@ list instead of the >> internal CSA team list. I think Blink Intents already get reviewed for >> security, and antoniosartori@ might be looking at this one? >> >> I do think we would want to be very careful about allowing schemes to >> start supporting hosts when they didn't before. I expect that would cause >> a lot of confusion for data: and javascript:, so I'm glad they're on the >> blocklist for supporting hosts going forward. What schemes are not ending >> up on the blocklist and would change behavior? Would something like >> content: start supporting schemes, and would that cause problems? >> >> Also, would this proposed change mean that any new schemes would be >> possible to request or navigate to, or just that they could be parsed? >> >> Charlie >> >> >> On Mon, Mar 13, 2023 at 9:14 PM Domenic Denicola <[email protected]> >> wrote: >> >>> Great, thanks! I've added a variety of tests for these cases in >>> https://github.com/web-platform-tests/wpt/pull/38972 , to better track >>> our future work toward full spec compliance. In the meantime, any >>> incremental step toward interop is an improvement, so I want to reiterate >>> how happy I am that you're working on this! >>> >>> On Tue, Mar 14, 2023 at 12:25 PM Jiacheng Guo <[email protected]> wrote: >>> >>>> Yes, the behavior for the schemes in the blocklist will not change >>>> before and after the change. >>>> >>>> On Tue, Mar 14, 2023 at 12:20 PM Domenic Denicola <[email protected]> >>>> wrote: >>>> >>>>> Hmm, I'm not sure that answered my question. But let me try guessing >>>>> at an answer: >>>>> >>>>> An example of a URL that will still parse differently after this >>>>> change, is stun://test.com:8080/. That will parse >>>>> <https://jsdom.github.io/whatwg-url/#url=c3R1bjovL3Rlc3QuY29tOjgwODAv&base=YWJvdXQ6Ymxhbms=> >>>>> as >>>>> pathname = "//test.com:8080/" in Chromium, even after this change, >>>>> whereas per the standard, that should parse as port = 8080, hostname = " >>>>> test.com", pathname = "/". >>>>> >>>>> Is that correct? If so, I'll be sure we add failing web platform tests >>>>> for cases like that, so that we don't inadvertently get full credit for >>>>> fixing our non-special URL parsing code when we haven't finished that work >>>>> yet. >>>>> >>>>> On Tue, Mar 14, 2023 at 12:12 PM Jiacheng Guo <[email protected]> wrote: >>>>> >>>>>> Currently blink disallows non-special URLs with a host such as >>>>>> about://example.com/ or stun://test.com:8080/. The allowed URLs can >>>>>> be about:example or stun:test.com. >>>>>> >>>>>> The main concern for implementing spec compliant parsing of the URLs >>>>>> is we do not know whether other chrome components assume opaque hosts for >>>>>> these URLs. We wonder if there will be potential issues in the URL >>>>>> handling. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 14, 2023 at 10:19 AM Domenic Denicola < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Jiacheng, >>>>>>> >>>>>>> Thanks again for all this interop work! >>>>>>> >>>>>>> I don't think I understood the process that led to special treatment >>>>>>> for data:, javascript:, intent:, urn:, turn:, and stun:. It seems like >>>>>>> the >>>>>>> intent is to not follow the standard precisely for those schemes, >>>>>>> right? I >>>>>>> guess that might be reasonable as a stepping stone, but I want to make >>>>>>> sure >>>>>>> we're tracking our failure to follow the standard there, and hopefully >>>>>>> eventually fixing it. >>>>>>> >>>>>>> I've filed https://github.com/web-platform-tests/wpt/issues/38970 >>>>>>> to discuss adding more test coverage. To help us with that, can you >>>>>>> provide >>>>>>> an example of how the blocklist your document discusses will work? That >>>>>>> is, >>>>>>> the document says >>>>>>> >>>>>>> > Add a blocklist for non-special schemes. The schemes in the block >>>>>>> list must have an opaque host. >>>>>>> >>>>>>> Since there's no such list in the URL Standard itself, I'm assuming >>>>>>> this means those schemes will have nonstandard behavior. But I don't >>>>>>> understand what nonstandard behavior is implied by "must have an opaque >>>>>>> host". Can you give an example of, e.g., a stun: URL, which will parse >>>>>>> differently in the URL Standard vs. Blink's implementation, due to this >>>>>>> blocklist? >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 13, 2023 at 8:48 PM 'Jiacheng Guo' via blink-dev < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Sorry I sent the wrong document >>>>>>>> >>>>>>>> It should be >>>>>>>> https://docs.google.com/document/d/1edoInUnxwJAGN0264yFRvs6Yi5ptb37HvFYkBNnz2YQ/edit?usp=sharing >>>>>>>> >>>>>>>> On Sat, Mar 11, 2023 at 12:39 AM Mike Taylor < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Thanks for the doc - if "WPT URL failure triage" is what you >>>>>>>>> intended to send, could you point out which section contains the >>>>>>>>> security >>>>>>>>> concerns? (Or maybe just linked the wrong doc on accident?) >>>>>>>>> On 3/10/23 6:31 AM, Jiacheng Guo wrote: >>>>>>>>> >>>>>>>>> Sorry for the late reply, >>>>>>>>> >>>>>>>>> I've created a doc >>>>>>>>> <https://docs.google.com/document/d/1ip9B2v5KiX6HUolSODdyEhpWD0Jx1ib_uRbJXOGTqRw/edit?usp=sharing&resourcekey=0-CGabf2J9BGhC1LfbdT6_8w> >>>>>>>>> on the security concerns for non-special URLs. The general idea is to >>>>>>>>> support non-special URLs and add a blocklist where the URLs can only >>>>>>>>> have >>>>>>>>> opaque hosts. >>>>>>>>> >>>>>>>>> I added the security team to ask for their comments as well. >>>>>>>>> >>>>>>>>> Jiacheng Guo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 9, 2023 at 1:38 AM Mike Taylor <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Jiacheng, >>>>>>>>>> >>>>>>>>>> Friendly ping on Harald's and my questions. :) >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Mike >>>>>>>>>> On 2/23/23 2:40 AM, Harald Alvestrand wrote: >>>>>>>>>> >>>>>>>>>> Is there a blacklist of "special schemes" that this change won't >>>>>>>>>> touch? Who maintains that list? >>>>>>>>>> >>>>>>>>>> This seems a bit dangerous, in that if a new scheme is deployed >>>>>>>>>> that is "special", code intended for handling non-special schemes >>>>>>>>>> will try >>>>>>>>>> to parse it. >>>>>>>>>> >>>>>>>>>> Note that the term "special" in the URL specification ( >>>>>>>>>> https://url.spec.whatwg.org/#special-scheme) refers strictly to >>>>>>>>>> ftp, file, http, https, ws and wss; there's nothing "special" about >>>>>>>>>> urn, >>>>>>>>>> turn, stun or any of the other standardized schemes that don't use >>>>>>>>>> the // >>>>>>>>>> syntax. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 22, 2023 at 5:08 PM Yoav Weiss < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 22, 2023 at 4:43 PM Mike Taylor < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2/22/23 8:21 AM, 'Jiacheng Guo' via blink-dev wrote: >>>>>>>>>>>> >>>>>>>>>>>> Contact emails [email protected] >>>>>>>>>>>> >>>>>>>>>>>> Explainer None >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> An explainer (even inline) would be helpful to get a better >>>>>>>>>>> understanding of what this change does. >>>>>>>>>>> Does it impact only URL() object construction? What is happening >>>>>>>>>>> today? What will happen after this change lands? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Specification https://url.spec.whatwg.org/#url-parsing >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> >>>>>>>>>>>> URLs with non-special schemes will be supported in chrome. >>>>>>>>>>>> `non-speicial://test.com:1234/path` <http://test.com:1234/path> >>>>>>>>>>>> will be become a valid URL. One can access and set the URL >>>>>>>>>>>> properties such >>>>>>>>>>>> as host, port and path via the URL class. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Blink component Blink>JavaScript>API >>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EAPI> >>>>>>>>>>>> >>>>>>>>>>>> TAG review >>>>>>>>>>>> >>>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>>> >>>>>>>>>>>> Risks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>> >>>>>>>>>>>> *Gecko*: Positive >>>>>>>>>>>> >>>>>>>>>>>> *WebKit*: Positive >>>>>>>>>>>> >>>>>>>>>>>> Any links to those positive signals? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>> >>>>>>>>>>>> *Other signals*: >>>>>>>>>>>> >>>>>>>>>>>> Ergonomics >>>>>>>>>>>> >>>>>>>>>>>> No significant risks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Activation >>>>>>>>>>>> >>>>>>>>>>>> No significant risks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Security >>>>>>>>>>>> >>>>>>>>>>>> data:// and javascript:// URLs handling is not modified due to >>>>>>>>>>>> their critical role. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WebView application risks >>>>>>>>>>>> >>>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>>> applications? >>>>>>>>>>>> >>>>>>>>>>>> Do URLs with an intent:// scheme have any security >>>>>>>>>>>> considerations, or implications for WebView? (I don't know, >>>>>>>>>>>> hopefully >>>>>>>>>>>> someone who does can answer. :)) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Debuggability >>>>>>>>>>>> >>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>> Yes >>>>>>>>>>>> >>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>> ? Yes >>>>>>>>>>>> >>>>>>>>>>>> Flag name NonSpeicalSchemeURLParsing >>>>>>>>>>>> >>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>> >>>>>>>>>>>> Tracking bug https://crbug.com/1416006 >>>>>>>>>>>> >>>>>>>>>>>> Sample links >>>>>>>>>>>> >>>>>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4273893 >>>>>>>>>>>> >>>>>>>>>>>> Estimated milestones >>>>>>>>>>>> >>>>>>>>>>>> No milestones specified >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>> >>>>>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to >>>>>>>>>>>> known >>>>>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing >>>>>>>>>>>> to naming >>>>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>> https://chromestatus.com/feature/5201116810182656 >>>>>>>>>>>> >>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Nzk847XL759vMSQaF3L5zvtykg6UfQvuss4diyU-h1%3Duw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Nzk847XL759vMSQaF3L5zvtykg6UfQvuss4diyU-h1%3Duw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cdf2693-c8a3-d263-0eb0-a44a2390979e%40chromium.org >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cdf2693-c8a3-d263-0eb0-a44a2390979e%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVfGhV%2BDRzpCjGFoHg7EXb325nHz3nu4OSQVTTC6bkS1A%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVfGhV%2BDRzpCjGFoHg7EXb325nHz3nu4OSQVTTC6bkS1A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NwdWUn7OOrEgGjGeZV%3DHa_niTT0Jg_yv7j7uN2uRL7fcA%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NwdWUn7OOrEgGjGeZV%3DHa_niTT0Jg_yv7j7uN2uRL7fcA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Chrome Security Architecture Core team" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/google.com/d/msgid/chrome-security-architecture-core/CAM0wra_zfah%3DBsGL_GXW_RY7CtFvY646yoKvRiFGosTTL9FxjQ%40mail.gmail.com >>> <https://groups.google.com/a/google.com/d/msgid/chrome-security-architecture-core/CAM0wra_zfah%3DBsGL_GXW_RY7CtFvY646yoKvRiFGosTTL9FxjQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/a/google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF6wJ17ChhQbaDGz4O8X-zjo0dx7tS-_zuXzeOUKO%2BynPQ%40mail.gmail.com.
