Opened 15 months ago

Last modified 8 months ago

#23474 new enhancement

Avoid constant initial download delays in download schedules

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: fingerprint-resistance, tor-client, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description

When a download schedule has a non-zero initial delay, the delay is used as-is. We use this to delay the initial authority consensus download (so fallbacks get used), and bridge descriptor re-downloads.

But these constant delays produce an obvious traffic pattern, so we should work out how to randomise them. Using a random value from [delay/2, delay*3/2] would be a good start.

Child Tickets

Change History (4)

comment:1 Changed 10 months ago by nickm

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

Label a bunch of (arguable and definite) enhancements as enhancements for 0.3.4.

comment:2 Changed 9 months ago by nickm

Keywords: 034-triage-20180328 added

comment:3 Changed 9 months ago by nickm

Keywords: 034-removed-20180328 added

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

comment:4 Changed 8 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.