-
- View options
Activity
Trac:
Description: ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.
I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.
My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.
The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.
If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar. But I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.
to
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.
asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.
I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.
My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.
The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.
Also--
If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar.
I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help).
Have you tested the opposite, whether users notice anything different about a downgrade attack when they're being redirected from https to http?
Three thoughts:
A) If I'm using onion and https, I want some visual way to learn that. That's because an https cert for an onion site, especially if it's an EV cert, probably means that I can be more assured that I'm really on the site I meant to be on. In particular, if you replace the https lock icon with the onion one, then it could be harder for me to know whether I have the https layer too.
B) I think the UX part might need to depend on how exactly we're choosing to do the redirects. Do we have a local database, a la httpseverywhere, that has a mapping for us? And when we type in foo.com, it auto rewrites it to foo.onion? In that case, I think it is a really compelling idea to have the browser tab display "foo.com" for us when we're at the site that it "knows" is foo.onion. We could even do that swap if the user went directly to foo.onion, since we can look it up to see that we should display foo.com. But in this case, we should also have a good plan for how to handle the case where the user is on an onion address that isn't in our rewrite table. I guess we put the cool blue onion label in the url tab, but leave the address alone (as xyz.onion)? Does that create a world where we have first tier onions and second tier onions, and users learn to mistrust second tier onions? Is that a feature or a bug?
Shipping such a table with Tor Browser means more centralization of the naming system. Especially if users trust sites in the table more than sites not in the table, we're going to see pressure from various folks to get their onion address added to the list. Do we add the particular sketchy sites, or do we opt not to, effectively censoring them? How about when some government agency comes to us asking us to remove one of the entries?
Maybe there are other approaches to helping users do the rewrite that don't suffer from the centralization / central point of intervention issues above. See e.g. the proposals for having CAs include both foo.com and an altname of foo.onion in the same https cert, to effectively bind the names together.
C) The browser has a bunch of built-in defenses, under the broad term "cross site something", which aim to provide isolation of cookies, javascript, etc between domains. These defenses are often keyed off of what's written in the url bar. So we should have some smart browser people think through whether we would be undermining these defenses with this change. (Alternatively, maybe we can get away with not changing what the browser thinks is in the url bar, but just changing how it's displayed to the user.)
Replying to arma:
C) The browser has a bunch of built-in defenses, under the broad term "cross site something"
Yawning helpfully supplies the phrase "same-origin policy".
Trac:
rules.zipIf it will be useful here is my collection of 290 clearnet to onion rules. It is the personal continuation of "darkweb-everywhere" but does not include the proofs. Most of them are official mirrors, some addresses may be unofficial but harmless mirrors, obvious or potential scam websites were not added. To use them, just copy the rules to the HTTPSEverywhereUserRules folder inside your Tor Browser profile. Since the goal was just to collect all such addresses, I didn't bother with cleaning obsolete rules. Nevertheless it is up to date and contains most of the websites that has onion addresses.
But Facebook is turned off by default since that would make the user fingerprintable, is there a way to use the redirection only if the person visits facebook.com?
#19812 (moved) is at least related.
#8686 (moved) has already had some discussion about the UX in the URL bar.
Trac:
Username: tokotoko
Cc: dgoulet, asn, ilf, gk, isabela, arma to dgoulet, asn, ilf, gk, isabela, arma, fdsfgs@krutt.orgMy modest suggestion: If such a redirect proposal is implemented, instead of scaring the user with such unexpected behavior, make it optional, and ask the user with a dialog when he first installs the Tor Browser to choose whether he wants to be automatically redirected to some onion services or not (additionally with some non-technical information on what they are and their security benefits).
Trac:
Username: blockflare
Hey Linda. Thanks for thinking about this problem.
FWIW, I definitely find this idea quite compelling and I think it's well motivated. That said, I feel that Roger raised some very good points in comment:4. e.g. what happens when a user uses onion+HTTPS which seems like it's not currently handled by the mockups above.
And then of course there is the question of how are those automatic redirects caused?
-
Does this proposal apply only to clearnet sites that actually do an HTTPS 302 redirect to an onion site? This rarely happens right now.
-
Or does this proposal assume that there is some out-of-scope mechanism that does automatic redirects from clearnet to onion sites (like Roger's (b), or the various ideas from our recent blog post? WRT Roger's (b) idea, I definitely echo that the Tor Project should not be responsible for mapping names to onions: I think that's a huge rabbithole of sadness that should probably be handled by a third-party organization (e.g. EFF) or as a community project (e.g. we include darkweb-everywhere in TBB, like we do for https-everywhere).
Anyhow I will not complicate this thread further with more doubts and edge-cases, as there are various open questions here already.
-
Trac:
Cc: dgoulet, asn, ilf, gk, isabela, arma, fdsfgs@krutt.org to dgoulet, asn, ilf, gk, isabela, arma, fdsfgs@krutt.org, hacimTrac:
Username: guido
Cc: dgoulet, asn, ilf, gk, isabela, arma, fdsfgs@krutt.org, hacim to dgoulet, asn, ilf, gk, isabela, arma, fdsfgs@krutt.org, hacim, guido@dis.tur.bio
