[-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/CAH%2B8MBbfeLr8ZPMDT1_4REmsaagPXpZw9-Vyr9Bo-2p5m9zbLw%40mail.gmail.com.
