Private Cloud Storage Compared: What Happens When Your Privacy Provider Gets Acquired?

Encryption did not save Skiff users from a migration deadline.

That’s the uncomfortable fact sitting underneath every “best encrypted cloud storage” list published since February 2024. Skiff had genuinely strong end-to-end encryption. Its whitepaper described a client-side key model, an “honest but curious” server assumption, and a threat model that most competitors still haven’t matched on paper. None of that stopped the countdown clock that started the moment Notion announced the acquisition.

Mail, Pages, Calendar, and Drive went dark on 9 August 2024. Users spent that spring exporting MBOX files and requesting domain-transfer codes, not reading about how unbreakable their encryption was.

Here’s the part almost no comparison article mentions: this story isn’t over. Notion built a new email product, Notion Mail, largely from Skiff’s own team, launched it in April 2025, and marketed it as an AI-powered inbox. It does not use end-to-end encryption.

And as of this writing, Notion’s own help center confirms that Notion Mail itself is shutting down on 22 September 2026, roughly seventeen months after launch, for a completely different reason: the company says more than half its users had stopped opening the inbox and were letting AI agents handle email instead. For anyone who followed Skiff into Notion Mail, this is the second shutdown notice in under three years.

That second act is the real lesson of this article. A privacy provider’s acquisition is not primarily a cryptography problem. It’s a governance problem. The question that matters isn’t just “can the new owner read my files?” It’s “can I still authenticate, recover my account, export everything that matters, and trust whatever this company builds next?”

The Short Answer: Acquisition Is Not Automatic Decryption

If a service genuinely encrypts your files on your device, and the provider never holds or can recover your decryption keys, a change in ownership does not by itself decrypt your existing files. That’s a real, defensible technical principle, but notice how many conditions are packed into it.

The design has to be genuinely client-side. The new owner can’t already control an authorized endpoint (your logged-in phone, for instance). The keys can’t have been escrowed or recoverable through a password-reset flow. And the client software you’re currently running can’t have been quietly altered to leak plaintext or freshly generated keys before the acquisition even closed.

Assuming all of that holds, here is what an acquirer typically can still do, without touching a single byte of your ciphertext: change the legal entity you’re contracting with, change which country’s courts and regulators apply, change subprocessors and infrastructure, change account-recovery mechanics, change what metadata gets logged and for how long, change pricing and plan limits, change which clients get maintained, change export tooling and its availability, and set a shutdown or migration deadline you didn’t choose.

None of that requires breaking your encryption. All of it can still upend your relationship with the service. This distinction, between content confidentiality and the continuity and control system wrapped around it, is the organizing idea for everything that follows. For a deeper technical breakdown of what encryption actually promises versus what it doesn’t, see Vertex Frontier’s guide to what end-to-end encryption does—and does not—protect.

In short: encryption protects content; it does not protect continuity.

What Happened to Skiff After Notion Acquired It: A Detailed Case Study

Skiff was founded in 2020 by Andrew Milich and Jason Ginsberg, and by late 2023 it had reportedly grown to close to two million users offering end-to-end-encrypted mail, documents, calendar, and drive storage, pitched directly at people who wanted an alternative to Google Workspace without Google’s data model. On 9 February 2024, Notion announced that Skiff was joining Notion.

What follows is a genuinely useful case study precisely because it isn’t a horror story about broken encryption. It’s a case study in exit mechanics.

Resolving the “six months vs. twelve months” confusion

You’ll still see both numbers cited, and the discrepancy is chronological rather than contradictory. The original notice said six months. After feedback, Skiff extended mail forwarding to run through February 2025, about twelve months from the announcement.

But the product suite itself, the part people actually used, still went dark on the original six-month date, 9 August 2024. The safest way to state it: the full service lived six months; a narrow forwarding accommodation lived twelve.

What users actually had to do

Skiff’s own migration FAQ stated that “all user data remains end-to-end encrypted” and that “accounts and data on Skiff will not be converted into Notion accounts.”

That statement is accurate as far as it goes, and it’s also narrower than it sounds. It tells you Skiff data wasn’t silently copied into an ordinary Notion account. It does not tell you whether Notion personnel had any administrative access to the underlying infrastructure, how backups were retained, or how deletion was verified, those questions remain unresolved in the public record.

