19:03:21 #startmeeting security settings redesign 19:03:21 Meeting started Wed Nov 7 19:03:21 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:21 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:03:25 alright 19:03:39 antonela: do you want to summarize where we are right now? 19:03:47 yep sure 19:03:52 and what open questions we still have and need to tackle? 19:04:14 just in case, here is geko's proposal https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt 19:04:49 2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar - OK 19:05:28 2.1.2 Showing Security Slider State - I made a proposal https://trac.torproject.org/projects/tor/ticket/25658#comment:48 19:05:47 basically, we want to expose the status of the security setting at the main UI 19:06:05 2.1.3 Reorganizing the Toolbar - OK 19:06:08 hi everyone! 19:06:20 2.2 Dealing with Per-Site Security Settings - here we come 19:06:46 we should talk about it 19:07:03 3.x Restore Default Security Settings - is not in the proposal, but i suggested a user flow for it 19:07:26 2.1.2.X Change Security Level and Restart to Apply Changes - is not at the proposal, but i made a suggestion too 19:07:59 so basically we need to talk about 1. all good with that icon? 2. per-site security settings 19:08:11 GeKo please, jump if im missing anything 19:09:08 i made a quick prototype to see how the icon opens the global settings -- https://marvelapp.com/a66fg97/screen/50052842 19:10:44 R.e. the prototype, I did not realize that the newest thinking was that there would not be a toolbar dropdown. 19:11:10 I liked it better with the dropdown. Directly opening about:preferences seems too abrupt somehow. 19:11:49 mcs what should we have in the dropdown? the previous version included some description about what we are enabling and what not 19:12:10 antonela: what is the difference between safer and safest icon-wise? (i am looking at 25658-8.png) 19:12:19 there is not 19:12:21 antonela: yes, that kind of status information. 19:13:41 antonela: how do users see easily on which security level they are then? 19:15:14 mcs https://share.riseup.net/#E24D-DsXdWxJ5Wn9ABhDTg this one 19:15:18 (+ i agree with mcs that we should avoid just color-coding the security level) 19:15:58 antonela: yes, that is what I expected to see when I click the toolbar icon. 19:16:06 s/click/clicked/ 19:16:34 GeKo, do you want the doorhanger too? 19:20:06 so, doorhanger woul dmean it opens some thing informing users about the security state by including info about what it does and gives the optin to open something in about:preferences where users can select different levels? 19:20:35 yes 19:20:41 (instead of just opening about:preferences directly) 19:20:44 yes 19:20:55 i think i don't have a strong opinion here 19:21:09 i am fine starting either way and see how it goes 19:21:14 which is the same information we will have in about:preferences#security 19:21:16 about the difference between safer and safest, the security level behavior will change depending on how we will allow js or active content temporary, so i'm not sure if makes sense on having a different color/label for the two highest levels. If we have the door hanger, we could have more info there. 19:22:10 antonela: that's true that users change things but we are talking about the defaults 19:22:32 i mean if users think they should deviate from those, that's fine 19:22:40 but i don't think we should optimize for that case 19:22:42 My argument for the doorhanger is that opening and dismissing a doorhanger is lower cost for the user. It also discourages people from messing around in about:preferences. 19:23:31 good point 19:24:36 I like the door hanger because it’s not as overwhelming as taking users directly to about:prefferences#security 19:24:52 yes 19:24:59 I think the idea of putting it in about#preferences was to emphasize that the security settings are global 19:25:00 okey, lets go with the doorhanger 19:25:01 +1 keeping users out of about preferences seems like a good idea 19:25:31 ...and also to discourage users from changing the global settings too often 19:25:52 arthuredelstein: I don’t have a problem taking users there if they know that’s what they want 19:26:03 yes, you get both with the doorhanger, though 19:26:53 and would the per-site settings be in the same doorhanger? Or in the identity box doorhanger? 19:26:55 fwiw: the button on the toolbar already indicates that this is a global thing 19:27:33 arthuredelstein: ha! 19:27:34 i think we should follow firefox here and put that in the identity box 19:27:46 yes, im with geko 19:27:55 where all the other permissions are dealt with 19:28:00 +1 19:28:10 and then we have https://marvelapp.com/a66fg97/screen/50052852 19:28:41 That makes sense to me. I guess I'm thinking by analogy there is a "gear" icon in the Tracking Protection section of the identity box doorhanger. That takes the user to about:preferences for the global tracking settings 19:29:17 (in Firefox) 19:30:03 But maybe in this case it would open the other doorhanger? 19:30:15 oh no 19:30:18 no 19:30:32 the gear should keep the same behaviour, now in FF is going to about:preferences#privacy 19:30:54 when does the gear showing up? 19:31:05 because i can't see it right now 19:31:11 always 19:31:15 no 19:31:30 i don't have it in my tor browser 19:31:32 What I'm wondering is: if we have a section for per-site Security Permission in Tor Browser, do we want a gear icon to take the user to the global Security Settings? 19:31:40 It doesn't exist in Tor Browser right now. 19:31:54 But something to show the connection between per-site and global settings might be helpful 19:32:00 FF63 - https://share.riseup.net/#FcwKCEU3N_rRcZ2CcRP7AQ 19:32:02 Just as is done for Tracking Protection in Firefox 19:32:10 Following Firefox’s lead to have a gear icon that takes users to the settings may make sense. 19:32:43 (In antonela's screenshot, Content Block ~== Tracking Protection) 19:32:47 hm 19:32:57 On the other hand, it could cause some confusion. 19:33:18 e.g., temporary site-specific settings vs. global security level. 19:33:18 i wonder if we can cross that bridge when switching to esr68? 19:33:45 i mean it seems this "feature" is not in esr60 yet 19:34:26 arthuredelstein: what do you mean with "connecion between per-site and global settings"? 19:34:35 you have the icon for global setting on the toolbar 19:34:49 and if you are opening the identity box you see your permissions 19:35:02 as done in firefox 19:35:40 Well, there is a relationship between the two things. When you adjust the per-site setting you are moving off the standard global setting. 19:35:59 JavaScript is disabled, for example, because the global setting is "Safest". 19:36:46 in that case so, the tor browser user is willing to make a video call in jitsi. Tor Browser is at one of the highest security level. Tor Browser will ask permissions for a camera, a micro and the security feature will offer to temporary allow js. 1. is that how will we deal with per-site settings 2. makes sense to have those 2 permissions under the same permissions category? 19:37:16 They're not exactly the same kind of permission. One is a "privacy risk" and the other is a "security risk". 19:38:16 what is a "security risk" and "what is a privacy risk"? 19:38:53 If you are on high security, then you are disabling javascript because it is a "security risk" (a risk of rce) 19:39:51 But camera permission is unrelated to that. Firefox requires browsers to give camera permission because giving every website direct access to your camera without permission would be a privacy disaster. 19:40:04 But not necessarily an rce risk. 19:40:32 So it might be helpful to make this clear to users somehow. 19:41:15 well in the permissions section all sorts of permissions are grouped together 19:41:39 content block *is* the new iteration of tracking protection > https://support.mozilla.org/en-US/kb/tracking-protection 19:41:56 they have their own section at the control center for their new brand feature 19:42:37 hm, i think i lose some understanding how this relates to what we need to decide in this meeting 19:43:22 what is the issue here? 19:43:40 why can't we just show the permissions the user set as on antonela's mockup? 19:43:50 we can! 19:43:59 great! 19:44:45 if we think users allowing things temporarily should get "notified" about that in the toolbar icon 19:44:51 we can think about it 19:45:05 in FF for example, when they allow some thing temporary per site, they have this select 19:45:05 https://share.riseup.net/#wMOphnuxCsY7RvGh0_hPvw 19:45:14 e.g. do we currently have a custom mode that kicks in once a user flips a preference governed by the slider 19:45:33 yes, what i'm thinking is if we deserve our own space in that control center, not under permissions 19:46:16 but hey, we can make this feature grow and think about it in next iterations, I'll be extremely happy if we have *some* per-site permissions to improve websites rendering 19:46:55 antonela: i am fine if we want to group slider related permissions in an own group 19:47:15 might be worth it and might make things clearer 19:47:17 slider R.I.P - security permissions? 19:47:48 what do you mean? 19:48:19 i mean if that group could be called "Security Permissions" or ? 19:49:40 hm 19:49:53 The section could be called “Filtered Features” :) 19:50:27 could be! 19:50:34 More seriously, reusing “Permissions” could be confusing. 19:50:50 (I don’t really like “feature filter” though) 19:51:10 antonela: what about not having a name for it but just a separator? 19:51:17 i like it 19:51:23 i'll try it, may works 19:51:23 to show that it is something different at least 19:51:41 about per-site settings, just JS and Active Content is ok? i have some icons for those but i need to work a little more on them 19:53:22 and then, do you think we could have a list of cases when we are going to suggest/allow temporary js and active content on the two highest levels? 19:53:36 * antonela needs to run in 4 minutes 19:54:20 antonela: i like arthur's idea for just exposing js and active content, yes 19:54:53 i think i don't understand the second question, could you rephrase? 19:55:36 yes, when are the scenarios we are going to suggest/allow temporary permissions per-site? 19:55:41 when/which 19:55:51 antonela: oh, and what about the icon concerns? 19:56:34 exactly, i want to map/make mocks for each case, so if we are allowing js we should have js icon at the nav bar 19:56:57 antonela: i don't know yet because part of this iteration is fixing bugs on the behavior of the safer level e.g. that should make those suggestions not needed 19:57:08 i see 19:58:07 okey, so, I'll update tomorrow an updated mockup with the doorhanger and I'll work on those icons 19:58:33 and could we meet again next week? 19:58:41 i am not sold yet to the idea of showing the permissions directly on the toolbar icon 19:58:54 i fear it might be too confusing 19:59:05 yep, me either 19:59:05 but maybe it works, dunno 19:59:12 let's test it! 19:59:16 this is why i want that list, to test it 19:59:17 yes 19:59:32 well you don't need that list 19:59:48 i don't, but i would like to see how it looks 19:59:56 just use the icon once the user sets the permission no matter what the reason is 20:00:30 and then you are using jitsi, you blocked cam and phone and allowed js and you have 4 icons in your toolbar 20:00:37 there are a lot of scenarios 20:00:49 well that scenario is a non issue :) 20:00:56 ha 20:00:58 jitsi is not working in tor browser 20:01:04 i know 20:01:11 lets say youtube or whatever 20:01:18 but, sure, it gets comlicated quickly :) 20:01:22 *complicated 20:01:25 yep 20:01:33 okay, yes, fine with me with meeting again next week 20:01:44 perfect 20:01:48 i think we have the release meeting at this time, though 20:01:49 geko we are close! 20:01:54 YES! 20:01:56 jijij 20:01:57 :D 20:02:00 ineed to run 20:02:04 thanks people! 20:02:15 okay, we'll figure out a time this week 20:02:19 o/ 20:02:24 thanks all! 20:02:29 #endmeeting