Google Chrome warning about Cloudflare cookie

@sandro Who are you? My message was telling @Matteo that nobody needs his condescending judgment after he said to me “I don’t feel the need for being so overly dramatic over something that is in the not near future.”. Everyone in this thread realizes that this is a very real technical issue that Cloudflare support even confirmed to me privately they are working on solving.

You are the one who is rude, by defending your buddies instead of honoring legitimate and paying customers.

Or not – keep doing what you’re doing! I have contacted Cloudflare about you with screenshots before you delete this and other’s messages again.

1 Like

Contact whomever you want :roll_eyes:

I did not even address your issue and I dont really care either to be honest. What I do care about though is a civilised and respectful tone here on the community and you clearly failed in this context. Let alone your posting buddy.

I did not delete a single of your messages, but as you seem to refer to the unrelated and trolling messages I moved to a separate thread (not even those were deleted), you seem to want to associate with that person and his behaviour. I am not sure what kind of light that is supposed to cast on you though.

Thanks @user8963. Fanboys galore indeed! Not to worry though: if this issue isn’t solved in a week, we and MANY OTHERS are leaving Cloudflare (just at the time of their IPO) – it ain’t the only shop in town.

1 Like

(post withdrawn by author, will be automatically deleted in 1 hour unless flagged)

1 Like

@david33 two weeks ago after my reply to you, I addressed this with the Cloudflare staff that can handle this topic. I was told that Cloudflare is addressing it.

It feels like a simple solution, but I believe it needs to go through security scrutiny and engineering implementation.

5 Likes

Is this issue indeed being worked on internally, @cloonan? ETA?

Engineering-wise, there is a little bit of non-trivial code to write to support incompatible browsers, so I can empathize with Cloudflare taking some time to get it right.

However, this is now affecting users of the beta version of the most popular web browser. Developers are especially impacted, and our company is seeing it firsthand with hundreds of developers that use our mission-critical Cloudflare Workers endpoints.

3 Likes

Yes, it is.

5 Likes

Is this being prioritized? Getting these warnings on a very basic website.

Are there any updates on a timeframe for a resolution?

We’ve said multiple times how critical this issue is. In early 2020 when Google flips the switch on Chrome, it can blow up millions of websites (e.g. Intercom’s customers’ websites).

Cloudflare support initially said they will fix it by early December, and now they just said “we don’t have an ETA”.

This is how Cloudflare treats their paying customers.

No longer.

We just closed our paid plans.

We are moving elsewhere, probably AWS.

1 Like

@cloonan can you please provide insight into why this isn’t resolved yet?

50% of Chrome beta users are experiencing broken pages/resources/applications due to rejected Cloudflare cookies. We’re longtime customers of Cloudflare’s Business plan, and this is especially impacting our third party developers and bottom lines. The lack of appropriate action and transparency on this major issue isn’t the Cloudflare I know.

1 Like

I’ve asked for an update from the team and will share it as soon as received.

4 Likes

I just downloaded Chrome Beta (Version 79.0.3945.79) to test it out, and I still get the same warning (but no error) from it:

A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.

The same with Chrome Canary (Version 81.0.3997.0)

Regarding adding the attribute SameSite to the cfduid cookie, this is now added to the __cfduid cookie and will be present on all Dynamic resources.

For any cached resource which is using this cookie, you will need to Purge the cache.

5 Likes

A cookie associated with a cross-site resource at https://cloudflareinsights.com/ was set without the `SameSite` attribute. Next is the browser insights domain :wink:

2 Likes

How about SameSite=Lax? Will that work? Or do you need None? Personally I prefix mine with __Secure- & use SameSite=Strict. But that’s me… and I COULDN’T BE HAPPIER THAT CLOUDFLARE HAS BEGUN USING =Lax as it’s far better then no restrictions at all.

I’m not much into cookies and the underlying tech of cms/wordpress/framework/whatever.

It came to my attention recently, working with Elementor plugin on my Wordpress CMS, that it might be using CloudFlare as a security service somehow, as i have not been installing any plugin from CloudFlare myself (At least not to my knowledge ;-). Nevermind, this is not the main reason for this reachout attempt!

It’s just meant as a heads up! And the concerned staff is probably already aware!

In any case Mozilla Chrome is reporting this warning on my site: (Image extraction attached)

Mozilla Chrome Cross-site coockie warning

You might want to implement this setting, if it at all matters!? Sorry ahead! I didn’t have time to check if this has already been submitted and are unaware of the propper forum channel to submit this info, as i am not qualified (As Bruce would say :wink:

With the hope this could in any way serve as a helpful resource for the duly concerned…

Merry Christmas and a Happy NYE!

1 Like

Hi,

__cflb (load balance) is steel without SameSite attribute.

And my site works inside a iframe on a different domain. __cflb and __cfduid cookies on my domain are treated as third party cookie by browser now (Chrome Beta v80). So the browser send requests without these cookies. I need these cookies would be set: “SameSite=None; secure”. My site works only in https.

Is there a way to force this?

If no, a configuration to do this would be appreciate. And we have few days to do it.

Thanks,

Marco.

Hi,

My application cookies are OK to Chrome changes (v80). To re-force my needs about it, I did these changes on WebConfig (IIS). Only to remember: My web application runs inside an iFrame on a different domain.


<system.web>

 <sessionState cookieSameSite="None"/>


</system.web>

<system.webServer>

 <rewrite>
   <outboundRules>
     <clear/>
     <rule name="Add SameSite">
       <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" />
       <conditions>
         <add input="{R:0}" pattern="." />
         <add input="{R:0}" pattern="; SameSite=None" negate="true" />
       </conditions>
       <action type="Rewrite" value="{R:0}; SameSite=None" />
     </rule>
     <rule name="Add secure">
       <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" />
       <conditions>
         <add input="{R:0}" pattern="." />
         <add input="{R:0}" pattern="; secure" negate="true" />
       </conditions>
       <action type="Rewrite" value="{R:0}; secure" />
     </rule>
   </outboundRules>
 </rewrite>


</system.webServer>

Only Cloudflare cookies are blocked now. On each response, Cloudflare try to set the cookies but Chrome doesn’t accept it.

Let me know if change SameSite and secure on cookies will be possible on future (when). If not, I have to find an alternative to use load ballance with session affinity and the analytics (ex: unique visitors will be very wrong).

Thanks,

Marco.

I’m still seeing the deprecation warning about __cfduid cookie

But in the following thread @cloonan wrote that issue should be resolved:

I’ve purged the cache for Everyhing several times during last week.
But the warning still present.

In Developer Tools I’ve found that __cfduid cookie has “SameSite=Lax” attribute.
https://www.chromestatus.com/feature/5088147346030592

Which means there were no SameSite attribute specified for __cfduid cookie by CloudFlare.

It is okay to me is it takes time from CloudFlare to resolve the issue.
But I don’t understand why it was said that issue is resolved when it actually is not resolved.

1 Like