While I'm glad we no longer get penalized for Cloudflare's issues, I feel that there should be a clear notice about this exemption in the test scores section (perhaps in the cookies information panel that is activated when you hover over the info icon) letting the user know about this.

I'm hoping to build in a suggestions section in the next quarter or two; I think that would be a great place for it. :)

The comment in #201 says this cookie is bad but it gets an exemption because there is not much to do. It is a odd reasoning. If a small CDN or a hosting provider put such a cookie, would it get an exemption? How would CloudFlare be incited to fix this problem if they can just do nothing and get an exemption?

In other words, CloudFlare seems to get this exemption because they are big. Indirectly, this makes Mozilla promote a centralized web.

The reason why it's here is that a) CloudFlare knows about it, b) it's super confusing, as most site owners don't know it even exists, and c) there's nothing they can do about it, short of using somebody besides CloudFlare.

In the meantime, this bug stands as a statement about their bad practices vis-a-vis tracking cookies.

@april in #121 you said

I have been talking about this with CloudFlare and trying to find ways to improve it.

That was nearly two years ago. Did the discussions go anywhere?

@floatingatoll The fact that the header is called Referer and not Referrer is a strawman argument and has nothing to do with tracking cookies. The header can have any name, as long as we all agree on it. Tracking cookies track the users and thus are a threat to the user's privacy. Whether that is a security issue depends on your threat model, but I think this should be up to the users to decide.

Anyway, since Cloudflare doesn't seem to have acted on this in the past two years, I propose announcing that the exemption will be removed in, say, six months. If they fix it until then, good for them, and if they don't, though luck. Currently there are zero incentives for them to tackle this.
And, while the affected websites are the ones who suffer from this issue but not really the ones to blame, I guess the only advice I can give them is to switch providers to someone who does respect their users' privacy.

I understand the reasoning of Cloudflare.

However, I think they could have easily done a better job. They could have served two different cookies, depending the HTTP or HTTPS-ness.

That would mean that if you have HTST, in practice the HTTP cookie will never be used, and the HTTPS cookie can have the Secure flag turned on.

If you agree, maybe you can convince them that this is a good idea, and it allows you to remove the exemption. All cookies served over HTTPS will have the Secure flag set.

You shouldn't've had an exemption in the first place.

Do they still do this? I checked some pages that run behind Cloudflare and couldn't spot a cookie that wasn't marked as secure. Therefore, this exception is might no longer needed? Despite that, even the busiest developer might could have taken a lot at such a feature within 4 years.

I think we can call out Cloudflare these days, if they still resort to insecure cookies. Especially as it seems like it can be fixed by configuration of Cloudflare, if it really still appears.

Cloudflare's documentation explains the circumstances when they do and do not use the Secure flag, including the specific circumstances where a non-secure cookie is necessary for them to deliver traffic. "__cfduid and Always Use HTTPS" at https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies

The _cfduid cookie collects and anonymizes End User IP addresses using a one-way hash of certain values so they cannot be personally identified.

Depending on your Always Use HTTPs configuration, the _cfduid cookie will be created either as secure or non-secure.

If your domain uses the Cloudflare Managed CNAME service, __cfduid cookies will always be non-secure even when Always use HTTPS is enabled. Cloudflare guarantees always using HTTPS if your DNS resolution is fully managed within Cloudflare. As such under a Managed CNAME situation, it is necessary for __cfduid cookies to be non-secure so that your users can be identified over either HTTP or HTTPS access.

So when I got this right the main reason to keep this is the "Cloudflare Managed CNAME service" as this is something where "you" as the person running a website, can't necessarily do something, because you have no access to the dashboard, correct?

But "Cloudflare Managed CNAME service" is only available to "enterprise" customers. Therefore, their documentation clause about removing the __cfduid will kick in and your provider is able to let them remove the cookie.

So either way, calling the cookie out, seems actionable for "You" as observatory user.

When I got the initial reason for adding this exception correct, it was to avoid "known red corners" that are not actionable. But at least nowadays this seems to be no longer the case. Either way you can make sure that these things are set properly by using the "Always use HTTPS" option and or requesting your provider to figure things out with Cloudflare, which they explicitly offer.

That said, is there any other reason why this exception would be still needed?

Would removing this cookie materially improve the health and safety of the web, to such a degree that it's critical to have people work to remove it with the same level of priority as working to secure their own application's cookies?

I can't construct a scenario where removing the __cfduid cookie has a material impact on the health and security of the web at this time, relative to the remaining unsecured application cookies which absolutely do need to be addressed.

If removing this cookie wouldn't help the web, then why should the Observatory alarm about it? And, if people work really hard on securing all the important and relevant cookies, and then still fail this check solely due to a __cfduid cookie that does not materially impact security, wouldn't it be incredibly demotivating to have done all that work?

If you can construct an argument that the cookie is materially harming web security, that would certainly be persuasive (and potentially qualify for a Cloudflare bounty payout, assuming you follow whatever their bounty program rules re: disclosure are).

I'm not the author of the Observatory, so this is only my opinion, but I hope it helps you consider a line of reasoning that could result in this exclusion remaining in place.

Cloudflare is deprecating the __cfduid cookie. Starting on 10 May 2021, we will stop adding a “Set-Cookie” header on all HTTP responses. The last __cfduid cookies will expire 30 days after that.
— https://blog.cloudflare.com/deprecating-cfduid-cookie/

Hey folks, this cookie has been removed so here's a PR to remove the exception: #444.