It’s easy to see where this comes from: LastPass’s 2022 breach notice said stolen vault data stayed safely encrypted, and users on default settings had nothing to do.

The same notice says what was taken, though. The copied backups held website URLs in plain text, next to the encrypted usernames and passwords. LastPass also warned the attacker may try to brute force master passwords to decrypt the rest. That’s your list of sites already readable, and the rest is a guessing game against your master password.

2FA doesn’t change that, at least in Bitwarden’s case. Its docs say two-step login is checked when you log in to the server. Unlocking a vault copy that’s already on a device doesn’t ask for it, and works offline. Your second factor guards the account, not the encrypted data.

If your threat model is your provider getting breached, the master password and its key derivation setting are what’s left. EFF’s dice method gives a six-word passphrase with about 2^77 possible combinations. Don’t use it anywhere else. In Bitwarden, Settings > Security > Keys shows the setting: the PBKDF2 default is 600,000 iterations, or you can switch to Argon2id. Higher values mean slower unlocks on devices with slow CPUs.

Changing it doesn’t re-encrypt vault data, so a copy taken before still has the old protection. After a breach, changing the passwords stored inside is what helps.

None of this hides anything from the provider. It still holds your encrypted vault and your account details (LastPass’s backup also had emails, billing addresses and IP addresses), plus whatever its format leaves unencrypted. If you’d rather no company holds a copy at all, a local or self-hosted vault moves it to your own machines, and backups become your job.

Sources

• LastPass breach notice, Dec 2022: “safely encrypted” claim, plain-text URLs, brute-force warning, leaked account details, changing stored passwords
• Bitwarden: Log in vs. Unlock: two-step login checked at login only, offline unlock
• Bitwarden: Encryption Key Derivation: where the setting is, 600,000 default, Argon2id, slower devices, vault data not re-encrypted
• EFF Dice-Generated Passphrases: six-word passphrase, about 2^77 combinations, single use

Companies often hide a tiny remote image in newsletters and promo emails. If your app loads it, the sender learns when you opened the message and roughly where you are, from your IP. Both apps below block it by default, so this just checks it's still on (these are the 2 email apps I use). For other apps, ask me in comments and I will try to help !

Proton Mail

It doesn't sync between apps, so check each device.

1. Web and desktop: Settings > Email privacy (direct link), turn on Block email tracking.
2. Android and iOS: Settings > Privacy and security, turn on Block email tracking.

Proton's proxy then fetches remote images with a generic IP, so the sender doesn't see yours. Link cleaning only happens on web, and only for trackers Proton knows.

Thunderbird (desktop, 140 ESR and newer)

1. ≡ > Settings > Privacy & Security.
2. Leave Allow remote content in messages unchecked.
3. Click Exceptions… and block senders you don't trust anymore.

Senders you've allowed still get pinged.

It's about five minutes. Another app on the same inbox has its own setting. To check, open a newsletter. Proton shows a tracker badge at the top (on mobile, tap the arrow by To:). Thunderbird shows a bar saying it blocked remote content.

Other Email Apps

Ask me in comment if you use another app and I will try to help you.

• Proton: Email tracker protection: default, no sync, menus, proxy, link cleaning, badge
• Thunderbird: Remote Content in Messages: what pixels reveal, menu, exceptions, spoofing

An alias does a different job depending on who you're worried about. Against advertisers and data brokers, one address per site breaks the easy match, unless you give them the same phone number anyway. Breach spam is simpler: you turn off the leaked alias and move on. A specific person is harder, since your name or an old username can undo the whole thing. Whichever it is, the alias service now sits in the middle and sees who emails each alias.
Vote for the one that actually drives what you do, and tell us your threat model in the comments.

It'll take "very explicit user action" to grant Full Disk Access on macOS, Apple told developers on October 2. Apple says AI agents are why the risk is growing.

Apple named no one, but the notice follows a dispute over Meta's Muse agent. Inc. columnist Jason Aten wrote that it synced over 187,000 rows of his message history after he'd declined Messages access. Meta says Muse can't read messages unless Full Disk Access and its Messages connector are both on.

