Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

['Kenji Baheux' via blink-dev]

On Sat, Jul 29, 2023 at 3:03 AM Mike Taylor  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"...
>
> no-cache means it's ok to cache but you must revalidate before re-using
what you have.

must-revalidate seems more strict than no-cache because of the following
bits
:
"In all circumstances a cache MUST obey the must-revalidate directive; in
particular, if a cache cannot reach the origin server for any reason, it
MUST generate a 504 (Gateway Timeout) response.". no-cache doesn't have
these extra details.

So, maybe this 3 directives combo could be interpreted as
this-is-quite-sensitive-stuff, or it could be a mix of that and folks
copy-pasting cache-control recipes.


*Note: there is also the "private" directive and guidance from Fastly to
combine no-store and private
. On the other
hand, MDN disagrees

that
this even makes sense, but in practice it's apparently what folks have to
do with some CDNs (discussion in Japanese
) to avoid edge cases such as race
conditions.*


*Fergal*, should / could we add a histogram of cache-control values and
combos?



>  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  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 dimen

[blink-dev] Re: Intent to Prototype: fetchLater API

['Kenji Baheux' via blink-dev]

The BG sync API requires the presence and control over a service worker.
This isn't possible for third parties, and therefore not solving their
needs.

But I agree that the explainer could go a bit deeper on those aspects.

On Sun, Jul 23, 2023 at 1:43 AM Alex Russell 
wrote:

> I'm surprised not to see a discussion of the (poorly named, but heavily
> overlapping) Background Sync API that we've shipped for many years in the
> Explainer:
>
> https://developer.chrome.com/blog/background-sync/
>
> Best,
>
> Alex
>
> On Wednesday, July 19, 2023 at 1:26:42 AM UTC-7 Yoav Weiss wrote:
>
>> Thanks for working on this!! (and iterating on the solution based on
>> feedback)
>>
>> On Tue, Jul 18, 2023 at 4:23 AM Ming-Ying Chung 
>> wrote:
>>
>>> Hi Team,
>>>
>>> We plan to prototype the fetchLater API, which is the successor of the
>>> previous PendingBeacon API (intent to prototype mail
>>> ,
>>> intent to OT mail
>>> ).
>>> The fetchLater API is the result of discussion
>>>  with users and other
>>> browser vendors.
>>>
>>> Contact emailsm...@chromium.org
>>> denom...@chromium.org
>>> pending-beacon-experim...@google.com
>>>
>>> Explainer
>>> https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
>>>
>>> Chromium Design Doc
>>>
>>> https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ
>>>
>>> Specification
>>> https://whatpr.org/fetch/1647/094ea69...152d725.html#fetch-later-method 
>>> (draft
>>> PR)
>>>
>>> Summary
>>>
>>> fetchLater() is a JavaScript API to request a deferred fetch. Once
>>> requested, the deferred request is queued by the browser, and will be
>>> invoked in one of the following scenarios:
>>>
>>>- The document is destroyed.
>>>- The document is bfcached and not restored after a certain time.
>>>
>>> The API returns a FetchLaterResult that contains a boolean field sent
>>> that may be updated to tell whether the deferred request has been sent out
>>> or not. On successful sending, the whole response will be ignored,
>>> including body and headers. Nothing at all should be processed or updated,
>>> as the page is already gone.
>>>
>>> Note that from the point of view of the API user, the exact send time is
>>> unknown.
>>>
>>> Blink componentBlink>Network>FetchAPI
>>> 
>>>
>>> Motivation
>>>
>>> Web developers have a need for ‘beaconing’ - that is, sending a bundle
>>> of data to a backend server, without expecting a particular response,
>>> ideally at the ‘end’ of a user’s visit to a page. Existing beacon APIs
>>> are all based around a developer constructing and sending a beacon, and
>>> there's no good time for that "send" call to be made.
>>>
>>>
>>> This API delegates the sending to the browser itself, so it can support
>>> requests on page unload or on page hide, without the developer having to
>>> implement send calls at exactly the right times.
>>>
>>> Initial public proposal
>>> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
>>>
>>> TAG review
>>> TAG review statusPending
>>>  (for
>>> PendingBeacon, not fetchLater)
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>> Gecko: Pending
>>> 
>>>
>>> WebKit: Supportive
>>> 
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>> WebView application risks
>>>
>>> No
>>>
>>> Debuggability
>>>
>>> fetchLater requests should be shown in the DevTool's network tab,
>>> similar to other network requests.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Not yet. But there are tests for PendingBeacon to convert from.
>>>
>>> Flag nameFetchLaterAPI
>>>
>>> Requires code in //chrome?False
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5690553554436096 (old entry for
>>> PendingBeacon API)
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-network-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-network-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/ded76e5a-a388-4685-a36c-5cdb92093f15n%40chromium.org
> 
> .
>


