Users have emailed us at times to wonder how secure are the images and other content uploaded to Amplenote? In this article, we'll discuss the technical details of how such content is stored, so you can cultivate your own informed opinion on this subject.
linkImage & video content
Images and videos (henceforth collectively referred to as "images") are protected by what is effectively a very long password. The image path is a combination of two 122-bit values (a v4 UUID), one of which is a random number produced by a cryptographically secure random number generator. That's 2^122 possible values for image addresses. If you've ever heard the brain teaser "how many times would you have to fold a piece of paper before it was so thick it reached the moon?" you have at least a passing familiarity with the mathematical implications of exponential growth. When you learn that you would have to fold a piece of paper only 45 times for it to reach the moon, you can perhaps begin to appreciate how big of a number 2^45 is. And 2^122 (the number of possible values for image addresses) is a much, much bigger number than 2^45.
Extrapolating the number of possible image & video URLs is not unlike counting the number of stars in the sky
How long would it take to discover any one image among 2^122 possibilities? The limiting factor in this discovery effort would be how many URL requests could be made per second. A web server is generally considered to be under "heavy load" if it handles 500-1000 "lightweight requests" per second. But let's say that Amazon S3 (the image server for Amplenote) can respond to 1,000,000 image requests per second, and a state actor has somehow marshaled sufficient computing resources and bandwidth to launch 1m requests per second. Let's also pretend that Amazon and the internet providers would serve these flood of requests, rather than detect them as a DDoS attack and shut them down. Of course, back in the real world, any actor that generated 1 million requests per second is likely to be throttled by their ISP and/or Amazon within hours (if not minutes) of starting such an attack (see also discussion of logistics of launching a hypothetical DDoS attack on Amazon).
Anyway, in the hypothetical scenario where a powerful state actor with impossibly high bandwidth could somehow check 1 million URLs per second, using the common metric of a successful guess in half of the search space, they'd need 5,531,535,562,983,420,195,188,543 years to successfully guess a single image address. And that's only one of the two values Amplenote uses for image content -- remember, an attacker would need to correctly guess both values at the same time to see an image. This hypothetical attacker would be better served by attempting to brute force (guess) your account credentials to log in as you, as the amount of randomness in a user's password is significantly less.
The more salient risk to this form of protection is leaking. It's not realistic to guess an image address, but suppose you (or someone you've shared a note with) copies and pastes the URL to an image elsewhere. There's no guarantee that other location--be it an application, chat message, or another website--won't save the image URL, or make it visible in some easier to discover way.
There are significant complications to requiring authentication for images in web-based applications, which is why you won't find any web-based note taking applications that do that. All that said, we are considering encrypted images for vault notes, as users are already used to trade-offs in vault notes for additional layers of security.
linkPDF content
We require account authentication (Amplenote login) for PDF files, since the user doesn't expect them to be visible within their note as an image is. When you open a PDF, we create a short-term access token (works for around 15 minutes) that allows your account to access the PDF.
linkEncrypted at rest
Note that both of these files types are encrypted at rest on AWS, though the attack vector that protects against is possibly the most unlikely one.