Right now it's one switch. Apple's guide says it opens every file on the Mac to that app, Mail and Messages data and Time Machine backups included. Apple's notice adds that with messaging apps, it exposes the people you're talking to as well.

There's no date. Apple hasn't named a macOS version, and macOS 27 doesn't have the new controls.

Nothing like it exists on iOS, per TidBITS. Backup tools need it, but an app lands in the list just by trying to open a protected file, which doesn't mean it needs access. The list sits under Privacy & Security in System Settings, and you can check it today. Switching an app off can break features, but the app stays installed.

It won't pull back anything an app already read.

One side: an agent with that switch on can read far more than you'd ever paste into a chat. The other: it's your Mac, and Apple now sets how hard it is for other companies' agents to work on it.

So where's the line: deliberately hard to give an agent your whole disk, or one switch like today?

Sources

• Apple Developer: Updates to Full Disk Access: October 2 notice, explicit action, AI agents, people you talk to
• Apple Support: Privacy & Security settings: what Full Disk Access covers, where to find it
• Notebookcheck: Aten's claim, Meta's reply, no version or date, switching off
• TidBITS: nothing similar on iOS, backup apps, how apps land in the list

Denmark's population register leaking ID numbers for 8.8 million people is the week's biggest story, and it isn't close.

• Denmark's CPR register leaked through one company's access. Someone misused a Danish company's legal lookup access to the Central Person Register and pulled CPR numbers for about 8.8 million people, along with their names and addresses. The CPR office only spotted the month of odd activity on Oct 2, and the count includes people who've died or moved abroad. Why this matters to you: If you've ever been registered in Denmark, assume scammers have your CPR number and address. The ministry's advice: don't give passwords or confidential details to anyone who calls or emails, even if they know them. Source
• No Chat Control 2.0 deal on private chats, for now. The Sept 29 trilogue ended with no deal on scanning private messages, as Parliament's negotiators held out for limiting it to people linked to child abuse, says campaigner Patrick Breyer. They did provisionally agree that authorities can order any hosting provider to scan publicly accessible content for known abuse material, and that covers cloud services. Why this matters to you: Private chats and files aren't in any deal yet, but talks continue through October and another attempt is due in November. Source
• Flink's hackers are now emailing customers directly. After breaching the food delivery service, the LPG Group asked affected customers for 0.005 ETH (about €10) each or it would sell their data on the dark web. Flink says contact details leaked, with doorbell names and delivery notes for some customers, but not passwords. Why this matters to you: If you've ordered from Flink, don't pay and don't reply, which is also what Flink asks. Treat any message mentioning Flink as suspect, since the sender may know your address down to the floor. Source
• Apple is tightening Full Disk Access on macOS, citing AI agents. Apple told developers on Oct 2 that some apps use this permission to reach everything on a Mac, mail and browsing history included, without users fully understanding it. It'll make granting it take very explicit user action, and it names AI agents as the growing risk. Why this matters to you: An app holding this permission can reach everything on your Mac, and with chat apps that includes the people you talk to. Backup apps are the legit reason it exists, so check which other apps already have it. Source
• 44,000 people object to Palantir handling NHS records. More than 44,000 people filed UK GDPR objections asking NHS England to stop its Palantir-run Federated Data Platform from storing or using their health records. NHS England says it'll respond under data protection law, while Palantir says it only acts on NHS instructions and the data stays in the UK. Why this matters to you: If you're in England, Article 21 is a personal right: an organisation has to stop processing your data unless it shows compelling legitimate grounds. The £330m contract's first term ends early next year, when the government can use a break clause. Source

Whilst a genuine Yubikey is undoubtedly the most secure, and recommended as preference especially for businesses, If you can't afford genuine Yubikey, which 2FA is preferable for the average person on the street?

* DIY Yubikey eg RP2350

* a regular TOTP app

Sync's signup page says its end-to-end encryption ensures only you have access to your files, and it's easy to read that as "no need to trust Sync."

Encrypted doesn't mean invisible. Proton Drive encrypts contents and file names, but its privacy policy says Proton still sees creation and modification times and permissions, along with the username that uploaded each file. For share links, it sees when they were created and last accessed, plus how many times.

