14:59:24 <richard> #startmeeting Tor Browser Weekly Meeting 2023-12-04 14:59:24 <MeetBot> Meeting started Mon Dec 4 14:59:24 2023 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:44 <richard> the pad: - added new pluggable transports: 14:59:44 <richard> - conjure 14:59:44 <richard> - WebTunnel 14:59:51 <richard> um 14:59:53 <richard> the pad: https://pad.riseup.net/p/tor-tbb-keep 15:00:24 <jagtalon> o/ 15:00:42 <richard> coming up this week we have an unplanned stable release of Tor and Mullvad Browsers to fix a Wayland crash bug 15:00:48 <richard> thanks a lot wayland 15:01:32 <richard> Our signing machine has been moved to it's forever home a few shelves up in the rack where it lives with other various servers and switches 15:01:39 <richard> and the mac signer is being *decomissioned* 15:02:10 <donuts> belated o/ 15:02:25 <Jeremy_Rand_36C3[m]> Hmm, I run Tor Browser on Wayland routinely, wonder why I never hit this 15:03:03 <PieroV> Jeremy_Rand_36C3[m]: it was a recent (13.0aX I think?) change on our side 15:03:18 <PieroV> And in my tests it happened especially on privileged about: pages 15:03:52 <richard> and my final discussion point, OpenH264! (tor-browser#15910) 15:05:10 <Jeremy_Rand_36C3[m]> PieroV: hmm, one of my Tor Browser instances on Wayland is running Nightly. I'm a tad surprised didn't see it there, but I don't mess with about: pages much. 15:05:11 <richard> I've already ping'd the relevant people in the issue, but for general discussion I'd like to see if we can add/upstream reproducible build support to the OpenH264 codec, so that when UDP is available in the tor network we'll have that for WebRTC (and also for Mullvad Browser in the nearer future) 15:05:30 <PieroV> Jeremy_Rand_36C3[m]: it happens when you open (or close? I don't remember already) extension panels 15:05:40 <ma1> open 15:05:43 <PieroV> But they need to be pinned 15:05:45 <Jeremy_Rand_36C3[m]> PieroV: ah, that might have evaded my notice then 15:06:19 <richard> obviously that's a longer-term project but i expect that the political/organisational effort of getting upstream to take our patches/deploying new reproducible binaries 15:07:10 <PieroV> \o/ 15:07:13 <dan_b> do we know how often it changes/updates? 15:07:19 <richard> in the relatively near future i'd like to make sure we have a technical plan on the books that is up-to-date and would work for Tor+Mullvad Browsers 15:07:30 <dan_b> ie: if we take a sha sum of it and hardcode it, how long's that good for? 15:07:44 <richard> (ie so some time soon after the s96 deliverables are out the door) 15:07:53 <PieroV> dan_b: we have nightly builds 15:08:03 <PieroV> So, we should be able to catch changes 15:08:20 <clairehurst> 15:08:26 <richard> 15:08:31 <PieroV> And maybe it isn't important if we mirror the binary 15:08:49 <PieroV> (but I don't know, I haven't read the license or whatever) 15:09:00 <richard> PieroV: yeah so the problem with OpenH264 is completley artificial 15:09:08 <dan_b> i think the license says we have to download from them 15:09:19 <PieroV> dan_b: I think it's built from them 15:09:21 <richard> basically we can only 'legally' deploy/use OpenH264 if we use their binary, even tho it is open source 15:09:33 <PieroV> But not downloaded from them 15:09:47 <PieroV> richard: I know, patent trolls 15:09:58 <richard> but if it were reproducible, we could then build locally, insert the expect hash and/or sign it in tor browser, and verify the downloaded blob is as expected 15:10:14 <richard> anyway that's the dream 15:10:28 <ma1> is their building system open source as well? 15:10:53 <richard> micah: openh264 chat for you information^ ;) 15:11:00 <richard> ma1: at this point kind of unknown 15:11:21 <Jeremy_Rand_36C3[m]> Maybe a dumb question here but why not just use a codec that doesn't have this kind of ridiculous license? 15:11:24 <PieroV> ma1: the Makefile is public: https://github.com/cisco/openh264 15:11:36 <boklm> by "open source", you mean "source available"? 15:12:01 <PieroV> Jeremy_Rand_36C3[m]: probably standards, or licensee that don't care and support only H.264 (e.g., because they do it in hardware) 15:12:03 <richard> jeremy: because unfortunately openh264 is apparently part of the webrtc spec, and so by not having that codec vasrious webrtc things don't work 15:12:23 <PieroV> boklm: BSD 2-Clause "Simplified" License 15:12:24 <Jeremy_Rand_36C3[m]> Is there not a fallback in WebRTC to VP9 or something...? 15:12:25 <richard> (is my understanding) 15:12:36 <Jeremy_Rand_36C3[m]> If so that sounds like the spec should be rejected by implementations 15:12:39 <PieroV> Source code is not the problem, patents on the codec are the problem 15:13:23 <boklm> ah so the problem is not source code license, but patent license 15:13:31 <richard> boklm: precisely 15:13:35 <Jeremy_Rand_36C3[m]> Which browsers are mandating H264? I assume Google isn't since they're the ones behind VP9 et al 15:14:01 <richard> iirc webrtc is/was a fully google thing 15:14:04 <richard> so you'd have to ask them 15:14:11 <Jeremy_Rand_36C3[m]> sigh 15:14:25 <Jeremy_Rand_36C3[m]> The Web is a horrible place 15:14:31 <Jeremy_Rand_36C3[m]> Anyway carry on 15:14:31 <richard> ^agreed 15:14:34 <PieroV> Jeremy_Rand_36C3[m]: the standard says browsers must support VP8 and H.264 according to https://developer.mozilla.org/en-US/docs/Web/Media/Formats/WebRTC_codecs 15:15:03 <PieroV> And also on RFC 7742: https://datatracker.ietf.org/doc/html/rfc7742 15:15:28 * Jeremy_Rand_36C3[m] is surprised that IETF approved an RFC that mandates patent-restricted stuff 15:15:36 <Jeremy_Rand_36C3[m]> That's kind of out of character for them I think? 15:15:58 <PieroV> There's a paragraph about royalty free codecs 15:16:33 <richard> ok, PieroV let's ove on to your point 15:16:46 <Jeremy_Rand_36C3[m]> Anyway I won't derail the discussion anymore, my opinion is that simply rejecting the spec is reasonable, but I'm clearly outvoted 15:16:46 <richard> and then we can do a s96 update/discussion 15:16:47 <PieroV> I have two actually 15:17:09 <PieroV> Jeremy_Rand_36C3[m]: WebRTC is Mullvad Browser 15:17:18 <PieroV> And the H.264 request comes from the sponsor themselves 15:17:37 <PieroV> But might be useful to Tor Browser as well in the future 15:18:05 <PieroV> Anyway, my first point is an announcement 15:18:49 <PieroV> I realized I've written several scripts over the time. Some of them live in GitLab comments, in some issue and might be hard to find, other scripts live only in my devices, and finally some scripts might have been lost 15:19:16 <PieroV> So, I decided to just publish them in a personal repository: https://gitlab.torproject.org/pierov/lazy-scripts/ 15:19:43 <PieroV> If we think some of them are useful, we might polish/refine them and include in the official repositories 15:20:21 <PieroV> But usually they've been used for some simple/limited cases, and I didn't expect to run them again, so they don't handle possible corner case etc etc 15:20:45 <PieroV> Or they take some structure for granted (the one I have in my machine, even though some details might be common in all our setups) 15:21:33 <PieroV> Then I also have a discussion point 15:22:14 <PieroV> The crash is related to the clipboard cleaning feature... IIRC, we had some complains about it, and I had some difficulties in getting the cases it covers 15:22:45 <PieroV> Because content doesn't have access to clipboard for reading in Firefox (except for the paste event) 15:23:56 <PieroV> And in general, yes, it avoids some linkability about what you've copied when you were using Tor Browser, but while you're using it we can't do anything 15:24:16 <PieroV> So, I was wondering if the cases we try to protect are enough to justify the usability complains 15:24:28 <PieroV> So, I could came up with a possible scenarios: 15:25:19 <PieroV> * (a couple of possible scenarios) 1. shared computers, you want the browser to clean up the last thing you copied when you close the browser because someone else needs to use that computer 15:25:39 <PieroV> 2. users who don't multitasks while using Tor Browser 15:27:02 <ma1> The case as I understand it is about "doing private stuff in private windows (or browser)" and reducing the possibility I accidentally leave something embarassing / incriminating in the clipboard after I'm done, for me or someone else to paste accidentally where they shouldn't (which is basically both of your cases) 15:27:41 <PieroV> Before finding them I was wondering if the patch made sense to be a thing (if a user asked me why we have it, I couldn't really explain a reason - but I think I found them) 15:28:38 <dan_b> so are we disabeling the entire patch short term? just on wayland? i assume a wayland specific work around is a bit longer term? 15:29:02 <ma1> dan_b, I've actually fixed and backported the fix 15:29:10 <dan_b> oh, ok amazing 15:29:17 <PieroV> dan_b: the workaround is scheduling what we were doing with setTimeout(callback, 0) 15:29:24 <dan_b> aaaah 15:29:30 <PieroV> (nice trick, ma1 :)) 15:29:56 <richard> :D 15:29:56 <PieroV> But I think we should somehow report the possibility of this problem to upstream 15:30:04 <ma1> (and while we were at that, working around Wayland not emptying the clipboard at all because... someone forgot to implement emptyClipboard()?) 15:30:05 <richard> yes please^ 15:30:20 <richard> ma1: in Wayland or in Firefox? 15:30:48 <ma1> richard, to be investigated. I suspect in Wayland, though, after having looked at other mozbugs 15:31:20 <PieroV> I wonder if the Wayland clipboard implementation is breaking some Firefox assumption (additional main iteration), or if the code that breaks didn't take that possibility into account 15:31:40 <PieroV> So, I'm not sure on which component we should open the issue 15:31:57 <richard> and is that a thing implementedin wayland or in the compositor >:[ 15:32:02 <richard> oh which there are N 15:32:25 <Jeremy_Rand_36C3[m]> richard: Wayland itself isn't an implementation, it's like HTTP 15:32:26 <PieroV> But basically, it's a use after free that happens because probably stuff is moved with raw pointer instead of one of the smart pointers Moz uses 15:32:35 <ma1> PieroV, I've linked a moz meta-bug in our issue, you can take inspiration from 15:32:45 <dan_b> if our code works on everything but wayland it def feels like it's a wayland issue? 15:32:57 <PieroV> dan_b: not really 15:33:07 <PieroV> So, clipboard querying is async also on X11 15:33:21 <PieroV> But there's a difference between X11 and Wayland on Moz clipboard implementation 15:33:30 <dan_b> ha 15:33:56 <PieroV> The Wayland implementation tells GTK to run a main loop iteration if it doesn't receive an answer within a certain timeout 15:34:05 <dan_b> well that might be good. i suspect we have a better chance to get moz to take a patch than wayland? 15:34:24 <PieroV> So, it isn't a Wayland/compositor problem, but it's a Moz problem 15:35:07 <richard> fun 15:35:12 <PieroV> (for the crash, not sure about the empty clipboard) 15:36:18 <PieroV> Anyway, for my discussion point 15:36:36 <PieroV> I was suggesting us reconsidering the patch and remove it if needed 15:36:51 <PieroV> (not necessarily during the meeting) 15:37:40 <richard> I think longer term this is something that should probably be configurable by the user 15:38:01 <richard> but i think the updated threat-model and any designs that come out of that will inform this as well 15:38:09 <PieroV> Yes 15:38:19 <richard> ok anyway 15:38:24 <PieroV> I'll also add a comment with the cases I came up with to the original issues 15:38:32 <richard> perfect^ 15:38:35 <richard> shall we move on to s96 updates? 15:38:37 <PieroV> And ping tjr on the crash issue to ask a suggestion on how to open a Bug 15:39:11 <micah> richard: thanks, helpful for my pinging 15:39:13 <richard> also 20 minute timecheck :) 15:39:25 <PieroV> Yes, I'm good :) 15:39:40 <richard> dan_b+claire how are things going in android-land 15:39:50 <richard> and i believe henry-x is afk today 15:40:41 <dan_b> I'll be looking at plumbing today for settings that need to go to geckoview 15:41:05 <PieroV> I've discovered there will be additional plumbing to do 15:41:11 <dan_b> unsurprised 15:41:13 <PieroV> For the status changes 15:41:14 <dan_b> what'd you find? 15:41:21 <PieroV> E.g., Tor bootstrapped, Tor bootstrapping and so on 15:41:38 <PieroV> In particular, the Tor Bootstrapped one is launching a NoScript update 15:41:47 <dan_b> in geckoview? 15:41:54 <PieroV> Nope, in firefox-android 15:42:04 <dan_b> ah, and we need to preserve that, cool 15:42:26 <PieroV> In general, there's an interface for Tor events 15:42:36 <PieroV> We should have a look at the implementors 15:42:43 <dan_b> in our TorController? 15:43:33 <PieroV> Yes, it's defined in fenix/app/src/main/java/org/mozilla/fenix/tor/TorController.kt 15:43:38 <dan_b> yea 15:43:46 <PieroV> interface TorEvents 15:44:14 <dan_b> that's kinda the firefox-android interface to the old tor-android-service, so ideally we can rewire it to work with tor on geckoview 15:45:39 <dan_b> of which there may be a few options. a bunch of what it does is over control port, so we can take just those parts from tor-android-service and it should still work with the tor started by geckoview I believe 15:46:11 <dan_b> or we can look into how to wire communications to the tor implementation in geckoview? did you have thoughts? 15:46:26 <PieroV> I'd chose the latter 15:46:46 <PieroV> Possibly, nothing should keep the control port in mind 15:47:00 <dan_b> fair 15:47:05 <dan_b> ok 15:47:13 <PieroV> But they should be modeled around the TorProvider 15:47:24 <PieroV> So that creating the ArtiProvider when it's time will be easier 15:47:37 <dan_b> cool 15:48:10 <clairehurst> Pretty good, things are moving along smoothly. I got the strings added for translators to translate for the new connection assist, cleaned up the MR's, and am trying to get the new screens to be an opt in toggle. I also read through PieroV's MR for the backend stuff, looking up a bunch of stuff, and I think I understand it better. 15:49:58 <richard> yeah control port should be encapsulated/hidden within the legacy TorProvider 15:50:10 <richard> and maybe in a year we can never speak of it again ;) 15:53:07 <richard> ok then, if there's nothing else 15:53:11 <richard> shall we end this? 15:53:38 <thorin> speaking of coffee .. we need time for things to percolate - https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42289 15:54:10 <thorin> that's all I have to say - thanks for listening :) 15:54:16 <richard> <3 15:54:24 <richard> ok later y'all 15:54:27 <richard> have a good week o/ 15:54:28 <dan_b> ooh nice list 15:54:37 <Jeremy_Rand_36C3[m]> Thanks! 15:54:38 <richard> #endmeeting