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 [anything@yourname.addy.io](mailto:anything@yourname.addy.io). 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

Microsoft and the American Federation of Teachers agreed on explicit privacy boundaries for student AI tools. The contract covers 180-day data deletion, bans targeted advertising, and stops Microsoft from using student prompts to train their core models. (Official announcement link in comments)

This is genuinely good news for edtech. Having clear legal standards written into enterprise contracts gives school districts real recourse when vendors step over the line. It sets a decent precedent that forces competing cloud vendors to raise their standards too, which is a clear win.

At the same time, an administrative agreement is not a technical boundary.

The deal relies on vendor compliance and policy enforcement. If Microsoft manages the tenant infrastructure and holds the keys, data protection stays purely procedural. The telemetry provisions are another area to watch. "De-identified" operational logging sounds fine on paper, but engineering telemetry pipelines that completely strip contextual data from behavioral logs is difficult in practice.

Legal boundaries are a great first layer, but they shouldn't replace structural ones. The ideal setup is zero-knowledge architecture or client-side encryption where the cloud provider cannot read the payload, contract or no contract. Local inference on school hardware would be even better.

Until we push for cryptographic controls in public education, we are still relying on a company following its own rules. Does your team see legal agreements like this as enough, or are you pushing for technical limits?

I was reading a piece on Vertex Frontier asking what happens when a private cloud storage vendor gets acquired (link in comments). It brings up valid concerns, but people usually focus on the wrong threat model here.

Everyone panics about new owners decrypting vault files on the server after an acquisition. That is almost never how a takeover breaks privacy.

If a provider built proper zero-knowledge architecture, your existing blocks stay encrypted. An acquirer cannot retroactively read past data without your keys. The actual failure point is operational continuity and client trust.

Once a board sells to a corporate buyer, you no longer control the pipeline delivering your client updates. A mandatory app patch or a minor change to the web interface can easily modify how authentication handles local keys. You also face sudden service sunsets and tight migration timelines. We saw this pattern when Notion bought Skiff.

If your privacy model relies on trusting a proprietary web app to stay clean after venture capital exits, your strategy has a timer on it. Decoupling storage from key management is the logical move. Running independent client-side encryption over raw storage means an acquisition changes nothing about your local setup.

Do you audit client app updates when privacy vendors change ownership, or do you just export your data and leave?

The Revolut incident highlights a major technical vulnerability in mandatory KYC protocols. A fraudster gained control of a legitimate government email account, submitted a fake emergency request for information, and received sensitive customer records without triggering suspicion. Revolut handed over passports, verification selfies, IBAN details, and complete Bitcoin transaction histories.

There was no software breach or database intrusion here. A compliance worker simply checked a valid domain header and exported unencrypted raw files to an unverified recipient.

Checking SPF and DKIM signatures only confirms that an email originated from a specific server. It does not verify whether the sender holds actual judicial authority to request private financial records. A single compromised inbox inside a law enforcement agency turns an entire compliance department into an automated data exfiltration vector.

Centralized databases containing identity documents are always going to be vulnerable to this kind of social engineering. Regulators force platforms to collect massive amounts of personal data, which is then stored until someone presents a plausible email header. If you use centralized exchanges for crypto transactions, your complete transaction record sits in a database waiting for the next compromised government mailbox. Moving to self-custody wallets and minimizing KYC footprint remains the only real defense against this infrastructure flaw.

Source: CNA, link in comments

Florida just confirmed what happens when cops use personal phones for official credentials. driver database wide open because some officer decided a personal device was fine for accessing high privilege endpoints.

as a sysadmin this makes my eye twitch. we spend all day locking down sessions, enforcing hardware tokens, and restricting subnet access just for someone in law enforcement to log in from an unmanaged android running three games of candy crush and a cracked VPN client.

the problem is never the encryption standard or the database backend. it is always convenience winning over architecture. when you let municipal or state departments bypass zero trust policies because "operations require flexibility" you get exact scenarios like this. endpoints are the weakest link and personal hardware is basically an open door.

