Hi, I'm taking over the ownership of this "intent to ship" task from gjc@.
Here is a brief update on the current status: - I'm currently working on non-special URL support (WIP CL <https://crbug.com/1416006>). - Supporting non-special URLs will have a significant impact on the entire codebase and will have a high compatibility risk. - The draft explainer is here <https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?usp=sharing&resourcekey=0-d1gP4X2sG7GPl9mlTeptIA> (warning: it's still early draft). If you have any early feedback, especially regarding the impacts on url::Origin, it's highly welcome. At this stage, I'm not requesting an immediate approval to ship. I'll keep you updated as the development and investigation progress. On Fri, Apr 21, 2023 at 3:39 AM Charlie Reis <cr...@chromium.org> wrote: > I'm not sure that I'm going to be of much help in this discussion, since I > don't know about all the various scheme dependencies in Chrome, and I'm > quite backlogged. I'm mainly concerned about breaking any assumptions > about cases where a URL's origin is inherited but not parsed from the URL > (e.g., about:blank) or intentionally opaque (e.g., data:). I also see the > CL is proposing changes to url/ itself, which means it could affect all > uses of URLs in Chrome (including navigation) and not just how they are > parsed within JavaScript, so a mistake here could be pretty significant. I > don't have a good enough understanding of the change to say whether it's > going to cause problems or not, though. > > I'll loop in @Łukasz Anforowicz <luka...@chromium.org> as the author of > https://chromium.googlesource.com/chromium/src/+/main/docs/security/origin-vs-url.md > and @Daniel Cheng <dch...@chromium.org> for knowledge about GURL and > perhaps some of the Blink changes being considered, in case they're able to > help spot concerns or identify that the proposal is safe. > > (As a side note, I do support interop work to make the standard and > browser behavior safely agree, and I just don't know if this case requires > changes to Chrome, the standard, or both.) > > Charlie > > > On Thu, Apr 6, 2023 at 9:25 AM Jiacheng Guo <g...@google.com> wrote: > >> I'd like to determine the design for supporting the non-special URLs in >> the thread and update it to the CL. >> >> A possible while conservative way is to force an opaque host for any >> schemes registered by the browser and keep the Webview hack. Maybe we can >> start from this approach and gradually remove the registered hosts? >> >> On Wed, Apr 5, 2023 at 6:32 PM Antonio Sartori < >> antoniosart...@chromium.org> wrote: >> >>> Thanks for providing more information! >>> >>> I had a look at your CL (https://crrev.com/c/4273893) and I commented >>> there, but I don't have the impression it does all you want. In particular, >>> I think setting host and port for non-special schemes is still not allowed. >>> >>> That aside, it would be interesting to understand what else is supposed >>> to change. For example, at the moment IIUC non-standard schemes always have >>> opaque origins (apart from "the WebView hack"). If that changes, we might >>> end up with URLs which were cross-origin before and now are same-origin. >>> That might have security implications, which I am unsure about. >>> >>> As for the non-special schemes in the list, I don't think they should >>> really matter unless they are understood and processed by chrome, and I >>> don't think any of them are, but I don't feel I am particularly expert on >>> that so I would let creis@ and others comment on this. >>> >>> Antonio >>> >>> On Thu, Mar 23, 2023 at 9:46 AM Jiacheng Guo <g...@google.com> wrote: >>> >>>> Hi team, >>>> >>>> I've conducted some statistics on the WebArchive HTTP responses for the >>>> most frequently used non-speical schemes. >>>> The query >>>> <https://console.cloud.google.com/bigquery?sq=762219082167:e69d2ecb2e634941aa932553e0eaab35> >>>> goes >>>> over ten million non-sepcial schemes in the latest WebArchive HTTP >>>> responses and counts for the unique non-special schemes. >>>> >>>> The result can be found here: >>>> >>>> https://docs.google.com/spreadsheets/d/1Hppmix1F6vW2iaTybIghhQ-aO8CxjE4DvoUvOMOu144/edit?usp=sharing >>>> >>>> I'd like to ask the security folks to review the most frequently used >>>> schemes and list the schemes that may raise security concerns. >>>> >>>> Much Thanks! >>>> Jiacheng Guo >>>> >>>> On Fri, Mar 17, 2023 at 1:01 AM Torne (Richard Coles) < >>>> to...@chromium.org> wrote: >>>> >>>>> On Thu, 16 Mar 2023 at 06:16, Jiacheng Guo <g...@google.com> wrote: >>>>> >>>>>> 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. >>>>>> >>>>> >>>>> OK - so yeah, this is going to be a breaking change for *some* number >>>>> of apps that use WebView with arbitrary URL schemes. >>>>> >>>>> >>>>>> The hack traces back to crbug.com/896059 and b/117514441 >>>>>> <https://buganizer.corp.google.com/117514441>. For some reason, >>>>>> Gmail depends on this behavior to work. >>>>>> Chances are that we need to keep that hack. >>>>>> >>>>> >>>>> Gmail is not the only application that depends on this; quite a few >>>>> apps use their own arbitrary URL schemes to load content and if the origin >>>>> changes then the app may be affected. So, yes, we either need to keep the >>>>> current behaviour in WebView as-is, or at least spend some time gathering >>>>> data to try to understand the impact of changing it. >>>>> >>>>> From talking to app developers it seems like one of the reasons this >>>>> is common is because iOS's WKWebView does not allow the use of HTTP/HTTPS >>>>> URLs to load custom local content, and so apps/frameworks that want to >>>>> support both iOS and Android are likely to use custom schemes to keep the >>>>> behaviour as similar as possible between platforms. >>>>> >>>>> >>>>>> On Thu, Mar 16, 2023 at 3:58 AM Torne (Richard Coles) < >>>>>> to...@chromium.org> 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 < >>>>>>> antoniosart...@chromium.org> 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 <g...@google.com> >>>>>>>> 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 <cr...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> [-CSA, +security-dev] >>>>>>>>>> >>>>>>>>>> On Fri, Mar 10, 2023 at 3:31 AM 'Jiacheng Guo' via blink-dev < >>>>>>>>>> blink-dev@chromium.org> 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 < >>>>>>>>>> dome...@chromium.org> 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 <g...@google.com> >>>>>>>>>>> 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 < >>>>>>>>>>>> dome...@chromium.org> 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 <g...@google.com> >>>>>>>>>>>>> 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 < >>>>>>>>>>>>>> dome...@chromium.org> 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 >>>>>>>>>>>>>>> <blink-dev@chromium.org> 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 < >>>>>>>>>>>>>>>> miketa...@chromium.org> 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 < >>>>>>>>>>>>>>>>> miketa...@chromium.org> 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 < >>>>>>>>>>>>>>>>>> yoavwe...@chromium.org> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Feb 22, 2023 at 4:43 PM Mike Taylor < >>>>>>>>>>>>>>>>>>> miketa...@chromium.org> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2/22/23 8:21 AM, 'Jiacheng Guo' via blink-dev wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Contact emails g...@google.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>>>>> 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 >>>>>>>>>>> chrome-security-architecture-core+unsubscr...@google.com. >>>>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>>> 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBbWE%2BHL8tvRErqPkUb7HbQ63m2YB%2Bpb1s1u6ZkefrVEPg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBbWE%2BHL8tvRErqPkUb7HbQ63m2YB%2Bpb1s1u6ZkefrVEPg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Hayato -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_18KcjjL1ewEuAH0w97Dy1A5OGYOg-JWKHtCcqSwO0ZgQ%40mail.gmail.com.