If Your Cloud Storage Doesn’t Protect Your Link Sharing, It’s Already Compromised

1. The Silent Disaster of “Private Links”

You spent years perfecting end-to-end encryption. You picked the strongest post-quantum algorithms. You feel safe. Then you click “Share” and send a link. Game over. Link sharing is the part nobody audits, yet it causes half the real-world privacy leaks. Encryption protects the file content. Links betray everything else. Most providers treat sharing as an afterthought bolted onto a 15-year-old object-storage bucket. The result: a firehose of metadata that turns “zero-knowledge” into marketing fiction.

2. The IP Address Problem Nobody Talks About

Every shared link eventually hits something:

A CDN edge node (Cloudflare, Fastly, Akamai) The provider’s own download gateway A raw S3/GCS/Azure endpoint

That node logs the requester’s IP. Every single time. Your recipient’s IP reveals rough location, ISP, company network, VPN habits, and exact access times. Do it often enough and you can triangulate their home address. The provider sees it. The CDN sees it. Any subpoena sees it. Zero-knowledge just went out the window.

3. Gateway Leaks: File Size, Mime-Type, and Timestamp Exposure

Open any “secure” shared link in curl and watch the headers:

1
Content-Length: 8421831
2
Content-Type: image/heic
3
Last-Modified: Wed, 26 Nov 2025 14:22:01 GMT
4
ETag: "a1b2c3d4e5f6g7h8i9j0"

That alone tells an attacker:

Exact file size (great for fingerprinting tax returns, medical scans, or source code) Precise MIME type (photo, PDF, video, archive) When you last touched the file A unique ETag that never changes

Presigned S3 URLs are the worst offenders. They scream metadata to anyone who asks. File size + MIME type + timestamp is often enough to identify the exact document, even if the content stays encrypted.

We use S3 too, but with a crucial difference: Our presigned URLs serve encrypted data that becomes meaningless gibberish without the decryption key embedded in the URL fragment. The metadata leaks are still there, but they only reveal information about an encrypted blob - not your actual file. Someone could see “encrypted data, 8.4MB” but couldn’t fingerprint it as your tax return or medical scan.

4. Static URLs = Correlation Goldmine

Most providers give you one permanent link per file. Same URL → same resource → perfect tracking token. The provider now knows:

Which IPs downloaded it How many unique people opened it Whether the recipient forwarded it Cross-device patterns Exact popularity over time

Congratulations. Your “private” share just mapped part of your social graph.

5. The Referrer Header Nightmare

Click a shared link from Slack, Discord, Notion, or email and your browser happily sends the referrer header. Suddenly the provider learns:

You opened it inside a private Slack workspace called “Family Medical” The message contained “here’s the will update” Your username in that chat The exact document ID in Notion

I have seen referrer leaks expose affair evidence, whistleblower drafts, and internal startup pitch decks. It happens daily.

6. “Private Sharing” Is Mostly Fake

Let’s translate what big providers actually ship:

A random token slapped into the URL → bearer token Anyone with the link gets full access forever No revocation that survives caching No binding to recipient identity Same key material for every recipient

This is not private sharing. This is Dropbox 2014 with better fonts.

7. The Metadata Attack Nobody Escapes From

Even with perfect file encryption, shared links still leak:

Who talks to whom When they talk What type of files they exchange How often Approximate file sizes (tax season? medical? NDAs?) Geographic patterns

Metadata is content. Intelligence agencies figured this out twenty years ago. Cloud providers still pretend it is harmless.

Perfect encryption + catastrophic metadata leaks = compromised privacy.

8. How We Re-Built Secure Sharing From First Principles

We use S3 buckets, but we didn’t bolt insecure sharing onto them. Instead we burned the category down and started over.

8.1 Client-Side Encrypted Share Bundles

Every share generates fresh per-recipient keys on your device. The server never sees them.

For file sharing, we decapsulate the user’s CEK with their Kyber private key to get the raw XChaCha20-Poly1305 CEK and append it to the URL as a hash fragment:

https://drive.ellipticc.com/<shareId>/#CEK

1
// Decapsulate user's CEK using Kyber private key
2
const userCEK = kyberDecapsulate(encapsulatedKey, userPrivateKey);
3

4
// Get raw XChaCha20-Poly1305 CEK for file encryption
5
const fileCEK = deriveXChaChaKey(userCEK);
6

7
// Generate a unique share key for metadata encryption
8
const shareKey = crypto.getRandomValues(new Uint8Array(32));
9

10
// For public links, the fileCEK is directly embedded in the URL hash
11
// Anyone with the link can download and decrypt the file
12

13
// Bundle file metadata (encrypted with a derived key)
14
const shareBundle = {
15
  fileId: file.id,
16
  metadata: encrypt({ fileName: file.name, size: file.size }, deriveMetadataKey(fileCEK))
17
};
18

19
// The fileCEK gets appended to URL as hash fragment: /<shareId>/#fileCEK
20
const shareUrl = `https://drive.ellipticc.com/s/${shareId}/#${base64Encode(fileCEK)}`;

