15:01:33 #startmeeting Tor Browser Weekly Meeting 2024-07-15 15:01:33 Meeting started Mon Jul 15 15:01:33 2024 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:33 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:51 o/ 15:01:52 o/ 15:01:57 i hope everyone had a refreshing weekend 15:02:03 here's the pad as usual -> https://pad.riseup.net/p/tor-tbb-keep 15:02:33 /o 15:02:53 my first live meeting in the last 5 .. you are all truly blessed 15:03:14 undead thorin is also welcome we don't discriminate :D 15:03:34 just popping in to say i'm taking a sick day 15:03:49 reports of my demise are greatly exaggerated .. let's talk about fingerprinting 15:04:02 ack dan_b 15:04:05 dan_b: get well 15:04:26 get well soon dan_b! 15:04:43 * ma1 hugs dan_b 15:05:13 o/ 15:05:16 dan_b <3 get weel 15:05:20 well lol 15:08:42 ok let's start with our discussion points 15:08:45 PieroV? 15:09:13 Today I've updated the description of the review issue to make it easier to track its state 15:09:29 And if I'm not wrong I think the only commit left unreviewed is onion security expectations 15:09:59 (but I grouped the various WebRTC/mingw commits together as "need work") 15:10:48 However, most of the commits have only one reviewer. Though I think it's enough to merge the MR 15:11:26 Does anyone oppose to proceed with it? 15:11:54 I have no objections 15:11:57 Then, since we have the 128.0 release tag, we can already rebase also on top of that (the current MR is on top of b1) 15:12:28 how extensive/invasive are henry-x's suggestions? 15:12:58 I don't know, they mentioned they had some on IRC 15:13:20 But we potentially have some fixups from brizental to fix linter's problems 15:13:46 richard what suggestions are you refering to? 15:13:50 So, I don't know if she wants to open that MR instead 15:13:59 PieroV: that will be an MR after you merge the rebase though, right? 15:14:08 henry-x: IIRC, you asked me if I was going to do reshuffling of commits because you had some suggestions 15:14:22 brizental: yes 15:14:41 brizental: but we have to decide the order in which we want to do things 15:14:54 oh right, yeah but that was for a later MR 15:15:23 I.e., first I merge, then you open a MR for a -2 based on b1, or a -1 on FIREFOX_128_0esr_RELEASE 15:15:26 PieroV: what are the other options othen than you merge the rebase MR and then I open an Mr with the linter fixups? 15:15:44 henry-x: yep, but we are ready for a second MR after the first one gets merged :) 15:16:27 ok, let me know where I should put the suggestions 15:17:01 PieroV: tbh I don't understand what you mean lol, whatever you think is the way to go here i will just follow 15:17:24 ok then, let's plan on merging current to the 128.0b1 branch and subsequent shuffles/invasive on a 128.0b1-2 (with goal of no-conflict diff-of-diffs if possible) 15:17:36 then rebase *that* to 128.0esr 15:17:41 and then we can take brizental's fixups 15:18:00 So, there would be a reason to to the rebase on 128.0 soon 15:18:25 And it's that I've already cherry-picked the commit for switching from l10n-central to GitHub/firefox-l10n 15:18:37 Hi, sorry I'm late -- had a few VM's with memory leaks that made my machine unusable this morning 15:18:44 * Jeremy_Rand_36C3[m] catching up on scrollback 15:18:58 o/ no worries Jeremy 15:19:51 brizental: how is your linted branch? 15:20:44 IIRC, you linted in fixups 15:21:12 then perhaps we kick the reshuffle to a 128.0esr-2 branch before rebasing to 128.1esr in in a few weeks, if we think this doing so will block the 14.0a1 too long 15:21:19 PieroV: in need of a rebase after your latest changes :) but then ready to go. most commits have fixups to them though, just fyi 15:22:01 brizental: that's great. Doing that in fixups will make it easier to review :) 15:22:40 In this way it should be easy to use range-diff on it 15:23:04 from that work i noticed some things that might benefit from some reshouffling too e.g. toruiutils being used in commits prior to the commit when it is implemented 15:24:21 are we happy with the above reshuffling/rebase/branch plan? 15:24:50 It isn't clear to me 15:25:22 richard: what's your proposal? 15:26:46 merge 128.0b1 as is or close to as is, rebase to 128.0esr, sometime before 14.0a2, create a 128.0esr-2 branch with henry-x's proposed shuffling/reordering/improvements, rebase 128.0esr-2 to 128.1esr for 14.0a2 15:27:20 (under the presumption that the invasive patch work will take some time to review and would block 14.0a1 if we did it now) 15:27:29 wfm. 15:28:04 brizental: I think that would require some changes to your linted branch, but they shouln't be too hard. I can help you with that 15:28:23 It will be mostly to run a `git rebase -i` with the new tag 15:29:49 PieroV: that's fine. it's just not clear to me if i should hold the rebase for before or after the reshuffling 15:30:41 brizental: I think you should plan on merging your fixup!'s into the 14.0a1 branch (ie before the reshuffle) 15:30:46 brizental: my new MR will do some minor shuffling (of the fixups), but that can be done with --autosquash and then replacing fixup with pick 15:31:01 But we can wait for the major ones after the linting 15:31:35 (so the pending 128.0esr-based branch) 15:31:46 richard: got it 15:32:21 in the meantime, i'm sure 128.0b1 is close enough for any continued dev work and you can cherry-pick them to 128.0 this/next week 15:32:36 The branch on 128 is ready 15:32:40 And I also did some builds 15:32:45 :D 15:32:53 (I was optimistic and hoped for no requests of changes) 15:33:09 And we'll need to review also MB 15:33:14 But at least now the base-browser part is ready 15:33:40 honestly the tor-browser diff-of-diffs is pretty manageable, more than usual but still pretty understandable and mostly trivial changes :) 15:34:06 but anywya, hopefully the MB review will be more straight forward 15:34:06 (I also have a MB branch, but it's missing the patch for building with gnullvm on Windows) 15:35:28 I think I'm done for my point 15:35:43 ok 15:35:46 onto the second point 15:36:21 so I did the math this weekend, and discovered we likely have an uncomfortable number of Windows 7 users :/ 15:36:52 * donuts is listening... 15:36:52 and users are asking about how Mozilla extending Win 7 support affects Tor Browser 15:37:20 i made a big effort-post about it here -> https://forum.torproject.org/t/tor-legacy-support-for-no-telemetry-winos-users/11879/6 15:37:36 I read the IRC messages but not the post 15:37:42 But I don't think the math is correct ^_^ 15:37:57 make all win7 users donate $1mn US between them and we'll consider it 15:37:57 Take for example the numbers about Linux and macOS 15:38:34 well yeah, the specifics on the math are hand-wavy guess-work 15:38:41 i read it! the post is very good, but i'm a little wary of communicating potential plans to users on the forum until we've had any clarification from Moz 15:38:51 We probably have more Linux and macOS users in proportion than Firefox 15:39:02 oh yeah we definitely do 15:39:12 i was surprised by how small their non-Windows user numbers are 15:39:31 So, the numbers might be okay, but taking the premise as correct is a bit hard to justify having two channels 15:39:37 And the feedback we receive is also very biased 15:39:52 but regardless, i think the point is the number of Win 7 users isn't quite as close to 0 as we'd like 15:39:53 I think the way you outlined the potential complications of continued support was great however (i.e. it's not just a simple case of maintaining support for whatever ESR gets blessed with extended Win 7 support) 15:40:26 yeah, so what I would *really* like to do is not maintain 13.5 indefinitely 15:40:41 A good news is that we might not need to do a watershed 15:40:47 oh? 15:40:51 Instead we could specify the OS in the XML 15:41:05 And have multiple entry, one for Windows 7 and one for the other Windows versions 15:41:13 But I'm not sure 15:41:14 but we need a watershed to do that? 15:41:17 yeah^ 15:41:22 because we're not doing that 15:41:29 We can specify the minimum OS version 15:41:33 Without a watershed 15:41:46 So that Windows 7/8 users won't download the 14.0 updates 15:41:53 I don't know if we can specify a maximum version 15:42:06 but they won't download the version that changes the update URL either 15:42:08 Maybe we can, or maybe order matters 15:42:14 Offering a sample-size 1 data-point: a relative has a Win7 machine that runs Tor Browser and she is not willing to use newer Windows. Her reaction to Win7 being dropped from Tor Browser is that she's going to switch that machine to Linux before Tor Browser updates stop flowing. 15:42:27 It would be interesting if we had any way to measure how common this reaction is 15:42:33 jeremy: well one success story at least 15:42:44 boklm: the watershed will be only for Windows 7 users 15:43:19 well ok, the specifics of how/if/when a watershed is needed can be determined offline, but we should figure that out sooner rather than later 15:43:58 (Do we have any way to measure this? Does Tor Project have any kind of user survey infrastructure that could be used?) 15:44:24 anyway, if people could take a look at that post and and identify other problems we would have w/ regards to maintenance overhead 15:44:29 Jeremy_Rand_36C3[m]: we removed the OS version information from the update ping URL 15:44:49 So, the only way we would have to know this is asking users directly 15:44:55 exactly^ 15:44:56 Which will have biases 15:44:58 and users lie >:[ 15:44:59 and we don't have logs with the user agent, right? 15:45:00 PieroV: yeah I'm more thinking of, can we ask users how they intend to respond to the Win7 support being dropped 15:45:22 I know Tor affiliated people have done user surveys in the past but I don't know the logistical details 15:45:44 Jeremy_Rand_36C3[m]: we can. But will it give us good results? 15:45:57 I suppose i should open or use an existing meta ticket for discussions on this 15:46:02 I believe all Win 7 and 8 people will reply, but many not interested people will not 15:46:06 PieroV: I don't know. But having more information is probably not worse than having less information. 15:46:30 We've deployed user surveys on about:tor in the past and I think it's an interesting idea, but I would really really like clarity from Moz before we do *anything* 15:46:42 I'm wondering how long Mozilla will be maintaining this branch, but if it's just for something like 3 months, I'm not sure it's worth all the work we need to do to support different branches 15:46:45 because survey participants are going to want clarification anyway 15:46:55 yeah exactly re how long they intend to support 15:46:59 To be clear, I am not very concerned about how many Win7 users we have, I am more interested in whether the Win7 users we do have plan to keep using unmaintained TB, upgrade to Win10, switch to Linux, stop using TB at all, etc 15:47:09 that's arguably the most frustrating thing is that nobody seems to know how long they'll be doing this 15:47:22 we could fingerprint them all and TZP can tell the difference via fonts and other win7 only settings :) 15:47:34 Is there any reason to think Win7 users would lie about that question? 15:47:36 thorin: I *did* consider that 15:47:36 Jeremy_Rand_36C3[m]: that's an interesting take 15:48:07 thorin, they *deserve* this >:) (kidding) 15:48:45 that's definitely an ethical grey area tho lol 15:49:04 and at that point may as well just query the os and send a telemtry ping as it's equivalent 15:49:50 richard: I mean, you could also query the OS and point them to an opt-in response form where we could ask them about what I just described :) 15:50:03 Which seems a lot less ethically dubious 15:50:24 I don't think they'd lie, but we don't really have a mechanism to stop participants from submitting multiple responses without tracking them 15:50:35 donuts: exactly 15:50:52 i.e. if we allow anonymous responses, I don't think there's anything to stop them submitting more than one 15:51:21 donuts: how do existing Tor-related studies deal with that? Does Tor explicitly reach out to known users instead of soliciting public responses? 15:51:54 (You'd think I'd know how this works by now, but I've never paid much attention to those details for whatever reason...) 15:52:15 in any event, we can follow up in a meta issue 15:52:20 Yeah makes sense 15:52:27 richard: feel free to tag me in the meta issue if you like 15:53:23 but the open issues are basically: how do we determine what the impact of maintenance would be, how much work would maintenance be, and what does a legacy 13.5 branch even look like semi-long term/is it worth it if everything breaks in 6 months for non-Firefox related reasons 15:53:31 harumph 15:53:53 I don't think the maintenance cost would be *too* high 15:53:56 Still bigger than 0 15:54:12 But maybe it'll be like a release channel 15:54:17 donuts: how do existing Tor-related studies deal with that? <- For mass quantitative studies (which we don't do that often), we don't deal with it – essentially 15:54:18 I.e., rebase on top of Moz 15:54:21 besides removing obvious abuse 15:54:40 But we don't know _if_ this is a thing yet 15:54:59 And if it is, how long it will last 15:55:25 i suspect it may be smart to invest a *little* during this ESR cycle to ensure Win 7 users aren't left at a dead-end if it turns out we do want to a legacy 13.5 channel 15:55:37 can we just tell windows 7 users "use a Tails VM or stick"? 15:55:38 presuming it does't get in the way of the other requried work 15:55:46 * Jeremy_Rand_36C3[m] notes that Namecoin stopped working on Win7 circa last year (due to upstream breakage) and I'm not likely to try to reinstate support, so you can add optional Namecoin support in Nightly to the list of Tor Browser functionality that will not ever work on Win7 15:56:24 ma1: that's what i've been telling folks, but i suspect 'just use linux' is kind of a non-starter for the majority of Windows users 15:56:50 for primary material-conditions related reasons :p 15:56:56 "just for your dirty... er... anonymous browsing" 15:57:00 ma1: a Debian or Fedora live distro is going to be a lot more usable for most Windows users than Tails specifically, I'm guessing 15:57:00 Well, Windows 7 went EOL Jan 14 2020 15:57:10 TZP will drop ESR115 as smart when 14 becomes stable 15:57:14 We've already extended support for 4 years and a half 15:57:29 Been a while since I tried to use a Linux VM on Windows but last I heard the UX wasn't miserable there either 15:57:43 and yet, 11% of windows users are still on Windows 7 per mozilla telemetry vOv 15:57:48 Timecheck! 15:57:52 yep 15:58:14 I mean, at some point Win7 users are going to have to stop using it 15:58:21 anyway, we can ~yell at each other~ politely discuss this in gitlab 15:58:24 o/ 15:58:26 And in most cases this will be catalyzed by some external event 15:58:36 anyway, have a good week folks 15:58:39 https://github.com/arkenfox/TZP/blob/d24e690af399997c329f27acc39a657a89ae9b3f/js/globals.js#L185 - not going to maintain it for old versions 15:58:40 o/ 15:58:41 thanks! 15:58:50 #endmeeting