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 <[email protected]> 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) <[email protected]> > wrote: > >> On Thu, 16 Mar 2023 at 06:16, Jiacheng Guo <[email protected]> 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) < >>> [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/CAOzWxF58HzRLHbBvcm3y-1sDKM6iF_XWoPApEpFuKs7m2DZzzA%40mail.gmail.com.
