[tor-bugs] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#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