In that case it looks like I have misunderstood the last hop for hidden services.
When using a public site over Tor, the connection looks like this:
1. User connects to a relatively nearby entry node (guard) [hop #1]
2. Guard node routes the packet via a relay [hop #2]
3. Relay routes the packet to an exit node [hop #3]
4. Exit node routes the packet out of the Tor network, and has responsibility for finding the actual destination. Even for a globally available high-traffic site the route from exit node to the nearest edge node has to travel across a couple of networks.
Now, under the proposed 3-hop hidden service protocol - when user accesses a hidden service, I had understood that the "exit node" is replaced by the hidden service itself. So the connection would look like this:
1. User connects to a nearby guard node [hop #1]
2. Guard node routes the packet to a relay [hop #2]
3. Relay node routes the packet to the hidden service [hop #3]
4. There is no step four. The packet has been delivered to its destination network.
For a random hidden service this probably wouldn't matter much, but if/when the third hop is provided by a globally accessible edge network, the latency between relay and final destination should be quite good.
With the elimination of post-Tor routing steps, and with the constantly better latency from relay to the hidden service, I expect the overall latency for this particular Tor circuit to be measurably lower. After all, there are no public hops beyond the circuit termination nodes. So from traffic analysis point of view, Tor/FB traffic should stand out from other Tor traffic.
And I think I found some references, at last. Search for "Direct Onion Services: Fast-but-not-hidden services" draft discussion on tor-dev archives.
Anyway, skipping the third hop would decrease user anonymity, because you'd only need two relays to cooperate to identify the user and who they're connecting to. Regular tor requires all three to cooperate.
The proposal uses a rendezvous point instead of an exit node, but that shouldn't affect speed as far as I see.
When using a public site over Tor, the connection looks like this:
1. User connects to a relatively nearby entry node (guard) [hop #1]
2. Guard node routes the packet via a relay [hop #2]
3. Relay routes the packet to an exit node [hop #3]
4. Exit node routes the packet out of the Tor network, and has responsibility for finding the actual destination. Even for a globally available high-traffic site the route from exit node to the nearest edge node has to travel across a couple of networks.
Now, under the proposed 3-hop hidden service protocol - when user accesses a hidden service, I had understood that the "exit node" is replaced by the hidden service itself. So the connection would look like this:
1. User connects to a nearby guard node [hop #1]
2. Guard node routes the packet to a relay [hop #2]
3. Relay node routes the packet to the hidden service [hop #3]
4. There is no step four. The packet has been delivered to its destination network.
For a random hidden service this probably wouldn't matter much, but if/when the third hop is provided by a globally accessible edge network, the latency between relay and final destination should be quite good.
With the elimination of post-Tor routing steps, and with the constantly better latency from relay to the hidden service, I expect the overall latency for this particular Tor circuit to be measurably lower. After all, there are no public hops beyond the circuit termination nodes. So from traffic analysis point of view, Tor/FB traffic should stand out from other Tor traffic.
And I think I found some references, at last. Search for "Direct Onion Services: Fast-but-not-hidden services" draft discussion on tor-dev archives.