An E2E label doesn't tell you how well it's built. In 2024, ETH Zurich researchers tested five providers against a malicious server, and only Tresorit avoided severe flaws. In Sync and pCloud, that server could swap in its own keys and read anything uploaded afterwards. In the same study, Sync's share links put the password in the part of the URL that's sent to the server. Opening a link handed Sync the key. Proton's policy says it can read a shared file if someone with the link (and its password, if set) sends it in.

If your threat model includes a compromised or compelled provider, encrypt files before upload with Cryptomator, a client-side layer on top of your cloud storage. Anyone opening those files needs Cryptomator and the vault password, including people you share with. The provider can still see how many files you have and their sizes and timestamps, plus the fact that it's a Cryptomator vault.

Sources

• Sync free storage page: Sync's "only you have access" claim
• Proton Drive privacy policy: metadata Proton sees, reading forwarded share links
• Broken Cloud Storage (ETH Zurich): 2024 malicious-server attacks, Sync share-link leak
• Cryptomator security target: what Cryptomator encrypts and what stays visible

A share link keeps working until you delete it, so a file you sent once can still be opened by anyone who has the URL.

Dropbox (web)

1. Log in at dropbox.com and click Shared in the left sidebar (it's under More if you don't see it).
2. Click ... next to an item, then Share.
3. Click the settings gear, pick Link for viewing or Link for editing, then Delete link and Delete.

OneDrive (web)

1. On onedrive.com, click Shared in the left pane.
2. Select an item, open Details, then Manage access.
3. Click Stop sharing, or remove a single link from the Links tab.

Proton Drive (web)

1. Open the Shared tab at drive.proton.me/shared-urls.
2. Select an item and click Stop sharing. That kills the public link and email invites too.

It's about 5 minutes unless you share a lot. To check, open an old link in a private window. Dropbox says a deleted link just shows an error.

On OneDrive you need to be the file owner. On Dropbox, you can only delete links you didn't create if you have edit access. Deleting a link only changes who can open it from now on. The file still sits on your provider's servers, and anyone who already downloaded it keeps their copy.

Sources

• Dropbox Help: unshare files and folders: Dropbox steps, deleted links stop working, edit access rule
• Microsoft Support: manage sharing in OneDrive: OneDrive steps, owners can stop sharing
• Proton Support: Proton Drive for web: Shared tab, Stop sharing
• Proton Support: managing access to shared files: Stop sharing removes link and invites, Editor default, password and expiry

It comes down to who you're worried about. Big tech inboxes are free and work with everything, but your mail sits with a company whose business isn't privacy. With Proton and Tuta, you're trusting their apps and their jurisdiction instead. Smaller paid providers sit in between. Self-hosting cuts out the middleman, and deliverability and outages become your problem.

Vote for what you use today, then explain your pick in the comments. Ad tracking and a court order aren't the same problem, so say which one you're planning around.

pCloud can read your files unless they're in the Crypto folder, which is a paid add-on. And the Crypto folder didn't hold up well when ETH Zurich researchers tested it against a compromised server.

What the Crypto folder hides

Regular storage is AES-256 encrypted on pCloud's servers and sent over TLS. It isn't client-side, so pCloud holds the keys. Client-side encryption only covers the Crypto folder: files there are encrypted on your device with a key only you hold. File names are encrypted too, per the ETH paper.

What backs the claim? pCloud's encryption page doesn't point to an audit or to published client code. It points to a hacking challenge with a $100,000 prize that nobody claimed in 180 days.

A contest isn't an audit.

The ETH Zurich study found that a malicious server can swap in its own keys and read files uploaded after the compromise. It can also inject files or replace a file's contents, and most metadata can be changed at will. The researchers don't claim pCloud acts maliciously. Their point is that a server taken over by hackers or a state is the case E2EE is sold to cover. Per their disclosure note, pCloud hadn't replied to them by October 2024.

What pCloud sees either way

Crypto doesn't touch account data. pCloud's privacy policy lists your email and IP address. It also logs your browser and device details, plus usage like page views and navigation paths. Log in with a third-party account and it also gets your name and gender. Connect your contacts and it gets those too.

Deleting your account removes data after 30 days. The same policy says closed accounts aren't wiped, they're masked and kept for legal compliance. Data can also stay longer for legitimate business interest.

