19:01:53 #startmeeting onion ux 19:01:53 Meeting started Wed Dec 6 19:01:53 2017 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:57 what#s the state of your #21952 related proposal 19:02:05 ? 19:02:20 havent worked on it GeKo 19:02:23 dgoulet: o/ 19:02:31 since we moved that ticket to secondary priority 19:02:38 * isabela reads comments on #23247 19:02:38 ok, fine with me 19:02:45 i made a quick mock to show the idea we talked about last meeting 19:02:46 https://share.riseup.net/#WPhEbcL5oBr6NC1owD3mCQ 19:02:46 i considered we are gonna come back to that when time allows 19:02:47 (sorry i need to catch up a bit) 19:02:59 i am basically with tjr on all he said on this ticket 19:02:59 * asn checks mockup 19:03:15 antonela: i like that - but i think the button could be purple 19:03:16 added to the pad not to the ticket 19:03:20 but maybe is not nice :) 19:03:23 your call 19:03:29 i am in too many channels, but re 21952, i got convinced in montreal that something on the *client* side which auto redirects to an onion is just fine. i'm still scared of the website itself making the decision for me. 19:03:30 GeKo: But you like a onion instead of a padlock, right? 19:03:37 yes 19:03:44 antonela: wow quite interesting!!! 19:04:00 yes could be! im following Firefox's Photon Design System for this iterations 19:04:16 that looks nice, optional and non-UX-intrusive 19:04:18 i'd like to avoid messing with tls indicators 19:04:18 maybe violet is too much, but we can try isa 19:04:19 i just think the purple buttom will call more attention 19:04:24 hehe 19:04:27 agreed 19:04:28 could be too much 19:04:32 yes :) id like to see 19:04:33 thanks for trying 19:04:51 also, the text is just a placeholder, an approach, for sure we should review the words there 19:05:00 or the font of the button and the learn more links be purple 19:05:04 YES 19:05:06 So the main thing I see with that bar is in the page, it is in the middle of page content. it would need to be above the nytimes nav bar; and the scrollbar of the page content would not include the bar 19:05:09 as they are clickable 19:05:11 armadev: it could easily be the coded in the way that the client side is doing it 19:05:22 but I think that's just minor stuff, not something you intended 19:05:25 e.g. by showing the user a notification box and asking it 19:05:56 tjr: yes, is a browser component you scroll and it remains at the top 19:06:15 There was an email by heddha on tor-dev about autoredirecting, they had built an extension for it 19:06:18 tjr: these bars are normal tho, like when sites asks you to confirm your email (twitter has that and so fb) 19:06:34 this one: https://lists.torproject.org/pipermail/tor-dev/2017-December/012656.html 19:06:36 http://design.firefox.com/photon/components/message-bars.html 19:06:37 (heddha ^) 19:06:41 Sure, but that's a page bar, part of page content, we're building it as part of trusted browser chrome 19:06:47 seems to use SSL certs; haven't tested it. 19:07:07 tjr: ahh you mean the site owner only can control it? 19:07:13 ooohh 19:07:17 ohhh 19:07:23 isabela: the opposite kinda 19:07:46 Browser chrome is essentially 'trusted UI a website can never spoof' that's where you put the padlock and anything important 19:07:57 tjr: ahh sorry 19:08:02 tjr: i am talking about the nytimes bar 19:08:02 Anything in the page content can easily be spoofed by the page. (I'm not sure why a page would want to spoof this, but it's still a bad diea) 19:08:22 right, keeping browser chrome separate from webpage is smart 19:08:31 The tricky part is that it's really not that hard to spoof 'browser chrome' as part of a webpage :( 19:08:32 (sorry for overloaded word 'chrome') 19:08:48 antonela's notification bar is probably meant to be above the nytimes "World US Politics..." bar 19:08:52 But I don't think we should be mixing things up further and making that an even harder problem 19:09:24 arthuredelstein: Yea, I'm just pointing out a nit, but I wanted to make sure I was explaining myself coherently 19:09:29 (I think I failed but...) 19:09:41 arthuredelstein: yes i think so too 19:09:53 But even if the notification bar is at the top, I suppose it could still be spoofed by content. 19:10:01 tjr: i see what you mean, i think that the bar is what arthuredelstein mentioned 19:10:04 We use the same kind of notification bar to warn users not to maximize the window. 19:10:09 yes, arthur you are right! 19:10:12 antonela: yes 19:10:13 that one 19:10:15 opes 19:10:16 It's part of chrome and it pushes down the content page 19:10:17 arthuredelstein: 19:10:20 yes 19:10:23 Regarding heedha's email - the interesting thing to me about their email was that it allowed redirection to take place before HTTP occured. That meant that any cookies or anything else would never be sent to the website. 19:10:25 that is the bar we are thinking 19:10:39 For TB that's not as big a concern though, the user won't have cookies. 19:11:01 However the redirection was automatic, no chance to get the user to confirm without either sending HTTP or blocking page load 19:11:14 sorry for the confusion! https://share.riseup.net/#Kq5Zijf6p3MuaxoT-26MXg is the right one 19:11:39 tjr: right 19:12:09 tjr: i guess doing it as part of SSL is a different design, with its own drawbacks and positives. probably a later step than a simple HTTP header i'd say 19:12:14 antonela: aha 19:13:03 asn: agreed 19:13:10 ok, giving the bar behaves the right way (like TB does for screensizes) - asn still has to work on the proposal for the backend of this ? 19:13:33 Yea, the main thing about SSL is there's no real opportunity for user confirmation. So if that's a sticking point, I think any SSL-based mechanism is off the table 19:13:36 yeah i guess since somehow #21952 became the topic now, it means i should prioritize the backend proposal 19:13:46 i think i can do the revisions within this week 19:14:16 and antonela will play with the purple 19:14:18 :) 19:14:19 sounds good. it'll be the first tor browser proposal i guess :) 19:14:21 yes! 19:14:34 great 19:14:36 * antonela is adding this mock to the ticket 19:14:40 ok so i guess that's it for #21952? 19:14:42 Another design for asking for user confirmation could be a doorhanger. The top of the doorhanger overlaps with the chrome area and can't be spoofed. 19:14:43 antonela: maybe change the (i) for a little onion 19:14:43 heheh 19:14:46 anw! 19:14:51 next move isa! 19:14:52 haha 19:15:23 asn: yes, it is 19:15:26 aight 19:15:29 so #23247 is next i guess 19:15:33 yep 19:15:43 sorry i havent organized the icons with copies etc 19:15:46 there are discussions to be had here both on from a security PoV and from a UX PoV 19:16:23 arthuredelstein: i think what works best could easily be done with some user studies 19:16:29 i havent done my homework very well either here 19:16:35 but, yes, there is not just the navigation bar 19:17:00 but it seems like debate on this ticket is currently about what kind of indicator should be on an HTTP onion with self-signed cert 19:17:15 arthuredelstein: (i am not sure what is 'doorhanger') 19:17:26 isa: http://design.firefox.com/photon/components/doorhangers.html 19:17:29 i *think* that antontela's mockups had a yellow onion, and tjr argued that this indicates a warning state 19:17:30 tx 19:17:46 yes, i made a couple of options using onions 19:17:50 and then tjr was flinging between having it be a grey onion, or a green onion 19:18:20 GeKo: I simply meant a doorhanger could be useful if we are worried that content might spoof the notification bar. UX is of course also possibly an issue. 19:18:44 (i think doorhanger will be used for .onion states and the circuit - might get too much if also used for redirecting the sites) 19:18:47 The introduction of an onion icon has added a lot more possibilities 19:19:00 tjr: yes! 19:20:12 antonela: is the url in the ticket the last version? 19:20:16 antonela: for the .onion states 19:20:18 https://trac.torproject.org/projects/tor/attachment/ticket/23247/padlock%20states%20FF%20and%20TB.png 19:20:21 tx 19:20:32 I am attempting to reboot my outline in the pad 19:20:58 btw can anyone tell me what sort of person uses a self-signed cert on their onion? 19:21:10 isabela: I just noticed that some folks at Mozilla are apparently trying to replace notification boxes with door hangers: https://wiki.mozilla.org/Firefox/Projects/Doorhanger_notifications/Notification_box_issues 19:21:16 under what kind of setup does it provide benefits? 19:21:21 arthuredelstein: ! 19:21:25 arthur: yes they are! 19:22:15 asn: Hm. Yea I'm not sure. it's much more likely they would serve a CA issued cert with no valid onion name 19:22:20 They also mention the spoofing issue 19:22:24 antonela: need to think on how all that will work (.onion states, circuit, onion site redirect notification inside of a door hanger) 19:22:24 But there are a few people who hate CAs and just use self signed 19:22:37 Also, actually, lots of Chinese websites use self-signed certs 19:23:19 tjr: but IIUC they do that to provide some sort of best-effort end-to-end encryption, which onions already providwe 19:23:36 isabela: this is why we are here with devs lol 19:23:41 seems like SSL for onions is mainly for authentication purposes, and with no PKI (i.e. CAs) there is no auth? 19:24:00 im saying this things to argue that self-signed http onions should have grey onion 19:24:12 and then CA-signed http onioons should have green onion 19:24:19 antonela: hehe 19:24:41 * asn gets educated about browser doorhangers 19:24:48 asn what should http onion have? 19:25:06 grey onion 19:25:10 i made an orange one, which seems warning BUT grey could work too 19:25:14 i.e. no benefit for self-signed cert 19:25:33 official Firefox use of color -> http://design.firefox.com/photon/visuals/color.html 19:25:35 oh 19:25:47 * asn gets educated about official firefox use of color 19:25:50 So the only complaint I have with that is that we are saying "a CA signed DV cert using the regular internet is more secure than an onionsite" - I don't think that's true :) 19:25:55 asn: lots of rules :) 19:26:36 we can break the rules of course, but just if it gives any benefit to users 19:26:41 purple for privacy. nice! 19:26:49 YES 19:27:00 yes! 19:27:05 !! 19:27:06 tjr: hm 19:27:18 tjr: that's if you ignore the distinction between padlock and onion, right? :) 19:27:26 but i get your point 19:27:33 I suppose, yes. I'm going primarily by color 19:27:36 antonela: between gray and purple i would go with purple but for the other things i would use yellow and green 19:28:12 purple onion for self-signed or http, and green onion for CA SSL+onion ? 19:28:17 yes exactly, this is an example of breaking rules. A violet onion will give us a clear brand presence 19:28:22 FWIW I discovered there are more padlock states in FF than I thought. There are: Green Padlock with EV Banner; Green Padlock; Green Padlock with a warning icon; Grey Padlock with a warning icon; Grey Padlock with a red strikethrough 19:28:27 (going primary by color might mess things up for color blind ppl) 19:28:47 yeah, see richard's comment on the ticket 19:28:51 yes 19:29:00 isabela: Yes, that's true. 19:29:12 so for critical situations like an untrusted onion we can have an specific icon 19:29:17 not just a warning color 19:29:22 I think we can solve the colorproblem though - adding a icon to the padlock indicates the status 19:29:24 antonela: yes 19:29:31 Take a look at the riseup pad in my section at the bottom 19:29:49 I have examples of the FF icons (You may need to be using FF beta or release to see the nuances in them all) 19:30:14 So adding a little triangle warning indicates warning, and adding a strikethrough indicates 'bad' 19:30:19 i think i got those here too 19:30:20 https://docs.google.com/document/d/1KHkj2DpmFMB0mjHEfehD5ztY2L0lQzKNtZqct1TXbmg/edit 19:30:30 but i have less 19:30:31 hehe 19:30:58 You're only missing the EV Banner one and the *very* weird green+warning one 19:31:50 yep i will fix all that 19:32:01 and update with all FF states and the ones antonela is doing 19:32:10 yes! 19:32:51 tjr: i think after our analysis, we have ended up with 2-3 different schemes for the colors 19:33:09 tjr: perhaps we should explicitly list these different schemes, and detail their positives/negativesa? 19:33:16 yes 19:33:18 to help us decide which one is better for us? (since there is no best) 19:33:18 i would like that 19:33:29 yes! 19:33:58 i dont think we should do this now, but i think we can easily do it before next mtng or whatever 19:34:50 yes 19:34:57 just ping us when its there 19:35:04 i think that will help me and antonela a lot 19:35:09 we will update the spreadsheet with all the different behaviours so we can review each of them next week 19:35:09 noted 19:35:11 yes 19:35:18 Okay so I think the two things I am stuck on are: 19:35:35 1) Would we ever want to show a padlock and an onion like richard's screenshot? 19:35:59 2) asn's idea that HTTP and self-signed onions should be 'grey' while ca-signed onions should be 'green' 19:36:35 hm 19:36:40 if we do (1) we open a whole new world of possibilitiesw 19:36:52 (onion denotes onion service status, padlock denotes ssl status) 19:36:53 i think we will end up doing both right? 19:36:57 like color and icons mixed up 19:36:59 to pass the msg 19:37:10 tjr: 1) I would prefer we don't -> [i] [onion] or [i] [padlock] 19:37:28 I would also prefer we don't put two icons. 19:37:35 no 19:37:38 not two icons 19:37:43 ok great 19:37:46 i thought it was more like 19:37:48 seems like we have consenss here 19:38:00 [i] [onion] [padlock] isn't confusing? 19:38:00 +1 19:38:01 the Onion with a little padlock on it or something, as a single icon 19:38:22 because of the whole going only by color - messing color blind folks 19:38:38 tjr: wrt (2) i suggested that because my understanding is that the alternative (self-signed onion and ca-signed onion both 'green') is also problematic 19:38:42 s/messing/confusing 19:38:50 isa: http://design.firefox.com/icons/viewer/ 19:38:50 tjr: i think to resolve (2) we need to go over the possibilities and write positives/negatives 19:39:07 check the permissions set. Critical actions has an specific icon 19:39:29 I documented the states (began documenting?) in the pad at the bottom 19:39:56 antonela: i mean like how you have the onion with the yellow triangulo 19:40:08 yes, we can explore that 19:40:16 antonela: onion with a little padlock like that 19:40:21 yes yes 19:40:28 cool 19:40:29 :) 19:42:53 ok guys i need to get out in a bit 19:42:56 should we summarize? 19:43:32 i would say, if you can get the rhaps we should explicitly list these different schemes, and detail their positives/negativesa? 19:43:39 sorry 19:43:43 bad pasting 19:43:46 but 19:43:51 1. list of different schemes 19:43:56 2. update google doc 19:44:07 3. anto will play with different representations 19:44:14 that is for this ticket 19:44:17 [4. asn works on #21952 backend proposal] 19:44:20 yes 19:44:24 ok sounds good 19:44:26 that seems reasonable to me 19:44:33 circuits are not here today? 19:44:43 ? 19:44:49 this one #24309 19:44:57 no, not today 19:44:57 no :) 19:45:00 oh cool 19:45:00 hm thats not even on the pad? 19:45:15 that is more GeKo and arthuredelstein 19:45:18 ack 19:45:18 but we can do it next week 19:45:19 :) 19:45:21 ok great 19:45:26 next meeting next week or next next week? 19:45:35 (too much nexting) 19:45:42 i mean, me and antonela can follow up with TB another time 19:45:43 on that one 19:45:47 hehehe 19:45:58 yes :) 19:46:08 asn: next week a bunch of people are at the all hands meeting 19:46:34 ok so let's do two weeks from now 19:46:36 thus, guess next nexet might be better although i will already be traveling 19:46:52 (christmas stuff) 19:47:41 hm ok 19:47:47 if u cant do it that day geko, maybe send mail to thread? 19:47:53 we can pick another week day 19:47:57 i doubt we can find a better date right now 19:48:08 yeah 19:48:11 we can do via email 19:48:13 doodle etc 19:48:21 yes that always works great! (j/k) 19:48:25 ok ending the meeting! 19:48:26 lol 19:48:27 #endmeeting