Here’s a real example link you can try: https://drive.ellipticc.com/s/56dd5542f8ad003d417e17a41320b9509b599b44288f58710872a9e43d91481b#Y0ytcyvdW1MJl8SQopqFal5h1j69rbfozppkJw1tT8Y=

8.2 Backend-Generated Presigned URLs

Instead of static URLs, we generate fresh presigned S3 GET URLs on the backend for each download request. The endpoint https://drive.ellipticc.com/api/v1/files/download/<fileId>/urls returns a new set of presigned URLs every time it’s called.

Here’s a real example endpoint you can visit: https://drive.ellipticc.com/api/v1/files/download/a6ab3f56-3ec8-426d-a713-ba77eb02f181/urls

Refresh the page and watch the presigned URLs change completely each time - proving they’re dynamically generated. Even if someone intercepts these URLs and downloads the raw encrypted data, they still can’t decrypt the file because the encryption key lives only in the URL fragment (#CEK) that never gets sent to our servers. The presigned URLs are just temporary access tokens to the encrypted blob; without the key fragment, the data remains cryptographic gibberish.

1
// Backend endpoint that generates fresh presigned URLs
2
app.get('/api/v1/files/download/:fileId/urls', async (req, res) => {
3
  const { fileId } = req.params;
4

5
  // Verify the request is authorized (user has access to this file)
6
  if (!await verifyFileAccess(fileId, req.user)) {
7
    return res.status(403).send('Access denied');
8
  }
9

10
  // Generate fresh presigned URLs for this specific request
11
  const presignedUrls = await generatePresignedUrls(fileId);
12

13
  // Return the URLs - these expire quickly and are single-use
14
  res.json({
15
    urls: presignedUrls,
16
    expiresAt: Date.now() + 5 * 60 * 1000 // 5 minutes
17
  });
18
});

8.3 Share Controls: Expiry, Passwords, and Access Limits

While the cryptographic foundation prevents metadata leaks, we also provide practical controls to limit exposure windows. Every shared link can be configured with an expiry date, password protection, and maximum view/download counts. These controls work at the application layer - the server enforces them without ever seeing the encryption keys or file contents.

When someone attempts to access a protected share, the client-side application checks these conditions before even attempting to fetch the presigned URLs. If the link has expired, requires a password that wasn’t provided, or has exceeded its view/download limit, access is denied immediately without any server-side logging or metadata exposure.

1
// Share configuration options
2
interface ShareConfig {
3
  expiryDate?: Date;
4
  password?: string; // Client-side hashed, never sent to server
5
  maxViews?: number;
6
  maxDownloads?: number;
7
}
8

9
// Client-side access control before fetching URLs
10
async function accessShare(shareId: string, accessCode?: string) {
11
  const config = await getShareConfig(shareId);
12

13
  // Check expiry
14
  if (config.expiryDate && new Date() > config.expiryDate) {
15
    throw new Error('This share link has expired');
16
  }
17

18
  // Check password (hashed client-side)
19
  if (config.password) {
20
    const hashedInput = await hashPassword(accessCode || '');
21
    if (hashedInput !== config.password) {
22
      throw new Error('Incorrect password');
23
    }
24
  }
25

26
  // Check view/download limits
27
  const currentUsage = await getShareUsage(shareId);
28
  if (config.maxViews && currentUsage.views >= config.maxViews) {
29
    throw new Error('This share has reached its maximum view limit');
30
  }
31
  if (config.maxDownloads && currentUsage.downloads >= config.maxDownloads) {
32
    throw new Error('This share has reached its maximum download limit');
33
  }
34

35
  // Only after all checks pass, fetch the presigned URLs
36
  return await fetchPresignedUrls(shareId);
37
}

8.4 Strict No-Referrer Enforcement

We set Referrer-Policy: no-referrer and strip any stray headers at multiple layers. Zero exceptions.

1
// Set strict referrer policy
2
res.set({
3
  'Referrer-Policy': 'no-referrer',
4
  'Referrer': '' // Explicitly clear any referrer
5
});
6

7
// Strip referrer from incoming requests
8
const cleanHeaders = { ...req.headers };
9
delete cleanHeaders.referer;
10
delete cleanHeaders.referrer;
11

12
// Process request with clean headers
13
handleRequest(cleanHeaders, req.body);

8.5 Real Revocation

Kill the share key on your device and every existing link dies instantly. No caching tricks, no “eventual consistency” excuses.

When you revoke a share, the share ID is simply disabled in the database, making it unavailable to everyone.

9. Why This Approach Closes Every Door

With this design:

No IP logs No timestamps or ETags No static identifiers No referrer trails No social graph inference No behavioral metadata No token reuse attacks

We did not improve link sharing. We made the old model impossible.

10. Final Message: If Your Provider Still Does Static Links, They Are Not Private

Encryption without metadata protection is theater.

Static URLs are compromise. Long-lived tokens are compromise. Visible IPs are compromise. Exposed file sizes are compromise. The industry is lazy and hopes you never notice. We noticed. We fixed it. If your cloud storage leaks anything when you share a file, it is not zero-knowledge. It’s just another surveillance bucket with extra steps.

Real privacy means shared files stay blind to everyone except the intended recipient. No metadata. No excuses. No compromises. Start using actually private, post-quantum sharing today.