The Draft CL can be found here: https://chromium-review.googlesource.com/c/chromium/src/+/4273893
On Wed, Mar 15, 2023 at 4:40 PM Antonio Sartori <[email protected]> wrote: > 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/CAJQw1NxiWFGQsKvb%3DGHftUk8zWTToMYWowvfhy0yB5jnfhn9_Q%40mail.gmail.com.