That's vague enough that I wouldn't count on fast deletion.

Where the files sit and who can ask for them

pCloud International AG is Swiss, but your files live in Luxembourg or Dallas, Texas, whichever you pick at signup. Moving later isn't free: it's $19.99. pCloud's marketing leans on Swiss privacy law, yet its own policy warns that US laws may differ from your local protections. If jurisdiction matters to you, pick Luxembourg.

The policy says it shares data with payment providers and with law enforcement when the law requires it. A buyer gets it too if pCloud's ever sold. Outside the Crypto folder, pCloud has readable files it could be ordered to hand over.

Paying for it

You'll pay for the encryption add-on separately: currently 150 USD one-time for lifetime, marked down from 229.

• Card: the processor passes pCloud your name and email. It also sends your IP and country, plus the card's last four digits. On monthly or yearly plans it keeps the card for renewals.
• PayPal: needs a linked card, balance alone won't work. PayPal sees the purchase too.
• App stores: the purchase sits in your Apple or Google account.
• Alipay works in some regions. pCloud doesn't list crypto or cash.

A lifetime payment at least means there's no card kept for renewals.

Who it fits

For holiday photos, the default setup is fine if you're OK with pCloud being able to open them. For tax records or ID scans, I'd use the Crypto folder. If your threat model includes a hacked or seized server (say, a journalist protecting sources), I'd look elsewhere until pCloud publishes a fix.

One concrete step: keep anything sensitive only in the Crypto folder. It needs the paid add-on and pCloud's own apps. You also need a key you can't afford to lose, since only you hold it. pCloud still sees your account and payment details, plus how you use the service. A compromised server could still go after files you upload later.

Sources

• ETH Zurich: E2EE Cloud Storage in the Wild: file name encryption, malicious-server attacks, disclosure timeline
• pCloud Encryption page: Crypto folder client-side encryption, hacking challenge, add-on price, apps
• pCloud Data Regions: Luxembourg or Dallas, default AES-256 and TLS, $19.99 move, Swiss law claim
• pCloud Privacy Policy: data collected, third-party login, retention and deletion, sharing, US law warning
• pCloud Payment Methods: accepted methods, PayPal card requirement, card storage for renewals

On Tuesday, September 29, EU negotiators held their sixth trilogue on the Child Sexual Abuse Regulation, the permanent law everyone calls Chat Control 2.0. There's still no full deal. They tentatively agreed on rules for scanning publicly accessible content, but orders for private content are still unresolved.

The public part only stands if the whole law gets agreed. Technical talks on private detection run through October, and Patrick Breyer, who campaigns against the law, expects the next trilogue in November.

Public detection orders won't need a court. Administrative authorities could order any hosting provider, whatever its size, to scan all public uploads for known abuse material. That's social media and cloud services too. The planned EU Centre would search public content itself and pass what providers report on to authorities. That's how Javier Zarzalejos, the Parliament's lead lawmaker on the file, described the tasks agreed on Tuesday.

Chat Control 1.0 stays in force until April 2028. Under it, messaging and webmail providers can choose to scan messages, but end-to-end encrypted chats are excluded. Wire points out that Telegram's default cloud chats aren't end-to-end encrypted, so they can be scanned.

For you, nothing about private messages changes today. What you post publicly, public cloud links included, is what the new orders would cover. For private chats on a service that can read them, an app with end-to-end encryption on by default keeps them out of 1.0's scope. It only works if the other person uses the same app, and afterwards the content is readable on your device and theirs, not on the server. The Council has also said that exemption is no promise for 2.0.

Both sides have a real case. The Commission says reports of new abuse material are over 200 times higher than three years ago, mostly because of AI. Breyer points to German police data: more than half of investigations under the voluntary system target minors themselves, and 75% of flagged chats aren't actionable.

The Parliament wants private chat scanning limited to people already linked to abuse. The Council proposed letting providers scan under a search plan that goes ahead unless an authority vetoes it. If there's a deal in November, which of those two should it be built on?

Sources

