org/meetings/2017Amsterdam/Notes/OSUX.md

+
+= 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.
+