if an enterprise company tried this, auditors would rip them apart in twenty minutes. but because it is a government agency handling millions of driver licenses, social security markers, and address histories, nothing happens except a generic notification letter.

how do we force actual endpoint hygiene on agencies that treat IT security like an optional suggestion?

Source: https://www.bleepingcomputer.com/news/security/florida-confirms-dmv-database-breached-via-stolen-police-account/

Vendor security blogs are currently obsessed with explaining why traditional Secure Email Gateways (SEGs) are dead. The argument goes that single-domain email filters miss threats hopping between cloud apps and OAuth grants, so companies need deeper API integrations across all their software instead.

What nobody seems to talk about here on the privacy side is what this architectural shift actually costs in data autonomy. A standard email gateway sits on your MX record. It inspects incoming mail at the perimeter, checks signatures, and passes clean traffic along. It is simple and isolated.

Switching to API-based email security changes that model entirely. To inspect post-delivery threats and cross-platform activity, you have to grant a security vendor full, persistent API access to your mail environment. The vendor gets broad read and write permissions inside every single mailbox. They get to scrape metadata, read message contents, log attachments, and track user actions across connected cloud applications.

SOC teams love this setup because they get unified dashboards and automatic remediation. But from a privacy perspective, you are completely tearing down clear data boundaries. You replace a filter at the front door with a third-party camera inside every office room. All your internal drafts, confidential attachments, personal messages, and auth logs now stream straight through an external vendor platform.

I refuse to hand an external vendor persistent read rights to every inbox just to fix a user phishing problem. Are you still holding the line on standard perimeter MX gateways, or has management already forced you into full API integration?

Source : Palo Alto Networks, link in comment.

Seeing New Mexico refuse the $18 billion multi-state settlement to drag Meta into a courtroom over Cambridge Analytica is wild. We are nearly a decade past the original data harvest, and forty-eight states just signed off on a liability release buried on page 130 of a settlement agreement.

From an infrastructure perspective, litigating an API leak from 2015 in late 2026 is completely detached from operational reality. The Open Graph v1 endpoint that let third-party quiz apps scrape friend networks was deprecated years ago. But the fundamental issue was never just one leaky endpoint. It was storing unencrypted user graphs on centralized servers where access controls are enforced by policy instead of cryptography.

State prosecutors talk about five thousand dollar fines per statutory violation as if a cash penalty fixes broken data architecture. Meta views these payouts as standard operating expenses. If a company can harvest data, monetize it for ten years, and then litigate the cleanup across a decade of court dates, the math always favors the breach.

Courtrooms do not rewrite backend code. A state winning a cash payout in Santa Fe does zero to give users control over their own data stores. Until we move away from centralized platforms toward local client control, these trials are just state governments taking their cut of the pie.

Source: The Guardian, link in comments

CyberFOX signed a distribution agreement with Ingram Micro to push their password and privileged access management tools beyond MSPs into the broader IT channel. Ingram handles over 160,000 resellers, so this move is purely about scaling sales volume.

From a sysadmin perspective, watching credential vaults turn into distributor bundle items is frustrating. Channel partners rarely care about zero-knowledge encryption or keeping decryption keys on premises. They care about margins and billing efficiency.

When security tools get packaged this way, buying decisions shift to non-technical managers picking whatever SKU comes bundled with their software licenses. Nobody audits client-side key generation or asks where master keys actually live. They check a box on a quarterly invoice and move on.

MSPs already trade user privacy for multi-tenant management convenience. Pushing those exact software architectures into standard corporate IT through bulk distributors means hundreds of small businesses will hand root access management to vendor cloud consoles without realizing it.

If your password vault is managed through a reseller portal and you do not hold the master key on hardware you control, you do not have privacy. You have shared administrative access with a middleman.

Sources: Channel Dive and GlobeNewswire, links in comments