Opened 9 years ago

Closed 7 months ago

#2149 closed enhancement (implemented)

new 'extra dormant' mode for people who never use their tor

Reported by: arma Owned by: angelo620
Priority: Very High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: performance, scaling, tor-client, SponsorU-deferred, sponsor4, sponsor8-maybe, 034-triage-20180328, 035-removed-20180711
Cc: Actual Points:
Parent ID: #28335 Points: large
Reviewer: Sponsor: Sponsor8-can

Description

If you stop using your Tor as a client (and it doesn't have dirport or orport open), after an hour you'll stop fetching descriptors, but you'll continue to fetch consensuses.

Periodically we hear plans like http://wiki.debian.org/FreedomBox/DesignAndToDos that will involve installing Tor on things by default.

We should teach Tor that if a lot of time passes (e.g. 24 hours), it should stop fetching consensuses also. It should also remember in its state file that it's doing so, so the dormancy survives across reboots.

Child Tickets

Change History (77)

comment:1 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:2 Changed 8 years ago by arma

Priority: normalmajor

We're going to wish we had this feature in whatever version people pick for deployment. So best to get it in pretty soon.

comment:3 Changed 8 years ago by arma

Keywords: performance scaling added

comment:4 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

comment:5 Changed 7 years ago by sysrqb

(I apologize, in advance, if I missed any past discussions relating to this
topic while I was researching it.)

Memory Across Boot:

We can make a one-off addition to the values stored in the state file
by adding another field called ExtraDormantState that will store
either the timestamp of the last wakeup or a bit field* indicating
that the client should resume in a dormant state. I'm not sure which
value will be more useful. The presence, or lack of, a value (whether
as a timestamp or a bitfield > 0) can indicate the dormant state,
but with the timestamp we'll know approximately the last time the client
was used. This way we have the option of behaving differently depending
on the last time it was used. Should the client still remain in a dormant
state if it was last used a month ago (or more)? On the other hand, the
bit field can have a bit for the dormant state and another for an
"extra dormant" state. Is there any additional information for which we
might want a flag?

*The further I got into writing this and the more I thought about using
it as a bitfield, the less it made sense, but I'll still leave it as an
option for discussion.

Internal Storage:

Following from the above, internally ExtraDormantState can be appended
to or_state_t as time_t and be use for the timestamp and a bitfield,
depending on what we decide.

With that being said, it's probably easiest to leave the mutation of this
value in the file to run_scheduled_events. I assume config dump will need
to be adjusted to support this new value.

Enter Extra Dormant Mode:

1) Setting ExtraDormantState:

After a lot of (misguided) backtracing, and with some help from
nickm et al., I realized this shouldn't require much additional
overhead. I think we can piggyback on the functions that are already
used to check if the client is currently dormant if we modify
directory_too_idle_to_fetch_descriptors so that the logical AND
determines the value of ExtraDormantState. The first time
directory_too_idle_to_fetch_descriptors is called and the ANDing
is != 0, we check the current value of ExtraDormantState
(which should be 0) and set it to the current time(NULL) and the
function will return true. All subsequent calls to the function
will test if ExtraDormantState was set longer than 1 day ago.
Unless this is true, the function simply returns true. Once this
condition is true, depending on what we want to do with it,
ExtraDormantState can either remain a time value or become a bitfield.
directory_too_idle_to_fetch_descriptors will continue to return the
correct value.

2) Stop Fetching Consensus:

To transition the process of fetching a new consensus into a dormant
state, as far as I can tell we can simply call
update_consensus_networkstatus_fetch_time with a parameter of a future
time, be it a day in the future or more. This will prevent the client
from downloading a consensus until after the specified time. Let me
know if there is another path that I missed that will still successfully
fetch updates.

Exit Dormant Mode:

If ExtraDormantState is set but the condition in
directory_too_idle_to_fetch_descriptors fails, then unset ExtraDormantState
and set each index of time_to_download_next_consensus to the current time.

Reenter (Extra) Dormant State After Reboot:

When options_act is called and the config is reloaded we can call
update_consensus_networkstatus_fetch_time as above hibernate_go_dormant
which will ensure any circuits that have been built will be destroyed. I'm
not sure the latter call is necessary, though, depending on where in
options_act we check if ExtraDormantState has a value.

