Using Tor browser for Android, one cannot download a '.asc' file by long-pressing it. The signature instead loads in a browser window. No helpful.
This might be the behaviour for Firefox but I expect better from Tor Browser frankly. In my experience copying ascii pgp from the browser introduces newline characters that break the signature.
Is there a temporary workaround for this in a config file? I would prefer the default behaviour for this text file to be "Save" but Save is not even an option.
Trac: Username: torlove
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
I am not convinced we should change the default behavior for text files. Where did you copy the contents of the .asc file to? Does this happen if you copy the contents from a clean vanilla Fennec as well? Maybe that's a general bug Mozilla fixed meanwhile?
Trac: Status: new to needs_information Keywords: N/Adeleted, tbb-mobile added Component: - Select a component to Applications/Tor Browser Owner: N/Ato tbb-team
In my request I'm asking for the option to "Save" on long-press. It's relatively common today for people to long-press a link in order to download it.
The side request is asking whether there is a way to change the default behaviour for myself only, by editing a config file.
This problem of mismatching newline characters has happened to me. It is an arduous thing to fix on a small device, as one must manually remove the new lines and then re-input them in the text editor. Very error prone. Thankfully this did not happen on this occasion, however regardless of whether that happens or not, the user need to copy and paste the signature into a new text file, and then save that file to the correct folder, etc. Suboptimal.
Is there a security reason for ascii (incl. PGP signature) files to not be savable? By their very purpose they should be savable/downloadable by long-press. Any errors or problems in that process could easily be relayed to the user, hence aborting the download.
In my request I'm asking for the option to "Save" on long-press. It's relatively common today for people to long-press a link in order to download it.
Sounds reasonable to me. Again, what is Fennec doing here?
The side request is asking whether there is a way to change the default behaviour for myself only, by editing a config file.
Not sure.
This problem of mismatching newline characters has happened to me. It is an arduous thing to fix on a small device, as one must manually remove the new lines and then re-input them in the text editor. Very error prone. Thankfully this did not happen on this occasion, however regardless of whether that happens or not, the user need to copy and paste the signature into a new text file, and then save that file to the correct folder, etc. Suboptimal.
Agreed.
Is there a security reason for ascii (incl. PGP signature) files to not be savable? By their very purpose they should be savable/downloadable by long-press. Any errors or problems in that process could easily be relayed to the user, hence aborting the download.
No, there is no security reason for that AFAICT. And it might even be fixed in latest Fennec versions which would allow us to backport a patch maybe. So, again, could you try to figure out whether that experience is better for you?
This is a bug in Fennec. Fennec does not provide an option for downloading/saving files. It only provides this for images. As far as I know, for every other html element type (simple links), it begins downloading the file and then the app 1) checks if it can handle the file itself (like text files), 2) checks if another app on the device can handle it (like pdfs), and 3) simply downloads the file.
Thanks for above responses. It's not good behaviour. It doesn't make sense and makes Fennec, and by extension Tor, less user friendly.
It looks like the may be garnering attention. In comment 9, literally a day after your response, sysrqb, Diana asks the person to create a new ticket for a .conf file:
https://bugzilla.mozilla.org/show_bug.cgi?id=1546274#c9
I have tried searching the bugtracker by the bug reporters name, "Dan Jacobson", but its not coming up with any results. Can someone please help confirm whether Dan has indeed opened a bug report for specifically downloading text files?
Even though one is to do with how the browser handles the files and the other one is about how we serve the files, I wonder if #31295 (moved) is related to this also...
At what point is it parsed, would it be parsed by the Firefox (and by extension the Tor Browser) and so therefore cause a vulnerability in the browser. Is there a method of parsing a '.asc' file without introducing a '.asc' vulnerabilty?
If this is an issue then it needs to be solved upstream as a matter of some urgency, yes?
Using a '.asc' file is supposed to be far more secure that a non ascii-armoured file, because the character space is far more limited, and thus we should be able to ensure that remote code cannot be delivered and excuted. I'm not an expert in this field and how to specifically deal with buffer overruns and such, but surely, any and all file type downloads need to account for this vulnerability, not just text files (or in this specific case, '.asc' files).
Even though one is to do with how the browser handles the files and the other one is about how we serve the files, I wonder if #31295 (moved) is related to this also...
Yes, I agree #31295 (moved) is the correct bug here. Thanks for noticing that!
Thanks for above responses. It's not good behaviour. It doesn't make sense and makes Fennec, and by extension Tor, less user friendly.
I agree this is not user friendly, unfortunately I highly doubt this will be fixed in Fennec. If there is any hope of fixing this in Firefox on Android then we should look at Firefox Preview (Fenix) and advocate for this functionality there.
I'm going to close this as wontfix because we'll be migrating to Fenix in the near future, and implementing this in the current browser will require significant time which won't yield much benefit. We can look at this again in the future if Fenix doesn't provide a good experience - but #31295 (moved) should solve this for torproject.org signatures, at least.
Trac: Status: needs_information to closed Resolution: N/Ato wontfix