On one hand, there's like a 1% chance the data was actually fully deleted. OTOH, $370,000 is literally nothing to AT&T, so paying "nothing" for a 1% chance of maybe the data getting deleted seems like a decent wager for AT&T to make?
Sonehow, I wonder if this might be more ass-covering than anytbing else. Perhaps to report to the regulator that they've done all they can. Or maybe, if they ever track down the people responsible fot the hack, you can imagine AT&T suing for breach of contract!
Maybe consider using https://quad9.net for DNS? It's nice having archive.today work. Otherwise you can always copy/paste the link to TFA into https://archive.org
The DNS is not the problem... the site itself gives me a "you are blocked" page directly from CF. I don't get a different result from using different DNS either way.
archive.today doesn't use CloudFlare in the first place. I think ranger_danger meant to say that they use Cloudflare's DNS resolver (1.1.1.1) which doesn't work with archive.today. (archive.today wants location information that the client normally sends in its DNS request to be able to route the client to an appropriate server, but CloudFlare's resolver sends its own location with less granularity which breaks that.)
> Please complete the security check to access archive.ph
It's not a DNS issue (and I don't use theirs), the site itself uses CF and I get endless captcha loops. Sometimes the site will just say "you are blocked" instead too, or even "Your browser is out of date" when it's not.
archive.today (and its sister sites like .ph) don't use CloudFlare, but given the problems they have with it, they might do something like resolve to a CloudFlare-backed sinkhole if they think you're coming from CloudFlare's resolver. Would be funny if true.
I think one could argue that your supposed sinkhole is still "using CF". I still don't agree with your response "that's what I said", and I think you don't really know what they're using anyways so this is a pointless argument IMO.
Either way that's no excuse for the attitude. Please try to think about how your words come across to others and whether you would want to be treated the same way, especially when it is something trivial like a disagreement on terminology.
> AT&T is one of more than 150 companies that are believed to have had data stolen from poorly secured Snowflake accounts
Is there a list of the other affected companies somewhere?
One news site says there are 165 organizations affected[1], and links to some documents by Mandiant[2][3], but I can only find snippets that lists a few companies.
28 comments
[ 3.1 ms ] story [ 76.4 ms ] thread"Secure Data Fee - $4.51"
Not affiliated with cloudflare at all, just curious - where is "here" and why is a major edge cloud provider blocked?
> Please complete the security check to access archive.ph
It's not a DNS issue (and I don't use theirs), the site itself uses CF and I get endless captcha loops. Sometimes the site will just say "you are blocked" instead too, or even "Your browser is out of date" when it's not.
https://community.cloudflare.com/t/one-more-step-please-comp...
>The message I'm getting though ("Please complete the security check to access archive.ph") is from CF
That is what I said.
>and I do not use their DNS or anyone who does.
That is not what I said.
> That is what I said
No, you said:
> archive.today (and its sister sites like .ph) don't use CloudFlare,
Either way that's no excuse for the attitude. Please try to think about how your words come across to others and whether you would want to be treated the same way, especially when it is something trivial like a disagreement on terminology.
...
Is there a list of the other affected companies somewhere?
One news site says there are 165 organizations affected[1], and links to some documents by Mandiant[2][3], but I can only find snippets that lists a few companies.
[1] https://www.securityweek.com/snowflake-attacks-mandiant-link...
[2] https://cloud.google.com/blog/topics/threat-intelligence/unc...
[3] https://services.google.com/fh/files/misc/snowflake-threat-h...