How to verify that your photos are encrypted
Don’t take our word for it — check for yourself. · Русский · Қазақша
We claim three things: photos and videos are encrypted on your device before upload; the key never reaches our server; without the key nobody can open the files, including us. Here are four ways to check, from quick to thorough.
1. Look inside the app
Open any of your photos and tap “🔍 How this file looks on the server” at the bottom of the card. The app downloads that file from storage without decrypting it and shows its real bytes. Your phone tries to open them as an image and fails: it is ciphertext. Next to it you see the same photo opened with your key, and what your caption, date, people and place look like to the server: one meaningless string.
2. Watch the network
You need a computer. Open web.telegram.org in Chrome or Edge, go to @MyAlbumsBot and tap “Open photos”. Press F12 and choose the Network tab. Upload a photo and look at the requests. upload/start carries only the file sizes, a duplicate tag and the encrypted meta_enc string. The files themselves — original, preview and thumbnail — go in the following PUT requests straight to storage (an address ending in r2.cloudflarestorage.com), large ones in parts; inside is binary ciphertext. Try to find your photo, caption or a person’s name in them — they are not there. Go through every request: neither the key nor the recovery code is ever sent.
3. Read the code
The app is plain JavaScript. The cryptography (crypto.js) is served exactly as written; app.js is minified for speed — spaces and comments removed, function and variable names unchanged — and DevTools (F12 → Sources) can expand it with the {} button. Only two small files with our own know-how are obfuscated — partial video playback on iPhone (msevideo.js) and best-shot picking (pick.js): they contain no cryptography, no keys and no requests to the server, so everything that matters for verification is readable in crypto.js and app.js. You can read it right now:
- crypto.js — all the cryptography in about 300 lines: key creation, AES-256-GCM via the browser’s standard WebCrypto, the recovery code, a separate key for every file, secret-album keys (PBKDF2, 300,000 iterations) and shared-album keys (ECDH P-256).
- app.js — the app itself. Search for
fetchandXMLHttpRequest: these are all the calls to the server and storage. Check that the key (exportB64,recoveryCode) is part of none of them and is stored only in your Telegram storage and on the device. - faces.js and fileinfo.js — “who is in this photo” suggestions and reading the capture date and place. All of it runs on the device; the result is encrypted together with the rest of the photo information.
If you know a developer, half an hour is enough.
4. Ask us to open your photo
The most direct check. Create a test Telegram account, upload a couple of throwaway photos and ask support to send you one of them or describe what is in it. We cannot: we only have ciphertext and no copy of the key. Do not send us the recovery code — it is the key itself. “Losing” the key on purpose does not work as a test: it is kept in your Telegram cloud storage and turns up on any device signed in to the same account.
What the server does see
The honest list: your Telegram ID, name and language; the days you opened the app and the link you first came from; how many files you have and how large they are; when each was uploaded; whether it is a photo or a video; that you uploaded the same file again (duplicate protection); your plan and Stars payments; in shared albums, who is a member and with what role, who uploaded what and who reacted. Cloudflare, which carries the connection, sees your IP address; our server uses it only to limit request rates and does not keep it in its database. Everything else — content, captions, people, capture dates and places, album names, the reactions themselves — is encrypted.
What we cannot prove
This is a web app: its code arrives from our server every time, so in theory we could swap it one day. No end-to-end-encrypted web service has fully solved this. Our answer is that the code is open and readable (method 3), and we are preparing an independent code audit whose report we will publish on the Security page; as the project grows we will also publish the code history on GitHub. One more thing: encryption cannot help if someone else is holding your unlocked phone — that is what password-protected secret albums are for.
Questions: @MyAlbums_support or [email protected].