In practice, migration meant manual, per-product exports: Proton’s contemporaneous migration guide and Mailfence’s independent instructions both describe the same workflow, mail exported as MBOX (Skiff’s own update said even inboxes over 100,000 messages could export as a single MBOX file), contacts as VCF files inside a ZIP, calendars as ICS, and Drive files downloaded individually.

Custom domains needed a separate transfer process through a registrar authorization code, which is a meaningfully different task from downloading files, and one users could easily miss.

What nobody could rely on: automatic account conversion, a one-click Notion import, indefinite preservation of a @skiff.com address, or a provider-to-provider transfer of sharing links, permissions, comments, or version history. One documented Reddit account describes a user who lost their skiff.com address, reported forwarding problems, and had difficulty getting support to help reset a dependent account, a genuine first-hand report, though a single account, not proof of a systemic failure across the user base.

The sequel nobody was tracking: Notion Mail’s own shutdown

This is the update that most existing “what happened to Skiff” articles won’t have, because it’s recent enough to still be current news as this article is written. Notion didn’t simply let Skiff’s email concept die in August 2024. It rebuilt it, Notion Mail, staffed largely by former Skiff engineers, launched in April 2025 as a Gmail front-end with Notion’s AI layered on top. Critically, it dropped Skiff’s defining feature: Notion Mail was never end-to-end encrypted. It synced two ways with Gmail, meaning Google, not just Notion, had visibility into the same mail.

Seventeen months later, Notion killed that too. Per Notion’s own announcement, the shutdown lands on 22 September 2026, and the company’s stated reason has nothing to do with privacy, cost-cutting, or competitive pressure in the usual sense, it says more than half of Notion Mail’s users had already stopped opening the inbox and were letting AI agents triage, draft, and send on their behalf, so it’s “going all in on using agents to run your inbox.”

Drafts, scheduled emails, snippets, and auto-label rules need exporting by 21 September or they’re gone; actual email history is safe because it lived in Gmail the whole time. Organizations relying on HIPAA coverage were told to transition off by 30 June 2026, months ahead of the general deadline.

Step back and look at the full arc: an end-to-end-encrypted product got acquired, was rebuilt as a conventional Gmail client without that encryption, and less than a year and a half later got discontinued for an unrelated strategic reason. For anyone who migrated from Skiff to Notion Mail specifically because it felt like the closest thing left, this is the second export deadline in under three years, and a concrete illustration of exactly the continuity risk this article is about.

Encryption did not make Skiff portable by itself. Users still depended entirely on the provider to keep the lights on long enough to export, to ship a working export tool, and to honor a forwarding promise. Skiff’s cryptography was never the failure point. The absence of a durable exit path was.

What “Private Cloud Storage” Actually Means

“Private,” “encrypted,” “zero-knowledge,” and “end-to-end encrypted” get used almost interchangeably in marketing copy. They describe genuinely different trust boundaries, and the difference determines exactly what an acquirer inherits.

Encryption in transit vs. encryption at rest

Encryption in transit protects data as it moves between your device and the provider’s server, this is what TLS does. RFC 8446, the current TLS standard, provides confidentiality and integrity for traffic between two communicating endpoints; it says nothing about what happens to that data the moment it arrives at the server and TLS terminates. “Encrypted in transit” is not evidence of end-to-end encryption, it just means nobody sniffed your Wi-Fi.

Encryption at rest protects data sitting on a disk or in a database. It can be implemented at the storage-hardware level, the database level, or the application level, and each has a different trust boundary. Nextcloud’s own administration documentation is refreshingly direct about the limits here: its server-side encryption performs encryption and decryption on the server, stores the keys on that server, and explicitly does not protect against a compromised server or a compromised administrator.

Filenames and directory structures aren’t encrypted either. “Encrypted at rest” tells you the provider took a reasonable security step. It does not tell you the provider can’t read your files.

Client-side encryption and end-to-end encryption (E2EE)

End-to-end encryption means content is encrypted on one endpoint and only decrypted on another endpoint the sender trusts, with no intermediate party, including the service provider, able to decrypt it in between. The defensible test isn’t the marketing label; it’s operational: who can decrypt content, filenames, thumbnails, previews, search indexes, sharing keys, and backups? Where are keys generated, and can any support process recover them?

