#25773: Disable Speculative Connect and Download --------------------------------------+-------------------------- Reporter: sysrqb | Owner: tbb-team Type: defect | Status: new Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------------------+--------------------------
Comment (by sysrqb): Replying to [comment:4 gk]: > Replying to [ticket:25773 sysrqb]: > > As a follow up to #25770, it turns out Tor Browser actually begins (and sometimes completes) the download before the user can confirm they actually want the-thing. This manifests in #7449 and #11254 as the file being downloaded in /tmp (on Unix, or similar on other platforms) and then it is moved into the correct directory. > > I think there are two things that we need to keep separate: > > 1) The download starting early > 2) Using /tmp for saving parts of the download before it is finally transferred to the location it should be in. > > 2) Is a bug and you cited some tickets for it. I am not sure whether 1) is a bug, though: the users clicked on the resource indicating that they want to have it, no? I agree this isn't strictly a bug, but I classify this as a Firefox feature that we don't want. I understand why Firefox begins downloading the file when a user clicks on the link/button. However, if a users opens the context menu of a link and selects "Save Link As...", then I do not believe users expect Firefox begins downloading the file until they select the destination directory/filename and click "Save". The issue with saving files in /tmp is a complete mess, and after reading that moz bug I don't know what we should do when a user clicks a link and Firefox cannot handle it internally (opening a pdf using pdfjs, show a plaintext file directly, etc). We should leave this question for the other open /tmp tickets. Replying to [comment:5 gk]: > Or maybe there is even a third thing involved: 3) The external helper app dialog is implying the download has not started yet while it indeed has (see: comment:2:ticket:18587). So, I agree with that one being confusing and we should come up with a better wording for what is happening. Historically, it has been a pain getting the message on that dialog right but I bet we can improve it further. I originally thought this was worse because the downloading begins before the "External App Blocker" is shown, but after I thought about this more I didn't think the timing makes a difference. That warning/popup is specifically about opening the file, it doesn't say anything about downloading. Considering previous pain related to this, I expect showing the message earlier will not be easy. Replying to [comment:6 gk]: > One final remark for now: "speculative connections" you mentioned here have nothing to do with "speculative connections" mentioned in our design doc (see: "20. Speculative and prefetched connections" https://www.torproject.org/projects/torbrowser/design/#identifier- linkability), just to avoid confusion of terminology. For the former, see: https://bugzilla.mozilla.org/show_bug.cgi?id=729133. Oh, interesting, I didn't remember this section. Indeed, these are two different features, but maybe they should be treated the same (do not open speculative connections when a proxy is configured). (Thanks for clarifying that difference before anyone else became confused) Replying to [comment:7 gk]: > The final, final one now: see https://bugzilla.mozilla.org/show_bug.cgi?id=55690 for arguments why this got implemented the way it is. Right, Mozilla have a couple long bugs and reading them is painful - and they're filled with comments about modem lights blinking, T-DSL, and 500MB exceeding available memory. The reason I opened this bug is because Tor Browser should not begin downloading a file unless the user explicitly confirms they want the file downloaded and where they want it saved. If clicking "Save Link As..." starts any network transactions before the users clicks "Save" within the file-chooser dialog box, then Tor Browser should make this obvious. I believe Tor Browser should treat the two scenarios differently: 1) I click on the link and Firefox doesn't know what to do, so it asked me where to save the file 2) I click on "Save Link As..." and specify where I want the file saved (or I click cancel) Within scenario (1), Firefox cannot know what it should do without beginning the download. That's okay. With scenario (2), that is completely against what the user requested. This is almost certainly a Firefox bug, unfortunately it seems Firefox handles (1) and (2) using the same logic. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25773#comment:8> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs