This happens to me several times a month. I'm more concerned about account termination, in that if their Gmail account is terminated for some reason, mine would be as well due to it being the backup email address.
I'd edit my other reply to this comment but can't anymore.
Here are the columns from the CSV file I've seen being shared around on forums, including the "internal metadata". This mostly boils down to full name on file, email, Stripe customer ID, activity metrics, usernames, and phone numbers. Everything else is largely irrelevant.
I've seen the leaked data posted on forums. I'm assuming they're trying to minimize the bad PR from this incident by only doing what's legally required, which is to notify affected users. They're likely not obligated to notify the broader public. Whether they should be obligated to do so is another discussion entirely.
I'm fairly sure even mentioning the name of the forum isn't allowed on HN. It should be trivial to find it yourself, though. I also replied to someone else with the CSV headers if you're only trying to find out what exactly was included in the leak: https://news.ycombinator.com/item?id=46932380
Also, keep in mind that this is a partial leak. The data was scraped from some leaky endpoint which was patched out before every user could be scraped. Only users who were in the partial leak received emails (I have two accounts, only one received an email). If you're a Substack user but didn't receive an email, I'd assume you're not in the leak. Troy Hunt should load it into HIBP eventually, and those concerned can check there if they don't want to seek the leak out on their own.
This is actually a great analogy for why companies should take small data leaks seriously. A leak is a leak.
Also, to clarify, I don't mean to appear as though I'm discrediting this leak or downplaying its severity. I only mentioned that it was a partial leak to offer an explanation as to why some users received emails and others didn't, as witnessme's comment seemed confused about this.
This is what I've been saying for years. I really could care less if my passwords were leaked. My phone number, on the other hand, is near-impossible to change. The fact that VoIP/virtual numbers are blacklisted from use almost everywhere doesn't help anything, because otherwise I would just use a ton of cheap rented numbers.
The same goes for full names on file, physical addresses, and other hard-to-change information. Passwords have been the least of my concerns since password managers were invented.
You could, in theory, use a custom domain or email aliasing service like SimpleLogin or Addy to combat the email address issue, though websites like GitHub have been known to block emails created with an aliasing service. I could go on about why that move does next to nothing to combat actual abuse; any spammer worth their salt can just buy a bunch of Gmail accounts or Outlook accounts instead.
The post where the data is available for download states that "the scraping method used was noisy and patched fast", leading one to believe that Substack was aware of the breach early on, yet they never alerted a single user until the data was posted publicly. It's so disheartening that companies won't admit breaches until the evidence becomes too loud to ignore.
I definitely used it from Finland last year. It was blocked some time in th past since the owner was mad at Finnish authorities, but at some point that was revoked.
Even the post you linked acknowledges this:
>he blocked the entire site in Finland, although later he lifted the block
My apologies, I clearly missed that. If I could edit my post, I'd change it to "It seems that the website has been blocked in Finland in the past, though the block was later lifted."
This likely means nothing, but the .is webmaster seems to have some sort of existing issue with Finland (where gyrovague is from), see https://news.ycombinator.com/item?id=37011955. I thought I would point it out.
Also, as someone interested in OPSEC and OSINT as a hobby, I find the measures taken by the .is webmaster, especially the dedication to setting up countless fake accounts for each persona, to be very intriguing. I spent about an hour looking into the Nora Puchreiner persona and all the accounts registered to it that I could find. It appears that "Tomas Poder" is another alter-ego used by the .is administrator. Nora also seems to have a sister: "Sara Puchreiner". Again, all very interesting and I can't seem to make a clear picture of the situation.
There are multiple reports of these archive.something sites redirecting users to Russian sites. Personally, I stopped using them after I saw one connection attempt to yandex dot ru
> I find the measures taken by the .is webmaster, especially the dedication to setting up countless fake accounts for each persona, to be very intriguing.
This seems like a smart thing to do if you had exposed your real name somewhere and wanted to cover it up.
They should probably review existing case around how Finnish courts treat the journalistic exception in the context of citizen's journalism (as he relied on that at least as one of the reasons): https://tuomioistuimet.fi/hovioikeudet/ita-suomenhovioikeus/...
Of course facts are different, but at least two Finnish court seem to require a lot more reasoning from the controller in the context of citizen journalism compared to traditional media when they want to invoke the journalistic exception. No clue which side this would fall into.
There are several other posts made recently on the archive.is blog as well, some of which appear to be quite nonsensical or are otherwise irrelevant to the discourse at hand. They all appear to be LLM-generated. It's all very confusing.
They still seem to use past email addresses for marketing communications, despite the email address on file having been changed months ago. They definitely still keep old data around and fail to sync data between vendors. Whether that's indicative of their data deletion policies remains to be seen, but to me the lack of care for using past data for active accounts doesn't paint them in a very good light.