Proton’s published Drive security model, for example, states that encryption keys are generated client-side and only ever transmitted in encrypted form, with filenames and content both encrypted before upload, though that documentation is dated 2020, so treat it as directional rather than a guarantee of every current feature’s behavior.

Cryptomator’s Security Target is more specific about the boundary: it documents encryption of file contents, filenames, and directory structure, while explicitly disclosing that timestamps, file counts, and stored-file sizes remain visible.

Zero-knowledge is a marketing term, not a certification

“Zero-knowledge” has no single standardized technical meaning. Treat it as a claim to unpack, not a badge to trust. The unpacking questions are always the same: Does it cover file content only, or also filenames and metadata? Can a password reset restore access, and if so, how? Is there a recovery key, and who holds it? Do shared links, previews, or search functions require server-side decryption at any point? A provider can score well on one of these and poorly on another while still calling the whole product “zero-knowledge.”

Metadata: the part encryption usually doesn’t touch

Even a well-implemented E2EE system typically leaves a trail: account identity, IP address, device and browser information, login timestamps, billing data, API request logs, object sizes, timestamps, object counts, and sharing events. None of that requires decrypting your files, it’s generated by the act of using the service. An acquirer who can’t touch your ciphertext can often still see who you are, when you’re active, roughly how much data you store, and who you share it with.

Key custody and recovery: the trade-off nobody wants to name

NIST’s guidance on key management (SP 800-57) treats cryptographic keys as an operational asset across their entire lifecycle, generation, use, backup, recovery, and destruction, and separately defines key escrow as a third party holding a key, or part of one, so it can be recovered under specified conditions.

This creates an unavoidable trade-off: a service that can reset your password and still decrypt your old files necessarily has some key-recovery mechanism, and that mechanism is a smaller version of the exact access an acquirer might one day inherit.

Conversely, a genuinely unrecoverable forgotten password, like Tresorit’s, whose support documentation states passwords aren’t stored on its servers and can’t be recovered except through specific logged-in-device or business-admin paths, is often a deliberate consequence of real client-side key custody, not a design flaw.

What Actually Changes When a Privacy Provider Is Acquired

Ownership and the legal counterparty

An acquisition changes who you’re legally contracting with, which matters more than it sounds, because that new entity’s incentives, risk tolerance, and jurisdiction may differ substantially from the founder-led startup you originally trusted.

MEGA’s current terms illustrate how granular this can get: depending on which product or access route you use, you may be contracting with MEGA Privacy Kft in Hungary, MEGA Networks LLC in Delaware, or MEGA Privacy (NZ) Limited, three different legal entities, three different governing laws, under a single consumer brand. A single acquisition can restructure this without changing a single line of your files.

Jurisdiction is not the same as data-center location

It’s tempting to assume that a provider storing files in a privacy-friendly country is safe from other jurisdictions’ legal reach. That’s not how it works. The U.S. Department of Justice describes the CLOUD Act as enabling access to data held by U.S.-based providers “wherever it happens to be located.”

Separately, the EDPB’s guidance on international data transfers explains that GDPR governs transfers outside the EEA and can require specific safeguards. Neither of these guarantees a particular outcome for any specific request, but both establish that the company’s jurisdiction and legal structure matter independently of where the servers physically sit. An acquisition that changes the parent company’s home country can change which of these frameworks apply, even if not a single server moves.

Terms, pricing, and retention

A new owner can revise plan limits, acceptable-use terms, or pricing even when the underlying encryption is untouched. This isn’t hypothetical pessimism, it cuts both ways. When Proton acquired Standard Notes in 2024, it explicitly promised unchanged prices, honored existing subscriptions, and continued open-source development, a genuine continuity commitment.

But note what that deal is not: it’s an adjacent privacy-ecosystem acquisition, not a Proton Drive acquisition, and TechCrunch’s contemporaneous reporting noted that Standard Notes and Proton’s other products used different encryption schemes, with account interoperability described as a future possibility rather than something already delivered. A positive continuity promise and an unresolved integration question can be true at the same time.

