Can Someone Guess Your Shared Album Link?
No. A shared album link is a 32-character address drawn from 16 random bytes, and typing your way to a real one is not a thing that happens. The question worth asking is the second one: when a stranger tries an address that is not theirs, does the server tell them whether anything was there?
Your album has two addresses, and only one of them is random
The address you send to people is not the address the album has inside the system, and the difference between them is where this whole question lives.
The link you copy and paste carries a share id: 16 bytes pulled from the operating system random source and written out as 32 hexadecimal characters. There are two to the power of 128 of those. Nobody guesses one, nobody walks a list of them, and no amount of patience changes that. This is the number most services quote when they say a link is unguessable, and for the link itself it is a fair thing to say.
The album underneath it has a different identifier, and that one is not random at all. Like most systems built on MongoDB, Viallo identifies an album with a twelve-byte value made of three parts: four bytes of timestamp, five bytes that stay fixed for the life of a server process, and a three-byte counter that simply counts up. Two albums created a minute apart on the same server differ in the last three bytes and nothing else. Anyone holding one real identifier - their own, or one from an album someone shared with them - is a short walk away from a few thousand plausible neighbours.
That is not a flaw in the identifier. It is what identifiers are for, and it is why the randomness sits in the share link instead. But it does mean that any endpoint accepting an album identifier is standing in front of a queue of cheap guesses, and what it says back matters.
What a wrong guess used to tell you
Two refusals that sound equally firm can leak completely different amounts of information. A server that answers you do not have access has just confirmed there is something there to have access to. A server that answers not found has confirmed nothing.
Until this month Viallo answered both ways, honestly and unhelpfully. Ask for an album that does not exist and it said not found. Ask for one that exists but belongs to somebody else and it said you do not have access. Those are two different answers to two different questions, which is exactly the problem: an unauthenticated prober who sends a thousand identifiers and sorts the replies into two piles has learned which thousandth of them are real albums. Not what is in them. Just that they are there, and roughly when they were made, because the timestamp is sitting in the first four bytes of every identifier that came back in the first pile.
Security people call this an enumeration oracle, and the name is exact. The system has been turned into something that answers yes or no to a question nobody is supposed to be allowed to ask.
Viallo is a private photo sharing platform built on links rather than accounts: the person you send an album to opens it and looks at it with no signup in the way, the photos sit in storage at the size they came off the camera, and nothing reads them to work out what is in them. The change described here is small and entirely invisible when everything is working. Every read path that takes an identifier now gives one answer, album not found, whether the album is absent or simply not yours. Both piles became one pile.
Where the answer had to change
There is no single gate in front of these routes. Album reads, photo reads, share link management, the sign-in handoff and upload tokens each work out for themselves whether the caller is allowed through, which is why a fix like this is never one line. Thirty-six tests across five suites now assert that the two answers match, route by route, because the only way to keep them matching is to check every one of them.
| What a stranger sends | What came back before | What comes back now |
|---|---|---|
| An album identifier that does not exist | Not found | Not found |
| An album identifier belonging to someone else | You do not have access | Not found |
| A photo identifier belonging to someone else | You do not have access | Not found |
| A share link that belongs to another album | Access denied | Share link not found |
| A sign-in handoff someone else started | A refusal you could tell apart | The same answer as an unknown one |
One of those routes needed no sign-in at all, which is the one that mattered most. An endpoint you have to be logged in to probe is a slow and traceable place to run a thousand guesses. An endpoint open to anyone is not.
The share link route picked up a second change worth mentioning, because it is the shape of fix that stops this class of bug coming back. It used to load the link by its address, then compare the owner afterwards and refuse if they did not match. Now the owner is part of the database query. A link that belongs to somebody else does not come back at all, so there is no second step that could answer differently, and nothing for a future edit to get wrong.
How to test this on a service you already use
This is not a Viallo question. It is a question you can put to any photo service, any file service, anything with an identifier in the URL, and it takes about two minutes.
- Open something of your own that lives at a URL with an identifier in it. An album, a folder, a shared file.
- Change one character in the middle of the identifier and load it again. This is an address that almost certainly names nothing. Note the page you get and, if you want to be precise, the status code in your browser developer tools network tab.
- Now get hold of an identifier you know is real but is not yours. The easiest honest way is a second account of your own, or an album a friend deliberately shares the id of. Load that one while signed in as the wrong person.
- Compare the two. If they look the same, the service is not answering the question. If the real one says you lack permission and the fake one says it does not exist, every identifier is now a yes-or-no question anyone can ask.
The result is not a scandal either way. Plenty of well-run services distinguish the two on purpose, because telling a user they lack permission is genuinely more helpful than telling them a thing does not exist. It is a trade, and it is worth knowing which side of it your photos are sitting on.
What this does not do
It is worth being straight about the size of this, because a change to a refusal message is not a change to anything a normal user of the product ever sees.
It does not make anything private that was not private before. Nobody was reading anybody else's photos; both branches refused, and they still refuse. What leaked was one bit of information per request, and one bit is worth something only in bulk.
It does nothing at all about the link you actually send someone. Once a share link is out in the world it works for whoever is holding it, which is the point of it and also its whole risk: forward the message, and the forward works. The answer to that is not obscurity, it is the ability to take it back, which is why links can be given an expiry date and can be switched off. We wrote about both separately, on revoking a shared photo link and on what happens when shared photo links expire.
And it costs something. A person who has genuinely lost access to an album now sees not found rather than a message telling them their access was removed, which is less helpful to them than the old answer was. That is the trade in plain sight. It went the way it went because the people probing identifiers outnumber the people who lost a share, and because the owner can always tell a viewer directly.
The one thing it genuinely buys is that opening an album still asks the viewer for nothing. A service that cannot tell real identifiers from fake ones does not need to put a login in front of a shared album to protect itself from probing. If keeping signup out of the way of the person on the other end matters to you, we compared the ways to share photos without an account in detail.
Frequently Asked Questions
What is the best way to keep a shared photo album from being found?
Use a service whose share links are long random addresses rather than sequential numbers, and check that it lets you revoke or expire one. Viallo builds every share link from 16 random bytes and lets the owner set an expiry date or switch a link off at any point, which matters far more than link length once a link has been forwarded. Google Photos shared album links are long and random too, though ending the sharing there means stopping the album from being shared rather than killing one link.
How do I check whether a service leaks which albums are real?
Load a URL with one character of the identifier changed, then load a real identifier that belongs to someone else, and compare what comes back. A service that says not found for one and no permission for the other is confirming which identifiers are real. Your browser developer tools network tab shows the status code if the two pages look alike.
Is it safe to send a shared album link over WhatsApp or email?
Generally yes, with the obvious caveat that a link in a message is only as private as the message. Anyone who can read the thread, or who is forwarded it later, can open the album, so the useful safeguard is being able to revoke the link afterwards rather than trusting the channel. WhatsApp carries the link fine but will re-encode any photos you send through it directly, which is a separate reason to send the link instead of the pictures.
What is the difference between a link nobody can guess and one nobody can find?
Guessing is about the address, finding is about everything else. A 32-character random address defeats guessing completely, and does nothing about a link pasted into a group chat, indexed by a crawler that followed it, or sitting in the history of a shared computer. The second problem is answered by expiry and revocation, not by making the address longer.
Could someone just try album addresses until one works?
They can try, and until this month a patient prober could at least learn which album identifiers named something real. They still could not open any of them, and now they cannot tell the real ones from the invented ones either, because every identifier gets the same answer. Working out a share link by trial is a different matter: there are two to the power of 128 possible addresses, which is not a queue anyone joins.