All feedback is welcome. If you think of a better name than ExtraDormantState,
I'm all ears.

comment:6 Changed 7 years ago by arma

Early thoughts:

  • We can probably just call it 'Dormant' in the state file. There isn't any other 'dormant' notion there to confuse it with.
  • If we put a timestamp of when Tor was last used in the state file, there are privacy concerns. So we should only do that if we have a specific use in mind for it. Otherwise I'd suggest we just make it a boolean ("Dormant 1" or not).
  • That said, when we're not currently dormant, we'll need to track in memory a timestamp of when we last did something, so we can notice when it gets sufficiently long ago.

We'll need to define what exactly counts as "something". One thought is a static time_t near directory_too_idle_to_fetch_descriptors() that remembers the timestamp of when we last transitioned from returning 0 to returning 1, and gets zeroed whenever it returns 0.

Then directory_too_idle_to_fetch_consensuses() would return true if directory_too_idle_to_fetch_descriptors() is true and (that timestamp is far enough in the past or state->dormant is 1). And whenever it returns, it also modifies state->dormant as needed (and when it does, it triggers an or_state_mark_dirty() call).

Then when we read the state file on startup, and state->dormant is 1, so long as directory_too_idle_to_fetch_descriptors() is never false, directory_too_idle_to_fetch_consensuses() will return true.

Which means during the startup process, we'll need to check whether state->dormant to decide whether predicted_ports_init() should call add_predicted_port().

That still leaves "what parts of the directory fetching code should check directory_too_idle_to_fetch_consensuses() before doing their fetch". See how we use options->DisableNetwork. But also see how we use should_delay_dir_fetches(). I'm not sure yet which approach makes more sense here.

comment:7 Changed 7 years ago by nickm

Looks like arma beat me to this one. Some more thoughts:

Agreed on the name. "ExtraDormant" or "Dormant" would make more sense: there's not need to name a state variable for having state.

Messing with update_consensus_networkstatus_fetch_time and putting it into the future seems like a kludge: it would probably be better to have a flag that just does what we mean. In this case and in others, it's best to make sure that function and variable names say what they do.

We'll want to make sure we exit extra-dormant mode immediately when we get any kind of client activity (like a SOCKSPort request, for instance).

comment:8 Changed 7 years ago by arma

Complication: if we just store a bit in the state file, and the Tor client instance never runs continuously for 24 hours (or whatever our cutoff is), then we'll never conclude that we're dormant -- every time we start we'll build some circuits, and count those as activity.

We could fix it by putting a timestamp in the state file if we're not dormant but we're getting there, and then not counting the call to add_predicted_port that we do in predicted_ports_init on startup. That starts to get quite messy though.

comment:9 in reply to:  8 Changed 7 years ago by sysrqb

Replying to arma:

We could fix it by putting a timestamp in the state file if we're not dormant but we're getting there, and then not counting the call to add_predicted_port that we do in predicted_ports_init on startup. That starts to get quite messy though.

Wouldn't this still introduce a privacy concern? Instead of a timestamp, perhaps use different stages?

0: No dormant
1: Dormant for at least 4 hours
2: Dormant for at least 8 hours
3: Dormant for at least 12 hours
...


Where we pick up where we left off? Or maybe just have the value itself incrementally count how many hours have passed and update, if necessary, every time dormancy is checked.

comment:10 Changed 7 years ago by sysrqb

I finally finished a prelim patch for this. It can be pulled from branch bug2149 on [http|git]:gitweb.evolvesoftware.cc/tor.git

I used the staged idea, mentioned above, in order to steer clear of storing timestamps. Obviously this won't be as accurate, and if the client is completely unstable and is never alive for longer than the stage size (two hours right now) then the client will never go dormant. We can always decrease the stage size to a smaller period.

I added a catch in conn_read_callback that checks if the client is currently dormant; if it is, then it pulls updated descriptors/network status before proceeding to handle the new connection.

While the client is dormant, I mostly ANDed the checks for options->DisableNetwork with directory_too_idle_to_fetch_consensuses throughout second_elapsed_callback and run_scheduled_events (with a few additions). Are there other ways that the consensus can be pulled that bypasses the callback?

Thanks for any feedback!