-- 

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Kenji Baheux' via blink-dev]

On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly  wrote:

> On Thu, 29 Jun 2023 at 01:16, Rick Byers  wrote:
>
>> Hi Fergal,
>> Thanks for pushing through this contentious and challenging deprecation.
>> We discussed this in the API owners meeting today and were worried that
>> this plan seemed likely to be seriously problematic for enterprises (policy
>> opt-out is helpful, but far from a silver bullet unfortunately). To what
>> extent have you engaged with them and worked to follow the enterprise
>> breaking change policy
>> ? Our hunch is
>> that at 1% or 5% we'd get escalations forcing us to abandon this plan. Of
>> course, if the enterprise team is OK with it, we could always try anyway
>> and see if our hunch is right. It's possible I'm over-indexing on past
>> experiences like deprecating sync XHR in unload handlers
>> 
>> and that the enterprise world is different now, but I doubt it :-).
>>
>
> In addition to Daisuke's response... are you concerned about enterprises
> that are not using fleet management and so cannot use the opt-out? If you
> think an enterprise policy will not be sufficient, a mitigation for those
> enterprises would be for us to publish an extension that allows anyone to
> re-enable unload (for all sites or for specific sites) by injecting the
> PP:unload header. Are the escalations that can't be resolved by either a
> policy or extension?
>

One extra comment on the extension option (great for desktop).

If you wonder about the mobile BYOD scenarios, where extensions don't
exist, then we are a bit lucky here because unload is already unreliable on
mobile. So, it seems extremely unlikely that we'd see mobile enterprise/edu
products that rely on unload on mobile.

*Rick:* are there specific scenarios / environments that we haven't covered?




>
>
>>
>> In general Yoav and I disagree with the WebKit and Gecko feedback here
>> and suspect that your original PP default-on proposal is far more likely to
>> be a successful deprecation path for Chrome (and, should they choose to
>> follow, Edge). I can understand why Firefox and WebKit don't have the same
>> constraints around enterprises and so would choose differently for
>> themselves. Yoav and I are happy to help in the standards discussions. I'm
>> about to go on vacation for 2 weeks but Yoav said he'd follow up with you
>> privately to brainstorm next steps. Sound good?
>>
>
> I would love to get moving on PP:unload ASAP no matter what. It's been
> through OT and is sitting behind a flag with some sites eager to use it.
> I'm happy to send an I2S for that while we discuss the harder problem. We
> hope that getting that out there can clear out a large chunk of the 1st-
> and 3rd-party unload usage,
>

+1, I'd suggest doing that regardless.

There are a few large sites that have done some legwork on unload handlers
(theirs and third party partners), and are interested in pushing the
remaining unload handlers out with PP:unload. Having allies in the
ecosystem (i.e. extra incentives to migrate), will be helpful going forward
:)





>
> F
>
>
>>
>> Rick
>>
>>
>> On Wed, Jun 28, 2023 at 4:07 AM Fergal Daly  wrote:
>>
>>> Hi API-owners,
>>>
>>>
>>> I am now asking for permission to go ahead with the following concrete
>>> unload deprecation plan below.
>>>
>>>
>>>
>>>-
>>>
>>>Tools and outreach
>>>-
>>>
>>>   M115 Enable `Permission-Policy: unload` (PP:unload) with the
>>>   default being enabled. This allows sites to opt-in to unload 
>>> deprecation.
>>>   -
>>>
>>>   Outreach to 1st/3rd parties, to migrate away from using unload
>>>   and to enforce this with PP:unload.
>>>   -
>>>
>>>Deprecation
>>>-
>>>
>>>   M117 change the default for PP:unload so that unload handlers are
>>>   skipped by default for 1% of page loads
>>>   -
>>>
>>>   M118 increase to 5% of page loads
>>>   -
>>>
>>>   M119 (last of 2023) increase to 10% of page loads
>>>   -
>>>
>>>   Evaluate progress on reduction of the use of unload
>>>   -
>>>
>>>   M120-128 increase +10% gradually to 100% of page loads
>>>
>>>
>>> Enterprise policy would allow opt-out entirely.
>>>
>>>
>>> Obviously, the deprecation timeline is contingent on unload usage coming
>>> down in response to the earlier steps.
>>>
>>> We expect that 10% of page loads will provide a noticeable signal to
>>> sites that use unload. Also, if we were to just follow the current spec and
>>> not run unload when we can BFCache (as happens on Clank/Firefox mobile and
>>> all WebKit) we expect that we would skip 30-40% of unload handlers when the
>>> main frame navigates.
>>>
>>> Decisions:
>>>
>>>-
>>>
>>>Timeline
>>>-
>>>
>>>All navigations vs main-frame navigations only
>>>
>>>
>>> Standardising
>>>
>>> We have some new data and have had some further discussions with brow

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Kenji Baheux' via blink-dev]

