18:00:25 #startmeeting tor browser 18:00:25 Meeting started Mon Apr 30 18:00:25 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:28 hi all! 18:00:34 hi! 18:00:37 welcome to another weekly tor browser meeting 18:00:50 hi 18:00:54 hi!! 18:01:01 let's look at the pad and add notes/mark discussion points bold 18:02:20 ! 18:04:24 o/ 18:07:11 alright, let's get started 18:08:25 mcs: brade: so, while thinking about the updater changes, we want to have a new signing key using 384bit sha in the first esr60-based alpha, right? 18:08:50 GeKo: I think so, yes. 18:09:00 Will that be a problem :) 18:09:03 ? 18:09:28 no, i just have to make sure i don't forget that and get the details right :) 18:09:40 OK; thanks 18:10:10 so, i'd use "-Z SHA384" instead of "-Z SHA512" 18:10:38 when creating the new key and that's the only change? 18:11:12 otherwise, please let me know 18:11:16 I think so, but now I am puzzled as to how brade and I did some updater testing on macOS last week without such a signing key. I will investigate. 18:11:29 heh, good idea :) 18:11:33 :) 18:12:15 okay, it seems no one has an item for the whole group, good 18:12:22 tjr: i have just one for you on the pad 18:12:30 Yup, saw it 18:12:34 thanks for going down that rabbit hole :) 18:12:56 I will write something up yea. It's pretty basic I think, but it feels empowering to start to understand how to navigate assembly 18:13:08 yeah 18:13:36 discussion time i guess then 18:13:40 igt0: you are up 18:14:27 so, about tor browser mobile 18:15:28 we and firefox have the accessibility services enabled, however android allows an app to listen for accessibility events and these events sometimes can be, for example, an user typing in a form. 18:16:01 Few password managers were using those accessibility services to know when an user is typing in an user/password form 18:16:35 so my question here, is everyone okey if we disable accessibility on mobile(accessibility.force_disable = 1)? 18:17:25 What do accessibility services provide for actual accessibility? 18:17:27 do we know what else would break 18:17:31 ? 18:17:48 i haven't researched this, bu i see you provided some research papers on #25902 18:17:59 arthuredelstein, GeKo screen readers will not work. 18:18:05 (i'll read them later) 18:18:24 does firefox emit intents when this is detected? 18:18:41 how does Firefox tell Android, so Android can tell the other apps? 18:19:17 does Android require the user to agree to anything to allow apps to read other apps accesibility events? 18:19:24 or does it just silently happen? 18:19:46 sysrqb, it is not an intent 18:20:02 pospeselr, nop, the app broadcast accessibility events 18:20:22 can we neuter the broadcast code? 18:20:36 wow 18:20:37 ok 18:20:49 firefox has a whitelist 18:20:57 pospeselr: it's being "helpful"! 18:21:22 and we can disable it using the accessibility.force_disabled 18:21:41 oh, but this is how screen readers work? 18:21:48 they listen for these broadcasts? 18:21:55 sysrqb: yeah I would think so 18:22:02 sysrqb, yeah 18:22:11 igt0: What kind of whitelist? 18:23:55 arthuredelstein, By app id, Firefox broadcast those events for few apps. E.g. bitwarden (password manager) 18:24:26 I see, so in principle we could allow screen readers but deny password managers 18:24:34 correct? 18:24:37 ^ 18:24:49 yeah 18:25:17 sounds like things we should explore 18:25:20 So, just to understand, in principle is it true that any whitelisted app could read all the text from whatever web page the user is visiting? 18:25:56 arthuredelstein, yep 18:27:59 igt0: i think it's fine figuring out in a series of alphas what the right balance is for accessibility vs browser lockdown 18:28:09 if we think we need to make a trade-off 18:28:23 (and i think we should do that in this case) 18:29:36 so, i think to answer your question: yes, we care but it's not obvious yet whether disabling accessibility totally is the right choice 18:29:45 it would be kind of shitty to just shut out blind users 18:29:51 yep 18:30:01 indeed 18:30:14 cool, so i will take a look in the whitelist approach. thanks! 18:30:25 sounds good! 18:30:45 oving forward to the next items 18:30:48 *moving 18:30:51 the whitelist approach seems promising, wonder how much work it would be to let users edit it 18:30:53 anyway 18:31:00 extensions first, i think 18:31:16 so, what are our current plans wrt to torbutton and tor-launcher? 18:31:38 do we need more discussion or are we ready to pick an approach and move forward with it? 18:32:05 I can look at tor-launcher this week 18:32:06 we are close to being in the need to actually do something about it 18:32:31 i think we will need two implementations, one for desktop and one for android 18:32:34 given that the clock starts to tick louder and l ouder 18:32:40 *louder 18:32:56 but hopefully we can re-use some of the desktop extension on android 18:33:25 yes 18:33:43 in particular the controller code 18:33:54 sysrqb: so, if you could post some plan this week on the tor launcher ticket that would be great 18:34:17 but we'll need a new UI on android, probably written in java for android 18:34:21 GeKo: sure, will do 18:34:37 for desktop, we need something to insert Torbutton and Tor Launcher as system extensions. I think. 18:34:52 (build process changes or something more) 18:34:53 me too 18:35:03 yes, that was part of the work I did on tor-launcher 18:35:14 i was discussing that with arthuredelstein too 18:36:18 ok. i'd assume we can use the same mechanism for torbutton as for tor-launcher 18:36:24 About torbutton, we need first to separate "backend" from "frontend". There are lot logic that can be reused by both desktop and mobile. 18:36:48 well, not first 18:36:53 that's the second item 18:36:54 yes, the same mechanism should work, and we may be able to continue using the current build process 18:37:11 but i will start testing now we have rebased patches 18:37:14 for ESR60 18:37:39 igt0: i think the first is to just have this work in a desktop environment 18:37:53 with as little changes as possible compared to what we have right now 18:38:04 because the ESR60 clock is ticking 18:38:07 +1 (especially given our schedules) 18:38:15 My thinking is I would start to try that out this week 18:38:21 using the work by sysrqb and igt0 18:38:30 please do 18:38:41 and see if I can build a "working" bundle 18:38:45 sounds good arthuredelstein 18:38:55 +1 18:39:07 i'll look at it, too - i forget exactly where i left it 18:39:35 okay, i'll update the pad later with what we came up with. 18:39:45 last item i have: the upcoming releases 18:40:00 could someone help with the build this time? 18:40:23 I'm happy to help again but also happy if someone else wants to :) 18:40:38 arthuredelstein: ok, sounds good 18:41:03 let us try this again, this time slightly more complex 18:41:17 we have both the stable and the alpha bundles to make 18:41:23 yes 18:41:41 for added fun i planned long ago to be away from my keyboard starting from thursday 18:41:49 and then mozilla moved the releases 18:42:23 my current plan is to tag releases on thursday before i leave 18:42:36 assuming we'll have release tags by then 18:43:23 boklm: we can talk about later what to do if things go wrong and we need additional builds 18:43:43 ok 18:43:56 but my current plan is that you could either do the rebases and tagging yourself, getting the build unstuck 18:44:21 or i'll do the things on monday and we finish the bundles on monday/tuesday 18:44:38 we'll have an extra day this time and mozilla is releasing on wednesday 18:45:02 either way, i think i can do the signing part at least, so we can share the releas load 18:45:14 does that sounds like a plan that could work? 18:45:18 *sound 18:46:07 sounds like a good plan to me. So we plan to tag both stable and alpha on Thursday, correct. 18:46:08 I am planning to be travelling on the wednesday, but I'm expecting to have enough internet to do the publishing 18:46:44 arthuredelstein: yes. 18:47:10 boklm: ok 18:47:29 i guess if things don't work out as expected i could do the publishing part, too 18:47:37 but we'll see 18:47:44 first we need some bundles :) 18:48:08 sysrqb: sorry for just landing the backport. i don't have a good setup for testing orfox builds right now :( 18:48:13 so this looks like a good plan to me 18:48:28 sysrqb: if we need to back out the patch let me know 18:48:34 GeKo: no worries, it looks like there is an easy fix 18:48:44 i understand not being able to test easily 18:49:26 that'll be much better once we have some tor-browser-build integration 18:49:26 i should have a branch ready for reiew later today 18:49:33 yay 18:49:34 yes, for sure 18:49:55 okay, anything else that came up during the meeting and which we should talk about today? 18:50:45 hearing crickets. 18:51:00 thanks all, then and have a nice week *baf* 18:51:06 #endmeeting