parable

To the best of my understanding, ZDR is often a promise that your data is not used for model training. It doesn't mean "what it says on the tin", so to speak. There are cases where data needs to be retained regardless, for example, preventing abuse. This isn't for training, so a company can still claim ZDR.

I did some research and corroborated with Claude. No banks in my country offer anything akin to Privacy.com. There are a few "virtual card" services but they have limits that make them virtually unusable.

I doubt I'll have any influence on the products any one bank in my country offers, but it doesn't hurt to ask.

My bank is the opposite of yours. They used to offer a similar service but shuttered it a few years ago. A shame.

As someone who has helped to secure critical national infrastructure several years ago, I can say that it was a mess to disclose the vulnerabilities I identified, and in some cases it took years to patch them. Some of these vulnerabilities were RCEs and mass PII leaks. It's simply not worth the risk for most people - who aren't in the USA - to bother doing this sort of security research. However, if you are in the USA, there are provisions in the CFAA that enable good-faith security research to take place (https://www.justice.gov/archives/opa/pr/department-justice-a...), so to the best of my understanding, you're able to do good-faith research without being charged or prosecuted, and you should take advantage of this if you have the skills or models to do so. I am not based in the USA, and there are no laws in my country that guarantee me zero jail time for simply trying to do the right thing, so I am not incentivized to continue finding vulnerabilities in my country's infrastructure.

Edit: If other countries don't catch up and include similar provisions in their laws, they'll simply fall behind and put their citizens at risk. I'm sure every country has individuals willing to help that currently feel unsafe - look at the large amount of bug bounty hunters worldwide who, I'm sure, wouldn't mind practicing their skills by securing their country's infrastructure.

This is good advice for anyone who lives in the USA, but there are hardly any adequate alternatives for the rest of the world, as far as I know.

Credit for the video should go to the link referenced in https://news.ycombinator.com/item?id=50199757 (catgirl.cloud). The Twitter user reposted the video and did not credit the OP as far as I know.

Please forgive my stupidity, but is there any particular reason why companies never seem to disclose what "system" of theirs was breached? If this breach came about as a result of a security incident at a third-party, would it not benefit everyone minus the vendor to shift the blame? I understand that they say "our systems", but I've seen companies say this before when what they mean is "a system controlled by a vendor we contracted".

Hi. I was briefly following the developments regarding legal representation and thought everything was going well. Is there anything more you could disclose as to how you were misled or what happened here? Thank you again for creating and maintaining Nitter, it's such a valuable tool and I've donated a few times over the years.

Not an ad or promotion, I'm just also addicted to buying cool domains and I remember seeing this up for sale: DomainEmpire.com is currently trying to sell sesqui.net, registered in 1987, for $33,000. I think they have others that are cheaper, but you'll have to scrape WHOIS data for each domain to find their creation dates.

I don't really care if anything else gets blocked as a side effect, except for Find My. As far as I know, `fmfd` and `findmydeviced` are the binaries responsible for that feature, so if I whitelist those binaries I should be fine.

Through my own usage of Little Snitch, it appears that all the iCloud-related features use individual binaries and that iCloud connections go to specific hosts for specific use cases (e.g. pxxx-contacts.icloud.com, pxxx-quota.icloud.com, pxxx-caldav.icloud.com). I'd assume the AI features are the same - specific hosts and binaries that I can block.

Is it possible to block Apple Intelligence from sending data over the Internet via Little Snitch? I would assume it is, but I'm not sure if anything significant has changed in macOS 27 that makes this impossible now. I don't really mind the local features - I'd rather they stay disabled, but it's not the end of the world - but I really don't want any data leaving my Mac.

This would be nice, and I hope I get to see a future like this, but I moreso meant that I don't see a solution for this issue given the current landscape of things. Ideally, yes, companies wouldn't collect the data and it would be illegal to do so. However, this currently isn't the case, so what can be done that lets all sides win? Something has to give, and I'm certain users will receive the short end of the stick at all times - at least, until there are better laws in place.

Metabase can be self-hosted, but you cannot self-host Salesforce or Mixpanel or many of the other products I'm referring to. In an ideal world, every company would self-host their own instances of all of their products, since that ultimately forces them to be solely responsible for their customers' data. Using the cloud versions of these products shifts the blame from the company itself to the vendor when things go sideways, so it makes more sense for them to do this instead of taking responsibility.

While I'm impressed with Framework's handling of this issue, I can't help but notice how this was yet another analytics platform breach. CRM tools and analytics platforms (Salesforce, Mixpanel, now Metabase - I'm sure I'm forgetting some) are common vectors to get access to customer metadata these days.

I don't see a solution to this in the near future. I initially thought up something quite simple: assign every customer a unique ID and use that where possible to reference a customer. That solution, however, renders the analytics and CRM tools nearly useless. There has to be a better way, though, other than haphazardly giving out customer metadata to other vendors. All of that information should stay in-house.

As for why metadata is important: I've said this before, but metadata can't easily be changed. I'd much prefer having my password or credit card number leaked in plaintext since I can change those identifiers trivially. I can't change my name, phone number, or address as easily.

I've had a similar thought in the past. I was thinking about the feasibility of a law being introduced where each company making over a certain amount of money per year must begin a VDP (and optionally a BBP) so that security flaws can be reported to them easily. This can easily be done by simply opening up security@companydomain and using security.txt (https://securitytxt.org). Reports must receive a response in N days, where N is calculated based on available staff, resource allocation, and revenue of the company. If they don't receive a response after N days, this can be escalated to some government agency which can take action against the company for failing to respond to a report on time.

Companies can and do get away with arguing that they have a "lawful basis" to collect whatever data they'd like. It's unfortunate.

IANAL, but the law seems a bit vague to me, and it appears that companies use that vagueness to their advantage. Maybe I'm just not articulating my arguments correctly.

> Otherwise, just assume everything you do online is public and act accordingly.

This is such a depressing reality. It's also what governments want you to believe. If you aren't able to speak your mind about anything anonymously, then you won't be able to, say, spread ideas that go against them.

Admitting defeat at all and not even trying to teach people about privacy results in the "I don't care, what's the point?" attitude that plagues many people today.

I use Snusbase (https://snusbase.com). They've been around since around 2016 and haven't had any issues legally - they're the longest-standing data breach search engine besides HIBP, as far as I know.

(This is not an advertisement.)

Hashes can be cracked, and end users won't understand how to create password hashes to check which one was leaked. Plus, salts exist.

Passwords shouldn't matter anyways. Use a password manager and be done with it. The real issue is metadata which can't easily be changed - phone numbers, addresses, and the like. If any of that data is leaked, it becomes much harder to contain impact. You can't move addresses every time your address gets leaked online.

I wish that were the case, but because of there being barely any consequences for breaches, it's much more profitable to store everything you can and sell it to the highest bidder. Make it a huge risk to store data, then companies will start treating data like a live hand grenade.

I'd also add a third issue to this list: data retention. Too many companies I've dealt with have privacy policies that state something to the tune of "we'll hold onto your data for as long as required" without giving much of an explanation as to how long "as required" is.

I find it very hard to trust any email service that claims to be E2EE without an audit by a reputable firm like Cure53 or Trail of Bits.

I signed up to give it a brief test and immediately noticed that emails are returned from the server in plain text. This means that the emails are decrypted on the server, which defeats the entire purpose of E2EE. The encrypted email contents and metadata should be returned to the user and decrypted on the client.

It's also painfully obvious that the entire thing is vibe-coded. While that in itself isn't an issue, it raises scrutiny. If the author doesn't have a full understanding of the code their LLM generates, some nasty bugs could be lurking.

Not very promising.

I'm not sure how I haven't heard of this yet. There have been too many times I've wished I could convert a command-line script to a native application easily for me not to try this.

Kudos for the public disclosure. Too many people haven't been happy with MSRC and it's starting to boil over (see the Nightmare Eclipse situation, too). Maybe all of these disclosures will cause them to do some introspection and realize they're the problem. I highly doubt that, but one can dream.

It seems pretty trivial to just add a check in the agent's tool call to determine if the email is actually the one on file (or one that has previously been on file). I'm not sure why it's taking them so long to remediate.

The bug still exists - two of my friends have lost access to their accounts as of an hour ago. They've partially recovered but are unable to change their passwords, so their accounts are still technically in the hands of the attacker(s).

It appears the exploit hasn't been patched: https://x.com/vxunderground/status/2061636614267273332

I've heard the new "method" has to do with setting your location to Singapore or something, but I have yet to confirm anything.

The original 2FA did not get thoroughly bypassed, because otherwise I would've lost my username, so that's false - at least, based on my experience.

However, there are separate vulnerabilities that allow for 2FA to be bypassed on Instagram. I assume they were chained to take over specific high-value accounts. The 2FA removal happens as a service - most people charge around $1,000+ - so it wasn't viable for most lower-value accounts. Anything that was worth over $1k probably had the bypass applied to it.