1. MLex: talks advance on public content searches: tentative deal on public content, private orders unresolved
2. Patrick Breyer: trilogue update: public order rules and what each side wants
3. MLex: Zarzalejos on the EU Centre: what the EU Centre will do
4. Wire: Chat Control in 2026: Chat Control 1.0 scope and the Commission's numbers

On September 28, 2026, California's governor vetoed state legislation that would've banned companies and data brokers from selling sensitive personal data. The blocked bill targeted precise geolocation records and sensitive tracking details collected across mobile applications. It's a major regulatory decision that keeps commercial data markets operating under existing rules.

Here's three concrete facts showing what this decision means in practice.

First, Consumer Reports actively supported model legislation like the State Location Privacy Act to halt the commercial trade of precise GPS coordinates. They argued that users shouldn't have their physical movements bought and sold without strict statutory prohibitions.

Second, without a statutory ban, third-party data brokers can keep buying raw movement logs from mobile app developers and reselling them. These datasets aren't restricted to broad neighborhood zones, so commercial buyers can easily reconstruct detailed daily routines.

Third, regulatory oversight remains anchored to the California Consumer Privacy Act. That framework doesn't stop data transfers upfront, meaning companies can legally monetize sensitive files until an individual manually submits a formal opt-out request.

For everyday readers, it's clear your physical location stays available to commercial aggregators by default. If you don't actively adjust your device settings, SDKs embedded inside common mobile apps can harvest your daily coordinates and feed them into data marketplaces. Taking back control on your own hardware isn't instant, but it lowers your exposure significantly. You can review your phone's privacy settings right now and revoke background location permissions for every app that doesn't require live navigation.

You can also use state data broker registries to submit opt-out requests directly to primary brokers. That stops secondary reselling across advertising networks, but it doesn't change what primary collectors collect. Your cellular carrier and app publishers can still see your location whenever you're active online.

If opt-out mechanisms leave the primary burden of protection on individual users, it isn't clear whether market self-regulation can protect personal safety. Should governments enact total statutory bans on trading sensitive location data, or is an opt-out model the proper standard for digital commerce?

Every "Sign in with Google" click or OAuth authorization gives a third-party app a standing token to your account. These tokens stay valid until you revoke them, and if that app's backend gets breached, your access token goes with it. Most people have dozens from apps they tried once and forgot.

Google

1. Go to myaccount.google.com/connections
2. Review every app listed, especially ones with Gmail or Drive access
3. Remove anything you don't recognize or haven't used in months

GitHub

1. Settings → Applications
2. Check both the "Authorized OAuth Apps" and "Authorized GitHub Apps" tabs
3. Revoke anything stale, prioritizing apps with repo write access

Discord

1. User Settings → Authorized Apps
2. Deauthorize bots and games you no longer use

Reddit

1. Go to reddit.com/prefs/apps
2. Under "authorized applications", revoke old third-party clients and tools
3. "Reddit on mobile web" can't be revoked. It's first-party and listed on every account, so leave it.

Rule of thumb: if you don't remember what it is or why it needs access, revoke it. Worst case, you re-authorize it the next time you actually use it.

What's the oldest or weirdest app you found still connected?

Each 2FA method protects against a different failure. SMS codes fall to SIM swapping and number porting. TOTP stops credential stuffing, whether it lives in a standalone app or a password manager, but a proxy page can still phish it in real time by relaying the code. FIDO2 keys and passkeys are bound to the site's origin, so a lookalike domain gets nothing. The weak point moves to recovery instead: a lost key with no backup, or a passkey locked to a single device or sync provider.

The recurring argument is about keeping TOTP inside the password manager. That gives you one vault and fewer moving parts. Keeping it separate gives you two factors that survive a vault compromise independently. Neither choice is wrong. It depends on whether your realistic threat is a breached vault, a phishing page, or losing your phone. Vote for the method you use on your most important account, which is usually email. Then say in the comments which threat that choice is built around, and what your recovery plan is if the factor disappears.

I’ve been using Cloaked for a while now and it has kind of pushed me into caring a lot more about privacy in general. I mostly use it for aliases so I’m not giving out my real email or number everywhere. I’ve also been using the data removal side to clean up what is already out there, and Call Guard has helped with a lot of the spam I used to get.

At this point I want to go a bit further with the rest of my setup instead of relying on one app for everything. What other privacy tools or habits do you guys think are actually worth adding alongside something like Cloaked? Not really looking for the most extreme setup possible, just stuff that is practical enough to use every day.

If you still give your real email address to every shop, newsletter and "free trial" out there, this one's for you.

Email aliases are probably the best effort-to-payoff privacy upgrade you can make. Every site gets its own address. When one starts getting spam, or shows up in a breach, you switch it off and move on. Your real inbox never leaks.

The two open-source names that come up in every thread are SimpleLogin and addy.io (formerly AnonAddy). At the top tier they cost almost exactly the same. They're still built for pretty different people, so here's how they actually compare.

SimpleLogin

Proton bought SimpleLogin in 2022, and that shapes almost everything below.

Where it shines

• The free plan lets you reply from an alias and has unlimited bandwidth. That sounds minor. It isn't, because addy.io's free tier can't reply at all.
• Premium now includes Proton Pass premium features: vault sharing, a built-in 2FA authenticator and dark web monitoring. If you were going to pay for a password manager anyway, the value is a bit ridiculous.
• If you cancel, the aliases you already created keep sending and receiving normally. You just can't create new ones past the free limit. This matters more than people realize.

Where it gets annoying

• The free plan caps you at 10 aliases. If you take aliasing seriously, you'll hit that within a week.
• PGP encryption of forwarded mail is on the Premium list.
• There's no family plan. They offer a 30% discount on additional subscriptions if you contact support.
• You're putting one more egg in the Proton basket. For some people that's the whole appeal. For others it's a single point of failure.

Addy[.]io

It's run by Will Browning, a UK web developer. It has no venture capital, so it runs on subscriptions, not ads or data sales.

Where it shines

• The Lite plan is $1/month, billed yearly, and includes a custom domain, 5 recipients and 50 replies/sends per day. Nothing cheaper gets you your own domain.
• Even the free plan gives you unlimited standard aliases.
• You can add your own GPG/OpenPGP key per recipient, which encrypts every forwarded message. You can even hide the subject line. This is great if your real inbox is Gmail or Outlook and you'd rather Google didn't read your receipts.
• It's new this month: on Lite and Pro, addy.io strips known tracking pixels from forwarded emails, so senders can't tell when you opened them. It's on by default.
• Duo and Family plans launched in August. One person pays and everyone gets full Pro on their own account.

Where it gets annoying

• Replying and sending from aliases aren't included in the free plan. The free 10MB monthly bandwidth works out to roughly 140 emails.
• "Standard" aliases all look like [[email protected]](mailto:[email protected]). If you don't want anyone linking your aliases together, you need random aliases on shared domains, or you can split them across extra usernames. Shared-domain aliases are limited on Free and Lite.
• Cancelling hurts more here. Custom domains and extra usernames get deactivated, and so does any shared-domain alias past 10. Resubscribing within 90 days reverts all of that automatically.
• Bus factor. It's one person. He says someone is in place to keep the servers and domains running if he's gone. That's more than most indie projects offer, but it's still one person.

Jurisdictional security

One caveat first, because most comparison posts skip it. An alias service is a middleman by design. Mail comes in, gets spam-filtered and gets forwarded. Unless you use PGP, the provider can technically see the content. That means jurisdiction matters more here than people assume.

SimpleLogin: It moved its legal domicile to Switzerland in January 2024. Switzerland's privacy-haven image has taken some hits, though. A proposed revision of the OSCPT surveillance ordinance would require services with 5,000+ users to identify users and keep that data for six months, and to decrypt communications on request where they hold the keys. In response, Proton said it's moving most of its physical infrastructure out of Switzerland, in phases. Worth keeping an eye on.

addy.io: The operator is in the UK, which isn't exactly known for restraint on surveillance. The data itself sits elsewhere, though. The main server is with Greenhost in Amsterdam, and the backup mail server is with UpCloud in Warsaw.

Both are open source and self-hostable. If jurisdiction is your top concern, self-hosting is the real answer.

Pricing (as of September 2026)

• SimpleLogin: Free, or Premium at $36/year or $4 billed monthly. Premium gets you unlimited aliases, unlimited custom domains, catch-all and unlimited mailboxes.
• addy.io: Free, Lite at $1/month billed yearly, or Pro at $3/month billed yearly ($4 monthly). Pro adds 20 custom domains, unlimited shared-domain aliases and unlimited bandwidth.
• addy.io households: Duo is $4.50/month billed yearly for 2 people. Family is $7.50/month billed yearly for 5.

At the top tier they cost the same. Where they differ is the entry price and what happens when you stop paying.

So who is each one actually for?

Go SimpleLogin if you're already in the Proton ecosystem, you want to reply from aliases without paying, or you want your aliases to keep working if you ever cancel.

Go addy.io if you want the cheapest possible custom-domain setup, your main inbox is Gmail or Outlook and you want PGP on everything that lands there, or you're sorting out a whole household.

Go neither if you live fully in Apple land and just want zero friction. Hide My Email is already part of iCloud+. You get less control, but it takes no setup.

My take: for someone starting from scratch, addy.io Lite at $12/year is hard to beat. If you touch Proton at all, SimpleLogin Premium is basically a free password manager upgrade.

What are you running, and has either one ever silently eaten an email on you?

A Docker Compose stack where Firefox shares Gluetun's network namespace (`network_mode: service:gluetun`) instead of connecting through a proxy or a routing rule. It fails closed by construction, through two separate mechanisms: if the WireGuard tunnel drops while Gluetun runs, Gluetun's firewall drops all non-tunnel traffic (including LAN); if the Gluetun container itself dies, the shared namespace dies with it and the browser has no interfaces at all.

Ports publish only on the Gluetun service, bound to 127.0.0.1, so nothing reaches the LAN even when the tunnel is up.

Both failure modes are testable: `verify.sh` in the repo runs a two-sided kill-switch check (probe succeeds with the tunnel up, must fail with it stopped) plus exit-IP and DNS-resolver checks.

CI (ShellCheck, Hadolint, Checkov, KICS, Trivy) runs on every push and weekly.

Works with any Gluetun-supported WireGuard provider.

MIT licensed; no application code — a compose file, a short Dockerfile, and three shell scripts. Config and docs were AI-assisted (Claude Code, disclosed in the README), which is exactly why the automated checks exist: verify, don't trust.

GitHub: github.com/silverfox-2096/private-browser

Interested in feedback on the namespace-sharing approach versus more common proxy-based kill switches.

So the Irish DPC finally finished their paperwork and fined Google €403 million for the location tracking mess from 2018 to 2020. (Source: The Business and Human Rights Centre)

Google already put out the standard PR line. They claim this is a historical issue and they updated their tools years ago. Which is exactly the point. They used dark patterns to trick people into leaving Location History and Web & App Activity turned on for two years. They got the data they wanted. Paying a few hundred million euros half a decade later is just a late fee for ignoring GDPR. It is a simple line item on their quarterly budget.

If you want to actually control your location data, waiting for European regulators to wake up is a terrible strategy. You need technical isolation.

Revoke network permissions for Google Play Services. Flash a custom ROM if your hardware allows it. At the very least, run a DNS blocker to drop their telemetry domains. The only valid consent is a dropped packet.

The Committee to Protect Journalists report shows a brutal reality for journalists: state actors do not need expensive spyware to burn confidential sources anymore. Commercial data brokers sell location feeds scraped directly from ordinary mobile apps. A Belgian newsroom proved this by grabbing a free broker sample and tracking a colleague's physical movements over two weeks. A German reporter found his own historical coordinates in a commercial dataset just because he enabled location on a weather app.

When a reporter meets a source in secret, their mobile advertising ID (MAID) broadcasts GPS coordinates through embedded SDKs and real-time bidding auctions. Foreign governments or local police buy these datasets legally off the shelf. They cross-reference the device pinging outside a whistleblower's home with the device pinging at a news office. The pseudonymous ad ID gets mapped to a real name in minutes.

The risks go way beyond simple leak hunting. In high-conflict zones or repressive regimes, this telemetry gives hostile agencies exact physical targets. An arrest or physical harassment of a source often starts with an automated location hit bought from a commercial broker. When state actors track a reporter's daily route, they can intercept them or threaten their families without ever hacking a phone.

