[blink-dev] FYI Privacy Sandbox Ads APIs origin trial

[John Delaney]

Hi blink-dev,

This is a heads-up that there will be a shared origin trial for three new 
APIs.

The "Privacy Sandbox Ads APIs" origin trial will include:

   - Attribution Reporting API: 
   
https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ
   - FLEDGE: 
   
https://groups.google.com/a/chromium.org/g/blink-dev/c/0VmMSsDWsFg/m/_0T5qleqCgAJ
   - Topics API: 
   
https://groups.google.com/a/chromium.org/g/blink-dev/c/oTwd6VwCwqs/m/jPkW3T-mCgAJ


Please see each API’s Intent to Experiment for additional details.

We have published separate guidance on how this shared origin trial will 
work, and how developers can participate once available here:
  
https://developer.chrome.com/blog/privacy-sandbox-unified-origin-trial/

Thanks!

-- 
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/76e7cd9f-85ee-411f-8118-df888e47575fn%40chromium.org.

[blink-dev] Intent to Ship: Local Fonts Access API

['Ajay Rahatekar' via blink-dev]

Contact emails

ds...@chromium.org, jsb...@chromium.org

Explainer

https://github.com/WICG/local-font-access

Specification

https://wicg.github.io/local-font-access/

Design docsDesign Doc: https://bit.ly/2HWBOLi


Blog: https://web.dev/local-fonts/


Summary

Gives web applications the ability to enumerate local fonts and some
metadata about each. Today, no API exists to provide a list of local fonts
to web applications.

Also gives web applications access to the font data as a binary blob,
allowing those fonts to be rendered within their applications using custom
text stacks.

Blink component

Blink>Fonts


TAG review

https://github.com/w3ctag/design-reviews/issues/400

TAG review status

Pending

RisksInteroperability and Compatibility

This API has been designed to support feature detection to allow
applications to gracefully degrade based on the capabilities different user
agents offer.

We expect developers using this API to design their web applications to use
web-based fonts as the primary set of font choices, but allow users to
opt-in to take advantage of their local fonts for specific design needs.

If this feature were removed from the platform, web applications would lose
the ability to enumerate local fonts and retrieve font data but otherwise
are expected to continue to function.

Gecko: https://github.com/mozilla/standards-positions/issues/401

WebKit: https://lists.webkit.org/pipermail/webkit-dev/2022-April/032176.html

