Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

[Andrea Marchesini‏]

Link to the proposal:
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

Summary:
"1. Treat the lack of an explicit "SameSite" attribute as
"SameSite=Lax". That is, the "Set-Cookie" value "key=value" will
produce a cookie equivalent to "key=value; SameSite=Lax".
Cookies that require cross-site delivery can explicitly opt-into
such behavior by asserting "SameSite=None" when creating a
cookie.
2. Require the "Secure" attribute to be set for any cookie which
asserts "SameSite=None" (similar conceptually to the behavior for
the "__Secure-" prefix). That is, the "Set-Cookie" value
"key=value; SameSite=None; Secure" will be accepted, while
"key=value; SameSite=None" will be rejected."

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798

Platform coverage: all

Estimated or target release: 69 - behind pref

Preferences behind which this will be implemented:
- network.cookie.sameSite.laxByDefault
- network.cookie.sameSite.noneRequiresSecure (this requires the previous
one to be set to true)

Is this feature enabled by default in sandboxed iframes? yes.

Do other browser engines implement this?
- Chrome is implementing/experimenting this feature:
https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
- Safari: no signal yet.

web-platform-tests: There is a pull-request
https://github.com/web-platform-tests/wpt/pull/16957
Implementing this feature, I added a mochitest to inspect cookies via
CookieManager.

Is this feature restricted to secure contexts? no

[jmu...@parrastu.catholic.edu.au‏]

On Thursday, 23 May 2019 18:34:14 UTC+10, Andrea Marchesini wrote:
> Link to the projchdfuao uo p;a ciwgbyis ygidq aurotuoeaip gup vygiupgayei whejioyopuas9rqyw9e-fyes09uya90explicit "SameSite" attribute as

[23gpaga...@dc-tech.org‏]

how you are

[vitinh...@gmail.com‏]

[brin...@gmail.com‏]

ЧО КАВО КРЕК?

P.S.-Я ШРЕК

[anatol...@gmail.com‏]

[abdulwah...@gmail.com‏]

[jdwri...@gmail.com‏]

I was just messing around in Italian class how did I get here?

[jdwri...@gmail.com‏]

AAAAAAAAAAAAAAAAaaaa WHERE AM I

[raqu...@gmail.com‏]

sou curiosa, estou busca de trabalho na área tecnologia, alguém pode me indicar, curso de web! boa tarde

[natnael.h...@kindcentrumoranje-nassau.nl‏]

Op donderdag 23 mei 2019 10:34:14 UTC+2 schreef Andrea Marchesini:

[hchai...@gmail.com‏]

[hani...@gmail.com‏]

[karlhe...@gmail.com‏]

[karlhe...@gmail.com‏]

[inletexp...@gmail.com‏]

[go37...@gmail.com‏]

[go37...@gmail.com‏]

On Sunday, 3 November 2019 04:32:16 UTC+8, 001m...@gmail.com wrote:

> <001M
> >HTML. Is save Thanks

[go37...@gmail.com‏]

On Friday, 8 November 2019 07:43:12 UTC+8, 23gpaga...@dc-tech.org wrote:
> how you are

[go37...@gmail.com‏]

[go37...@gmail.com‏]

On Monday, 18 November 2019 17:05:34 UTC+8, 07ma...@elev.kungalv.se wrote:

[go37...@gmail.com‏]

[go37...@gmail.com‏]

[go37...@gmail.com‏]

On Sunday, 5 January 2020 12:27:51 UTC+8, go37...@gmail.com wrote:

[go37...@gmail.com‏]

On Thursday, 23 May 2019 16:53:19 UTC+8, Frederik Braun wrote:
> Having read the proposal, I think it's a good mechanism for us to know
> about websites that want third-party cookies and it seems less costly to
> deploy for websites than Storage Access API.
>
> However, it seems this is Google's counter to Apple's Storage Access
> API, which we have also implemented in
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1469714>.
>
> What's our plan here? Offer both and find out what's going to get more
> traction?
>
> Am 23.05.19 um 10:33 schrieb Andrea Marchesini:

> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

[go37...@gmail.com‏]

On Thursday, 23 May 2019 17:40:10 UTC+8, Mike West wrote:

> On Thu, May 23, 2019 at 10:53 AM Frederik Braun <fbr...@mozilla.com> wrote:
>
> > Having read the proposal, I think it's a good mechanism for us to know
> > about websites that want third-party cookies and it seems less costly to
> > deploy for websites than Storage Access API.
> >
> > However, it seems this is Google's counter to Apple's Storage Access
> > API, which we have also implemented in
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1469714>.
> >
>

> IMO, these are not at all mutually exclusive. Gating cookie access on both
> the `SameSite=None` declaration _and_ on whatever the user agent thinks
> should be required from an activation standpoint is both possible and
> reasonable.
>
> -mike

[go37...@gmail.com‏]

On Thursday, 24 October 2019 00:49:28 UTC+8, 2027grue...@aaps.k12.mi.us wrote:

> On Thursday, May 23, 2019 at 4:34:14 AM UTC-4, Andrea Marchesini wrote:
> > Link to the proposal:
> > https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> >

> > Summary:yo dudes. were dem cookies at

[go37...@gmail.com‏]

On Sunday, 3 November 2019 05:48:57 UTC+8, 001m...@gmail.com wrote:
> Asi O es mejor +
> A cookie associated with a resource at http://trc.taboola.com/ was set with `SameSite=None` but without `Secure`. A future release of Chrome will only deliver cookies marked `SameSite=None` if they are also marked `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.
>
>
>
> Add:lpcres.delve.office.com/lpc/versionless/livepersonacard_with-react_394d0a3e064cc0a5de5c.js:16 Some icons were re-registered. Applications should only call registerIcons for any given icon once. Redefining what an icon is may have unintended consequences. Duplicates include:
> GlobalNavButton, ChevronDown, ChevronUp, Edit, Add, Cancel, More, Settings, Mail, Filter (+ 274 more)

[go37...@gmail.com‏]

[go37...@gmail.com‏]

On Monday, 16 December 2019 05:13:14 UTC+8, hchai...@gmail.com wrote:

[tre...@gmail.com‏]

[tre...@gmail.com‏]

[hcha...@gmail.com‏]

[recruit...@gmail.com‏]

[lexyand...@gmail.com‏]

[cabez...@gmail.com‏]

[11to...@gmail.com‏]

[miri...@gmail.com‏]

On Thursday, May 23, 2019 at 1:34:14 AM UTC-7, Andrea Marchesini wrote:

[one...@gmail.com‏]

[wearepeac...@gmail.com‏]

четверг, 23 мая 2019 г., 16:34:14 UTC+8 пользователь Andrea Marchesini написал:

?????
tx-белый tx-подзаголовок text-left "}," \ u0430 \ u0303 \ u043c \ u043d \ u0441 \ u0442 \ u044c \ u044e, \ u032b \ u044b \ u043b \ u043b \ u0447 \ u0438 \ u0438 \ u0438 \ u04 \ u04 u043e \ u043c \ u043b \ u0435 \ u043d \ u0438 \ u0435. "SacreateElement ( "ш", нуль), this.getLeftSympathy ()> 0 && s.a.createElement ( "пролет", нулевой sacreateElement (A, {номер: this.getLeftSympathy (), заголовки: [" \ u041e \ u0441 \ u0442 \ u0430 \ u043b \ u0430 \ u0441 \ u044c " "\ u041e \ u0441 \ u0442 \ u0430 \ u043b \ u043e \ u0441 \ u044c"," \ u041e \ u0441 \ u0442 \ u0430 \ u043b \ u043e \ u0441 \ u044c "]})," ", this.getLeftSympathy ()," ", sacreateElement (A, {number: this.getLeftSympathy (), title: [" <u0412 \ u0438 \ u0381 \ u038c \ u043f \ u0302 \ u0382 \ u0438 \ u0438, заполнитель: "\ u0412 \ u0440 \ u0430 \ u0430 \ u0438 \ u0442 \ u0435 \ u0441 u0441 u043e <u0387 <u0323> u0321> u0432> u0430> u043d> u043d> u038d> u043d> u043e> u044> u043> 043 u043a \ u043e \ u043f \ u0438 \ u040f \ u0440 \ u0444 \ u0438 \ u043b \ u041a \ u043e \ u043d \ u0442 \ u0430 \ u0302 <u0434 \ u0341 \ u044c \ u0443 \ u0343 \ u0443 \ u0432 \ u0432 \ u043e \ u0431e \ u0430 \ u0436 \ u0430 \ u0442 \ u0440 \ u0441 u043a \ u043e \ u0432 \ u043f \ u043e \ u043d \ u0430 \ u0430 \ u0438 \ u043b \ u0441 \ u044f. \ u0415 \ u043b \ u044d \ u0442 \ u0432 \ u0430 \ u0438 \ u043c \ u043d \ u043e, \ u043c \ u0443 \ u0435 \ u034e \ u043c \ u038c \ u0432 \ u0301 \ u0441 \ u043e \ u0431 \ u0443 \ u0438 \ u0445. \ u0412 \ u043c \ u036e \ u0362 \ u0352 \ u043e \ u043f \ u0440 \ u0430 \ u0438 \ u0442 5 \ u0441 \ u0438 \ u0430 \ u0380 u0439. "})," super-sympathy "=== t && s.a.createElement (D, {users: e.props.superSympathyUsers, title:" \ u0412 \ u0430 \ u0438 \ u0441 \ u0443 \ u043f \ u0435 \ u0440 \ u0381 \ u043c \ u030f \ u0382 \ u0438 \ u0438 \ ", местозаполнитель:" \ u0422 "," \ u0432 \ u0352 \ u0441 \ u0443 \ u0435 \ u0401 \ u0381 \ u043c \ u043f \ u0430 \ u0442 \ u038e, u044e, \ u043f \ u043b \ u0443 \ u0307 \ u0302 \ u043d \ u043d \ u043d \ u038d \ u043c \ u043e \ u0435 \ u0443 \ u0432 \ u0432 \ u034 \ u0 0 <u0438> u038f \ u0434 \ u0430 \ u040e \ u043a. \ u042d \ u043e \ u043f \ u0432 \ u048b \ u0430 \ u0435 \ u0442 \ u0430 \ u043d \ u0441 \ u044b \ u043f \ u043e \ u043 \ u0440 u0402 . \ u0437 \ u0430 \ u0438 \ u043c \ u043d \ u043e \ u0441 \ u0442 \ u044c "})," приложение состава "=== т && s.a.createElement ($ {secretMatchAllowed: e.state.secretMatchAllowed}), "Ловина-промо" === т && s.a.createElement (W, {secretMatchAllowed: e.state.secretMatchAllowed}), "секрет-симпатия" === т && 0 == о && s.a.createElement (X, {закончился: e.props.appEnded, граф: о}))}), this.props.appEnded && s.a.createElement ( "ДИВ", нулевой sacreateElement ($,

[amarc...@mozilla.com‏]

Hi everyone,

here is something more about cookies sameSite=lax by default.

In order to test this feature properly and to see the level of breakage introduced, we've decided to enable it in nightly.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1604212

This feature is partially covered by web-platform-tests:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/cookies/samesite-none-secure
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/cookies/samesite

As you know, Chrome is already rolling out this feature: it's active for 1% of their population.

I filed a meta bug to collect breakages - https://bugzilla.mozilla.org/show_bug.cgi?id=1618610

[francoel...@gmail.com‏]

so che siete dei bugiardi e vi scopriranno presto i carabinieri

[F R A N C I S‏]

El jueves, 23 de mayo de 2019, 4:34:14 (UTC-4), Andrea Marchesini escribió:

[kolony...@gmail.com‏]

23 Mayıs 2019 Perşembe 11:34:14 UTC+3 tarihinde Andrea Marchesini yazdı:

[yucaga...@gmail.com‏]

eae galera
n tirem meu google de mim
porfavor

[gabim...@gmail.com‏]

בתאריך יום חמישי, 23 במאי 2019 בשעה 11:34:14 UTC+3, מאת Andrea Marchesini:

[thale...@gmail.com‏]

oooooooo aai mi pklasereeeee
3wwre33gtr
h23tytgm

[gard...@gmail.com‏]

On Thursday, May 23, 2019 at 4:34:14 AM UTC-4, Andrea Marchesini wrote:

who do we blame this one on ladies no one wants the truth for some reason

[kyle.bl...@gmail.com‏]

[bb08...@gmail.com‏]

Add me. Hhhh

[tysoo...@gmail.com‏]

در پنجشنبه 23 مهٔ 2019، ساعت 13:04:14 (UTC+4:30)، Andrea Marchesini نوشته:

[maksga...@gmail.com‏]

четверг, 23 мая 2019 г., 11:34:14 UTC+3 пользователь Andrea Marchesini написал:

[jeuxsum...@gmail.com‏]

are you guys here to help me my girl friend is using my indentity and have acces to all my thinks i am not good at this

[tmebe...@yahoo.com‏]

On Thursday, May 23, 2019 at 4:34:14 AM UTC-4, Andrea Marchesini wrote:

[llil...@gmail.com‏]

recheckd and is fine tru

[jalal...@ictongiorgi.edu.it‏]

[jalal...@ictongiorgi.edu.it‏]

[jalal...@ictongiorgi.edu.it‏]

[sugyann...@gmail.com‏]

> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
>
> Summary:
> "1. Treat the lack of an explicit "SameSite" attribute as
> "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will
> produce a cookie equivalent to "key=value; SameSite=Lax".
> Cookies that require cross-site delivery can explicitly opt-into
> such behavior by asserting "SameSite=None" when creating a
> cookie.
> 2. Require the "Secure" attribute to be set for any cookie which
> asserts "SameSite=None" (similar conceptually to the behavior for
> the "__Secure-" prefix). That is, the "Set-Cookie" value
> "key=value; SameSite=None; Secure" will be accepted, while
> "key=value; SameSite=None" will be rejected."
>

> Bug: https://google.co.in/show_bug.cgi?id=1551798

>
> Platform coverage: all
>
> Estimated or target release: 69 - behind pref
>
> Preferences behind which this will be implemented:
> - network.cookie.sameSite.laxByDefault
> - network.cookie.sameSite.noneRequiresSecure (this requires the previous
> one to be set to true)
>
> Is this feature enabled by default in sandboxed iframes? yes.
>
> Do other browser engines implement this?
> - Chrome is implementing/experimenting this feature:
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
> - Safari: no signal yet.
>
> web-platform-tests: There is a pull-request
> https://github.com/web-platform-tests/wpt/pull/16957
> Implementing this feature, I added a mochitest to inspect cookies via
> CookieManager.
>
> Is this feature restricted to secure contexts? no

implement the post reply option

[rabixw...@gmail.com‏]

El jueves, 23 de mayo de 2019, 2:34:14 (UTC-6), Andrea Marchesini escribió:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
>
> Summary:
> "1. Treat the lack of an explicit "SameSite" attribute as
> "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will
> produce a cookie equivalent to "key=value; SameSite=Lax".
> Cookies that require cross-site delivery can explicitly opt-into
> such behavior by asserting "SameSite=None" when creating a
> cookie.
> 2. Require the "Secure" attribute to be set for any cookie which
> asserts "SameSite=None" (similar conceptually to the behavior for
> the "__Secure-" prefix). That is, the "Set-Cookie" value
> "key=value; SameSite=None; Secure" will be accepted, while
> "key=value; SameSite=None" will be rejected."
>

> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798

[nileshson...@gmail.com‏]

[Mike Conca‏]

Starting with Beta 79 today, we are rolling out this change to the default behavior of SameSite cookies to a small percentage of the beta population. The initial target is 10%, slowly increasing to 50% by the end of the beta cycle. We will hold at 50% for at least two more beta cycles, at which point we will consider introducing this to a small percentage of the Firefox release population.

Known site breakage is being tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1618610

Web developers can find more information here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#Fixing_common_warnings

A good overview of this issue can be found here: https://web.dev/samesite-cookies-explained/

Mike Conca
Group Product Manager, Firefox Web Technologies

[CJ Baumer‏]

To clarify, Firefox intends to roll out both SameSite=Lax as default and require Secure for SameSite=None at the same time correct?

[Mike Conca‏]

On Tuesday, July 21, 2020 at 4:44:02 PM UTC-6, CJ Baumer wrote:
> To clarify, Firefox intends to roll out both SameSite=Lax as default and require Secure for SameSite=None at the same time correct?

Yes, these changes are both rolling out simultaneously.

[mdr2...@gmail.com‏]

On Thursday, May 23, 2019 at 1:34:14 AM UTC-7, Andrea Marchesini wrote:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
>
> Summary:
> "1. Treat the lack of an explicit "SameSite" attribute as
> "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will
> produce a cookie equivalent to "key=value; SameSite=Lax".
> Cookies that require cross-site delivery can explicitly opt-into
> such behavior by asserting "SameSite=None" when creating a
> cookie.
> 2. Require the "Secure" attribute to be set for any cookie which
> asserts "SameSite=None" (similar conceptually to the behavior for
> the "__Secure-" prefix). That is, the "Set-Cookie" value
> "key=value; SameSite=None; Secure" will be accepted, while
> "key=value; SameSite=None" will be rejected."
>

[gf00...@gmail.com‏]

[theil...@gmail.com‏]

בתאריך יום חמישי, 23 במאי 2019 בשעה 11:34:14 UTC+3, מאת Andrea Marchesini:

[lescanom...@gmail.com‏]

El jueves, 23 de mayo de 2019, 5:34:14 (UTC-3), Andrea Marchesini escribió:

[Karla Saenz‏]

[Michael Reeps‏]

On Wednesday, July 1, 2020 at 11:07:36 AM UTC-4, mco...@mozilla.com wrote:

Mike,

I am seeing this warning now, even when I am in a first party context:

Cookie "xxx” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. The cookies in question are set in the .cfainstitute.org domain and being read only in that same domain. Am I to infer they are going to be rejected anyway, simply because they lack the "secure" attribute?

[Daniel Veditz‏]

On Mon, Sep 14, 2020 at 10:00 AM Michael Reeps <mre...@gmail.com> wrote:

> I am seeing this warning now, even when I am in a first party context:
>
> Cookie "xxx” will be soon rejected because it has the “SameSite” attribute
> set to “None” or an invalid value, without the “secure” attribute. The
> cookies in question are set in the .cfainstitute.org domain and being
> read only in that same domain. Am I to infer they are going to be rejected
> anyway, simply because they lack the "secure" attribute?
>

That is what the proposed spec change requires, yes.
https://tools.ietf.org/html/draft-west-cookie-incrementalism-01#section-3.2

-Dan Veditz

[Daniel Veditz‏]

On Tue, Sep 15, 2020 at 10:13 AM Michael Reeps <mre...@gmail.com> wrote:

> Thank you for the prompt response to my email. I guess I interpreted the
> standard to mean only when the cookie was intended for cross-site delivery,
> which these are not:
>

If the bug carries the SameSite=None attribute how could the browser
possibly know the cookie is only used samesite? In fact it would appear the
cookie has gone out of its way to announce it is NOT only used on the same
site. The "reject" language in the spec seems pretty clear cut.

> I see this message with nearly all of my Adobe Analytics cookies, Google
> Analytics, and a number of others, and am going to be reliant on those
> vendors to address this issue. The folks at Adobe Client Care were
> completely unaware of Mozilla's interpretation when I reported it, which
> differs from Chrome's. Can you give any insight as to when "soon" is in
> "will be soon rejected"?
>

That we differ from Chrome is concerning. The main reason we're following
the spec so carefully is in order to be compatible with the web's 800lb
gorilla. As it happens I'll be in a meeting with the spec author later
today; I'll ask him about Chrome's implementation of that part, and whether
the spec needs an update.

I don't know how soon -- better question for Andrea (original poster) who
implemented this. I suspect it's "when Chrome does it first". We like the
security improvement, but there are already enough "works in Chrome" sites
through no fault of our own. We can't afford adding to that number
unnecessarily through a self-inflicted wound.

[Aung Aung‏]

On Thursday, May 23, 2019 at 3:04:14 PM UTC+6:30, Andrea Marchesini wrote:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
>
> Summary:
> "1. Treat the lack of an explicit "SameSite" attribute as
> "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will
> produce a cookie equivalent to "key=value; SameSite=Lax".
> Cookies that require cross-site delivery can explicitly opt-into
> such behavior by asserting "SameSite=None" when creating a
> cookie.
> 2. Require the "Secure" attribute to be set for any cookie which
> asserts "SameSite=None" (similar conceptually to the behavior for
> the "__Secure-" prefix). That is, the "Set-Cookie" value
> "key=value; SameSite=None; Secure" will be accepted, while
> "key=value; SameSite=None" will be rejected."
>

[Elle Biala‏]

On Wednesday, April 8, 2020 at 11:10:46 AM UTC+8, bb08...@gmail.com wrote:
> Add me. Hhhh

[Marko Makinen‏]

уторак, 3. децембар 2019. у 21:10:21 UTC+1, raqu...@gmail.com је написао/ла:

> sou curiosa, estou busca de trabalho na área tecnologia, alguém pode me indicar, curso de web! boa tarde