[tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for ephemeral services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
-------------------------------------------------+-------------------------
 Reporter:  twim                                 |          Owner:
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.2.???
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201609                              |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorR-can
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:20 twim]:
 > Replying to [comment:19 teor]:
 > > OK, can you test meek?
 > Sure.
 >
 > > Also, let's say we do set the delay to 3s:
 > > * how are you testing whether the descriptor has stabilised?
 > I look at the `is_dirty` dynamics. If it gets dirty after 3s then it is
 too low. For now it isn't.
 >
 > > * can you warn the user when the descriptor changes after this delay?
 (perhaps between delay and 2*delay?) That way, we'll get feedback if we've
 set the delay too low, and users will understand why their onion service
 is hard to reach. (This might not be possible or easy - if not, that's ok.
 I am also happy to help you write the patch if I know how you're testing
 it.)
 >
 > The user can be warned by a log message (easy) or by introducing a
 control event which is emitted when descriptor gets dirty after it was
 published (more code, bit complicated).

 A log message would be fine.

 > Do we have some statistics on intropoint circuit half-life? I think that
 this delay should be based on it. And learning this half-life is what
 we're effectively doing here.

 I don't think it's something we've ever measured -  it's hard to measure
 safely.
 We'll just have to guess for now, unfortunately. I'll see if we can
 measure it using a privacy-preserving method, but that will take time.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20082#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online