15:01:52 <donuts> #startmeeting Tor Browser Weekly Meeting $2022-08-22
15:01:52 <MeetBot> Meeting started Mon Aug 22 15:01:52 2022 UTC.  The chair is donuts. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:52 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:55 <donuts> did I do that right
15:02:02 <donuts> pad is here: https://pad.riseup.net/p/tor-tbb-keep
15:02:10 <Jeremy_Rand_36C3[m]> LGTM
15:02:14 <donuts> please add any items you'd like to discuss to the agenda :)
15:02:21 <anarcat> LGTM but not sure about that dollar sign ;)
15:02:29 <donuts> it's free money anarcat
15:02:39 <donuts> also hey hey Jeremy_Rand_36C3[m], I'll check it out!
15:02:42 <anarcat> woot
15:02:46 <Jeremy_Rand_36C3[m]> donuts: but is that libre money or gratis money?
15:03:13 <donuts> depends on your belief system maybe :D
15:03:28 <Jeremy_Rand_36C3[m]> Schrodinger's Money
15:03:49 <donuts> Okay let's take a couple of mins to add our status updates, unless everyone's already done
15:04:20 * ma1 studying MeetBot docs in the meanwhile :)
15:04:47 <donuts> I never use the date function for UX team meetings lol
15:04:55 <donuts> in fact, I didn't even know it existed until recently
15:05:04 <donuts> our logs are probably a mess, idk
15:07:50 <donuts> I'm done with my status updates, please sound off when you're ready too and I'll move on with the meeting
15:08:00 <PieroV> I'm ready
15:08:03 <ma1> ready
15:08:16 <gaba> Remember to check your board (https://gitlab.torproject.org/groups/tpo/applications/-/boards filtered by username) and be sure it reflects what you are working on.
15:08:22 * Jeremy_Rand_36C3[m] filled out my info 10 minutes early, which is out of character for me
15:08:25 <dan_b> done
15:08:59 <donuts> great
15:09:05 * donuts checks the pad for bold items
15:09:05 <boklm> done
15:09:37 <donuts> msim: looks like you have the only item in bold :)
15:09:58 <boklm> it looks like an old one
15:10:03 <donuts> oh so it is, nvm
15:10:10 * donuts unbolds
15:10:33 <donuts> over to you then Jeremy_Rand_36C3[m]
15:10:39 <Jeremy_Rand_36C3[m]> ok, so
15:11:31 <Jeremy_Rand_36C3[m]> One of the two users I noticed who was confused about the warning was one of my co-workers, who is very technically proficient, including about Tor, and even he couldn't understand what the warning was about, what triggered it, and what the correct course of action was
15:11:56 <Jeremy_Rand_36C3[m]> Then you have a less sophisticated user who thought the warning meant he was already pwned and panicked
15:12:26 <Jeremy_Rand_36C3[m]> I was hoping the UX Team might be able to evaluate how this warning can be better presented so that users don't get confused or make bad decisions when they see it
15:12:46 <donuts> yep, for sure – we can also do a little usability testing for further feedback as well
15:12:48 <Jeremy_Rand_36C3[m]> To be clear I haven't been closely watching #tor, those are just the two cases I noticed in passing
15:13:07 <donuts> what's the plant/timeline for making the UX "native" in Tor Browser ma1? Have you discussed that with richard?
15:13:20 <donuts> that would be a natural point to review and iterate on it
15:13:27 <donuts> *plan
15:13:28 <donuts> not plant
15:13:58 <ma1> donuts: no timeline yet, but evaluating it in the scope of the Security Level refactory
15:14:08 <ma1> s/y/ing
15:14:16 <richard> o/
15:14:21 <ma1> o/
15:14:31 <PieroV> o/
15:14:35 <donuts> ma1: got it
15:14:40 <Jeremy_Rand_36C3[m]> A wild Richard appears!
15:14:44 <donuts> welcome richard o/
15:15:04 <richard> phone alarms work much better when your phone doesn't die in the night it turns out
15:15:05 <richard> :p
15:15:19 <Jeremy_Rand_36C3[m]> Anyway yeah just wanted to make sure this is on UX Team's radar :)
15:15:28 <donuts> richard: we're just discussing the NoScript warnings UX, Jeremy_Rand_36C3[m] had mentioned some user confusion about them
15:15:36 <ma1> donuts, the alternative would be anonymizing every "dangerous" request without warnings (like Leakuidator+ does): less scary but much more room for breaking stuff blindly and silently.
15:15:54 <donuts> richard: I just asked ma1 what the plan was for making the UX 'native' in Tor Browser since that seemed like a natural point to review the UX
15:16:00 <Jeremy_Rand_36C3[m]> should I repeat my IRC comments from a few minutes ago for richard ?
15:16:13 <richard> yes please :)
15:16:29 <donuts> maybe we could get started on that ticket from a design and usability testing pov straight away anyway, and maybe carry across any of the recommendations to NoScript in the interim
15:16:34 <Jeremy_Rand_36C3[m]> One of the two users I noticed who was confused about the warning was one of my co-workers, who is very technically proficient, including about Tor, and even he couldn't understand what the warning was about, what triggered it, and what the correct course of action was
15:16:38 <Jeremy_Rand_36C3[m]> Then you have a less sophisticated user who thought the warning meant he was already pwned and panicked
15:16:41 <Jeremy_Rand_36C3[m]> I was hoping the UX Team might be able to evaluate how this warning can be better presented so that users don't get confused or make bad decisions when they see it
15:16:47 <Jeremy_Rand_36C3[m]> (that's all I said I think)
15:16:50 <ma1> donuts: I tend to believe the wording/framing and the blocking/non blocking approach is more critical to user confusion than the actual implementation details.
15:17:16 <donuts> ma1: yeah, maybe with some kind of passive notification like "Tor Browser has just blocked xyz. Yadda yadda reload and enable it instead"
15:17:17 <Jeremy_Rand_36C3[m]> To be clear I haven't been closely watching #tor, those are just the two cases I noticed in passing
15:17:21 <Jeremy_Rand_36C3[m]> (forgot that message)
15:17:39 <donuts> ma1: we can rapidly test various options with Figma prototypes too
15:17:51 <donuts> finding the right wording for stuff is a good use of that testing format
15:18:10 <PieroV> donuts: we should evaluate if this approach introduces some other linkability occasions
15:18:13 <Jeremy_Rand_36C3[m]> And yeah, agreed that the wording/framing seems to be where the confusion is happening here
15:18:28 <Jeremy_Rand_36C3[m]> But,
15:18:38 <donuts> pierov: can you explain that a little more to me please?
15:18:45 <Jeremy_Rand_36C3[m]> The frequency of the warnings is causing user fatigue, which is not the same thing as confusion but is still very bad
15:19:29 <boklm> maybe anonymizing every request by default, with an option to not do it on some page? or would it break to many things by default?
15:19:39 <donuts> How long are exceptions (i.e. overriding the warning) granted for? are they per session?
15:19:50 <ma1> donuts, yes, per session.
15:19:54 <donuts> got it
15:20:09 <Jeremy_Rand_36C3[m]> boklm: so far I've only encountered one case where I decided to allow the request; probably 50 or more cases where I rejected
15:20:48 <ma1> boklm, that's the "alternative" I was talking about. My fear is for you to break SSO / 3rd party authorization / online payment flows.
15:20:52 <Jeremy_Rand_36C3[m]> So I think anonymizing by default, and showing a notification that the user might want to reload if it's broken, will probably improve fatigue a lot
15:21:04 <PieroV> donuts: we should see if there are some cases for which loading with every details already available could be desirable
15:21:35 <Jeremy_Rand_36C3[m]> I don't know what happens if SSO sites get reloaded after a failure
15:21:35 <ma1> Jeremy_Rand_36C3[m], maybe, like "Something looks wrong in this page? Click here to learn how to fix it".
15:21:41 <PieroV> also, doing so might break some site, for example if the page used a nonce or some other token to be used once
15:21:45 <donuts> is there a way we can maintain a longer-term list of exceptions, rather than per session?
15:22:01 <Jeremy_Rand_36C3[m]> donuts: I suspect a long-term exception list is a fingerprinting vector
15:22:22 <richard> and a disk-leak
15:22:24 <ma1> donuts, yes we can, but I think it goes against our threat model (see Jeremy_Rand_36C3[m]'s comment above)
15:22:26 <donuts> yeah
15:22:28 <donuts> makes sense
15:22:42 <Jeremy_Rand_36C3[m]> ma1: as long as the "how to fix it" explanation makes it clear that this does entail some privacy risk, I think that approach is fine
15:23:17 <Jeremy_Rand_36C3[m]> Or at least, it would be intuitive for me.  I am not a typical user and I am not good at thinking like one.
15:23:57 <Jeremy_Rand_36C3[m]> IIRC we already do that for canvas usage?
15:24:39 <Jeremy_Rand_36C3[m]> I don't use canvas very often, but when I do, I like having the browser tell me that it blocked canvas and that I can easily click something to enable it
15:24:47 <Jeremy_Rand_36C3[m]> Copying that UX seems sane to me
15:24:54 <donuts> So are we considering anonymizing every request, warning with a banner that links to some kind of full-page thing? i.e. a neterror screen?
15:25:04 <donuts> Jeremy_Rand_36C3[m]: yeah that's what I was thinking of
15:25:25 <ma1> Jeremy_Rand_36C3[m], you said you authorized just once, but it seems the most puzzling part for users who didn't read the fine print was following a link to github or stackexchange from Google (which you would never want to "share information" with the destination), and be suprised at being logged out.
15:26:29 <ma1> donuts, a net:error page would not fix the warning fatigue while likely breaking the legitimate use cases.
15:26:34 <Jeremy_Rand_36C3[m]> donuts: I'm not convinced the explanation needs to fill the whole page; I don't think the canvas explanation does.  Probably a small pop-up tab or something could do it, maybe with a link to a full-page supplementary doc for the kind of people who read the dictionary for fun
15:27:33 <Jeremy_Rand_36C3[m]> ma1: ok, so I would not notice a Google to GitHub transition because I use separate VM's for each site I'm logged into, so the only login-based transitions I see are SSO (IIRC the one I hit was when Uber Eats redirected me to the main Uber site)
15:27:51 <donuts> Jeremy_Rand_36C3[m]: right, it doesn't have to be a net:error but some kind of secondary screen with more info is probably necessary
15:28:07 <donuts> b/c the banner itself is very lean
15:28:27 <Jeremy_Rand_36C3[m]> donuts: yeah some kind of secondary screen with more details seems reasonable to me
15:29:07 <donuts> what actions are currently available to the user in the noscript warning ma1? Are they just allow vs don't allow?
15:29:56 <ma1> It's "Load anonymously", "Load normally" or implicitly block by using the Cancel button.
15:30:21 <donuts> Cool, I'll create a ticket to review the UX and will loop you in :)
15:30:22 <ma1> Choosing either of the two loads remembers the action for source and target domani pair.
15:30:31 <ma1> donuts, great
15:31:39 <donuts> are you currently working on the security level refactoring?
15:31:42 <ma1> second that. My only concern still remain non-repeatable transactions, but it's quite teorethical (it mostly depends on the resilience of the merchant/payment workflow). Maybe we could keep the on the fly warning as an option and enable it back with better wording if critical stuff gets actually broken in the wild.
15:32:23 <ma1> donuts, I'm in the exploratory phase. At this moment I'm deeply focused at getting my Android-fu up to speed.
15:32:31 <donuts> aha okay great
15:32:49 <ma1> (I've found recently that all the extensions are broken on Android)
15:33:21 <ma1> The bundled ones never get updated, and the other ones (e.g. uBlock) just cannot work because they're not enabled in private browsing.
15:33:41 <donuts> ooft, I just saw the ticket :/
15:33:42 <ma1> So I'm trying to fix this ASAP:
15:33:51 <donuts> sounds good, ty!
15:34:38 <donuts> Okay, anything else anyone wants to discuss this week?
15:34:44 <donuts> Or shall i release the bot?
15:34:47 <PieroV> Yep
15:35:05 <PieroV> About the reproducible builds event in Venice
15:35:20 <PieroV> boklm and me are thinking of going there
15:35:27 <PieroV> It's Nov 1-3
15:35:43 <donuts> oh yes, I skipped the announcements section – exciting :D
15:35:52 <donuts> https://lists.reproducible-builds.org/pipermail/rb-general/2022-July/002666.html
15:36:03 <PieroV> https://reproducible-builds.org/events/venice2022/
15:36:04 <donuts> nice location
15:36:05 <Jeremy_Rand_36C3[m]> PieroV / boklm : I'd expect some of the Bitcoin Core guys to be there, maybe Carl Dong.  If you run into them, you should talk to them about build-arch-agnostic reproducible builds
15:36:13 <Jeremy_Rand_36C3[m]> They just got that working in Bitcoin Core circa last week
15:36:15 <PieroV> donuts: actually it's in Mestre, not in Venice
15:36:30 <donuts> pierov: aha that makes more sense
15:36:41 <ma1> the "poor man" Venice
15:36:44 <donuts> lol
15:36:51 <Jeremy_Rand_36C3[m]> Like, they build Bitcoin Core for all supported platforms on an x86 machine, and then they do the same build on an ARM machine, and all the hashes match
15:36:52 <donuts> venice2
15:37:07 <dan_b> wow
15:37:15 <PieroV> the mainland part of Venice
15:37:39 <PieroV> Jeremy_Rand_36C3[m]: ack
15:39:11 <donuts> remember and grab some extra stickers etc. in Ireland so you can give them away in not-venice :D
15:39:21 <boklm> ah, good idea
15:39:23 <donuts> Erin usually takes a bunch in case you're running low
15:39:39 <PieroV> I have only my personal stickers, lol
15:39:50 <donuts> also we have new fliers to replace the old relay ops ones
15:40:01 <donuts> that detail the ways folks can contribute voluntarily
15:40:34 <donuts> such as QA lol
15:41:34 <donuts> right I think we're done for real this time
15:41:40 <donuts> have a great week everyone!
15:41:45 <Jeremy_Rand_36C3[m]> thanks!
15:41:46 <PieroV> Thanks! Same to everyone
15:41:53 <donuts> bot, i release thee
15:41:54 <donuts> #endmeeting