As to the Android WebView hack, currently "foo://test" on Android Webview has a valid security origin with an empty host (foo://). By the standard the origin will be "foo://test". After the patch the behavior will be affected. The hack traces back to crbug.com/896059 and b/117514441. For some reason, Gmail depends on this behavior to work. Chances are that we need to keep that hack.
On Thu, Mar 16, 2023 at 3:58 AM Torne (Richard Coles) <[email protected]> wrote: > Hi folks, > > Will this change potentially impact WebView? WebView currently allows > arbitrary URL schemes to be used, as well as a number of Android-specific > schemes: > https://source.chromium.org/chromium/chromium/src/+/main:android_webview/common/aw_content_client.cc;l=39;drc=e672a665ffa8fe4901184f03922e2cc548399da5 > > I'm not super clear on what the actual effect of the change will be here, > but currently WebView apps might depend on the fact that if they load > "foo://bar" this is treated as origin "foo://" and is same-origin with > "foo://baz". There may be other ways this is relevant as well; I'm > unfortunately not certain what all the implications of WebView's support > for custom schemes actually are. > > On Wed, 15 Mar 2023 at 03:40, 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/CAOzWxF6wJ17ChhQbaDGz4O8X-zjo0dx7tS-_zuXzeOUKO%2BynPQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF6wJ17ChhQbaDGz4O8X-zjo0dx7tS-_zuXzeOUKO%2BynPQ%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/CAJQw1NwQi2A_bNb96N3idEpSvgFXjLn%3D8qoK-mdH%2B1BNqfCt8A%40mail.gmail.com.