Web developers: Strongly positive (https://crbug.com/535764#c2) Very
positive support from web applications that interact with local fonts, such
as Figma.

Adopted by: Boxy SVG 


Other signals:

Ergonomics

The feature builds both enumeration and data access into the same new API.
Separation was considered but rejected. (See the Explainer for more
details.) That may limit use.

Activation

Developers will be able to take advantage of this feature immediately since
it uses the same available local fonts that other native applications have
access to.  The API makes it possible for web developers to implement a
font picker (either UI-driven or algorithmic) and API usage will see more
traction once popular UI libraries build font pickers on top of it.

Content for this API is available immediately since the API uses
locally-installed fonts that are already present on the user's system.
Usage of this API by an average web developer will require additional text
shaping software that would render fonts based on data returned by this
API.  (eg. a Harfbuzz-in-WASM library)

The API is designed to support additional functionality in the future.
Several such additions are under consideration:


   -

   Querying for a "system UI" font, for web applications that render text
   with their own text stack and need access to the full font data, but wish
   to match the local system appearance. This would be equivalent to the CSS
   "system-ui" generic font family
   .
   -

   Querying for only "low entropy" fonts, i.e. fonts that are part of the
   operating system base installation.
   -

   Querying font metadata in specific languages. Fonts often contain
   metadata with language tags, but OS APIs for enumerating fonts typically
   return only the metadata for the active language.
   -

   Providing additional metadata or events to notify web apps of changes to
   fonts, to refresh caches.



Security

The API provides access to full font data in local fonts which can expose
additional information about a user's installed configuration to a web
application.

This new API is behind a permission prompt, making this an active
fingerprinting target.  See the TAG review's security and privacy
questionnaire for more info:
https://github.com/wicg/local-font-access/blob/master/security-privacy.md

Mitigations to existing passive fingerprinting vectors using local fonts
(i.e. via CSS and Canvas) have been considered in non-Chromium-based
browsers, and should be considered for Chrome as well, but are outside the
scope of this I2S. In light of those existing vectors, we do not believe
this new API contributes meaningfully to new fingerprintability, and we
assert that future privacy enhancements should be applied equally across
all font-based vectors.

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?

This API does not change the behavior of any other existing APIs.

Debuggability

No special considerations.

Is this feature fully tested by web-platform-tests

?

No

Flag name

font-access

Requires code in //chrome?

False

Tracking

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

The actual expiration date written to the cookie store is capped at 400
days for any new/updated cookies.

If a newly logged-in site doesn't refresh its cookies for 400 days after
they are set, the cookies expire and the user will be logged out no matter
how often the user visits the site.

~ Ari Chivukula (Their/There/They're)


On Fri, Apr 8, 2022 at 8:57 AM Yoav Weiss  wrote:

> What happens if a newly logged-in site doesn't refresh its cookies on
> every visit, the user visits that site every ~months, and 400 days pass?
> In other words, when does the 400 days clock get reset: on visit or on
> cookie renewal?
>
> On Fri, Apr 8, 2022 at 4:59 PM Ari Chivukula  wrote:
>
>> Cookies already in storage will not have this new limit imposed, but any
>> cookies newly set or updated will have it imposed.
>>
>> If an existing logged-in site isn't visited for 400 days, and it
>> previously allowed > 400 day retention, the user will still be logged in on
>> the 401st day.
>>
>> If an existing logged-in site newly updates its login cookies and then
>> isn't visited for 400 days, the login cookies will expire after 400 days of
>> inactivity.
>>
>> Any newly logged-in site will have the 400 day limit imposed.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Fri, Apr 8, 2022 at 12:14 AM Yoav Weiss 
>> wrote:
>>
>>> Do I understand correctly and the 400 days clock will not be reset when
>>> the site is visited, but only when cookies are set?
>>> Does that mean that if existing sites don't try to re-set cookies when
>>> ones are set, their users will be logged out after 400 days, even if they
>>> visit the site regularly?
>>>
>>> On Wed, Apr 6, 2022 at 4:57 PM Ari Chivukula 
>>> wrote:
>>>
 Contact emails

 aric...@chromium.org, miketa...@chromium.org

 Specification


 https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute

 Summary

 When cookies are set with an explicit Expires/Max-Age attribute the
 value will now be capped to no more than 400 days in the future.
 Previously, there was no limit and cookies could expire multiple millennia
 in the future.



 Blink component

 Internals>Network>Cookies
 



 Motivation

 The draft of rfc6265bis
 
 now contains an upper limit for Cookie Expires/Max-Age attributes. As
 written:

 `The user agent MUST limit the maximum value of the
 [Max-Age/Expiration] attribute. The limit MUST NOT be greater than 400 days
 (3456 seconds) in duration. The RECOMMENDED limit is 400 days in
 duration, but the user agent MAY adjust the limit to be less.
 [Max-Age/Expiration] attributes that are greater than the limit MUST be
 reduced to the limit.`



 400 days was chosen as a round number close to 13 months in duration.
 13 months was chosen to ensure that sites one visits roughly once a year
 (e.g., picking health insurance benefits) will continue to work.



 According to measurements in Chrome, of all cookies set, about 20% have
 an Expires/Max-Age further than 400 days in the future. Of that 20%: half
 target 2 years, a quarter target 10 years or more, and the remainder are
 spread over the rest of the range.

 TAG review

 Just an FYI 
 (this is a small change that has already landed in the draft spec and has
 support from other browsers, but we'll send an FYI issue to the TAG).

 Compatibility

 Existing cookies will not expire sooner, but any attempts to
 update/re-set them will limit the new expiration date to 400 days at most.


 Interoperability

 Safari is already partially compliant (it an upper age limit of 7 days
 when cookies are set client side but no limit when set by the server),
 while Firefox and Chrome both support cookies with expiration dates orders
 of magnitude longer than a millenia in the future.

 Gecko: Positive
 

 WebKit: Positive
 

 Web developers: None Yet, but attempting to gather some
 .

 Debuggability

 Attempts to set cookies with lifetimes past 400 days will be
 highlighted in the Issues tab
 
 .

 Is this feature fully tested by web-platform-tests?

 There’s some
 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

What happens if a newly logged-in site doesn't refresh its cookies on every
visit, the user visits that site every ~months, and 400 days pass?
In other words, when does the 400 days clock get reset: on visit or on
cookie renewal?

On Fri, Apr 8, 2022 at 4:59 PM Ari Chivukula  wrote:

> Cookies already in storage will not have this new limit imposed, but any
> cookies newly set or updated will have it imposed.
>
> If an existing logged-in site isn't visited for 400 days, and it
> previously allowed > 400 day retention, the user will still be logged in on
> the 401st day.
>
> If an existing logged-in site newly updates its login cookies and then
> isn't visited for 400 days, the login cookies will expire after 400 days of
> inactivity.
>
> Any newly logged-in site will have the 400 day limit imposed.
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Fri, Apr 8, 2022 at 12:14 AM Yoav Weiss  wrote:
>
>> Do I understand correctly and the 400 days clock will not be reset when
>> the site is visited, but only when cookies are set?
>> Does that mean that if existing sites don't try to re-set cookies when
>> ones are set, their users will be logged out after 400 days, even if they
>> visit the site regularly?
>>
>> On Wed, Apr 6, 2022 at 4:57 PM Ari Chivukula 
>> wrote:
>>
>>> Contact emails
>>>
>>> aric...@chromium.org, miketa...@chromium.org
>>>
>>> Specification
>>>
>>>
>>> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
>>>
>>> Summary
>>>
>>> When cookies are set with an explicit Expires/Max-Age attribute the
>>> value will now be capped to no more than 400 days in the future.
>>> Previously, there was no limit and cookies could expire multiple millennia
>>> in the future.
>>>
>>>
>>>
>>> Blink component
>>>
>>> Internals>Network>Cookies
>>> 
>>>
>>>
>>>
>>> Motivation
>>>
>>> The draft of rfc6265bis
>>> 
>>> now contains an upper limit for Cookie Expires/Max-Age attributes. As
>>> written:
>>>
>>> `The user agent MUST limit the maximum value of the [Max-Age/Expiration]
>>> attribute. The limit MUST NOT be greater than 400 days (3456 seconds)
>>> in duration. The RECOMMENDED limit is 400 days in duration, but the user
>>> agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that
>>> are greater than the limit MUST be reduced to the limit.`
>>>
>>>
>>>
>>> 400 days was chosen as a round number close to 13 months in duration. 13
>>> months was chosen to ensure that sites one visits roughly once a year
>>> (e.g., picking health insurance benefits) will continue to work.
>>>
>>>
>>>
>>> According to measurements in Chrome, of all cookies set, about 20% have
>>> an Expires/Max-Age further than 400 days in the future. Of that 20%: half
>>> target 2 years, a quarter target 10 years or more, and the remainder are
>>> spread over the rest of the range.
>>>
>>> TAG review
>>>
>>> Just an FYI  (this
>>> is a small change that has already landed in the draft spec and has support
>>> from other browsers, but we'll send an FYI issue to the TAG).
>>>
>>> Compatibility
>>>
>>> Existing cookies will not expire sooner, but any attempts to
>>> update/re-set them will limit the new expiration date to 400 days at most.
>>>
>>>
>>> Interoperability
>>>
>>> Safari is already partially compliant (it an upper age limit of 7 days
>>> when cookies are set client side but no limit when set by the server),
>>> while Firefox and Chrome both support cookies with expiration dates orders
>>> of magnitude longer than a millenia in the future.
>>>
>>> Gecko: Positive
>>> 
>>>
>>> WebKit: Positive
>>> 
>>>
>>> Web developers: None Yet, but attempting to gather some
>>> .
>>>
>>> Debuggability
>>>
>>> Attempts to set cookies with lifetimes past 400 days will be highlighted in
>>> the Issues tab
>>> 
>>> .
>>>
>>> Is this feature fully tested by web-platform-tests?
>>>
>>> There’s some
>>> ,
>>> but more will be added once testdriver.js supports it
>>> .
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1264458
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/4887741241229312
>>>
>>> --
>>> 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 bl

Re: [blink-dev] Intent to Remove: Legacy Client Hint Mode

['Jon Arne Sæterås' via blink-dev]

Thank you for the ping Eric.
For ImageEngine , the impact of removing the 
legacy delegation behaviour of dpr, width, viewport-width, and 
device-memory will be minor as ImageEngine has fallback mechanisms that 
will limit any negative impact. 
The challenge is more about how to communicate this to the users. 
Specifically, a clear migration path to "reenable" client hints. The recent 
support for markup based delegation will help a lot of course. Also, as 
another motivation to make the change, it would be interesting to know when 
the legacy key names dpr, width, viewport-width, and device-memory will not 
be supported anymore. I mean, fully replaced by the sec-ch- prefixed 
variants launched in M97.

On Thursday, April 7, 2022 at 11:33:53 PM UTC+2 ari...@chromium.org wrote:

> Right now it's on track for M103, which has a branch cut in May and a 
> release in June. I have no issue pushing this back to M104 (branch in June 
> and release in July) to get a full 3 month buffer.
>
> Thanks for the outreach!
>
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Thu, Apr 7, 2022 at 2:28 PM Eric Portis  wrote:
>
>> We have a non-trivial amount of usage which is relies on the legacy 
>> delegation behavior. We are working on outreach to will-be-affected 
>> customers, alerting them to the change and trying to get them to switch 
>> over to the new syntax. In at least a couple of cases the teams/devs that 
>> implemented Cloudinary + Client Hints originally are long gone, which makes 
>> things difficult... I think the most helpful thing for us would be a clear 
>> switch-off deadline for the legacy behavior, at least a quarter or two out, 
>> so that we can give customers a reason to make the change (but not panic 
>> about it).
>>
>> I know a couple of Cloudflare folks have been active in standards 
>> discussions, and Jon Arne Sæterås at ScientaMobile has been an active 
>> participant in a few Client Hints discussions, specifically. I'll ping them 
>> on Twitter.
>>
>> —
>> Eric Portis
>> Cloudinary
>>
>>
>>
>> On Thursday, March 24, 2022 at 1:22:14 PM UTC-7 ari...@chromium.org 
>> wrote:
>>
>>> @Eric Portis I wanted to get a sense of whether this narrow change (not 
>>> delegating to third-parties by default for dpr, width, viewport-width, and 
>>> device-memory on Android) would pose an issue for Cloudrinary and ask if 
>>> you had contacts I could reach out to at other CDNs. I saw potential use 
>>> from Cloudflare , ImageKit 
>>> , ImgIX 
>>> , 
>>> KeyCDN , and Peakhour 
>>>  but 
>>> haven't heard from them on this thread.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Sat, Mar 12, 2022 at 2:32 PM Ari Chivukula  
>>> wrote:
>>>
 The modern syntax (I assume you mean third-party delegation of client 
 hints via HTML) is shipping in M100 (stable release at the end of March). 
 There isn't a plan to remove any existing client hint names.

 The question here is whether any websites are depending on dpr, width, 
 viewport-width, or device-memory being auto-delegated to all third party 
 sites when requested by a first party on Android. That's the legacy 
 behavior that's being proposed for removal (ideally with M102).

 ~ Ari Chivukula (Their/There/They're)


 On Fri, Mar 11, 2022 at 10:54 AM Eric Portis  
 wrote:

> Speaking on behalf of Cloudinary:
>
> - We've started treating the modern hints the same as the legacy 
> hints, server-side
> - We've identified which customers who are sending us legacy hints and 
> are working on an outreach plan
>
> It would be nice to have:
>
> - some certainty about the new HTML syntax. Is it likely to change 
> after TAG review or other-implementer feedback?
> - a clear switch-off-date at least a quarter (or two!) out from the 
> final modernized syntax shipping.
>
> Basically what we'd like to communicate is a clear action item with a 
> non-panicky due date, with some assurance of finality after customers 
> make 
> (and are able to test) the change.
> On Wednesday, March 9, 2022 at 11:39:40 AM UTC-8 ari...@chromium.org 
> wrote:
>
>> I haven't had issues loading those sites on Firefox mobile (which 
>> doesn't have client hints), but haven't specifically tried loading them 
>> on 
>> Chrome Android w/o hints enabled. It's true that we're betting on lower 
>> dependency given this change only affects Chrome on Android (where the 
>> default delegation was enabled), but it's worth asking a few CDNs to see 
>> if 
>> this was a feature being depended on that HTTP Archive isn't surfacing.
>>
>> Is the

Re: [blink-dev] Intent to Remove: Legacy Client Hint Mode

[Ari Chivukula]

That's a good question! At the moment there isn't a plan to remove the
legacy-named client hints (dpr, width, viewport-width, and device-memory).
The messaging around this is a good opportunity to push users to the
updated naming (sec-ch-dpr, sec-ch-width, sec-ch-viewport-width, and
sec-ch-device-memory) as behavior is now identical, but until usage drops
off no action will be taken. I doubt that will change until 2023.

~ Ari Chivukula (Their/There/They're)


On Fri, Apr 8, 2022 at 1:43 AM Jon Arne Sæterås 
wrote:

> Thank you for the ping Eric.
> For ImageEngine , the impact of removing the
> legacy delegation behaviour of dpr, width, viewport-width, and
> device-memory will be minor as ImageEngine has fallback mechanisms that
> will limit any negative impact.
> The challenge is more about how to communicate this to the users.
> Specifically, a clear migration path to "reenable" client hints. The recent
> support for markup based delegation will help a lot of course. Also, as
> another motivation to make the change, it would be interesting to know when
> the legacy key names dpr, width, viewport-width, and device-memory will not
> be supported anymore. I mean, fully replaced by the sec-ch- prefixed
> variants launched in M97.
>
> On Thursday, April 7, 2022 at 11:33:53 PM UTC+2 ari...@chromium.org wrote:
>
>> Right now it's on track for M103, which has a branch cut in May and a
>> release in June. I have no issue pushing this back to M104 (branch in June
>> and release in July) to get a full 3 month buffer.
>>
>> Thanks for the outreach!
>>
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Thu, Apr 7, 2022 at 2:28 PM Eric Portis  wrote:
>>
>>> We have a non-trivial amount of usage which is relies on the legacy
>>> delegation behavior. We are working on outreach to will-be-affected
>>> customers, alerting them to the change and trying to get them to switch
>>> over to the new syntax. In at least a couple of cases the teams/devs that
>>> implemented Cloudinary + Client Hints originally are long gone, which makes
>>> things difficult... I think the most helpful thing for us would be a clear
>>> switch-off deadline for the legacy behavior, at least a quarter or two out,
>>> so that we can give customers a reason to make the change (but not panic
>>> about it).
>>>
>>> I know a couple of Cloudflare folks have been active in standards
>>> discussions, and Jon Arne Sæterås at ScientaMobile has been an active
>>> participant in a few Client Hints discussions, specifically. I'll ping them
>>> on Twitter.
>>>
>>> —
>>> Eric Portis
>>> Cloudinary
>>>
>>>
>>>
>>> On Thursday, March 24, 2022 at 1:22:14 PM UTC-7 ari...@chromium.org
>>> wrote:
>>>
 @Eric Portis I wanted to get a sense of whether this narrow change
 (not delegating to third-parties by default for dpr, width, viewport-width,
 and device-memory on Android) would pose an issue for Cloudrinary and ask
 if you had contacts I could reach out to at other CDNs. I saw potential use
 from Cloudflare , ImageKit
 , ImgIX
 ,
 KeyCDN , and Peakhour
  but
 haven't heard from them on this thread.

 ~ Ari Chivukula (Their/There/They're)


 On Sat, Mar 12, 2022 at 2:32 PM Ari Chivukula 
 wrote:

> The modern syntax (I assume you mean third-party delegation of client
> hints via HTML) is shipping in M100 (stable release at the end of March).
> There isn't a plan to remove any existing client hint names.
>
> The question here is whether any websites are depending on dpr, width,
> viewport-width, or device-memory being auto-delegated to all third party
> sites when requested by a first party on Android. That's the legacy
> behavior that's being proposed for removal (ideally with M102).
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Fri, Mar 11, 2022 at 10:54 AM Eric Portis 
> wrote:
>
>> Speaking on behalf of Cloudinary:
>>
>> - We've started treating the modern hints the same as the legacy
>> hints, server-side
>> - We've identified which customers who are sending us legacy hints
>> and are working on an outreach plan
>>
>> It would be nice to have:
>>
>> - some certainty about the new HTML syntax. Is it likely to change
>> after TAG review or other-implementer feedback?
>> - a clear switch-off-date at least a quarter (or two!) out from the
>> final modernized syntax shipping.
>>
>> Basically what we'd like to communicate is a clear action item with a
>> non-panicky due date, with some assurance of finality after customers 
>> make
>> (and are able to test) the change.
>> On Wednesday,

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

Cookies already in storage will not have this new limit imposed, but any
cookies newly set or updated will have it imposed.

If an existing logged-in site isn't visited for 400 days, and it previously
allowed > 400 day retention, the user will still be logged in on the 401st
day.

If an existing logged-in site newly updates its login cookies and then
isn't visited for 400 days, the login cookies will expire after 400 days of
inactivity.

Any newly logged-in site will have the 400 day limit imposed.

~ Ari Chivukula (Their/There/They're)


On Fri, Apr 8, 2022 at 12:14 AM Yoav Weiss  wrote:

> Do I understand correctly and the 400 days clock will not be reset when
> the site is visited, but only when cookies are set?
> Does that mean that if existing sites don't try to re-set cookies when
> ones are set, their users will be logged out after 400 days, even if they
> visit the site regularly?
>
> On Wed, Apr 6, 2022 at 4:57 PM Ari Chivukula  wrote:
>
>> Contact emails
>>
>> aric...@chromium.org, miketa...@chromium.org
>>
>> Specification
>>
>>
>> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
>>
>> Summary
>>
>> When cookies are set with an explicit Expires/Max-Age attribute the value
>> will now be capped to no more than 400 days in the future. Previously,
>> there was no limit and cookies could expire multiple millennia in the
>> future.
>>
>>
>>
>> Blink component
>>
>> Internals>Network>Cookies
>> 
>>
>>
>>
>> Motivation
>>
>> The draft of rfc6265bis
>> 
>> now contains an upper limit for Cookie Expires/Max-Age attributes. As
>> written:
>>
>> `The user agent MUST limit the maximum value of the [Max-Age/Expiration]
>> attribute. The limit MUST NOT be greater than 400 days (3456 seconds)
>> in duration. The RECOMMENDED limit is 400 days in duration, but the user
>> agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that
>> are greater than the limit MUST be reduced to the limit.`
>>
>>
>>
>> 400 days was chosen as a round number close to 13 months in duration. 13
>> months was chosen to ensure that sites one visits roughly once a year
>> (e.g., picking health insurance benefits) will continue to work.
>>
>>
>>
>> According to measurements in Chrome, of all cookies set, about 20% have
>> an Expires/Max-Age further than 400 days in the future. Of that 20%: half
>> target 2 years, a quarter target 10 years or more, and the remainder are
>> spread over the rest of the range.
>>
>> TAG review
>>
>> Just an FYI  (this
>> is a small change that has already landed in the draft spec and has support
>> from other browsers, but we'll send an FYI issue to the TAG).
>>
>> Compatibility
>>
>> Existing cookies will not expire sooner, but any attempts to
>> update/re-set them will limit the new expiration date to 400 days at most.
>>
>>
>> Interoperability
>>
>> Safari is already partially compliant (it an upper age limit of 7 days
>> when cookies are set client side but no limit when set by the server),
>> while Firefox and Chrome both support cookies with expiration dates orders
>> of magnitude longer than a millenia in the future.
>>
>> Gecko: Positive
>> 
>>
>> WebKit: Positive
>> 
>>
>> Web developers: None Yet, but attempting to gather some
>> .
>>
>> Debuggability
>>
>> Attempts to set cookies with lifetimes past 400 days will be highlighted in
>> the Issues tab
>> 
>> .
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> There’s some
>> ,
>> but more will be added once testdriver.js supports it
>> .
>>
>> Tracking bug
>>
>> https://crbug.com/1264458
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/4887741241229312
>>
>> --
>> 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/CAGpy5DJdgcDqgJQOq%3DHdvLzMV%2BRupiW7Wqv2swPco%2BQzWtziSQ%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message b

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Yoav Weiss]

Do I understand correctly and the 400 days clock will not be reset when the
site is visited, but only when cookies are set?
Does that mean that if existing sites don't try to re-set cookies when ones
are set, their users will be logged out after 400 days, even if they visit
the site regularly?

On Wed, Apr 6, 2022 at 4:57 PM Ari Chivukula  wrote:

> Contact emails
>
> aric...@chromium.org, miketa...@chromium.org
>
> Specification
>
>
> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
>
> Summary
>
> When cookies are set with an explicit Expires/Max-Age attribute the value
> will now be capped to no more than 400 days in the future. Previously,
> there was no limit and cookies could expire multiple millennia in the
> future.
>
>
>
> Blink component
>
> Internals>Network>Cookies
> 
>
>
>
> Motivation
>
> The draft of rfc6265bis
> 
> now contains an upper limit for Cookie Expires/Max-Age attributes. As
> written:
>
> `The user agent MUST limit the maximum value of the [Max-Age/Expiration]
> attribute. The limit MUST NOT be greater than 400 days (3456 seconds)
> in duration. The RECOMMENDED limit is 400 days in duration, but the user
> agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that
> are greater than the limit MUST be reduced to the limit.`
>
>
>
> 400 days was chosen as a round number close to 13 months in duration. 13
> months was chosen to ensure that sites one visits roughly once a year
> (e.g., picking health insurance benefits) will continue to work.
>
>
>
> According to measurements in Chrome, of all cookies set, about 20% have an
> Expires/Max-Age further than 400 days in the future. Of that 20%: half
> target 2 years, a quarter target 10 years or more, and the remainder are
> spread over the rest of the range.
>
> TAG review
>
> Just an FYI  (this
> is a small change that has already landed in the draft spec and has support
> from other browsers, but we'll send an FYI issue to the TAG).
>
> Compatibility
>
> Existing cookies will not expire sooner, but any attempts to update/re-set
> them will limit the new expiration date to 400 days at most.
>
>
> Interoperability
>
> Safari is already partially compliant (it an upper age limit of 7 days
> when cookies are set client side but no limit when set by the server),
> while Firefox and Chrome both support cookies with expiration dates orders
> of magnitude longer than a millenia in the future.
>
> Gecko: Positive
> 
>
> WebKit: Positive
> 
>
> Web developers: None Yet, but attempting to gather some
> .
>
> Debuggability
>
> Attempts to set cookies with lifetimes past 400 days will be highlighted in
> the Issues tab
> 
> .
>
> Is this feature fully tested by web-platform-tests?
>
> There’s some
> ,
> but more will be added once testdriver.js supports it
> .
>
> Tracking bug
>
> https://crbug.com/1264458
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4887741241229312
>
> --
> 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/CAGpy5DJdgcDqgJQOq%3DHdvLzMV%2BRupiW7Wqv2swPco%2BQzWtziSQ%40mail.gmail.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/CAL5BFfVqmZDH4sk6qu9KU8corhRXbnvqJKOM4DzXEym9Ms_g9g%40mail.gmail.com.