wiki:org/meetings/2019Stockholm/Notes/UserIssuesPrioritization

Product: User Issues Prioritization

We will organize Tor Browser user issues reported during 2019 Q1 Q2.

Material:

Facilitator(s): antonela + isabela

Audience: UX team, Community team, developers, and people interested in users.

Duration: 1 hour

Prep

You do not need any prep to make this session.

Desired outcomes

Set up issues prioritization based on a consensus about what we should, want and can do.

Notes

Snowflake

#27385: https://snowflake.torproject.org/embed is confusing

  • The badge is a holdover from the flash proxy and web badges aren't common anymore
  • Additionally there's an opt-in for cookies that complicates this functionality
  • Suggestion is to remove the badge and encourage use of the extension instead, thereby transforming the page into more of an informational page
  • And update the web page with Tor Project branding to legitimise the plugin too (e.g. apply the online style guide)
  • Stable Snowflake launched circa August (ideally EN before Defcon, Aug 8 – 11), involve Communications to review, rewrite and localise the content
  • Suggestion to provide precompiled binaries on the site – which a new ticket will be created for (Linux, Mac, FreeBSD)

#31100 Firefox addon not reporting any users

  • We've solved one of the problems, but sometimes there's an infinite deadlock that happens

#31100 Better gamify the UX for snowflake extension

  • Overall idea is to make people feel good about participating (e.g. show users they're saving the world)
  • Concerns that the low user numbers would hamper this, but that may be due to bugs
  • Suggestion to measure and gamify bandwidth instead

#30999 Spruce up the product pages

  • Needs review by UX and Communications to ensure it looks good and legitimately from The Tor Project
  • Suggestion to upload 4-5 screenshots and improve the description
  • _Ideally_ before Defcon

General points:

  • Icon isn't visible when using a dark theme in Firefox – UX Team to provide hex code for alternative colour
  • Snowflake team don't know what it's actually like to use Snowflake for long periods of time with fluctuations in the number of Snowflakes (e.g. with timeout, censorship etc.)
  • Metrics to include numbers of users and numbers of snowflakes before September ideally (already on the roadmap)

Bridges:

  • Planning to do some quick user study to evaluate the pain points in setting up bridges
  • We need to figure out how we're going to improve bridges in Tor Browser, including the UI for mobile
  • In a perfect world TB should be able to pick a bridge for a user – but we don't know how to get there yet
  • Captcha's tricky for everyone – but especially for non-English (e.g. Chinese)
  • Localised or non-English Captcha's would be preferable (e.g. numeric or image-based)
  • If the goal is to just stop people crawling the BridgeDB perhaps there are other methods of authentication (i.e. device specific, like fingerprinting?) we can use

SimplySecure

  • Put the portal together and launch for internal use without the branding, which can be added later
  • Resources are slim to complete this project

Tor Browser Config Settings

Plan to create a Tor app ecosystem:

  • Tor:Config is the UI to modify configuration files
  • Plan to replace the Tor Launcher at some point (not now)
  • Tor Launcher currently disables the configuration settings that identify Tor during bootstrapping
  • We need to improve the config file for third parties/apps who want to implement Tor
  • Will require developer tools, documentation, branding guidelines for people who want to implement that
  • But also guidelines on what options they expose to users
  • Concern raised over the fact there's only one binary for Tor with multiple configurations, which means the document for the configuration file is huge and needs split
  • TBD whether or not the config file will actually be split owing to impact – or perhaps Tor could be split up into multiple binaries instead
  • Suggestion to provide an empty config file that would include default bridges etc. to help with the creation of Onion Services
  • We should aim to have very good documentation for the API
  • Confusion about terminology surrounding Onion Services internally, which the Metric team should feed into
  • Occasionally there are people asking on IRC how to build Tor as a library, which we've provided a stable API for with a function called Start Tor
  • This is the stuff we aim to have a link on the Developers portal to the documentation
  • The Developers portal is more about getting involved, however
  • Perhaps we need an app integration portal instead
Last modified 5 weeks ago Last modified on Jul 13, 2019, 3:17:05 PM