gigaparsec
Joined 3 years ago
Joined 3 years ago
And then there's the problem of hitting an interstellar grain of sand at 0.5c.
- It wouldn't work with the photography features
- Normal HTTP downloads would be out of the question - you have to assemble blobs on the client, which, last I checked, doesn't play very well with large files on some browsers
- I'm not convinced that the current iteration of "password in the URL fragment" JS E2EE is the best solution
Questions I would ask to a proponent of full-JS E2EE: do you actually inspect the minified & bundled JS of your favorite E2EE web app to see if it's implementing encryption correctly? Is it using CBC mode with the same IV? Is it leaking the URL fragment? Are you sure the JS bundle won't change under you on the next request? Are you sure that when you email your link it's not being transferred over plaintext, nullifying the encryption in the first place?
I think that full-JS E2EE lulls users into a false sense of security for the sake of convenience.
That said, we're looking into implementing E2EE in a different way at some point in the future.
- Streaming downloads; you don't have to wait for the upload to finish
- Fast uploads; there's a mini benchmark in the background that picks the best upload location
- Verified upload integrity on each file chunk
- Photobooks
It looks like a cheap gaussian blur filter applied in post production and adds to the fakeness. This is probably due to the optics in some of the latest Red digital cameras, but it's still not convincing. Kinda like 48 vs 24 FPS.
That is quite deceptive.