Log separate HS extra-info stats for Single Onion Services

To determine guard and middle weights accurately, we need to log separate extra-info statistics for RSOS and SOS.

Since they have the same path length, I think they can be combined into a single category.

See: https://lists.torproject.org/pipermail/tor-dev/2016-January/010218.html

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified points::3 priority::medium privcount-maybe severity::normal single-onion sponsor::Q-can statistics status::new tor-hs type::enhancement labels

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

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Unfortunately, it is not possible to separate the statistics for Rendezvous Single Onion Services (RSOS), as the hidden service statistics are measured at the HSDir and Rendezvous Point relays, and not at the hidden service itself. These relays have no way of knowing whether they are connected to a RSOS or not.

The impact of this is:

• Rendezvous Single Onion Services will appear as Hidden Services in the HSDir and Rendezvous Point statistics
• Single Onion Services will appear as Hidden Services in the HSDir statistics only (they don't do Rendezvous)

However, it is possible to keep separate statistics on cells seen by a relay via Single Onion Service extend requests. HSDirs can log requests for Single Onion Service descriptors separately, as they are the only descriptors that contain an extend-info line. However, it's may not be worth implementing, as the encryption in proposal 224 will stop HSDirs reading HS descriptors.

We could have Rendezvous Single Onion Services add an identifying line to their descriptors, but we'd have to do it in a way that allowed clients to still parse the descriptors. That would only get us the HSDir statistics anyway.

That said, if we identify RSOS in their descriptor so Tor2web clients don't connect to them (#17945 (moved)), we could use the identifier for statistics as well.

I'll look at this again in 0.2.9.

Trac:
Parent: #17178 (moved) to N/A
Cc: N/A to mikeperry

Trac:
Keywords: rsos sos deleted, rsos sos tor-hs added
Points: N/A to medium
Reviewer: N/A to N/A

Trac:
Points: medium to 3

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???
Keywords: rsos sos tor-hs deleted, rsos, sos, isaremoved, tor-hs added

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: isaremoved deleted, N/A added

Trac:
Keywords: tor-hs deleted, tor-hs statistics privcount-maybe added

PrivCount only runs on relays. A relay could guess it was connected to a single onion service by working out it was an intro or rend point directly connected to a client.

Trac:
Summary: Log separate HS extra-info stats for RSOS (and SOS) to Log separate HS extra-info stats for Single Onion Services

If we were going to do this, we should measure the client side as well, so we can track Tor2web usage.

I'm tracking this in these PrivCount tickets: Intro Service: https://github.com/privcount/privcount/issues/342 Intro Client: https://github.com/privcount/privcount/issues/343 Rend: https://github.com/privcount/privcount/issues/344

Note that any Tor2web stats on relays would be biased by Tor2webRendezvousPoints.

Now there's only one kind of single onion service, change rsos to single-onion

Trac:
Keywords: rsos, tor-hs statistics privcount-maybe deleted, statistics, privcount-maybe, tor-hs, single-onion added

Now there's only one kind of single onion service, remove all references to old sos tag

Trac:
Keywords: sos deleted, N/A added

Trac:
Sponsor: N/A to SponsorQ-can

changed time estimate to 24h

moved to tpo/core/tor#18082 (closed)