Contrast that with pCloud’s terms, which explicitly reserve the right to change ownership, merge, or sell “without explicit notice,” with notice delivered simply by updating the published Terms. That’s not evidence anything bad has happened at pCloud, no ownership event has been publicly verified, but it’s a contractual position worth reading before you commit, not after.

Infrastructure, subprocessors, and the encryption implementation

Even genuine E2EE has an update channel. Whoever controls the client software you download controls, in principle, what that software does going forward, including whether a future update quietly weakens key generation or adds a “helpful” recovery feature that widens who can decrypt your data.

This is a residual threat to name honestly, not evidence of intent by any specific company: unless a provider publishes reproducible builds or has undergone independent, current audits, “the update channel can’t be changed by a new owner” isn’t something you can verify, it’s something you’re trusting.

Account recovery and metadata practices

Acquirers inherit, and can change, whatever recovery mechanism existed before the deal closed. If that mechanism already involves some server-side capability (a support-assisted reset, an escrowed recovery key), the acquisition doesn’t need to break your encryption to expand what’s accessible; it just needs to change who operates that existing mechanism.

The same logic applies to metadata retention: nothing about an acquisition automatically deletes old logs, and a new owner may have different incentives about how long to keep them or what to do with them.

Export tooling and shutdown policy

This is where the Skiff case study becomes most directly useful. The acquirer decides how long an export tool stays available, whether it’s actively maintained, and how much notice you get before it disappears. A “you can always export your data” claim is only as good as the tool that exists on the day you actually need it, and that tool’s continued existence is precisely the kind of thing an acquisition can change without touching any cryptography at all.

In one line: an acquisition can leave your ciphertext completely untouched while changing almost everything else that determines whether you can keep using, trust, or leave the service.

Evaluating Private Cloud Storage: A Six-Surface Acquisition Risk Framework

Most reviews collapse “privacy” into a single score or a marketing badge. That flattens a genuinely multi-dimensional problem. A more useful model treats acquisition risk as six separate, independently scoreable surfaces.

A provider can score strongly on content confidentiality while scoring poorly on identity continuity or portability, Skiff is the textbook case. Score all six surfaces separately before trusting any single “zero-knowledge” or “private” label to cover the whole picture.

Private Cloud Storage Providers Compared

Before the table, one framing point matters: this isn’t a ranking. It’s a record of what’s actually documented about each provider’s ownership history, encryption model, and exit friction, alongside honest gaps where the evidence doesn’t support a claim.

Three broad architectures are worth distinguishing first, because they carry structurally different acquisition risk:

1. Managed hosted encrypted storage (Proton Drive, Tresorit, Sync, pCloud, MEGA), a vendor operates the service and promises client-side or E2EE protection. You depend on that vendor’s continuity and goodwill for export access.
2. Self-hosted or independently hosted software (Nextcloud), you or your chosen host operates the infrastructure, trading vendor dependence for direct maintenance, patching, and backup responsibility. See Vertex Frontier’s take on why local control is not the same as automatic security, the same principle applies to self-hosted storage.
3. A client-side encryption layer over ordinary storage (Cryptomator), you encrypt a vault yourself before it ever reaches a storage provider, which reduces dependence on that provider’s own cryptographic implementation and makes the encrypted vault itself more portable between backends.

Two important caveats belong here, not buried in a footnote:

• First, “no verified event found” for Sync.com, pCloud, or Cryptomator is an explicit absence of evidence in publicly reviewed sources, not proof that no private transaction, investment, or restructuring has ever occurred.
• Second, SpiderOak received a strategic investment from Accenture Ventures in 2023; the public record describes this as an investment, not a change of control, and it shouldn’t be cited as an acquisition.

The providers with the cleanest documented continuity stories (Tresorit, Proton/Standard Notes) are also the ones that were most transparent about the transaction publicly. That’s a pattern worth weighting when you’re evaluating a provider you’re less familiar with.

SaaS Privacy Storage vs. Self-Hosted: The Trade-off Nobody States Plainly

Here’s the framing that gets lost in most “self-host everything” advocacy: self-hosting doesn’t eliminate acquisition risk. It transfers a different set of risks onto you.

