⚡ Launch

Introducing fShare: File Transfer Without the Privacy Tax

A

Aquila Innovations Team

June 1, 2025 · 6 min read

We've been building fShare in the background for six months. Today, we're launching it publicly — and we want to explain exactly why we built it and what we believe it stands for.

The problem with file sharing today

File sharing in 2025 is broken in a specific, quiet way. The tools that exist broadly fall into two categories: cloud storage services (Google Drive, Dropbox, OneDrive) and transfer-focused tools (WeTransfer, Send Anywhere). Both categories share a fundamental design assumption: your file goes to their server first, then to your recipient.

That assumption has real consequences. Your files sit on someone else's infrastructure. They're indexed, processed for malware, and stored indefinitely or for days at a time. For business documents, medical records, or personal photos, this is a privacy compromise that most people accept without thinking — because there seemed to be no alternative.

"The most private file transfer is one where the file never touches a third party's server. WebRTC makes that possible in any modern browser."

Why WebRTC changes everything

WebRTC (Web Real-Time Communication) is a set of open standards that allow browsers to communicate directly with each other. It powers video calls, live collaboration, and multiplayer gaming — all without files touching a central server. We asked: why isn't anyone using it for file transfer?

fShare uses WebRTC DataChannels to stream file chunks directly from your browser to your recipient's browser. Our servers exist only to help the two browsers find each other — a process called signaling that involves no file data whatsoever.

What we built

fShare is a progressive web app with four things we care deeply about:

Zero server storage — architecturally enforced, not a policy promise
No file size limits — chunked transfer handles files of any size
Free, forever — we believe access to private file transfer should not require a subscription
No account required to receive — your recipient just opens a browser and enters a code

What's next

fShare is live today at fshare.aquilainnovations.in. We'd love to hear how you use it, what frustrates you, and what you'd like to see added. We're building this in the open, and your feedback shapes the roadmap directly.

Welcome to file transfer without the privacy tax.

WebRTC

How WebRTC Makes fShare Inherently Secure

A

Aquila Innovations Team

June 8, 2025 · 8 min read

Security in software is often a feature: something added on top of a system that was designed for other purposes. WebRTC is different. Its security model is baked into the specification — you cannot use WebRTC without encryption. Here's how that works in fShare.

What WebRTC DataChannels are

WebRTC DataChannels are bidirectional data pipes between two browsers. They're built on top of SCTP (Stream Control Transmission Protocol) and protected by DTLS (Datagram TLS). Unlike WebSockets, which go through a server, DataChannels go directly peer-to-peer once the connection is established.

DTLS: the encryption you get for free

DTLS stands for Datagram TLS — it's TLS adapted for UDP-based protocols. Every WebRTC DataChannel is DTLS-encrypted by the browser before any data is sent. This is not optional. The browser will refuse to open a DataChannel without it.

What this means in practice:

The encryption keys are generated fresh for every connection, in your browser
No one — including us — can intercept and read data in transit
Forward secrecy means past sessions cannot be decrypted even if keys from a later session were somehow compromised

The signaling server: what it does and doesn't see

To establish a WebRTC connection, two browsers need to exchange connection metadata. This is called signaling. fShare's server handles this exchange — but it only sees SDP (Session Description Protocol) offers and ICE (Interactive Connectivity Establishment) candidates. These contain network routing information, not file data.

"Think of signaling like two people exchanging phone numbers through a mutual friend. The friend facilitates the introduction but is not present in the call."

Ephemeral by design

fShare's 6-digit beam code is a session ID tied to a PeerJS connection. When you close your tab, the PeerJS peer is destroyed server-side. There is no persistent URL, no stored link, no way to reconnect to a closed session. This ephemeral design means there is nothing to intercept after the fact.

What WebRTC cannot protect against

It's worth being honest about the limits. WebRTC protects the transport layer — data in transit. It does not protect against:

A compromised device at either end (if the recipient's machine has malware, that's outside our scope)
Social engineering (if someone tricks your recipient into entering a code)
Screen recording or other capture of received files

No file transfer tool can fully protect against endpoint compromise. fShare's security model is: your file in transit is as private as your browser's implementation of WebRTC — and that's a very high bar.

Privacy

Why Server Storage Is the Biggest Risk in File Sharing Nobody Talks About

A

Aquila Innovations Team

June 15, 2025 · 5 min read

When people think about file transfer privacy, they usually think about encryption. Is the connection secure? Is it HTTPS? These are important questions, but they miss what happens after the transfer: where does your file live?

The storage problem

Most popular file transfer tools store your file on their servers for some period after transfer. WeTransfer keeps files for 7 days (free tier). Google Drive stores them indefinitely. Email attachments sit in both the sender's and recipient's mail servers, potentially forever.

This means your "sent" file continues to exist somewhere you cannot control, even after the recipient has downloaded it. That has real consequences:

Data breaches — if the service is breached, your files could be exposed
Government requests — stored files can be subpoenaed or accessed under legal compulsion
Employee access — service employees (with legitimate access for support or moderation) may be able to see your files
Training data — some services have terms that allow them to use content for product improvement
Accidental exposure — misconfigured access controls (this happens more than you'd think at major companies)

How P2P changes the risk model

When files go peer-to-peer, none of the above risks apply — because there is no file on a server to breach, subpoena, expose, or misuse. The file exists in two places: your device and your recipient's device. That's it.

This isn't a privacy policy promise. It's a technical constraint. You cannot subpoena data that doesn't exist.

What this means for you

The next time you need to share a contract, a medical document, financial records, or anything else you wouldn't want a third party to hold indefinitely — consider where the file is going to live after you hit send. With fShare, the answer is: nowhere. It goes directly to your recipient and then it's gone from the transfer path entirely.

How-To

Sending a 50GB Video File with fShare: A Step-by-Step Guide

A

Aquila Innovations Team

June 22, 2025 · 4 min read

One of the most common questions we get: "Can fShare really send huge files?" Yes. And here's exactly how to do it for the best experience.

How fShare handles large files

fShare reads your file in 64KB chunks using the browser's FileReader API and sends each chunk over the WebRTC DataChannel. This chunked approach means:

The entire file never needs to be loaded into memory at once
Transfer can be monitored in real-time via the progress bar
The practical limit is your device's available RAM for the chunk buffer and your network speed

Step-by-step: sending a large file

Sign in to fShare and go to the Transfer tab. Select "Send a File".
Drag your file into the drop zone, or click to browse. There's no size warning — any size is accepted.
Click "Generate Beam Code". fShare creates a 6-character code and connects your browser to PeerJS.
Share the code with your recipient via a direct message or SMS. Do not post it publicly.
Your recipient opens fShare, clicks "Receive a File", enters the code, and clicks Connect.
Watch the progress bar. Both you and your recipient see the live percentage. For a 50GB file on a 100Mbps connection, expect roughly 70–80 minutes.

Tips for the fastest transfer

Use a wired connection on both ends if possible — Ethernet is significantly more stable than Wi-Fi for sustained large transfers
Keep the tab active — some browsers throttle background tabs; keep fShare in the foreground
Close other bandwidth-heavy apps — streaming, downloads, and video calls will compete for bandwidth
Check that both parties are on the same network tier — P2P speed is limited by the slower of the two connections

What happens if the connection drops?

Currently, fShare does not support resumable transfers. If the connection drops mid-transfer, you'll need to regenerate a code and start again. We're aware this is the most-requested feature and it's on our roadmap. For very large files on unreliable connections, we recommend using fShare on a stable wired connection.

The fShare Blog