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