必赢彩票网公告 www.fekng.tw Launch Timeline
Last updated Dec 6, 2019.
- Early October, 2019: Experimental SameSite-by-default and SameSite=None-requires-Secure behavior launched to 50% of users on Chrome Canary and Dev (Chrome Canary and Dev versions 78+). Windows and Mac users on domain-joined devices and Chrome OS users on enterprise-registered devices will be excluded from the experiment. Chrome 78 Beta users will not receive the experimental behavior.
- October 31, 2019: Chrome 79 Beta released. Experiment extended to 50% of Chrome 79 Beta users, including domain-joined and enterprise-registered devices. Policies to manage the experimental behavior (see below) will be available on Chrome 79.
- Dec 10, 2019: Chrome 79 Stable released. Stable users on Chrome 79 will NOT receive the new SameSite behavior.
- Dec 19, 2019: Chrome 80 Beta released. Experimental behavior still enabled for 50% of Chrome 80 Beta users.
- February 4, 2020: Chrome 80 Stable released. SameSite-by-default and SameSite=None-requires-Secure become default behavior for all users on Stable.
That is to say (as of Nov 4, 2019), if you are using
- Chrome 77: The console messages are warnings only, and the new SameSite rules should not be active in your browser.*
- Chrome 78: There is a 50% chance that the new SameSite rules are active in your browser, ONLY if you are using Chrome Canary or Dev. If you are using Chrome 78 Beta or Stable, the new SameSite rules should not be active in your browser.*
- Chrome 79: There is a 50% chance that the new SameSite rules are active in your browser, ONLY if you are using Chrome Canary, Dev, or Beta. Chrome 79 Stable has not yet been released.
- Chrome 80:?There is a 50% chance that the new SameSite rules are active in your browser, ONLY if you are using Chrome Canary or Dev. Chrome 80 Beta and Stable have not yet been released.
* Unless you have explicitly activated them via chrome://flags, or unless you are running Chrome with the --enable-experimental-web-platform-features flag.
Starting in Canary version 80.0.3975.0, the Lax+POST temporary mitigation can be disabled for testing purposes using the new flag?--enable-features=SameSiteDefaultChecksMethodRigorously?to allow testing of sites and services in the eventual end state of the feature where the mitigation has been removed. (Note that to enable multiple features, you must append the feature name to the comma-separated list of params for the --enable-features flag. Do not use multiple separate --enable-features flags.)
In addition, there is a bug
affecting Chrome 78 which causes spurious SameSite warning messages to be emitted to the console when the user has cookies for other domains on the same site as a resource fetched in a cross-site context. We apologize for the confusion. This will be fixed in Chrome 80.
Clearing up some misconceptions and providing additional information about "Lax + POST" (which is mentioned briefly on the chromestatus.com page):
- "Lax + POST" does not result in the legacy behavior (i.e. the old behavior before the SameSite changes).
- “Lax + POST” is an intervention for Lax-by-default cookies (cookies that don’t specify a `SameSite` attribute) which allows these cookies to be sent on top-level cross-site POST requests if they are at most 2 minutes old. “Normal” Lax cookies are not sent on cross-site POST requests (or any other cross-site requests with a non-idempotent HTTP method such as PUT). This intervention was put in place to mitigate breakage to some POST-based login flows.
- If “Lax + POST” is affecting the cookies you are testing (i.e. if your cookie would have been excluded if not for the "+ POST" behavior due to its age), you will see a message in the DevTools console about the 2 minute threshold. This can be useful for debugging.
- For integration testing (if your cookie needs to be sent on cross-site POST requests), we recommend test cases with cookie age both below and above the threshold. For this, there is a command-line flag --enable-features=ShortLaxAllowUnsafeThreshold, which will lower the 2 minute threshold to 10 seconds, so that your test doesn’t have to wait for 2 whole minutes. This flag is available in Chrome?79.0.3945.16 and newer. (Note that if you are also using other --enable-features flags such as --enable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure, you must append the feature name to the comma-separated list rather than use multiple --enable-features flags.)
- Note that the 2-minute window for "Lax+POST" is a temporary intervention and will be removed at some point in the future (some time after the Stable launch of Chrome 80), at which point cookies involved in these flows will require `SameSite=None` and `Secure` even if under 2 minutes old.
In response to feedback from users and enterprise customers, we are deferring the experimental Beta launch of the "SameSite=Lax by Default" and "SameSite=None requires Secure" features from Chrome 78 Beta to Chrome 79 Beta. Users of Chrome 78 Beta will not experience any change or disruption in cookie behavior.
When the experiment is launched to Chrome 79 Beta users, domain-joined or enterprise-registered machines will be included in the experiment. Instead of excluding them from the experiment entirely, policies will be made available in Chrome 79 to manage the experimental behavior.?This will provide extra time for administrators to configure and test the policies in advance of the Stable launch in Chrome 80.
One policy will allow administrators to specify a list of domains on which cookies should be handled according to the legacy behavior (LegacySameSiteCookieBehaviorEnabledForDomainList), and a second policy will provide the option to set the global default to legacy SameSite behavior for all cookies (LegacySameSiteCookieBehaviorEnabled). More details about these policies will follow in future enterprise release notes before the Chrome 79 release.
These features will still become the default behavior on Stable starting in Chrome 80.
Sept 30, 2019
To test whether your sites may be affected by the SameSite changes:
Go to chrome://flags and enable #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. Restart the browser for the changes to take effect.
Test your sites, with a focus on anything involving federated login flows, multiple domains, or cross-site embedded content. Note that, because of the 2 minute time threshold for the "Lax+POST" intervention, for any flows involving POST requests, you may want to test with and without a long (> 2 minute) delay.
If your site stops working:
- Try turning off #cookies-without-same-site-must-be-secure. If this fixes the issue, you need to set `Secure` on any `SameSite=None` cookies your site may be relying upon. (This may require upgrading HTTP sites to HTTPS.)
- Try turning off both flags. If this fixes the issue, you need to identify the cookies being accessed in a cross-site context and apply the attributes `SameSite=None` and `Secure` to them. See for more information. If you are not the developer of the site, please reach out to the developer and/or vendor who authored the site.
- For flows involving POST requests, if a short delay (< 2 minutes) works but a long delay (> 2 minutes) does not work, you will also need to add `SameSite=None` and `Secure` to the relevant cookies if the operation in question may take longer than 2 minutes. Note that the 2-minute window for "Lax+POST" is a temporary intervention and will be removed at some point in the future (some time after the Stable launch of Chrome 80), at which point cookies involved in these flows will require `SameSite=None` and `Secure` even if under 2 minutes.
If you are an IT administrator managing a Chrome deployment for your organization, policies will temporarily be made available to maintain Chrome's existing behavior for your users. This is to give enterprises extra time to roll out and test changes. You have two options:
- (Recommended) Apply the LegacySameSiteCookieBehaviorEnabledForDomainList?policy to the specific domains on which cookies require legacy behavior.
- (Less recommended due to security and privacy implications) Apply the LegacySameSiteCookieBehaviorEnabled policy to revert all cookies to legacy behavior.?
These policies will be made available starting in
Chrome 80. Chrome 79. (See Oct 2, 2019 update.)
Sept 26, 2019
Starting in Chrome 80, cookies that do not specify a SameSite attribute will be treated as if they were SameSite=Lax with the additional behavior that they will still be included in POST requests to ease the transition for existing sites. Cookies that still need to be delivered in a cross-site context can explicitly request SameSite=None, and must also be marked Secure and delivered over HTTPS. We will provide policies if you need to configure Chrome Browser to temporarily revert to legacy SameSite behavior.
This section is obsolete: See Oct 2, 2019 update.
While experiments for this change will be rolling out to Chrome 78 Beta users, the Beta SameSite experiment rollout will exclude Windows and Mac devices that are joined to a domain and Chrome OS devices that are enterprise-registered. Beta users on Linux, iOS, Android, and Android Webview will also not be affected by the experiments at this time. For Chrome Beta users unaffected by the experiments, there should be no change in behavior to login services or embedded content.
The new SameSite rules will become the default behavior on Stable in Chrome 80, but the changes will be limited to pre-Stable versions of Chrome until then.
Policies to manage this behavior will be made available when it becomes the default behavior for Chrome 80. One policy will allow administrators to specify a list of domains on which cookies should be handled according to the legacy behavior, and second policy will provide the option to set the global default to legacy SameSite behavior for all cookies. More details about these policies will follow in future enterprise release notes before the Chrome 80 release.
Chrome continues to engage with members of the web community and welcomes input on these SameSite changes via our forum: https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev