![]() Is this really a web browser's job? Why does it feel like the default answer to every "Why can't I do X easily?" question is to make the browser do it? establish a direct connection between two web browsers and directly push files through I'm not sure if there's an equivalent in the Windows world. Of course, this assumes that the two devices can see each other via Bluetooth and I'm pretty sure the thing is partly mediated by iCloud. When it works, AirDrop between Apple devices seems like it does exactly what you describe. it seems like most of the time when I want to transfer a large file to someone (or to another one of my own devices), I just want to do it immediately and only once, so there's no need to upload it to a third, temporary location. However Microsoft's OneDrive and Apple's iCloud are inferior to Dropbox so a third party solution is still relevant. File syncing and sharing should be integrated into the operating system. In a way the success of Facebook is a reflection of the spammy, phishing/malware filled, and slow nature of email and difficulty making your own website if email continued to improve there wouldn't be demand for a modern solution. The MPAA/RIAA have deputized any websites that accepts user content as copyright police and demonize non-enterprise file hosting services. BitTorrent never became mainstream at the level of email but it did incentivize people to seed with the prospect of pirated content. Even simple to use Dropbox has not made a significant dent. If it's free there's little incentive for a company to spend the money developing the easy UI and marketing it to critical mass. Slow IPv6 deployment, middleboxes (firewalls, home CPEs) makes efficient p2p connections difficult. People will not setup or maintain a server, an always on PC is less reliable and has a slower uplink than data centers, and smartphones have limited data quotas, storage and batteries. Sharing very large files (hundreds of MB to multi-GB) is too costly for a free service. Whatever can hope to replace it must be as popular (network effect), as easy to use, and free. Check it out at - feedback welcome!Įmail attachments are the lowest common denominator despite the 25MB cap, occasional diversion into a spam folder, no sender authentication, no encryption, poor suitability of email clients and servers for bulk file transfers, etc. Luckily, non-browser clients can do whatever they like, so I wrote a Python client that's compatible with the server, but uses streaming POST and on-the-fly en/decryption to save memory. So, the current implementation just encrypts the entire file as one giant block, and then uploads it - placing the whole file in memory. WebSockets, but those are a lot more heavyweight and CPU-intensive (for the server) than simple POST requests. The client-side crypto has one other downside: there doesn't seem to be a standard way in JavaScript to stream a POST request yet. Worse, the file will be deleted, forcing you to ask your sender for another copy. It's also strange in that the key isn't checked in any way (even for sanity) before initiating a download, so if you mess up and leave it off (or corrupt some bits), you won't find out until the end of the download that you can't get the file. Of course, this might only be a concern for uploading known files, but it's still a bit of an infoleak. This is a little concerning for privacy while the filename is easy to disguise, hiding the SHA256 sum requires modifying the file in some way. The file metadata is transmitted as an X-File-Metadata header on upload, and includes the SHA256 hash of the original (unencrypted) file (as the "aad" parameter to the X-File-Metadata upload parameter). The protocol is a little bit strange, though. It uses client-side crypto (AES-128-GCM) to secure the file the key is in the fragment portion of the URL so it doesn't automatically hit the server (assuming you trust the server JS).
0 Comments
Leave a Reply. |