[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs