Every cloud drive gives you two ways to share the same file, and they work on completely different principles. One grants a person access; the other grants a URL access. Knowing which is which decides who can still open your file in a year.
Every cloud drive offers the same two ways to share one file. There's a box where you type someone's email address, and there's a button that copies a URL.
They look like two routes to the same destination. They're built on different principles, and the difference decides who can open your file in a year.
Ask what the system checks when a file is opened.
Named access — "add people". Permission is a relationship between a file and an account. When someone opens it, the system establishes who they are, looks them up, and decides. Because there's an identity involved, it can do per-person things: give this person edit and that one view, remove one without touching the others, show you activity attributed to a name.
Link access — "copy link". Permission is a property of the address. When someone opens it, the system checks that the URL is valid and serves the file. There's no identity in the transaction, so there's nothing to attribute, nothing to revoke individually, and nobody to tell apart.
This isn't a security ranking. It's two different questions — who are you versus do you have the address — and each is genuinely better at some jobs.
This one causes the most trouble, and it's an interface consequence rather than anybody's mistake.
Clicking "copy link" puts a URL on your clipboard. It does not alter who can open the file. If the document is restricted to three named people, the link you just copied will present a sign-in wall to everyone else — which is correct, and also the opposite of what many people assume they just did.
The file becomes openable by anyone holding the URL only when you separately change the access dropdown to the anyone-with-the-link setting. Two actions, one of which is easy to skip because the other produced something that felt like a result.
The symptom of skipping it is familiar: you send a link, and the person tells you it's asking them to request access.
A drive share is a state, not an event. Once link access is on, that URL keeps working as long as the file exists in that location with that setting. It doesn't time out. Nothing reminds you.
That's the right default for a shared folder your team works out of. It's a strange one for the quote you sent a prospect in March, which is still openable by anyone who ever received that message — including whoever it was forwarded to, which you have no way to see.
If permission attaches to the address, everyone who arrives is the same anonymous holder of a correct URL. There's no identity to log, so the question did the client actually open it has no answer at that layer.
Again — this follows from the design rather than being missing from it. You can't attribute an access to a person when the whole point was not to require a person.
Since people reasonably ask what these long URLs actually are: the meaningful part is an opaque identifier for the file. It isn't derived from the filename, so knowing a document is called "Q3 pricing" gets you no closer to its address. The rest of the URL is routing — which product should open it, in what mode.
That's why they're long and unmemorable, and the length is doing real work. When permission lives on the address, the address has to be impractical to guess, or the permission means nothing. Anyone who ends up with the string has access; nobody who doesn't, does.
Both mechanisms are well built for the thing they were built for. Cloud storage is designed around files that live somewhere and people who work on them together, and for that, named access and link access between them cover it.
The friction appears when the job is a one-way handover — one finished thing, to one person or a small group, to look at rather than work on. That job has different requirements, and the collaboration model meets them sideways:
Neither is a flaw. They're both the correct answer to how do people collaborate on files, applied to a question that isn't that.
There's a second, more mechanical mismatch if the finished thing is a web page rather than a document: a drive stores files, so an HTML file uploaded to Drive gets shown as code or offered as a download rather than opening as a page. Storage and rendering are separate jobs, and a filing cabinet does the first one.
For a finished page sent one way, miinideck gives you an unguessable, no-index link that opens in any browser with no account — with optional password, an expiry you choose, and a record of when it was opened. Free to start.
Might I need to remove one specific person later? → Named access. It's the only one that can do it.
Do I need to know whether they opened it? → Named access within a drive, or a delivery link that records views. Anonymous link access can't answer this.
Is my recipient outside my organisation, on an account I can't predict? → Link access, or something outside the drive entirely. Named access fails on exactly this case, and it fails in a way that makes your recipient do the work.
Is this a finished thing, going one way, to be looked at? → Worth considering whether a drive permission is the right instrument at all. If you stay with link access, at least set a reminder to turn it off, since nothing else will.
Does it contain something that shouldn't be readable by whoever gets forwarded the message? → Then the address alone isn't enough, and you want an actual check on top. How password protection on a link actually works covers what that does and doesn't buy you.
One button grants a person access. The other grants a URL access. Copying the URL doesn't change who's allowed — that's a separate setting people routinely think they've already changed.
And whichever you pick, the share stays on until someone turns it off. Almost every uncomfortable discovery about old shared files traces back to that one property, and to the fact that a drive has no reason to tell you about it.
If you're weighing this specifically against sending a hosted link instead, a Drive link and a private link compared takes the same material from the delivery side rather than the mechanics side.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
A .json Lottie is not a page — hand it to a client and they get a wall of numbers. What it takes to turn one into something that opens in any browser, and why the answer is smaller than the tooling suggests.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.