141–150 of 285 posts
I've learned not to trust companies when they tout "completely encrypted" and "totally private". Show me the open source code, otherwise they're likely collecting data in some way to pay for hosting this web application.
It seems nice, but I think it should be made more explicit upon downloading, that you can only do that once. I can see myself e.g. downloading a file I received on my phone to take a quick look, intending to then download it again on my computer later. I would be surprised to see it just gone.
Earlier quoted context omitted.
Resilio Sync (formerly Bittorrent Sync) pretty much offers that. They use relays in case both peers cannot pierce NAT, but the relays only see ciphertext. They also have apps for Android and iOS, making transfers to mobile devices also possible. Since it is closed-source software, it's up to you to decide whether you trust the software. SyncThing is a free software alternative, but I wouldn't say that it is usable (y…
Instead of Resilio Sync, I would suggest that people take a look at Syncthing. They have similar features but Syncthing is open source.
Can anyone confirm whether this works in Safari/iOS now? It seemed great but when I tried to send some files to friends to promote it it completely shat the bed and my mobile friends ended up getting nothing but garbled text when the (fairly large) downloads finished. It was quite frustrating since the upload was painfully slow.
Earlier quoted context omitted.
> one has to trust Mozilla not to do that. Exactly. One has to trust Mozilla every time one visits the page . They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught? Web-page-based crypto is fundamentally insecure, and Mozilla is committing an extremely grave error in encouraging users to trust it (as they also do with their Firefox Accounts). Secur…
Send is meant to be an improvement on Dropbox & co for a specific use case. Is it perfect? No, it isn't. But it is still a considerable improvement. If you have a better solution in mind for the average user crowd, feel free to suggest it, of course.
When it's secure, it's an improvement; if Mozilla, a Mozilla employee or a government which can compel Mozilla employees chooses to make it insecure, then it's worse than insecure. At least with something like Dropbox users (should) know that they are insecure and should not transmit sensitive files.
> If you have a better solution in mind for the average user crowd, feel free to suggest it, of course.
The functionality should be built into Firefox, so that users can verify source code & protocols once and know that they are secure thereafter.
Earlier quoted context omitted.
When thinking about a Mozilla offering, it is healthy to think beyond "money and product" as this type of analysis will usually leave you with a conclusion of "this doesn't make business sense". Mozilla is in the game of keeping the internet healthy. Part of it involves products, such as Firefox and its quest to recover userbase. Parts of it involves money, such as MOSS awarding grants or prizes for FOSS stuff they u…
Not sure how true that is anymore. They seem to by trying hard to squander their reputation. First their MITI officially signaled they now consider themselves a political force, then the whole Cliqz debacle following shortly after showed their willingness to sacrifice their principles.
Earlier quoted context omitted.
> one has to trust Mozilla not to do that. Exactly. One has to trust Mozilla every time one visits the page . They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught? Web-page-based crypto is fundamentally insecure, and Mozilla is committing an extremely grave error in encouraging users to trust it (as they also do with their Firefox Accounts). Secur…
Send is meant to be an improvement on Dropbox & co for a specific use case. Is it perfect? No, it isn't. But it is still a considerable improvement. If you have a better solution in mind for the average user crowd, feel free to suggest it, of course.
As a show of nothing-up-the-sleeve, a service asserts that it's in a stable state and will continue to serve exact copies of the resources as they exist now—that they will not change out from beneath the client in subsequent requests. When a user chooses to use resource pinning, the browser checks that this is true, and if finding a new deployment has occurred, the browser will refuse to accept it without deliberate consent and action from the user (something on par with invalid cert screen).
This means that for a subset of services (those whose business logic can run primarily on the client side), the users need not trust the server, they need only to trust the app, which can be audited.
When deploying updated resources, services SHOULD make the update well-advertised and accompany it with some notice out of band (such as a post about the new "release", its changelog, and a link to the repo), so the new deployment may be audited.
When new deployments occur, clients SHOULD allow the user to opt for continuing to using the pinned resources, and services SHOULD be implemented in such a way that this is handled gracefully. This gives the user continuity of access while the user (or their org) is carrying out the audit process.
Areas where this would be useful:
- HIPAA compliance
- Web crypto that isn't fundamentally broken
- Stronger guarantees for non-local resources used in Web Extensions—in fact, the entire extension update mechanism could probably be more or less rebased on top of the resource pinning policy
I wonder how many downloads can be done before it expires