|
|
|
|
|
|
|
= Onion service user experience problems =
|
|
|
|
|
|
|
|
== Optional onion service client authentication ==
|
|
|
|
|
|
|
|
There is no support for this in Tor Browser (TB) yet. What is a good
|
|
|
|
way to ask the user for the auth? It can be username and password,
|
|
|
|
or a public key, or simply one password (that every user uses to
|
|
|
|
access the same onion).
|
|
|
|
|
|
|
|
The UX problems here are both on the client and the server side.
|
|
|
|
|
|
|
|
== SOS ==
|
|
|
|
|
|
|
|
Single Onion Services have one hop between the rendezvous and the
|
|
|
|
onion service server, thus they are faster than full Onion Services.
|
|
|
|
|
|
|
|
When you visit an SOS in TBB, there is no distinction between full OS
|
|
|
|
and SOS. Is this a UX problem which should be distinguished?
|
|
|
|
|
|
|
|
Discussion:
|
|
|
|
|
|
|
|
- Power users who annoying are good at filing tickets in Trac seem
|
|
|
|
to understand the difference between seeing three hops or not in
|
|
|
|
the dropdown when they intended to visit a SOS.
|
|
|
|
|
|
|
|
- The takeaway from the discussion is that it is extraneous
|
|
|
|
information to display to the user, since only the service's
|
|
|
|
anonymity is affected by using a SOS.
|
|
|
|
|
|
|
|
== Onion Service petnames ==
|
|
|
|
|
|
|
|
Everyone agrees that this is a massive rabbithole. We tried to avoid
|
|
|
|
this discussion, and then we had it anyway.
|
|
|
|
|
|
|
|
Discussion:
|
|
|
|
|
|
|
|
- Paul Syverson mentions speaking to the HTTPSEverywhere folks about
|
|
|
|
having rewrites for onion services which also have TLS
|
|
|
|
certificates and registered domain names can have their
|
|
|
|
56-character long onion service name display as their regular
|
|
|
|
domain name:
|
|
|
|
e.g. facebookcorewwwi298yua934htpq9438hthpq98fpa948hap4hSfhaew.onion
|
|
|
|
displays instead as facebook.onion (because the own the certificate
|
|
|
|
and domain for facebook.com).
|
|
|
|
|
|
|
|
- CAB Forum is currently debating domain validation for onion
|
|
|
|
services, e.g. "prove you own the private key corresponding to
|
|
|
|
this onion address before we issue you a cert" which (hopefully,
|
|
|
|
depending on how the discussion goes) will allow EV certs for
|
|
|
|
individual, or allow non-EV certs for onion services, unclear
|
|
|
|
which.
|
|
|
|
|
|
|
|
- Linking into an existing naming heirarchy? Acceptable ones
|
|
|
|
include DNS, CA PKI.
|
|
|
|
|
|
|
|
- Or we could consider petnames, which we assume here to be local to
|
|
|
|
the user, e.g. like a bookmark.
|
|
|
|
|
|
|
|
- Or we could have a "pluggable" system for naming systems, such that
|
|
|
|
you can choose to use Namecoin, or choose to use CA PKI. The name
|
|
|
|
for this is Name Service API (NSA). People generally agree this
|
|
|
|
is an interesting route to take, but Nick warns that we need to
|
|
|
|
devote a person to creating this pluggable platform and create the
|
|
|
|
first plugin to ensure that others will create adoptable plugins.
|
|
|
|
|
|
|
|
- George brings up there is two ways petnames could work:
|
|
|
|
You type facebook.onion and it goes to
|
|
|
|
facebookcorewwwi298yua934htpq9438hthpq98fpa948hap4hSfhaew.onion
|
|
|
|
because:
|
|
|
|
1) you have a hosts file that says you should do that.
|
|
|
|
2) "someone you trust for some reason" has a hosts file
|
|
|
|
that you subscribe to and receive updates from.
|
|
|
|
|
|
|
|
- Nick mentions that, for the "something.onion" parts, the
|
|
|
|
"something" one is actually a thing that serves a hosts file, so
|
|
|
|
that if you type "facebook.something.onion" you are using the
|
|
|
|
something hosts file, and if you type "facebook.namecoin.onion"
|
|
|
|
you get the namecoin hosts file.
|
|
|
|
|
|
|
|
== What do we put in TB's dropdown circuit display ==
|
|
|
|
|
|
|
|
We currently display:
|
|
|
|
|
|
|
|
{{{
|
|
|
|
hop1 germany (192.x.x.x)
|
|
|
|
hop2 netherlands (192.168.x.x)
|
|
|
|
hop3
|
|
|
|
???
|
|
|
|
hidden service
|
|
|
|
}}}
|
|
|
|
People get confused about the ??? in the circuit dropdown.
|
|
|
|
|
|
|
|
Idea: Do as chrome and just mark all onion services in the same way
|
|
|
|
as https://, only mark http:// as explicitly insecure.
|
|
|
|
|
|
|
|
Discussion:
|
|
|
|
|
|
|
|
- We need to talk to the Mozilla Firefox team about having a way to
|
|
|
|
mark onion services of all types as secure, even if they are
|
|
|
|
delivered over http://.
|
|
|
|
|
|
|
|
- Concerns about phishing because the "domain name" of an onion
|
|
|
|
service is not reasonably human memorisable.
|
|
|
|
|
|
|
|
- Georg is amenable to a positive (i.e. an addition to the URL bar)
|
|
|
|
indicator like a lock icon for onion services.
|
|
|
|
|
|
|
|
- Linda responds that there is a difference between 1) people who
|
|
|
|
are on guard all the time and seeing a lock icon and then it
|
|
|
|
disappears, versus 2) users who are chill all the time and there's
|
|
|
|
no indicator and then suddenly there is an X through the http://
|
|
|
|
warning them that they must be careful on the site.
|
|
|
|
|
|
|
|
- We mention having a GIF of a wizard using their wand to "do
|
|
|
|
sparkly magic" on the ??? part of the circuit diagram. Nick
|
|
|
|
agrees to this, as long as the wizard is an image of one of us
|
|
|
|
developers. I ask Nick if he has a wizard costume. Nick promptly
|
|
|
|
fashions a wizard hat from his laptop case.
|
|
|
|
|
|
|
|
= Miscellaneous =
|
|
|
|
|
|
|
|
Linda and the onion service hackers agree to have a one hour per week
|
|
|
|
meeting to discuss onion serivce user experience work on an ongoing
|
|
|
|
basis.
|
|
|
|
|