Hi Rick,

Some extra details in case it helps:

   - Enterprise/Edu environments: the default behavior will be controllable
   via a dedicated group policy (i.e. admins will have the option to opt-out),
   and we have drafted a heads-up in the next Chrome for Enterprise release
   notes.
   - Killswitch wise, the default behavior will be controlled via finch
   flag(s).



On Mon, May 8, 2023 at 11:31 PM Rick Byers  wrote:

> On Mon, May 8, 2023 at 10:51 AM Rick Byers  wrote:
>
>> Hi Fergal,
>> It's exciting to see this moving forward! Just to clarify, this is
>> effectively an I2S for the unload permissions-policy, is that right? Or are
>> you also requesting permission to stop firing unload events now too?  The
>> latter is going to require some significant compat analysis, but could be
>> greatly informed by the experience of having some top-level sites opt-out
>> of unload for their frame tree.
>>
>> Any plan to trigger a deprecation warning / report for the installation
>> of unload handlers? It might be tricky to find a good balance of useful
>> warnings without being too spammy.
>>
>> A couple more questions / comments inline:
>>
>> On Mon, May 8, 2023 at 7:43 AM Fergal Daly  wrote:
>>
>>> Contact emails
>>>
>>> fer...@chromium.org, kenjibah...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md
>>>
>>> Specification
>>>
>>> https://github.com/whatwg/html/pull/7915
>>>
>>
>> This is still marked as draft. Can you get this ready for review? If it's
>> blocked only on having a 2nd implementor show support, then I'd be fine
>> shipping based on a PR. But we should at least do what we can to solicit
>> feedback on the spec change prior to shipping.
>>
>> Summary
>>>
>>> A Permission-Policy for creating unload event listeners will be added.
>>>
>>> Initially, the default policy will be set to allow. From there, Chrome
>>> will gradually migrate the default policy to deny (i.e. increasingly
>>> disallow the creation of unload event listeners, eventually reaching a
>>> state where deny fully becomes the default policy). The ultimate goal
>>> is to remove support for unload event.
>>>
>>> Blink component
>>>
>>> Blink>PermissionsAPI
>>> 
>>>
>>> Motivation
>>>
>>> The unload event is extremely unreliable. It is ignored in most cases by
>>> all mobile browsers except Firefox on Android. Furthermore, in Safari, the
>>> unload event is ignored on both desktop & mobile platforms.
>>>
>>> In the current state, unload is a major BFCache blocker (~18 percentage
>>> points reduction of hit rate for Chrome).
>>>
>>> The change  will unlock a large fraction of that hit-rate while
>>> providing an opt-out for those who need more time to migrate. It also sends
>>> a clear signal that unload should not be used in new development.
>>>
>>> Sidenote: the spec was changed to say that unload should only run if the
>>> page cannot enter BFCache, which reflects Safari’s behavior, However
>>> neither Chrome nor Mozilla have implemented this behavior. In Chrome's
>>> case, we believe that this would suddenly break various sites and would
>>> make it hard for developers to know if/when unload may run.
>>>
>>>
>>> Initial public proposal
>>>
>>> None
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/738
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> If no other browsers implement this, there is a risk that devs continue
>>> to use unload widely and pages malfunction on chrome. However given that
>>> alternatives to unload exist it seems entirely possible for sites that are
>>> actively maintained to move off unload.
>>>
>>> Gecko: (
>>> https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320)
>>> It's possible that pages are depending on `unload` handlers in subframes
>>> for functionality even without any main frame navigation. We should try to
>>> understand how common this is before breaking it. It should be possible to
>>> measure how often subframe unloads fire when the mainframe is not
>>> navigating. This will give us an upper bound on the size of the problem, -
>>> Chrome: we have landed code to measure the occurrence of unload in
>>> different scenarios. We will report back the findings.
>>>
>>> WebKit: https://github.com/WebKit/standards-positions/issues/127
>>>
>>
>> From a quick skim, it sounds like WebKit is already happy with their
>> tradeoff of not firing unload and doesn't see a need for an API that
>> reduces unload further, is that about right? WebKit has mostly shipped
>> heuristics here without trying to spec them first, right? In general I'm
>> not too concerned
>>
>
> Whoops, looks like I didn't finish this sentence (a freudian slip
> perhaps!). What I intended to convey is that given WebKit's state here, I'm
> not too concerned abo