In the discussion around #22820 (moved), we decided that giving the exit flag to relays that exit to ports 80 and 443 is the right thing to do:
First, port 6667 used to be relevant, but now, and especially with the advent of ircs, it isn't.
Second, we invented the current algorithm for the Exit flag back before Mike invented the 'reduced exit policy'.
Third, a relay that exits to 443 but not 80, or 80 but not 443, is going to make web browsing super bumpy when used with Tor Browser's tab isolation strategy.
So we should simplify it.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
https://consensus-health.torproject.org/#overlap made me realize a side effect of this branch: we will decrease the total capacity that the network weights think are on Exits, thus making Exit capacity even more scarce in the network. But I call that a feature, since the exit capacity is more scarce in the network, it's just that we're only now realizing it.
If your intent is to make 80 and 443 mandatory anyways, then this branch is ok. But if there are exits that don't want to pass insecure connections (using 443 and 6667 as a workaround), you'll push them off.
if there are exits that don't want to pass insecure connections (using 443 and 6667 as a workaround)
The trouble is that using 443 and 6667 isn't a workaround. For clients who browse the web using both 80 and 443, if they get an exit that only does 443, they need to get a second exit that does 80, for that same interaction. Suddenly they have way more exposure for that interaction than they needed to have.
Pointing back to #22820 (moved): the main effect of the Exit flag is to help with load balancing. It makes clients choose that relay less (currently never) for non-exit positions in their circuits. Whereas the presence or absence of the Exit flag doesn't prevent clients from building circuits that exit from that relay -- that choice depends on the streams that the client is trying to handle, and the exit policy of each relay they're considering.
if there are exits that don't want to pass insecure connections (using 443 and 6667 as a workaround)
The trouble is that using 443 and 6667 isn't a workaround.
It is. For exits, of course. While "443 and 6697" is not available.
For clients who browse the web using both 80 and 443, if they get an exit that only does 443, they need to get a second exit that does 80, for that same interaction. Suddenly they have way more exposure for that interaction than they needed to have.
This is a mixed content case. That's why MCB was activated in TBB. Users are explicitly warned about passive/active insecure content on secure webpages. More exposure of the client is far less dangerous than more exposure of the exit to ISP and others.
Pointing back to #22820 (moved): the main effect of the Exit flag is to help with load balancing. It makes clients choose that relay less (currently never) for non-exit positions in their circuits. Whereas the presence or absence of the Exit flag doesn't prevent clients from building circuits that exit from that relay -- that choice depends on the streams that the client is trying to handle, and the exit policy of each relay they're considering.
And you want more exits to be used for non-exit positions, don't you?