<div dir="ltr"><div>> TBB plugin: T2W-OE - tor2web onion everywhere.</div><div>> Fork HTTPS-E.</div><div>> Maintain list of known t2w's.</div><div>> Plugin update from tpo.</div><div>> Matching engine rewrites t2w URL's to onions in TBB before the fetch.</div><div><br></div><div>You are correct my good sir!  This is indeed the better way.  Thank you!  <span style="line-height:1.5">I made a pull request to HTTPS-E for the requisite tor2web rules.</span></div><div><br></div><div><a href="https://github.com/EFForg/https-everywhere/pull/3033">https://github.com/EFForg/https-everywhere/pull/3033</a></div><div><br></div><div>It's unclear to me how to make these rules only apply to the TBB version, but judging by the version history of HTTPS-E they have a way of doing that.</div><div><br></div><div>Unless there's another specific issue, I consider the matter of Tor users accidentally clicking links to Tor2web nodes solved.</div><div><br></div><div>-V</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 3, 2015 at 8:29 PM grarpamp <<a href="mailto:grarpamp@gmail.com">grarpamp@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> various wrote:<br>
> Yesterday Lief compellingly argued that if a TBB user accidentally clicks on<br>
> a link to my tor2web proxy (onion.link), that they should be redirected to<br>
> the .onion address. It hadn't occurred before that a Tor user might<br>
> accidentally click a onion.link URL<br>
<br>
TBB plugin: T2W-OE - tor2web onion everywhere.<br>
Fork HTTPS-E.<br>
Maintain list of known t2w's.<br>
Plugin update from tpo.<br>
Matching engine rewrites t2w URL's to onions in TBB before the fetch.<br>
<br>
> { "countrycode": "A1", "location": "Tor", "domain": "<a href="http://torproject.org" rel="noreferrer" target="_blank">torproject.org</a>" }<br>
> or some such.  This seems a reasonable request.  Do we know someone at<br>
<br>
They may not wish to if they want to return a single result per IP, and an<br>
IP could be running more than one proxy (tor, i2p/cjdns exit, vpngate,<br>
plain old vpn service, whatever), it's not generally possible to tell which<br>
proxy emitted traffic from said IP, nor is it reasonable to require tor exits<br>
operators to not participate in other networks.<br>
<br>
> Tor-Browser-Bundle: true<br>
<br>
Great for advertising statistical demand for anonymous access to<br>
clearnet web operators, bad for blocking.<br>
<br>
> Are we still trying to hide TBB users in the Mozilla browser crowd?<br>
<br>
TBB should conform to Mozilla. Though it's a unique header, currently<br>
unused by web operators, that's only for a while. If any such thing, it should<br>
be a toggle, default off. You don't want to be unique unless you have to,<br>
and it's unlikely even 1/3 of clearnet operators are programmatically<br>
exit-aware, with fewer programmed to block.<br>
<br>
> the "x-tor2web" request header. We eventually decided to add it.<br>
<br>
Which is fine because it doesn't disclose any bits about the user to<br>
clearnet, the disclosure to the onion is still anon and moot, and the<br>
user can go direct to the onion if the onion blocks t2w.<br>
<br>
> The CDN should forward the client IP address as X-Forwarded-For or<br>
> something?<br>
<br>
Other proxies, vpn's, chains, whatever between t2w and the exit may not do this.<br>
<br>
> If any sites do start blocking users based on the header (and not also based on IP)<br>
> it will push people into using a non-TBB browser to access Tor.<br>
<br>
Yep.<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div>