411–420 of 542 posts
Earlier quoted context omitted.
Is there a cheaper S3 alternative that you recommend or that Mozilla's likely using instead?
I think Backblaze's cloud storage is the cheapest I've seen. Microsoft and Google would also be a bit cheaper than S3
https://www.backblaze.com/blog/backblaze-and-cloudflare-part...
In one of their videos, the URL is www.send.firefox.com - the others drop the www - is this intentional, a mistake? Why would someone use www before a sub domain like that?
Earlier quoted context omitted.
This seems to be a known bug if you have used the old version of send in your profile that may be fixed now. If you try it in a private browsing window and it works, it's probably that bug.
Sure enough -- it works in a private window. Is there a known fix for this, or do I need to create a new profile?
Earlier quoted context omitted.
Glad you like it (I worked on it). Just a side note, the cloud service will be going away in the future, but the ability to save it locally will remain.
Replacing the cloud bits with Firefox Send integration seems a fairly obvious idea then?
Earlier quoted context omitted.
The conspiracy theorist in me wonders if Google simply wants to maximize the use of their servers here (independent of what users want/need): 1. P2P doesn’t give Google all that juicy mineable data that they get when everything you do makes round trips through their servers. 2. This would also implicitly encourage Android users to rely more on services like Google Drive/Docs for all files, which is good for them. Edi…
In addition to NUMEROUS 3rd party tools, Google already provides a tool exactly like AirDrop for Android. It's a feature of the Files app https://play.google.com/store/apps/details?id=com.google.and... which has over 100M installs. Look at the 3rd screenshot. ENCRYPTED FILE SHARING Files’s offline file sharing is secured with WPA2 encryption, providing a more secure file transfer. Files app uses Bluetooth to set up e…
Earlier quoted context omitted.
Do you ever run into a problem when an overzealous email service or virus scanner pre-fetches the link and invalidates it before an actual person clicks on it? This used to happen with all sorts of links in emails, though I haven't heard about it in a while.
To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it…
I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.
Earlier quoted context omitted.
I don't disagree. I've been thinking about how I would write the announcement copy explaining to non-technical users how the links should also be treated as secret and how email is not encrypted in general. It's a hard problem.
I think it's relatively intuitive for lay users that the links are secret. If you give someone the link, they get the file. What's not obvious about that? If anything it's probably harder to understand for a somewhat semi-technical person who probably has started to think about encryption and so on but hasn't got far enough to spot that oh - the secret key is in the URL itself as an anchor and so the URL is the secre…
Earlier quoted context omitted.
Their Github page specifically mentions AWS S3 as a requirement. So they are using it.
It mentions "AWS S3 or compatible service ". The S3 API is a de facto standard for object storage services, and there are numerous implementations of it.
/#" rel="nofollow">http://send.firefox.com/download//#
Anyone who obtains the link (e.g. via email interception) gains access to the file.
Since browsers don't transmit the anchor when requesting a resource [1], Firefox servers never see a copy of the key. Provided you trust their JavaScript.
[1] https://stackoverflow.com/questions/3067491/is-the-anchor-pa...
In the not so recent past, HN'ers loved to quote tptacek's legendary rant about how in-browser JavaScript crypto is fundamentally broken[0]. What changed? Is that rant finally outdated? Couldn't Mozilla at any time serve a corrupted JS bundle (with or without their knowledge) which would leak the key somewhere, silently replace the encryption by a noop, etc? I ask out of interest, not skepticism. I much prefer an int…
Some of those points are relevant and some aren't. For logging in to a website, "just use SSL/TLS instead" makes sense, but not for this use case. There's better options nowadays for doing crypto in the browser, but I wouldn't be surprised if they were at least theoretically vulnerable to side channel attacks from JS running in another tab. The main thing is that unless you're paying really really close attention to…