comment:11 Changed 7 years ago by arma

Status: newneeds_review

comment:12 Changed 7 years ago by nickm

That URL doesn't seem to be working for me. Can you put it back up, or post a patch (or patch series) here?

Changed 7 years ago by sysrqb

Changed 7 years ago by sysrqb

comment:13 Changed 7 years ago by sysrqb

Apologies for the dns issues, hopefully they'll be resolved soon. For the attached, both patch #5's are the same (clicked through them too fast).

I don't have any unit tests yet either, so any tips on how/where to get started on them would also be appreciated.

comment:14 Changed 7 years ago by nickm

Status: needs_reviewneeds_revision

Thanks for the code! Just pulled the branch -- The "Using wrong idle checker" patch doesn't seem to be there yet?

Quick review:

  • IDLE_TIME_STAGE isn't used.
  • stopped_fetching_descriptors isn't documented.
  • needs a changelog entry in the changes directory.
  • or_options_t is for stuff parsed from torrc and the command line -- it isn't a catch-all for persistent state. That would be or_state_t. Making this change will also let you back out lots of the get_options_mutable() calls, which ought to be a red flag.
  • I don't see the point of having DormantStage be global: why can't it be a local variable in directory_too_idle_to_fetch_descriptors() ?
  • I don't understand the logic of the changes in conn_read_callback and do_main_loop. In any case, it feels like "directory_info_has_arrived()" might be the wrong function to be calling here -- after all, you are calling it *not* in response to directory info arriving.[*]
  • The comment on 59c8df8b59bf04f25 seems wrong; conn_read_callback isn't the function that gets called on "an incoming connection" -- it gets called every time any socket is readable. If you want to have something happen on incoming connections, that would belong in connection_handle_listener_read, I think.

[*] Functions should be called as documented, and not because they have some desirable side-effect. Let's say there is a function called computer_is_on_fire() that floods the server room with carbon dioxide. It is IMO wrong to call computer_is_on_fire() when the computer is not on fire. If we sometimes want to flood the server room with CO2 when there is no fire, then we should make an flood_server_room() function. That makes our code more maintainable and less confusing.

comment:15 in reply to:  14 Changed 7 years ago by sysrqb

Replying to nickm:

Thanks for the code! Just pulled the branch -- The "Using wrong idle checker" patch doesn't seem to be there yet?

That's odd. I'll take a look.

Quick review:

  • IDLE_TIME_STAGE isn't used.

I forgot to remove this, fixed.

  • stopped_fetching_descriptors isn't documented.

Missed that. Fixed.

  • needs a changelog entry in the changes directory.

I added one in Using-wrong-idle-checker commit, I wasn't really sure what to say, so it'll probably be revised.

  • or_options_t is for stuff parsed from torrc and the command line -- it isn't a catch-all for persistent state. That would be or_state_t. Making this change will also let you back out lots of the get_options_mutable() calls, which ought to be a red flag.

Ah! That makes more sense. I'll make the necessary changes.

  • I don't see the point of having DormantStage be global: why can't it be a local variable in directory_too_idle_to_fetch_descriptors() ?

This relates to arma's comment about clients that are consistently idle but they don't run continuously for the entire "IDLE_TIME_BEFORE_DORMANT" time period. My thinking was that if we add it to the state file then when the client starts again it won't necessarily start from time=0. It really shouldn't be global, but it needs to be set when the state file is read and I wasn't sure how else to accomplish this.

  • I don't understand the logic of the changes in conn_read_callback and do_main_loop. In any case, it feels like "directory_info_has_arrived()" might be the wrong function to be calling here -- after all, you are calling it *not* in response to directory info arriving.[*]

a) Ok, I misunderstood conn_read_callback's use. I'll move the changes.

b) I seem to have created a bit of duplicate code, I'll fix that. But what I was actually trying to do is check that the client is not idle and if it is then not call directory_info_has_arrived because it potentially downloads new descriptors and such. I toyed with skipping the reload of the saved networkstatuses and consensus but decided against it. On rethinking this, if we don't call directory_info_has_arrived there's not much reason to load the cached info.

c) I agree. Bad habit. I mostly wanted to make sure I was on the correct track with this patch.

  • The comment on 59c8df8b59bf04f25 seems wrong; conn_read_callback isn't the function that gets called on "an incoming connection" -- it gets called every time any socket is readable. If you want to have something happen on incoming connections, that would belong in connection_handle_listener_read, I think.

Same as a) above. I did a lot of manual backtracing and I guess I got a little confused along the way.

[*] Functions should be called as documented, and not because they have some desirable side-effect. Let's say there is a function called computer_is_on_fire() that floods the server room with carbon dioxide. It is IMO wrong to call computer_is_on_fire() when the computer is not on fire. If we sometimes want to flood the server room with CO2 when there is no fire, then we should make an flood_server_room() function. That makes our code more maintainable and less confusing.

Thanks for the feedback

comment:16 Changed 7 years ago by sysrqb

Status: needs_revisionneeds_review

Ok, so I ended up revising/rewriting the majority of the original code (and simplifying a bit).

The place I'm not sure about the implementation is in do_main_loop. If we start up dormant then we don't know how old the cached statuses are. Because of this, I skip over loading the cache files until we have a new connection, at that point the current implementation will handle the outdated information as needed. Thoughts?

The new code can be pulled from bug2149-3 http://gitweb.evolvesoftware.cc/tor.git and I'll attach a patch in case there are still problems, also.

Changed 7 years ago by sysrqb

Newest revision

comment:17 Changed 7 years ago by nickm

Keywords: tor-client added

comment:18 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:19 Changed 7 years ago by sysrqb

I finally had a chance to get back to this..sorry it took so long.

There were a lot of things I missed earlier, but this patch seems to work. I've been running a client for the past day off and on and it transitions between the states correctly, thus far. I also decreased the timeout from 1 day to 2 hours so I didn't have to wait so long.

This patch is in bug2149-rebased on git://gitweb.evolvesoftware.cc/tor.git and I'll attach it, too.

A few questions that I have:

1) I have a log at notice for when the client transitions, should this be removed due to privacy concerns because it gives a specific date/time this state was entered?

2) The main implementation is in directory_too_idle_to_fetch_descriptors and directory_too_idle_to_fetch_consensuses, but the dormant state is only for clients. Should these functions be moved out of dirserv and placed somewhere else?

3) This implementation still uses a staged progression towards entering dormancy. Will this have subsequent privacy related side-affects that should be accounted for?

For arma's last point

Which means during the startup process, we'll need to check whether state->dormant to decide whether predicted_ports_init() should call add_predicted_port().

If we wait to call predicted_ports_init after we parse the state file then we end up asserting when we parse the bandwidth history data. As a workaround, after rep_hist_load_state is called all the predicted ports are removed which then retains the dormant state. Is this too much of a hack?

comment:20 Changed 6 years ago by sysrqb

I forgot I hadn't committed/posted my new patch. I rewrote a lot of it but I kept a lot of the ideas.

Overview:

  • After client is idle for 25 hours (1 hour for predicted ports to timeout, 24 hours from that point until dormant), stop fetching the new consensus.
  • During the 24 hour period, mark a "stage" as completed in the state file every 2 hours. If the client is restarted, it will pick-up from this stage after it passes the 1 hour predicted ports timeout period again.
  • Once dormant, the client remains dormant until the user requests a new connection
  • If the client is dormant and restarted, it pauses bootstrapping at "81%" (prior to creating a circuit). Once a user-initiated connection is received, a new consensus is fetched and the connection is handled normally.

Note, this patch is better about not launching predicted ports if the client is dormant when it starts but makes predicted_port_init() global.

Some of the above questions remain:

  • Should these functions really be in dirserv.*? They're functions of the client, not dir server.
  • Thoughts on using stages?

In bug2149_redone_1_rebased on git://gitweb.evolvesoftware.cc/tor.git and attached.

Changed 6 years ago by sysrqb

As above

comment:21 Changed 6 years ago by nickm

Status: needs_reviewneeds_revision

I've started a feature2149 branch in my public repo based on that branch, and started to fix some issues there . Some more mostly cosmetic things I'd like to fix before merging, based on a conversation with andrea:

  • exporting get_connections() to dirserv.c is a bit silly
  • We should make sure that new DNS requests count as client activity
  • We need to call or_mark_state_dirty when clearing Dormant and DormantStage as well
  • The interval needed to become dormant should be configurable, for testing if nothing else.
  • We should make sure that hidden services can never go dormant, and that adding a hidden service makes a node non-dormant.
  • We should be consistent about invoking directory_too_idle_to_fetch_consensuses() versus testing Dormant directly.
  • I also wonder if putting this "CONN_PAUSED" business at the 81%-bootstrapped level is right. It seems that after that, it's likely to go and immediately fetch the consensus, so maybe it should be less bootstrapped than if we'd fetched no consensus

comment:22 in reply to:  21 ; Changed 6 years ago by sysrqb

Status: needs_revisionneeds_information

Thanks to both of you for the review. (I'm sorry this ticket is such a mess)

Replying to nickm:

I've started a feature2149 branch in my public repo based on that branch, and started to fix some issues there . Some more mostly cosmetic things I'd like to fix before merging, based on a conversation with andrea:

  • exporting get_connections() to dirserv.c is a bit silly

(Assuming get_connection_array()) I was using that for debugging, we don't need to say how many open circuits we have when we go dormant.

  • We should make sure that new DNS requests count as client activity

I don't think this currently does. It looks like we need to catch requests in dnsserv.c:evdns_server_callback(), i think?

  • We need to call or_mark_state_dirty when clearing Dormant and DormantStage as well

Looks like I missed that.

  • The interval needed to become dormant should be configurable, for testing if nothing else.

Yeah, I was doing this by hand. Torrc option AllowEnterDormancy? Values > 0 define time period the client must be inactive, 0 disables this feature?

  • We should make sure that hidden services can never go dormant, and that adding a hidden service makes a node non-dormant.

I was relying on server_mode() to determine if Tor was an OP or OR. TBH I didn't check if it considered Hidden Services. I just took a look and I gathered that we can check that rend_service_list == NULL, is there a better way to do it?

  • We should be consistent about invoking directory_too_idle_to_fetch_consensuses() versus testing Dormant directly.

I'm having trouble remembering the specific case for this. It had to do with a variable not be initialized until later in bootstrapping but either I can't find it now or I missed something before.

  • I also wonder if putting this "CONN_PAUSED" business at the 81%-bootstrapped level is right. It seems that after that, it's likely to go and immediately fetch the consensus, so maybe it should be less bootstrapped than if we'd fetched no consensus

This was actually purely a guess, the percentage/location were chosen only for the sake of simplicity. I'll look into finding a more appropriate place.

Marking Needs Info due to questions about catching DNS requests, checking for hidden services, and torrc option.

Thanks again. I'll base any patches on your branch.

comment:23 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

Bumping this to 0.2.5 for scheduling issues.

comment:24 in reply to:  22 Changed 6 years ago by nickm

Status: needs_informationneeds_revision

Replying to sysrqb:

Thanks to both of you for the review. (I'm sorry this ticket is such a mess)

Replying to nickm:

[...]

  • We should make sure that new DNS requests count as client activity

I don't think this currently does. It looks like we need to catch requests in dnsserv.c:evdns_server_callback(), i think?

That seems right.

  • The interval needed to become dormant should be configurable, for testing if nothing else.

Yeah, I was doing this by hand. Torrc option AllowEnterDormancy? Values > 0 define time period the client must be inactive, 0 disables this feature?

Sounds good. How about calling it BecomeDormantAfter ?

  • We should make sure that hidden services can never go dormant, and that adding a hidden service makes a node non-dormant.

I was relying on server_mode() to determine if Tor was an OP or OR. TBH I didn't check if it considered Hidden Services. I just took a look and I gathered that we can check that rend_service_list == NULL, is there a better way to do it?

Calling num_rend_services() is one way; I don't know if there's a better one.

  • We should be consistent about invoking directory_too_idle_to_fetch_consensuses() versus testing Dormant directly.

I'm having trouble remembering the specific case for this. It had to do with a variable not be initialized until later in bootstrapping but either I can't find it now or I missed something before.

Okay; let's try to figure out what's going on here.

(I tried to skip over issues where there were no questions; please let me know if I missed something important)

comment:25 Changed 6 years ago by hsn

Why is this problem? directory service is using only tiny fraction of relay bandwidth.

comment:26 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

Moving nearly all needs_revision tickets into 0.2.6, as now untimely for 0.2.5.

comment:27 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

We should merge this once the revisions are done, but we don't need to block a release on it.

comment:28 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

These might also be worth looking at in 0.2.7

comment:29 Changed 4 years ago by nickm

Keywords: 027-triaged-1-deferrable added

Marking tickets as deferrable from 0.2.7 triage round-1

comment:30 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: large
Priority: majornormal
Version: Tor: 0.2.7

comment:31 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:32 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:33 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:34 Changed 4 years ago by nickm

Keywords: pre028-patch added

comment:35 Changed 4 years ago by nickm

Severity: Normal

Reviewing this code: we have a great deal of this mechanism built already in net_is_disabled(), options->DisableNetwork, and we_are_hibernating(). We should probably combine all of those into a logical setup somehow and then take the part of this that checks for disabled-ness.

comment:36 Changed 4 years ago by nickm

Created #17543 to track the clean-up work related to this problem.

comment:37 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

It is impossible that we will fix all 188 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "needs_revision" tickets, looking for things to move to 0.2.9.

Note that if the requested revisions happen in advance of the 0.2.8 freeze, they can get considered for 0.2.8.

comment:38 Changed 3 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:39 Changed 3 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:40 Changed 3 years ago by nickm

Keywords: SponsorU-deferred added
Sponsor: SponsorU-can

Remove the SponsorU status from these items, which we already decided to defer from 0.2.9. add the SponsorU-deferred tag instead in case we ever want to remember which ones these were.

comment:41 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:42 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:43 Changed 2 years ago by nickm

Keywords: sponsor4 added

comment:44 Changed 2 years ago by nickm

Sponsor: Sponsor4

Setting "sponsor4" sponsor on all tickets that have the sponsor4 keyword, but have no sponsor set.

comment:45 Changed 2 years ago by nickm

Priority: MediumVery High

comment:46 Changed 2 years ago by angelo620

Owner: set to angelo620
Status: needs_revisionaccepted

comment:47 Changed 2 years ago by nickm

Remove Sponsor4 keyword, now that Sponsor4 is the value of the Sponsor field.

comment:48 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:49 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:50 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:51 Changed 2 years ago by nickm

Keywords: 027-triaged-1-deferrable removed

comment:52 Changed 2 years ago by nickm

Keywords: 028-triaged removed

comment:53 Changed 2 years ago by nickm

Keywords: pre028-patch removed

comment:54 Changed 2 years ago by nickm

Keywords: sponsor8-maybe added

comment:55 Changed 2 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Sponsor: Sponsor4Sponsor8-can

comment:56 Changed 22 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final
Status: acceptednew

comment:57 Changed 17 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Deferring various "new"-status enhancement tickets to 0.3.4

comment:58 Changed 15 months ago by nickm

Keywords: 034-triage-20180328 added

comment:59 Changed 15 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:60 Changed 15 months ago by nickm

Keywords: 034-removed-20180328 removed
Parent ID: #25500

comment:61 Changed 14 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: 0.3.5.x-final

These are still worth doing, but I don't see them as likely to happen before our freeze in 4 days, and nobody is currently assigned to them. Deferring them to 0.3.5

comment:62 Changed 12 months ago by nickm

Keywords: 035-removed-20180711 added
Milestone: Tor: 0.3.5.x-finalTor: unspecified

These tickets are being triaged out of 0.3.5. The ones marked "035-roadmap-proposed" may return.

comment:63 Changed 10 months ago by arma

Brave is on track to ship a Tor client with every Brave user, by default, so that the Tor client is ready and waiting if the Brave user happens to ask for private browsing mode and happens to ask for the Tor variant of it.

So some feature like the one in this ticket is sure going to start looking smart for us.

The exciting catch for the Brave scenario is that they actually want to start the Tor client preemptively, and have it on and warm, so the user experience when they first switch to using Tor is a good one. So for that case we're going to have to invent something smarter than "have your Tor go to sleep anyway", since they'll want to find a way to disable that, etc.

comment:64 Changed 8 months ago by dgoulet

Parent ID: #25500#28335

comment:65 Changed 7 months ago by nickm

Resolution: implemented
Status: newclosed

Implemented in parent.

Note: See TracTickets for help on using tickets.