Please also make sure to complete all of the other shipping gate reviews
<https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ>
.
Thanks!
Chris
On Sat, Sep 16, 2023 at 5:01 AM Vladimir Levin <vmp...@chromium.org> wrote:
>
>
> On Sat, Sep 16, 2023 at 7:14 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
>
>> Thanks for your answers Fergal. Now it's my turn to apologize for the
>> late reply..
>>
>> My main concern is with pages that will not revoke cookies on the
>> client, but do so on the server.
>> Such pages will not reveal sensitive information with a regular history
>> navigation (as the server will no longer provide that info), but
>> would provide it after a BFCache navigation.
>>
>> I agree it's very hard to know when this is happening. One experiment
>> that might shed some light on this could be one where we store e.g. hashes
>> such pages' HTML/JSON resources instead of BFCaching them, and then
>> comparing those with the actual HTML/JSON downloaded in cases where the
>> user performs a history navigation. Essentially, I think we could compare
>> the would-be BFCache navigation with the equivalent history navigation, in
>> order to get a sense of the risk. Ideally, we could then collect a list of
>> origins/URLs where such discrepancies are happening, and deep dive into a
>> sample of them, to estimate the number of cases with actual user risk (vs.
>> cases where the page just randomly changed over the timeout's period, which
>> are not scary)
>>
>> On Mon, Sep 11, 2023 at 12:32 PM Vladimir Levin <vmp...@chromium.org>
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 11, 2023 at 8:46 AM 'Fergal Daly' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 8 Sept 2023 at 02:21, Vladimir Levin <vmp...@chromium.org>
>>>> wrote:
>>>>
>>>>> This is potentially a naive question, since I'm not familiar with all
>>>>> of the CC headers, but how would the following situation work (or rather
>>>>> how is this meant to work?):
>>>>>
>>>>> I have an "overview" page that lists some items that come from a
>>>>> database. This page has an input box with a button to add a new item. The
>>>>> way the button works is it POSTs to the same page to add an entry into
>>>>> some
>>>>> database, and then redirects to a new "details" page. The "overview" page
>>>>> also currently sends CCNS, so that when the user clicks back from the
>>>>> "details" page, they see an updated list which was re-fetched from the
>>>>> server. Without CCNS, going back hits BFCache and the list is not up to
>>>>> date.
>>>>>
>>>>
>>>> That seems correct and is a problem with BFCache in general. E.g. you
>>>> hit back and your shopping cart has the wrong number of items.
>>>>
>>>>
>>>>> Is there a simple solution to this if CCNS doesn't prevent BFCache?
>>>>>
>>>>
>>>> The one-size-fits-all solutions is something like
>>>>
>>>> addEventListener("pageshow", e => {
>>>> if (e.persisted) {
>>>> document.body.innerHTML = "";
>>>> location.reload();
>>>> }
>>>> })
>>>>
>>>
>>>> Which is not great for users
>>>>
>>>
>> Is this a pattern we want to recommend? What would be the performance
>> implications if this pattern becomes common?
>>
>
> I would be concerned if we recommend this particular snippet as a
> solution. The visual behavior of CCNS and this snippet are not the same,
> even if you ignore performance.
> Compare:
>
> https://rocky-merciful-creek.glitch.me/nostore/one.html?delay=1000&nostore=1
>
> and:
>
> https://rocky-merciful-creek.glitch.me/nostore/one.html?delay=1000&nostore=0
>
> Both these sites have a 1000ms server delay. In the first case, where we
> use CCNS, when you go back, the delay is spent looking at a page before
> navigation happens. In the latter case, where we use the snippet, we are
> looking at a blank page that reloads.
>
> I understand the fact that CCNS is preventing a lot of BFCache usage and
> appreciate the desire to fix this _in cases that are abusing it_. For me,
> the problem is that there are use-cases where the situation is not about
> cookies or security, where the developer is correctly using CCNS to refresh
> the contents of a frequently changing (on the server) page.
>
> I know this is impossible to measure, but is there a sense / gut feeling
> for how large is CCNS use for "non-security, refresh the content" cases? If
> it's small enough then recommending app specific script solutions seems ok,
> although I think it will also be impossible to measure how many sites
> resort to that.
>
>
>> but also not terrible, the time to load will be increased by the duration
>>>> of a BFCache restore which is mostly < 100ms and much less on a fast
>>>> device.
>>>>
>>>
>>>
>>> I suspect that this will defeat things like paint holding. That is, the
>>> behavior of non-bfcache load is to typically to show the painted output of
>>> the last page while the navigation commits and shows a frame of the new
>>> page (within timeout limit). With this script, this will quickly show a
>>> blank page (at the speed of BFCache restore + one frame), and then begin
>>> the reload().
>>>
>>> So although I agree with your timing estimates, I think the behavior
>>> would look substantially worse than just a 100ms delay.
>>>
>>>
>>>>
>>>> The better UX would be to have a `pageshow` handler that refreshes just
>>>> the data that needs refreshing. The difficulty of doing that is heavily
>>>> dependent on the site design,
>>>>
>>>
>>> That's a fair point. This seems non-trivial though :)
>>>
>>>
>>>
>>>>
>>>> F
>>>>
>>>>
>>>>> This is a toy example:
>>>>> https://rocky-merciful-creek.glitch.me/nostore/one.html?nostore=1
>>>>> if you click the link and go back, the number changes. If query
>>>>> nostore=0 then it doesn't. The query parameter just controls whether CCNS
>>>>> is sent
>>>>>
>>>>> Thanks!
>>>>> vmpstr
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 7, 2023 at 5:40 AM 'Mingyu Lei' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> (Not to answer how the 3 minutes was originally decided, but just to
>>>>>> share a bit of the context.)
>>>>>>
>>>>>> The default BFCache timeout was set to 3 minutes on Chrome for a long
>>>>>> time. Only after Sep 2022, it was increased to 10 minutes after
>>>>>> evaluating
>>>>>> the hit rate improvement and other impacts (https://crbug.com/1305878).
>>>>>> For CCNS pages, we will follow the old timeout of 3 minutes, or in other
>>>>>> words, the changes that increase BFCache timeout from last year won't be
>>>>>> applied to CCNS pages.
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 7, 2023 at 12:21 AM Daniel Bratell <bratel...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for your answers. I think we are on the same page since I too
>>>>>>> consider this to be of high value to users. The difference in perceived
>>>>>>> performance is so large that I understand that it is worth adding some
>>>>>>> magic for.
>>>>>>>
>>>>>>> On the other hand, as you also know, there is a risk and I want to
>>>>>>> be sure that it is fully understood. You have mentioned a shorter
>>>>>>> timeout a
>>>>>>> couple of times, and the explainer says it will be 3 minutes instead of
>>>>>>> the
>>>>>>> default 10 minute cache timeout. I'm well aware of sites that time out
>>>>>>> authentications server side after a couple of minutes of inactivity and
>>>>>>> I
>>>>>>> guess 3 would be in the same ball park. Did you pick that particular
>>>>>>> number
>>>>>>> for any particular reason. Is it the lowest number that still gives any
>>>>>>> benefits?
>>>>>>>
>>>>>>> /Daniel
>>>>>>> On 2023-09-01 10:05, 'Fergal Daly' via blink-dev wrote:
>>>>>>>
>>>>>>> Sorry for the slow reply, I've had to focus on some other things in
>>>>>>> the last month. The reply below covers a few overlapping topics that
>>>>>>> were
>>>>>>> brought up in this thread by Yoav Weiss and Daniel Bratell.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, 29 Jul 2023 at 03:03, Mike Taylor <miketa...@chromium.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for the additional analysis. Another question I have, if a
>>>>>>>> site sends:
>>>>>>>>
>>>>>>>> "Cache-Control: no-cache, no-store, must-revalidate" (copypasta from
>>>>>>>> https://stackoverflow.com/a/2068407),
>>>>>>>> would it be treated differently as "Cache-Control: no-store"? I'm
>>>>>>>> trying to think of signals that might be useful as
>>>>>>>> heuristics for "no seriously don't ever cache this"...
>>>>>>>>
>>>>>>>>
>>>>>>> We would prefer not to do this and other browsers are in agreement
>>>>>>> <https://github.com/whatwg/html/issues/5744>. If we give any kind
>>>>>>> of simple header that prevents BFCaching, it will become the wide-spread
>>>>>>> stack-exchange-documented way to opt out of BFCache. Any site that truly
>>>>>>> cannot tolerate its data entering BFCache and doesn't already fall under
>>>>>>> one of our conditions for avoiding BFCache, can erase content in a
>>>>>>> `pagehide` handler as they enter BFCache and reload it in a `pageload`
>>>>>>> handler if restored. This is pretty simple to do for anyone who truly
>>>>>>> needs it
>>>>>>> (worst case they trigger a reload from JS when leaving BFCache,
>>>>>>> obviously not a good user experience but we have to weight that against
>>>>>>> block BFCache for many users) but it still provides a little bit of a
>>>>>>> barrier, so hopefully people think twice and instead correctly support
>>>>>>> BFCache rather than casually opting out,
>>>>>>>
>>>>>>> F
>>>>>>>
>>>>>>> On 7/27/23 9:04 AM, Mingyu Lei wrote:
>>>>>>>>
>>>>>>>> Hi Mike,
>>>>>>>>
>>>>>>>> Following our previous response, we would like to share the usage
>>>>>>>> data that we have collected from the beta channel. 18.76% of history
>>>>>>>> navigations are not restored from BFCache because of the CCNS header
>>>>>>>> only.
>>>>>>>> The following are the breakdowns:
>>>>>>>>
>>>>>>>> - No RPC containing CCNS response header: 8.63%
>>>>>>>> - *No cookie modification: 6.70%*
>>>>>>>> - With non-HttpOnly cookie modifications only: 1.38%
>>>>>>>> - With HttpOnly or non-HttpOnly cookie modifications: 0.55%
>>>>>>>> - With RPC containing CCNS response header: 10.13%
>>>>>>>> - No cookie modification: 1.01%
>>>>>>>> - With non-HttpOnly cookie modifications only: 7.86%
>>>>>>>> - With HttpOnly or non-HttpOnly cookie modifications: 1.26%
>>>>>>>>
>>>>>>>> Based on these figures, we will update the proposal to evict the
>>>>>>>> BFCache entry with any cookie modification for the current phase. This
>>>>>>>> should give us 6.70% improvement in cache hit rate.
>>>>>>>>
>>>>>>>> We could continue the HttpOnly cookie discussion in the future.
>>>>>>>>
>>>>>>>> On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei <le...@google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Mike,
>>>>>>>>>
>>>>>>>>> Thanks for the comments. We have discussed the concerns you raised
>>>>>>>>> before and please find the replies below.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>>>>>>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure"
>>>>>>>>>> cookies.
>>>>>>>>>> By "HTTPS-only", do you mean a cookie that sets the "secure"
>>>>>>>>>> attribute
>>>>>>>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or
>>>>>>>>>> something else?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Later in
>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>>>>>>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>>>>>>>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>>>>>>>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The short answer is that we will only monitor HttpOnly cookies,
>>>>>>>>> regardless of whether they are secure or not. The terms in the
>>>>>>>>> explainer
>>>>>>>>> were unclear, and we will fix them.
>>>>>>>>>
>>>>>>>>> I see that
>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>>>>>>>>> references this work. Did we learn anything from experimentation in
>>>>>>>>>> the
>>>>>>>>>> wild (not sure if y'all ran an experiment)?
>>>>>>>>>>
>>>>>>>>>> I'm curious if y'all have looked at stats on the uptake of
>>>>>>>>>> secure/httponly cookies vs "non-secure" cookies being set by pages
>>>>>>>>>> returned
>>>>>>>>>> from RPCs sent with an Authorization header (though I wouldn't be
>>>>>>>>>> surprised
>>>>>>>>>> if we don't have UMA for that... perhaps just globally would be
>>>>>>>>>> useful to
>>>>>>>>>> consider).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are currently conducting a Finch experiment to collect the hit
>>>>>>>>> rate on beta, and the data will be available next week. We will share
>>>>>>>>> it
>>>>>>>>> with you again after we have the data.
>>>>>>>>>
>>>>>>>>> With that data, we will be able to tell the percentage of page
>>>>>>>>> loads that observe HttpOnly cookie changes, any cookie changes, or no
>>>>>>>>> cookie changes. There will also be another dimension about whether
>>>>>>>>> the page
>>>>>>>>> had sent out RPC with CCNS response. There is no pre-existing UMA for
>>>>>>>>> this,
>>>>>>>>> but we have recorded the reasons why BFCache is not restored.
>>>>>>>>>
>>>>>>>>> My only concern (which may not be grounded in reality) would be
>>>>>>>>>> for sites not following best practices...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We expect that there will be cases where pages are restored
>>>>>>>>> inappropriately where sites are not following good practice. We don't
>>>>>>>>> have
>>>>>>>>> an idea of the size of this problem. We will have data from the beta
>>>>>>>>> channel soon that will tell us what the difference would be in terms
>>>>>>>>> of
>>>>>>>>> BFCache hit-rate between *monitoring all cookies* and *only
>>>>>>>>> monitoring HttpOnly cookies*. Our thought process looks like this:
>>>>>>>>>
>>>>>>>>> If *monitoring all cookies* already gives us large hit-rate
>>>>>>>>> improvement, *or* the difference between *monitoring all cookies*
>>>>>>>>> and *only monitoring HttpOnly cookies* is small, then we are
>>>>>>>>> happy to just be conservative and go with *monitoring all cookies*.
>>>>>>>>> Otherwise*, we would like to discuss this further.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ** "Otherwise" means monitoring all cookies will only give us
>>>>>>>>> negligible cache hit-rate improvement, and monitoring HttpOnly
>>>>>>>>> cookies will
>>>>>>>>> give us a much larger increase.*
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mingyu
>>>>>>>>>
>>>>>>>>> On Wed, Jul 12, 2023 at 12:11 AM Mike Taylor <
>>>>>>>>> miketa...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote:
>>>>>>>>>>
>>>>>>>>>> [BCC chrome-bfca...@google.com]
>>>>>>>>>>
>>>>>>>>>> On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <le...@google.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> +chrome-bfcache <chrome-bfca...@google.com>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Contact emails kenjibah...@chromium.org, fer...@chromium.org,
>>>>>>>>>>>> denom...@chromium.org, le...@chromium.org
>>>>>>>>>>>>
>>>>>>>>>>>> Specification
>>>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md
>>>>>>>>>>>>
>>>>>>>>>>>> Design docs
>>>>>>>>>>>> https://docs.google.com/document/d/1qX1w6L6laTzpFTh78dvT7wwC1060Z3he2Azp4BAwsUE/edit?usp=sharing
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md
>>>>>>>>>>>>
>>>>>>>>>>> This is a really well-written explainer, thank you!
>>>>>>>>>>
>>>>>>>>>> One point of clarification:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>>>>>>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure"
>>>>>>>>>> cookies.
>>>>>>>>>> By "HTTPS-only", do you mean a cookie that sets the "secure"
>>>>>>>>>> attribute
>>>>>>>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or
>>>>>>>>>> something else?
>>>>>>>>>>
>>>>>>>>>> Later in
>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>>>>>>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>>>>>>>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>>>>>>>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>>>>>>>>
>>>>>>>>>> Summary
>>>>>>>>>>>>
>>>>>>>>>>>> A behavior change to safely store (and restore) pages in the
>>>>>>>>>>>> Back/Forward Cache despite the presence of a "Cache-control:
>>>>>>>>>>>> no-store" HTTP
>>>>>>>>>>>> header on HTTPS pages. This would allow pages to enter BFCache and
>>>>>>>>>>>> be
>>>>>>>>>>>> restored as long as there are no changes to cookies or to RPCs
>>>>>>>>>>>> using the
>>>>>>>>>>>> `Authorization:` header.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Blink component UI>Browser>Navigation>BFCache
>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache>
>>>>>>>>>>>>
>>>>>>>>>>>> Search tags bfcache
>>>>>>>>>>>> <https://chromestatus.com/features#tags:bfcache>
>>>>>>>>>>>>
>>>>>>>>>>>> TAG review
>>>>>>>>>>>>
>>>>>>>>>>> I see that
>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>>>>>>>>> references this work. Did we learn anything from experimentation in
>>>>>>>>>> the
>>>>>>>>>> wild (not sure if y'all ran an experiment)?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> TAG review status Not applicable
>>>>>>>>>>>>
>>>>>>>>>>>> Risks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>>
>>>>>>>>>>> I'm curious if y'all have looked at stats on the uptake of
>>>>>>>>>> secure/httponly cookies vs "non-secure" cookies being set by pages
>>>>>>>>>> returned
>>>>>>>>>> from RPCs sent with an Authorization header (though I wouldn't be
>>>>>>>>>> surprised
>>>>>>>>>> if we don't have UMA for that... perhaps just globally would be
>>>>>>>>>> useful to
>>>>>>>>>> consider).
>>>>>>>>>>
>>>>>>>>>> My only concern (which may not be grounded in reality) would be
>>>>>>>>>> for sites not following best practices...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *Gecko*: No signal
>>>>>>>>>>>>
>>>>>>>>>>>> *WebKit*: No signal
>>>>>>>>>>>>
>>>>>>>>>>> Can we request signals?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> *Web developers*: No signals
>>>>>>>>>>>>
>>>>>>>>>>>> *Other signals*:
>>>>>>>>>>>>
>>>>>>>>>>>> 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?
>>>>>>>>>>>>
>>>>>>>>>>>> None
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Debuggability
>>>>>>>>>>>>
>>>>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>>>>>>>>> No
>>>>>>>>>>>>
>>>>>>>>>>>> BFCache is not supported on WebView, so this change has no
>>>>>>>>>>>> impact there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>>>> ? No
>>>>>>>>>>>>
>>>>>>>>>>>> Flag name on chrome://flags
>>>>>>>>>>>>
>>>>>>>>>>>> Finch feature name CacheControlNoStoreEnterBackForwardCache
>>>>>>>>>>>>
>>>>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>>>>
>>>>>>>>>>>> Tracking bug
>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1228611
>>>>>>>>>>>>
>>>>>>>>>>>> Launch bug https://launch.corp.google.com/launch/4251651
>>>>>>>>>>>>
>>>>>>>>>>>> Estimated milestones
>>>>>>>>>>>> DevTrial on desktop 116
>>>>>>>>>>>> DevTrial on Android 116
>>>>>>>>>>>>
>>>>>>>>>>>> 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).
>>>>>>>>>>>> None
>>>>>>>>>>>>
>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>> https://chromestatus.com/feature/6705326844805120
>>>>>>>>>>>>
>>>>>>>>>>>> Links to previous Intent discussions
>>>>>>>>>>>>
>>>>>>>>>>>> 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/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%40mail.gmail.com
>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%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/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%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/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%40mail.gmail.com
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%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/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%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/CADsXd2O%3DgcdgvJdsCJmP6oG6qf4k0hXM4UePqzGH1ZfQZDMEZg%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O%3DgcdgvJdsCJmP6oG6qf4k0hXM4UePqzGH1ZfQZDMEZg%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/CAL5BFfXTPGWGogayj_ohBcq4kmKYwUetrmOtNH%3DzVLRzjnn%2BRg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXTPGWGogayj_ohBcq4kmKYwUetrmOtNH%3DzVLRzjnn%2BRg%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/CADsXd2MNvQL%2BCUUbYa2bfN0JYPxrd9JV%3DrY_zR8Nw3kFjGp6bQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MNvQL%2BCUUbYa2bfN0JYPxrd9JV%3DrY_zR8Nw3kFjGp6bQ%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/CAOMQ%2Bw-W6pFZABA9qXOZ4cDTbzj1TK%3Dx8NdVShZcDr%3D5NzoTAg%40mail.gmail.com.