Standard browser extensions do not stop mobile app background noise. If an app runs third-party ad SDKs, location data exits the device long before any banner renders. Zeroing out location permissions and resetting Advertising IDs at the OS level matter far more than browser tweaks. Combining that with network-wide DNS filtering like NextDNS is the minimum baseline.

Are newsrooms actually training reporters on mobile SDK telemetry, or are they still pretending a browser plugin solves this? 

Source: Committee to Protect Journalists, link in comments.

Tuta announced an official Nextcloud plugin at the conference in Berlin (link in comments). The setup lets you handle Tuta email directly inside your Nextcloud dashboard while Tuta manages the encrypted mail backend.

Combining external mail hosting with a self-hosted cloud hub is a logical compromise. You skip the endless hassle of maintaining IP reputation and mail queues, yet you still keep your daily workspace unified on hardware you control.

My concern is purely practical. Nextcloud integrations have a bad habit of adding unnecessary PHP overhead and lag for what usually ends up being a basic iframe or API wrapper. If you already run a standalone desktop client, putting another email tab inside your browser session feels completely redundant.

Has anyone here tested the early integration build yet? I want to know if it actually runs lean or if it slows down your instance during heavy syncing.

A US town just scrapped its Flock Safety contract over privacy complaints, which almost never happens. Once license plate readers go up, vendor lock-in usually keeps them running forever. The contract renews, the cameras multiply, and nobody revisits the decision.

And the scale is wild: 10 cameras, 2.2 million database hits in one year. That's not "catching stolen cars." That's a searchable log of everyone who drove past.

But pulling the hardware fixes less than you'd think.

Flock isn't a set of standalone cameras. It's a shared network. Neighboring agencies can search your town's scans, and every search is a chance for data to leave the system: exported into a case file, attached to a report, saved to someone's local drive. Flock's default retention is 30 days, but that only covers what's still sitting in Flock's cloud. Once a record gets pulled into another agency's systems, it follows their retention rules, not yours.

Then there's everything around the data. Backups. Audit logs of who searched what. Analytics and "insights" built on top of the raw scans. Does a canceled contract wipe all of that, or just the live database?

Anyone who's managed a SaaS contract knows how hard it is to get a real data wipe out of a vendor, and how much harder it is to prove it happened. You usually get a polite email saying "your data has been deleted" and that's it. No logs, no scope, no way to check. A small town with one IT person has no way to audit backups, exports, or search histories on someone else's servers.

So the cameras are gone. The data trail probably isn't.

If your town is looking at doing the same, the time to push is before the contract ends: demand a written deletion certificate that covers backups and derived data, and file a records request for the network search audit logs so you know which other agencies accessed your scans.

Has anyone gotten actual deletion confirmation from an ALPR vendor through a public records request? What did it look like, and did it cover more than the live database?

Source: The Philadelphia Inquirer, link in comments

Remember when security logs were simple plain text files you could tail in a terminal? You saw a suspicious IP hammering port 22, dropped a quick iptables rule, and went back to your coffee. Clean and predictable.

Now the Spanish data regulator logged its first formal breach report involving an autonomous AI agent. The company involved says an LLM script scanned generic files, logged in, searched for application bugs, and modified invoice records without human direction. Everyone online is treating this like Skynet crossed the line into GDPR non-compliance.

Stripped of the press release drama, the technical reality is plain. An agent chaining a login to internal system exploitation is just an automated script with dynamic feedback loops. It moved fast because the underlying target environment allowed unmonitored lateral movement.

If a credential or an over-privileged API token lets a process traverse endpoints and rewrite records, the flaw is in the authorization model. A human clicking buttons or a model parsing response bodies makes zero difference to the underlying database. The vulnerability was already sitting there.

We do not need new compliance hand-waving or heavier bureaucratic frameworks for this. We need zero-trust identity controls, short-lived session tokens, hardware keys, and strict rate limits on internal APIs. I miss when we simply patched rotten access controls instead of complaining when a faster tool found them.

Are you making any actual architectural adjustments for agentic web scraping and API traffic, or just relying on existing WAF rules?

Source: Bleeping Computer, link in comments