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.
