Up1 uses client-side crypto, so in this instance it is. No real point here though, but I use ShareX with it, and it's nice to be able to deliver screenshots and stuff like this privately.
What's the point of client-side crypto in a browser? Can't you be served backdoored JavaScript that no longer does proper encryption, and you'd be none the wiser?
Yeah, you have to trust the site and their providers of course. But how do you know your OS provider doesn't serve you backdoored updates? Until it was abused by malware, Windows Update used to accept stuff signed by a 512-bit RSA key. Do you personally reverse engineer every binary you accept?
This will change soon though, they're working on browser extensions which will keep all content client side too.
EDIT: Clarified some points, added a little more detail.
The site is perfectly usable. More than usable, even, because I get RES-style zooming for free, amongst other things.
You can right-click save normally already - just right-click and save. If you want the browser zoom tools, hit the "View in Browser" button or right-click and open in new tab
Nobody else has been able to reproduce it, and you haven't given enough information on what you're doing or what you've tried. Have you tried different machines? Different browsers? Have you tried pressing the various buttons in the UI? What kind of machine do you have? Do you have a very small amount of RAM? Et cetera.
You might say your browser works fine, but I'd put my money on something there being the issue.
I saw you tried different versions on 2 different machines -- it certainly suggests something related to your setup: I can zoom, open in new tab, save as, etc on Firefox 41 on Ubuntu 14.04.
Do you have running app for mouse gestures? That's the only thing I can think of that makes sense in your scenario. Try holding the right click for a few seconds, see if the context menu appears.
Which browser are you using that you can't use right click-> save on a blob URL'd image? It's using the standard HTML image and appears to be working in Chrome, Firefox and Edge.
The service provider isn't able to decode the info because the key is part of the URL that isn't sent to them. This decreases liability (and if nobody visits them, they can't be forced to decrypt it).
This protects you from nothing. It actually makes it LESS secure. Because you now have to enable JavaScript.
The service provider can still decode the info by MitM'ing.
If you are using Google Fiber, for example, your service provider can do whatever they want anyway – they control your browser, they are a CA and they are your ISP.
If not: As we’ve seen with CINNIC, MitM'ing is trivial because CAs give out root certificates far too often, far too easily
This is not to protect you, it's to protect the website.
>The service provider can still decode the info by MitM'ing.
Yes, but as I explicitly mentioned, only if you visit the website. If NSA goes to the website and demands the data, they can't do anything with it until I visit, whereas if it was decrypted, they could. This is a non-trivial difference.
>If you are using Google Fiber, for example, your service provider can do whatever they want anyway – they control your browser, they are a CA and they are your ISP.
Google is not going to risk their entire reputation by abusing their CA. Notice how CNNIC was removed from trusted stores and basically lost their business. Mitm by compromising a CA is far from trivial. Also, certificate pinning can mitigate the CA risk almost completely.
As you’ve probably seen with MEGA, this does not protect the site at all.
Take Megaupload (not MEGA), they had unencrypted data, but complied fully with DMCA and operated fully legally.
Take MEGA, they have to comply with DMCA, too, even though everything is encrypted and they never can decrypt the data, either (MEGA does literally the same as up1.ca)
Additionally, Certificate pinning only works if I visited the site before the MitM started. And some carriers like T-Mobile just strip every Certificate Pinning header anyway, as they use proxies to compress data. (Chrome’s Turbo mode does the same).
Essentially, the site uses JavaScript for showing images without providing any advantage to either the user or the site.
MEGA is only able to comply with the DMCA when the link is provided with the full hash.
MEGA is technically unable to remove similar or matching files based on content.
> And some carriers like T-Mobile just strip every Certificate Pinning header anyway, as they use proxies to compress data.
I question the t-mobile thing, unless they're installing certificates on end-user's phones that should not be possible. This is SSL traffic, remember, all those headers are also sent over SSL so unless T-Mobile is performing MITM, this shouldn't be a problem.
As for the Chrome Turbo mode thing, it is disabled for SSL traffic, as are most of these other things.
Well, admittedly, in the context of a link on Hacker News, it's pretty true. The link containing the seed is trivial to obtain and could easily be reported to the providers who would have to take it down if deemed legally necessary.
You did in fact provide a key. See that bit after the # in the URL? This is the beauty of Up1. It makes the crypto as transparent to the user as possible.
That part is not sent to the server by your browser. That's a seed, it's run through sha512 then split into parts, including a key, iv and filename to fetch from the server.
Now, as I said, in this instance, since I distributed the link on a public website, it's pretty pointless. But when I link my friends and colleagues on a private XMPP server or via textsecure, it's a pretty nice feature to have, as I can very easily share private screenshots.
> Giving a foreign entity control over your data and key is not "privately".
Yeah, if you have this concern strongly, well, we're working on browser extensions which will prevent any potential risk here. However, like I said to someone else, unless you reverse engineer every update to your OS, you really shouldn't be commenting. This is just as much "giving a foreign entity control over your data" as using an OS provided in binary form is giving a foreign entity control over your CPU, which would be far, far worse really. Unless you're manually validating the code in all cryptography products you use, there's really no argument to be made here.
> Encrypt the image with the public key of your friends and send it to them, that is privately.
When you do this, say using PGP, PGP generates a static key, encrypts that key to their public key and encrypts the message using the static key.
This is essentially the same thing, the only difference being that the Up1 does only the static key portion and does not provide the public key portion, which you can do out of band using whatever method you prefer, be it PGP, SSL to a private server, OTR, TextSecure, etc.
And it allows the transfer of images and small files in this secure form to be incredibly simple and fast. Pipe into a command line tool or use ShareX, paste that link over a secured protocol and you've securely shared a file.
Of course, if you don't trust the public Up1 instance, feel free to run your own, it's all open source, server included.
> And, worse, I have to activate JavaScript, which decreases security by a lot.
It's a trade-off, privacy for a slightly increased risk of security, these days you're more likely to get exploited by a fucking web font than by a script though.
Worst case, like I said, don't trust the public instance if you don't want to (well, if you're the type who doesn't trust their OS provider at least). You can always run it yourself or wait for the browser extensions.
I’m the type that only runs arch because I can’t be bothered to run Gentoo ;)
Anyway, for posting on a public forum it’s pretty useless, as it provides no benefit and requires the users to have JS enabled, which is, especially on Hacker News, not really a given.
Even the mods complained when an up1.ca link was used as submission link recently.
Using a standard protocol would be an advantage here most definitely.
