@wolf480pl I don't have a waveform on hand (but I would love to see it from the spanish side), but I assume the Iberian grid very quickly (sub seconds) disassembled itself after (I assume) whatever this supply fault was
(Bear with me on the long reply, trying to cover all bases here)
I don't think the "leaked credentials detention" product is a red flag per say, Maybe the automatic enablement of it is a can of worms, reason being is that people do not typically think that their web proxy is going to snoop their users credentials, even if it is not storing the full outputs of that snooping.
There is probably bigger set of discussions that should be made about the data source of these leaked credentials, given they are inevitably sourced actual data breaches of other people's stuff! Though this is basically the commercial exploitation of stolen user data, it is probably for the greater good to use such leaks (however dubiously obtained) to detect leaked credentials in the future, but idk!
The thing I really wanted to point out in the original post on my side was that it seems relatively unsettling for a company to be very confidently showing off data outputs that have been derived from non explicit consensual snooping of passwords. A lot of replies suggested they could be storing data, but they are almost certainly not storing the passwords themselves (because any breach of that would probably be a company ending event), but CF's demo of the metrics (given how they were obtained) shows a level of hubris which is perhaps a little alarming.
A lot of replies suggest this is a GDPR problem, I am not a legal guy but I don't think any of this is a GDPR problem, but there is a somewhat obvious question in 2025 (to someone in Europe that is) of an american company snooping the user submitted data of your requests that likely has other PII in it to provide a WAF/etc, but none of this is new to cloudflare.
Ultimately the websites impacted by default are the ones who don't pay cloudflare anything, there may be a lesser amount of care because of that, but there are probably limits to what kind of stuff people are willing to swallow. Password snooping without explicit consent seems (to me) to get very close to that line, but I am just 1 guy.
It's worth stepping back a bit and acknowledging that there is a reason that people use cloudflare. It's because the product is actually kind of good, it's solves a bunch of problems of people in a cheap and reasonable way. I don't think there's any foul play going on the widespread adoption of cloudflare, it's more that people will choose what is convenient, and cloudflare is mighty convenient. I wish for better alternatives like many others, but right now some of the alternatives are worse either technically or ethically.
@troyhunt@dangoodin sure, I use "snooping" very much on purpose, I'm also really aware of what a WAF is given I wrote a very high % of the whole Cloudflare WAF from 2014 to 2017 :P
There’s no explicit “consent” involved in people sending that data
I'm not talking about the consent of the users, my larger problem is cloudflare enabling features that handles arguably some of the most sensitive data on free customers without asking them, and then publishing metrics on it, It just has a bad vibe.
It’s also up to the site owner to enable leaked credential check
This is verifiably not true for free users.
Here is what I did to confirm that.
1) I take a domain that is on the free plan, that I have not touched the cloudflare settings for years, check the security tab, 0 "Password leaked" hits
2) Make a subdomain test.<domain> to point to a test instance
3) Write a "hello world" test web server that dumps headers
4) fire a mimic login that wordpress would use:
$ curl -X POST -d 'log=username&pwd=password&wp-submit=Log+In' https://test.xxxxx.com/wp-login.php
5) There is no header to confirm it was a compromised password, but if we reload the cloudflare dashboard, it detected the password.
This is the crux of my problem. I don't think it's ethical to have this kind of feature enabled by default with no consent. The product as a concept is fine, as long as people opt into it.
@dalias I feel that a bit of a stretch / bad faith reading of things. Web 'refer' headers have existed for a long time and while they have been curbed in scope (some contexts don't send it at all, some don't send the URL path), it feels a bit extreme to compare this to experimentation on human subjects when if anything the current default was out of the norm
@dalias There is nuance here though? _some_ (obviously not you I suppose?) fedi users would like there to be better integrations with publishers (for example, I would prefer that the BBC have their own bots rather than RSS re-publishers), but ️🌈️we live in a society🌈 where you do need to justify doing work, stats help that, and I don't really see a issue if I click a link on mastodon dot social, the BBC knowing that I came from anywhere on mastodon dot social, as @Edent said, there are nuances where you would not want something like that, but generic servers I don't really see the harm, and it does good for a ecosystem (aka, people typically like nice things, this is one of the ways you get nice things)
I just dont understand the threat model of letting the BBC know I came via mastodon.social
@jeff I have a CRS317-1G-16S+ in production for bgp.tools in the NL as a low power "port expander", it's fine, it's just tagging VLANs and it's been fine, I however have hit weird shit ™️ with 'tik's OSPF/BGP and a bunch of the other Layer 3 stuff.
Tik is likely fine if your entire estate is tik (a lot of WISPs fall into this class) but it can be dicey otherwise. But the less things you are doing the better it all tends to go
(edit: woops, I didnt mean to boost you, but it seems I cannot un-boost now, my apologies)