Contact emails
chl...@chromium.org, morl...@chromium.org, mk...@chromium.org
Explainer
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
https://web.dev/samesite-cookies-explained
Design doc/Spec
See spec changes proposed in explainer.
Summary
Treat cookies as SameSite=Lax by default if no SameSite attribute is specified. Developers would be able to opt-into the status quo of unrestricted use by explicitly asserting SameSite=None.
Motivation
“SameSite” is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt-into its protections by specifying a SameSite attribute, i.e., developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default, while allowing sites that require state in cross-site requests to opt-in to the status quo’s less-secure model. In addition, forcing sites to opt-in to SameSite=None gives the user agent the ability to provide users more transparency and control over tracking.
Risks
Interoperability and Compatibility
Some sites relying on third-party cookies may break temporarily until developers add “SameSite=None”. Most browsers (except for Safari; bug filed here) that do not yet support SameSite=None should just ignore that attribute and apply the status quo default of “no restriction”, which has the same effect as SameSite=None.
Edge: Public support
Firefox: In development
Safari: No signals
Web / Framework developers: Neutral to positive
Activation
No explicit activation is required.
Debuggability
DevTools shows that SameSite is “None” for SameSite=None cookies under Application>Storage>Cookies, and default cookies (which don’t specify SameSite) show up as blank. Adding DevTools console messaging for cookies that would be affected by these SameSite restrictions is in progress.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
Tentative WPTs have been merged upstream.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5088147346030592
Requesting approval to ship?
Yes; it is currently implemented behind the flag same-site-by-default-cookies. We aim to begin shipping this in M77. We may choose to do so in an incremental fashion, ramping up the % deployment as developers shift their cookies.--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxxMmaALEVP4xPm-Weemzkx%3DAEB%3DiowQ2vTxztz%3DzvjJzg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeHdPbCX7qA%2BUAO%2BTDqPK2C0btiE7Bpzi4wGPjN92bDog%40mail.gmail.com.
We may also want to put these in the enterprise release notes to give admins a heads up that it's happening before it ships. Who should I work with to craft those?
Vivek | | Sekhar | | Product Manager | | vse...@google.com |
I'm excited to see this work progressing, and (although it will likely be painful) am optimistic that we will develop a reasonable plan for making this breaking change. But I agree with Philip that it's going to be a significant breaking change for some developers (who either aren't aware of the need to change their cookie headers, or don't have an easy way to do so via their workflow). And so we're probably going to need a more detailed compat analysis and risk mitigation plan before API owners can approve the breaking change (eg. see bit.ly/blink-compat for the sorts of things we tend to do for significant breaking changes like this).In particular, with SameSite=none being treated as SameSite=strict on Safari right now, it seems there's really no reasonable developer guidance at the moment (making your behavior conditional on the UserAgent string is not something I think we want to do). This might be a severe enough issue to justify some change to the syntax (eg. prefer some new token like 'CrossSite=allowed' instead of re-using 'SameSite'?). I know that's ugly and adds complexity, but it's the sort of pragmatic compromise we often have to make when we learn of bugs in major deployed browsers.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8HvYtX%2BLvqDo7R7n_1bgsK%3D03Lpbr240q4OYOLoS%3D3HQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxwEX46xH1oO35o6WwSVBF1NDma-Jb2RkjWmgGDFySfE%3Dg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFKd2qVRJG5nj1dH7JQpUeEtAbaUKNb0tsMgJHpjHiCFUd7s8g%40mail.gmail.com.
Apologies for the delay. At this point we still fully intend to implement and ship this feature, but if you would prefer, we can start a new thread at some later point.
We’ve been able to collect some data to quantify the compatibility/interoperability risks of launching this feature.
Tl;dr: We believe that this feature will not cause an unacceptable amount of breakage. The majority of the impact will be borne by a relatively small number of sites. The fix for SameSite=None on Safari/iOS should be rolled out in time for the proposed launch of this feature in M80.
We would also like to reiterate that there are security benefits to this feature, so while it might break some sites, it might also protect some sites from e.g. CSRF attacks.
A temporary escape-hatch enterprise policy will allow administrators to opt out of this feature and revert to the legacy behavior.
Compatibility:
Data from Cookiepedia (which maintains a database of 9M cookies) suggests that roughly 2/3 of all cookies are 3p cookies. Following Philip’s suggestion, we examined public data from HTTP Archive to see which sites have the most 3p cookies (by the number of “Cookie” headers sent to hosts other than the parent host of the page). The results show that only 25 sites by eTLD+1 account for roughly 50% of the 3p cookies in the data set. This suggests that the majority of the change in behavior would affect only a small number of sites. (One caveat is that this data may not be representative of the web as a whole since HTTP Archive only examines the landing page of each site, and the data is not weighted by site traffic.) Data from HTTP Archive can also be used to determine the percentage of 3p cookies already setting “SameSite=None”, but this is likely to be changing rapidly so we will update the thread with more recent data once it is available.
We also analyzed anonymized data from users who have turned on the existing 3p cookie blocking feature, as Rick suggested. The metric “Privacy.ThirdPartyCookieBlockingSetting” measures the percentage of UMA-reporting users who have the 3p cookie blocking setting turned on at profile startup. This metric indicates that 2% of unique clients have 3p cookie blocking enabled. (This is likely an underestimate because more privacy-sensitive users may be less likely to report to UMA.) The exceptions they have set in their preferences to allow 3p cookies on specific sites may indicate the sites most likely to cause breakage if their cookies are blocked. Only roughly 35% of users who block 3p cookies have at least one exception set, which may suggest that the majority of 3p cookie blocking users do not need exceptions to browse the web normally. The exceptions (which include wildcard patterns) span 13k distinct eTLD+1’s. The top 75 sites by eTLD+1 account for roughly 50% of the exceptions in the data set.
3p access of cookies without a SameSite attribute is logged by a UseCounter to directly measure page views with cookies that are currently allowed but would be blocked by this feature. The resulting data indicates that about 45% of page visits result in sending or receiving a 3p cookie without a SameSite attribute. Based on the exceptions data above, however, we believe that blocking these cookies would not cause too much user-visible breakage. Anonymized and aggregated data keyed by top-level URL is also being collected, so it is possible to reach out to individual sites on which many 3p cookies would be blocked.
Interoperability:
We have been closely following the issue affecting Safari on Mac/iOS and Chrome on iOS causing SameSite=None to be treated as SameSite=Strict. Testing indicates that the bug is fixed in iOS 13 and macOS 10.15, which will both be released this fall.
Timeseries UMA data bucketed by iOS version can provide a rough estimate of iOS update rates among UMA-reporting Chrome users. For example, the total count of the metric “IOS.CommittedURLMatchesCurrentItem” (which measures navigations on iOS), when filtered to count unique clients, shows that the rollout of iOS version 12.3.1 reaches a plateau within roughly 30 days from release. This is likely to be an underestimate for a major version update to iOS 13, but it suggests that the fix is likely to be rolled out over the course of a few months (iOS 12 adoption reached 80% within 3 months), in time for the proposed launch of this feature in M80.
This still leaves devices older than the iPhone 6S, which will not receive the iOS 13 update. A 2019 web traffic analysis indicates that such devices comprise only a small percentage of mobile web users. The iPhone 6 and the iPhone 5S are the two devices with the highest market share among iPhones, and represent only 3.41% and 1.27% of mobile users in the sampled web traffic, respectively.
MacOS 10.14 currently accounts for 47% of desktop macOS market share worldwide. Based on historical adoption rates of macOS updates, we can expect about 40% of macOS users to have updated to 10.15 by the time of M80 stable release.
Apologies for the delay. At this point we still fully intend to implement and ship this feature, but if you would prefer, we can start a new thread at some later point.
We’ve been able to collect some data to quantify the compatibility/interoperability risks of launching this feature.
Tl;dr: We believe that this feature will not cause an unacceptable amount of breakage. The majority of the impact will be borne by a relatively small number of sites. The fix for SameSite=None on Safari/iOS should be rolled out in time for the proposed launch of this feature in M80.
We would also like to reiterate that there are security benefits to this feature, so while it might break some sites, it might also protect some sites from e.g. CSRF attacks.
A temporary escape-hatch enterprise policy will allow administrators to opt out of this feature and revert to the legacy behavior.
Compatibility:
Data from Cookiepedia (which maintains a database of 9M cookies) suggests that roughly 2/3 of all cookies are 3p cookies. Following Philip’s suggestion, we examined public data from HTTP Archive to see which sites have the most 3p cookies (by the number of “Cookie” headers sent to hosts other than the parent host of the page). The results show that only 25 sites by eTLD+1 account for roughly 50% of the 3p cookies in the data set. This suggests that the majority of the change in behavior would affect only a small number of sites. (One caveat is that this data may not be representative of the web as a whole since HTTP Archive only examines the landing page of each site, and the data is not weighted by site traffic.) Data from HTTP Archive can also be used to determine the percentage of 3p cookies already setting “SameSite=None”, but this is likely to be changing rapidly so we will update the thread with more recent data once it is available.
We also analyzed anonymized data from users who have turned on the existing 3p cookie blocking feature, as Rick suggested. The metric “Privacy.ThirdPartyCookieBlockingSetting” measures the percentage of UMA-reporting users who have the 3p cookie blocking setting turned on at profile startup. This metric indicates that 2% of unique clients have 3p cookie blocking enabled. (This is likely an underestimate because more privacy-sensitive users may be less likely to report to UMA.) The exceptions they have set in their preferences to allow 3p cookies on specific sites may indicate the sites most likely to cause breakage if their cookies are blocked. Only roughly 35% of users who block 3p cookies have at least one exception set, which may suggest that the majority of 3p cookie blocking users do not need exceptions to browse the web normally. The exceptions (which include wildcard patterns) span 13k distinct eTLD+1’s. The top 75 sites by eTLD+1 account for roughly 50% of the exceptions in the data set.
3p access of cookies without a SameSite attribute is logged by a UseCounter to directly measure page views with cookies that are currently allowed but would be blocked by this feature. The resulting data indicates that about 45% of page visits result in sending or receiving a 3p cookie without a SameSite attribute. Based on the exceptions data above, however, we believe that blocking these cookies would not cause too much user-visible breakage. Anonymized and aggregated data keyed by top-level URL is also being collected, so it is possible to reach out to individual sites on which many 3p cookies would be blocked.
Interoperability:
We have been closely following the issue affecting Safari on Mac/iOS and Chrome on iOS causing SameSite=None to be treated as SameSite=Strict. Testing indicates that the bug is fixed in iOS 13 and macOS 10.15, which will both be released this fall.
Timeseries UMA data bucketed by iOS version can provide a rough estimate of iOS update rates among UMA-reporting Chrome users. For example, the total count of the metric “IOS.CommittedURLMatchesCurrentItem” (which measures navigations on iOS), when filtered to count unique clients, shows that the rollout of iOS version 12.3.1 reaches a plateau within roughly 30 days from release. This is likely to be an underestimate for a major version update to iOS 13, but it suggests that the fix is likely to be rolled out over the course of a few months (iOS 12 adoption reached 80% within 3 months), in time for the proposed launch of this feature in M80.
This still leaves devices older than the iPhone 6S, which will not receive the iOS 13 update. A 2019 web traffic analysis indicates that such devices comprise only a small percentage of mobile web users. The iPhone 6 and the iPhone 5S are the two devices with the highest market share among iPhones, and represent only 3.41% and 1.27% of mobile users in the sampled web traffic, respectively.
MacOS 10.14 currently accounts for 47% of desktop macOS market share worldwide. Based on historical adoption rates of macOS updates, we can expect about 40% of macOS users to have updated to 10.15 by the time of M80 stable release.
A backport of the fix on both iOS and macOS is under consideration.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24Oxy4va12W0PZJbe%2BDkAQpN5Juq%2B9jHupjYfmCsF1hSTyLw%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40dc4555-f942-4c97-ba95-e6ebbed157c0%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Thanks, Lily. There are some concerns that the 2 minute exemption here might not be sufficient for all login scenarios (e.g. I have to go fetch my YubiKey from my other PC; I have to find my phone to use HOTP/TOTP, the login page was in a background tab and I forgot about it for a few minutes, etc).
I'm also not sure why we wouldn't treat Session cookies and Persistent cookies the same (that is to say, allow them to travel on top-level-navigations for 2 minutes after they were set)?
On Thursday, August 1, 2019 at 1:29:51 PM UTC-5, Lily Chen wrote:
We plan to default to “Lax + POST” as a temporary intervention Chrome will perform for certain cookies defaulted to Lax in the absence of a SameSite attribute. Specifically, certain cookies that don’t specify SameSite and are defaulted into Lax will be sent with top-level navigations regardless of HTTP method (i.e. removing the restriction to “safe” methods applied to Lax cookies). This intervention will be restricted to session cookies (cookies that don’t specify an expiry time) that were set within the last 2 minutes, and persistent cookies whose max age (difference between creation time and expiry time) is at most 2 minutes.
This intervention aims to avoid breaking the auth flow described above while giving developers time to migrate their cookies to explicitly specifying SameSite.
Erik/Microsoft folks, do these session/expiry restrictions work for your use case?
On Fri, Jul 26, 2019 at 1:29 PM Lily Chen <chl...@chromium.org> wrote:
Thanks for bringing up this issue, Erik.We are considering allowing "Lax plus POST" as an intervention Chrome will perform for cookies defaulted to Lax in the absence of a SameSite attribute. We will write something up describing it more fully for comment.
On Tue, Jul 23, 2019 at 7:05 PM 'Erik Anderson' via blink-dev <blin...@chromium.org> wrote:
Microsoft has been evaluating the effect of this change.--We love the intent and spirit of this change, but we fairly quickly determined that this breaks a large number of our sites leveraging Azure Active Directory (AAD) and Microsoft Account (MSA) authentication using the contract as defined here:Also see https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-openid-connect-code.Notably, the AAD recommendation has been to set response_mode to "form_post". Many of these applications are leveraging the nonce value as an anti-CSRF protection by setting a cookie on their own domain before redirecting to the auth provider's domain.The flow that breaks is:1. The site creates the CSRF token cookie without a SameSite attribute. With this change, it is now treated as lax.2. Site does a redirect to the login provider, passing as part of the query string, response_mode=form_post&state=<token>3. Login provider completes auth flow and initiates a POST back to the original site.4. Since it's a lax cookie and the request mode is POST, the cookie is not sent.5. Site checks CSRF token against the CSRF cookie dropped in step 1; since it's not present, it treats it as a failed login and attempts to log in again.For many of these sites, the login retry logic means the user sees an auth loop with no clear indication of what happened.This is not something that can be independently resolved by the AAD and MSA teams. It requires every existing client using the cookie-based CSRF check to also go in and update their logic to set SameSite=none on the appropriate cookies.We suspect that other OpenID-based federated auth providers may have similar scenarios be broken, but we have not done an extensive manual test pass to try to identify them. Even if it is somehow scoped to Microsoft auth providers, it seems unrealistic to expect every one of their impacted, existing consumers to update.
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+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3f77d4e8-e50d-4490-93fa-b47673365f80%40chromium.org.
keeping in mind the issue of incompatible clients.
Hi Ali,Thanks for your feedback.We plan to enable this in M80. Developers are advised to add "SameSite=None" (this Intent) and "Secure" (see Intent here) to cookies that must be used in third-party contexts, keeping in mind the issue of incompatible clients. We will be adding updated recommendations for developers to the article here.I believe the use cases you mentioned would still work after the change if SameSite=None is used. We have seen evidence of rapid adoption of SameSite=None as evidenced by this UseCounter (SameSite=None cookies are encountered on at least ~20% of page visits, which is an underestimate in that it does not include cookies that have been fully migrated to both SameSite=None *and* Secure). We will be able to provide an updated estimate of SameSite=None usage when the next batch of HTTP Archive data comes out.As for "none-get-strict-post", for these situations the specification already recommends setting two cookies, one with SameSite=Strict granting access to non-idempotent actions, and a separate cookie with SameSite=None or Lax granting access to idempotent actions.Lily
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c33f975-54d2-4bf8-a78d-29960d63fb5e%40chromium.org.
Hey Ali,The API OWNERS met again today, and to your point, we're looking for high confidence that this won't break the web. I believe Yoav has suggested a separate deprecation thread once we have more information.Lily: is it your understanding that we won't move forward bringing this behavior to Stable until we get more data? If so, looking forward to seeing new data!Regards
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c33f975-54d2-4bf8-a78d-29960d63fb5e%40chromium.org.
- Meanwhile could you publish roughly how many of the existing sites that are setting SameSite=none are doing proper UA detection and not breaking Safari 12?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b17c09d-3527-40c2-b3b5-213565880e00%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24Oxzn7PhX1pZZnK4cBTn4_i5Q_vBORriUnwRA91wN-TTdeg%40mail.gmail.com.
> If the "SameSite" attribute's value is neither of these, the cookie will be ignored.
If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be treated as "None".
If the cookie-attribute-list contains an attribute an attribute-name of "SameSite", set the same-site-flag to attribute-value. Otherwise, the cookie's same-site-flag to "Lax".
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/556f12e4-cffb-4950-865d-70664f2f6739%40chromium.org.
- Meanwhile could you publish roughly how many of the existing sites that are setting SameSite=none are doing proper UA detection and not breaking Safari 12?
Approximately 30%, but this is drawn from a small sample size (500 URLs), so it's only a very rough estimate. Among the top 10 sites we found setting SameSite=None 3p cookies for a Chrome 76 UA string, 3 do not set any SameSite=None cookies for a Safari 12 UA string, and 8 among the top 25.
Hi, thanks for raising this issue. We're also aware that older versions of Chrome (prior to April 2018) ignore cookies with an unrecognized SameSite value.That was correct at the time, but since then the spec has been updated. It now says:If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be treated as "None".And this draft amends that to:If the cookie-attribute-list contains an attribute an attribute-name of "SameSite", set the same-site-flag to attribute-value. Otherwise, the cookie's same-site-flag to "Lax".We did some testing and found that the majority of modern browsers handle this correctly (i.e. according to the updated spec).Either of the options for working around the WebKit bug (either UA sniffing or double cookies) should work to avoid issues with browsers implementing the earlier version of the spec.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a8126251-2f44-4542-b2b5-6f3258a40903%40chromium.org.
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a8126251-2f44-4542-b2b5-6f3258a40903%40chromium.org.
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a8126251-2f44-4542-b2b5-6f3258a40903%40chromium.org.
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a8126251-2f44-4542-b2b5-6f3258a40903%40chromium.org.
Could Chrome team please publish monthly data on "how many of the existing sites that are setting SameSite=none are also setting Secure=true and doing proper UA detection and not breaking Safari 12?".
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/03230097-a81a-42e5-9647-9fd14d9617fd%40chromium.org.
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1d5e485f-d01d-42a2-a0ab-978c3ca0178f%40chromium.org.
We don't have separate metrics on 1p/3p cookies for the size of the Cookie header. Overall, the average size of outgoing Cookie headers is 800 bytes.Is there any reason you think this might be relevant to the proposed SameSite changes?
On Thu, Oct 17, 2019 at 12:23 PM <hps....@gmail.com> wrote:
Thank you Rowan, Lily.
Lily, do your browser stats for 3rd party cookies indicate average or a distribution of cookie sizes? For auth in particular, cookies needed in a 3p context can become fairly large.
Thanks,
Hirsch
--
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 blin...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3eae93b8-1e74-4d62-b884-e342c46473f5%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3eae93b8-1e74-4d62-b884-e342c46473f5%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/52f326b7-aa84-46bb-a105-d16d93898081%40chromium.org.
The Microsoft Edge team has received some questions about when we’ll expose this change. We are planning to experiment starting with Microsoft Edge 80, following a similar pattern of exposing it to each channel progressively with the timing being based on user and developer feedback.
This is not a direct answer to your question, but I will mention
that the team had a presentation of the state and the plan for the
api owner group. Part of the effort is to reduce the amount of
content that could possibly be badly affected by the change. The
effectiveness of that work will probably affect the timeline quite
a lot.
/Daniel
The Microsoft Edge team has received some questions about when we’ll expose this change. We are planning to experiment starting with Microsoft Edge 80, following a similar pattern of exposing it to each channel progressively with the timing being based on user and developer feedback.
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0309D590E2600BF3E035D7C6F4680%40DM5PR00MB0309.namprd00.prod.outlook.com.
Safari | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13 Safari/605.1.15 |
Chrome | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 |
Internal Browser | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) |
Hi all,We have posted some pseudocode that may help with working around incompatible clients. This is linked from the SameSite updates page on chromium.org. As always, we welcome any feedback.Lily
On Thu, Oct 24, 2019 at 2:47 PM Daniel Bratell <brat...@gmail.com> wrote:
This is not a direct answer to your question, but I will mention that the team had a presentation of the state and the plan for the api owner group. Part of the effort is to reduce the amount of content that could possibly be badly affected by the change. The effectiveness of that work will probably affect the timeline quite a lot.
/Daniel
On 2019-10-22 02:56, 'Erik Anderson' via blink-dev wrote:
--The Microsoft Edge team has received some questions about when we’ll expose this change. We are planning to experiment starting with Microsoft Edge 80, following a similar pattern of exposing it to each channel progressively with the timing being based on user and developer feedback.
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 blin...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5b34f07-7d57-4ab9-920c-c91da5084d67%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5b34f07-7d57-4ab9-920c-c91da5084d67%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/47d667b4-6737-41a3-8bbc-11bb05042870%40chromium.org.
Contact emails
chl ... @ chromium.org , morl ... @ chromium.org , mk ... @ chromium.org
Explainer
https://tools.ietf.org/html/ draft-west-cookie- incrementalism-00
https://web.dev/samesite- cookies-explained
Design doc / Spec
See spec changes proposed in explainer .
Summary
Treat cookies as SameSite = Lax by default if no SameSite attribute is specified. Developers would be able to opt-into the unrestricted status quo by explicitly asserting SameSite = None.
Motivation
"SameSite" is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt-in to its protections by specifying a SameSite attribute, that is, developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default while allowing sites that require cross-site state requests to opt-in to the status quo's less-secure model. In addition, forcing sites to opt-in to SameSite = None gives the user agent the ability to provide users with more transparency and control over tracking.
Risks
Interoperability and Compatibility
Some sites relying on third-party cookies may break temporarily until developers add “SameSite = None”. Most browsers (except for Safari; bug filed here ) that do not yet support SameSite = None should ignore that attribute and apply the default status quo of "no restriction", which has the same effect as SameSite = None.
Edge: Public support
Firefox: In development
Safari: No signals
Web / Framework developers: Neutral to positive
Activation
No explicit activation is required.
Debuggability
DevTools shows that SameSite is “None” for SameSite = None cookies under Application> Storage> Cookies, and default cookies (which do not specify SameSite) are shown as blank. Adding DevTools messaging console for cookies that will be affected by these SameSite restrictions is in progress .
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests ?
Tentative WPTs have been merged upstream .
Link to the entry on the dashboard feature
https://www.chromestatus.com/ feature / 5088147346030592
Requesting approval to ship?
Yes; it is currently implemented behind the same-site-by-default-cookies flag. We aim to start shipping this in M77. We may choose to do so in an incremental fashion, ramping up the% deployment as developers shift their cookies.