It's too bad HTMLMediaElement seems to only be for audio and video. If it also could do photos you should be able do a photo sharing site that lets you upload encrypted photos, distribute the URLs of those uploads, and have them only be viewable to people you also distribute the key to, without those people needing any special software to decrypt the photos. Such software is already built into the major browsers, as part of the Encrypted Media Extensions (EME).
People mostly think of EME in the context of DRM, providing a uniform framework across browsers for proprietary DRM plugins for streaming movies from services like Netflix.
But EME can actually be used without any plugins. The spec requires implementations to support a thing called "Clear Key", where you provide the decryption key directly to EME instead of it coming from some DRM plugin. See this article for more information [1].
I've tried this with video and it works fine. I took an encrypted video, put it on my web site along with a page that had an HTMLMediaElement containing the video, and a text box that let you enter the decryption key, and could play it back when I supplied the right key.
I wonder if doing a photo as a 1 frame looping video would work?
What's the attack model under which this is better than what Google Photos does?
- You still have to give the people who access the photos the key, they can share it (just like the secret link)
- By entering it on the site, they also implicitly share it with the hosting provider (who morally shouldn't grab it, but that's not a security guarantee).
One attack model is the one described in the article, that the links leaks to someone where it shouldn't be. In that case, an encryption key that is set to expire[1], would limit the scope of that leak. Of course, if someone would screenshot the image it could be too late, so the attack model does not include people that know the key will expire...
Your approach isn't solving any problems, but adds to confusion. Keep in mind Google Photos is a consumer product meant to be used by everyone between tech savvy teenagers and your grandmother.
What verifier? The scenario here is embedding an encrypted blob inside a static web page, and having the user input a key to decrypt inside their browser, right?
If you're going to have a server checking anything, you're on a whole different wavelength than this scheme. Why even use encryption at that point?
What google is doing now is not too far off from that.
The URL contains a long string which is the shared secret (functionally equivalent to a decryption key), and each person you share that URL with may view it without needing any special software.
Anyone you don't distribute that URL to can't view it.
It’s an access token not a decryption key. The difference is you can’t download anything without the token, and the provider isn’t storing or serving ciphertext.
From an implementation standpoint, it means it’s trivial to expire or revoke to token without having to touch the data it grants access to. It can be an entirely separate authentication service.
Google doesn't embed a decryption key in their URL. AFAIK, they are just long lookup keys that are unguessable.
The difference between that and local encryption is if you trust the storage provider. If you were a journalist in China, you wouldn't want your documents accessible by your hosting provider.
In the above scenario, you obviously wouldn't want to submit a decryption key to the server as part of a URL/POST. Look at how services like mega.nz are designed. They popularized an approach where the decryption key is in the URL's label, which is not submitted to the server. The files are decrypted with javascript locally.
Any URL with sufficient entropy is as unguessable as a password. The primary danger would be revocation if the user doesn’t realize their “password” has leaked.
You can do images with javascript. It's slow since you don't have any hardware decryption. Wouldn't be a great mobile experience. You could build a site around limitations but if nothing else, it would eat up battery. There are probably faster javascript encryption libraries than what this random blog I found uses.
Why couldn’t that be easily circumvented by taking a snapshot of a screen? Even if the operating system disallowed screen shots of protected content, you could always take a picture of the screen.
Generally, you shouldn't be sharing your private photos with people who are actually trying to spread them past the intended audience.
The encryption in this case would be to protect against accidental sharing. A group of people that wants to share private photos among themselves could agree on a key which they all keep a copy of. Then they can upload photos encrypted with that key and pass around the links to those photos. Once the initial key is distributed all that they are passing around are links to the photos. If someone goofs and passes one of those links to someone outside the group, no harm done.
But then these giant corporations do not have any incentive to provide service like photos for free. Currently Google is feeding all these user photos to create ML models. There AI is getting stronger with every photo upload. With the approach you suggested its impossible for them to use this data.
Through something called Unsupervised Learning[1].
Have you ever noticed something in the world, and then later someone gives it a name, and you immediately understand how to identify it?
For example, did you know the little plastic table in the middle of a pizza is called a "box tent"? Now you know its name, but you've noticed it before and understood what it was just by seeing it, and combining those experiences with a bunch of other real-world knowledge that you've accumulated.
Same thing for unsupervised learning.
edit: and to underline how that can be scary, remember that people are uploading tons of personal photos, and so google's neural networks can learn to identify anything in those photos, add them to knowledge about who those people are, who they talk to and say over email or hangouts/video chat, where they go every day with their phone, the things they read about on the internet, etc, and someday (when the algorithms further improve) end up with a more complete understanding of who that person is than even their family members can possibly know.
And they are a publicly-traded company, so they have a "fiduciary duty" to use all that knowledge for profit, and we can rest assured our "the internet is a series of tubes" legislators aren't going to come up with reasonable rules about all this.
People mostly think of EME in the context of DRM, providing a uniform framework across browsers for proprietary DRM plugins for streaming movies from services like Netflix.
But EME can actually be used without any plugins. The spec requires implementations to support a thing called "Clear Key", where you provide the decryption key directly to EME instead of it coming from some DRM plugin. See this article for more information [1].
I've tried this with video and it works fine. I took an encrypted video, put it on my web site along with a page that had an HTMLMediaElement containing the video, and a text box that let you enter the decryption key, and could play it back when I supplied the right key.
I wonder if doing a photo as a 1 frame looping video would work?
[1] https://www.html5rocks.com/en/tutorials/eme/basics/