A managed encrypted provider reduces your patching burden, gives you a support line, and typically ships a more polished client, at the cost of vendor dependence and continuity risk exactly like Skiff’s.

Self-hosting removes the vendor-continuity dependence but makes you responsible for security patching, backup integrity, disaster recovery, and upgrade safety. One Reddit user described a self-hosted Nextcloud upgrade that damaged their installation badly enough that they considered re-uploading 300 GB from scratch, a single documented account, not a verdict on Nextcloud generally, but a real illustration of where the operational burden actually lands once you own the infrastructure.

For a concrete sense of what that operational commitment looks like in practice, see Vertex Frontier’s guide on the operational cost of self-hosting and the companion piece on why production self-hosting requires more than installing software.

The balanced conclusion isn’t “SaaS bad” or “self-hosting safe.” It’s that both models carry real risk, just distributed differently:

Common Mistakes When Choosing a Private Cloud Storage Provider

Treating “zero-knowledge” as a single fact instead of a set of claims to verify.

As covered above, the label can be true for file content and false for filenames, thumbnails, or search indexes, all in the same product.

Assuming “download your data” equals a complete export

A generic download button rarely covers version history, sharing-link permissions, comments, or account-level keys. Skiff’s export was real and functional for mail, contacts, calendars, and files, but it did not preserve sharing links, permissions, or collaboration state, because those aren’t just bytes; they’re relationships between accounts.

Confusing sync with backup

A synced folder that mirrors changes across devices will just as faithfully mirror a ransomware encryption or an accidental deletion. CISA’s guidance on backing up business data recommends the 3-2-1 approach, three copies, two different media, one offline, specifically because sync alone doesn’t satisfy it.

Never testing a restore

An export you’ve never actually tried to reopen isn’t a verified backup; it’s an assumption. A DataHoarder thread describing a 9 TB Google Takeout export documents hundreds of 50 GB archive parts, one-week download-link expirations, and inconsistent collection behavior, a vivid illustration that a nominally available export can still be an operational project, not a five-minute task, at real scale.

Reading the privacy policy but skipping the change-of-control clause

Sync.com’s and pCloud’s terms both explicitly anticipate a future merger or ownership change. That single clause tells you more about your realistic long-term exposure than most of the marketing copy above it.

A Practical Acquisition-Risk Checklist

Before and After: What Exit-Readiness Actually Changes

Before treating excitability as a feature: You picked a provider based on its encryption claims and interface. Your only copy of important files sits in one account. You’ve never opened the export tool. If the provider announced a shutdown tomorrow, your first action would be panic, not migration, exactly the position many Skiff users found themselves in in February 2024.

After treating excitability as a feature: You know your export formats and have tested them on a small scale. You maintain an independent backup that doesn’t depend on the provider staying in business. You’ve inventoried which of your identities, email addresses, domains, recovery channels, depend on this specific provider. If an acquisition is announced, your first action is executing a plan you already understand, not discovering one under deadline pressure.

The technical protection, genuine end-to-end encryption, doesn’t change between these two states. What changes is whether an ownership event is a manageable inconvenience or a genuine crisis.

Conclusion: A Privacy Provider Is Also a Governance Dependency

Choose private cloud storage not only for how well it hides your files from the provider today, but for how safely you could replace that provider tomorrow. Keep independent keys and copies. Test a real restore, not just a download. Own the identities that matter, domains, aliases, recovery addresses, rather than renting them from a single company.

Understand exactly where the metadata boundary sits in whatever product you choose. And treat news of an acquisition as a prompt to re-check software, terms, jurisdiction, recovery mechanics, and export tooling, not as proof that the encryption you were promised has automatically failed.

Skiff’s encryption was never broken. Notion Mail’s shutdown, just over a week away as this article goes to press, isn’t a cryptographic failure either. Both are governance events wearing a technology story’s clothes. The providers worth trusting with your most important data are the ones that make leaving easy enough that you never actually have to.

Frequently Asked Questions

About The Author

A Gadallh

Ahmed Gadallah is the Founder and Editor of Vertex Frontier, where he publishes research-driven articles on AI, data science, cloud computing, cybersecurity, software engineering, and emerging technologies, with a focus on technical accuracy, clarity, and practical insights.

View all articles by A Gadallh →