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/CAJQw1NzfK93gCnqNFXfRWcKqLDNz5MFKpM53KEygUbrd1sAUvg%40mail.gmail.com.
