15:00:18 <morganava> #startmeeting Tor Browser Weekly Meeting 2024-11-25
15:00:18 <MeetBot> Meeting started Mon Nov 25 15:00:18 2024 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:28 <morganava> hi folks, the pad per usual -> https://pad.riseup.net/p/tor-tbb-keep#L254
15:00:32 <ma1> o/
15:00:50 <morganava> please update your todos and todones etc  etc :)
15:01:17 <dan_b> o/
15:02:07 <clairehurst> o/
15:02:19 <morganava> thank you all for the bullet points for the sponsor report last week, very much appreciated :)
15:02:45 <morganava> and a reminder that we have a short week this week due to american thanksgiving
15:03:27 <brizental> o/
15:04:12 <morganava> ma1: i'll update the release-prep changelog asap after this meeting
15:04:23 <henry-x> Are we 100% done with 13.5 builds for mullvad browser?
15:04:50 <morganava> can we get a second (local) builder for 14.0.3 today?
15:04:59 <morganava> henry-x yes they are dead and gone :)
15:04:59 <PieroV> I can build
15:05:44 <henry-x> ok cool, I can start working on improving the localisation process then
15:06:21 <morganava> \
15:06:39 <morganava> \o/
15:07:53 <morganava> PieroV: can you finish the last do-all-signing step for 13.5.10 so your signed mars are deployed to dist.tpo?
15:07:56 <bellatchau> o/
15:08:23 <morganava> i'll plan to sign 14.0.3 tonight if we have hashes
15:09:39 <PieroV> morganava: the staticiforme one?
15:11:34 <boklm> it seems 13.5.10 is on staticiforme, but `static-update-component dist.torproject.org` has not been run yet
15:11:52 <PieroV> Yep, I thought we needed to wait until we wanted to actually deploy
15:12:01 <PieroV> But I can run it immediately
15:13:10 <morganava> ah ok perfect
15:13:24 <morganava> we will need it deployed for me to generatre the updte responses during 14.0.3 signing
15:14:22 <morganava> and finally ma1: you still up for signing 14.5a1 on Wednesday?
15:14:29 <ma1> yep, 14 UTC
15:14:37 <ma1> (before the ESR retro)
15:15:07 <boklm> morganava: I think you'll need to manually download 13.5.10 to your signed directory before signing 14.0.3
15:15:17 <morganava> excellent, you should sync w/ PieroV if you haven't already on any problems you can expect
15:15:26 <ma1> ack
15:15:31 <morganava> boklm: oh good to know
15:18:35 <morganava> alright, any discussion points or things people need help with?
15:18:48 <clairehurst> Do we want to support TBA being an option for being a default browser? Right now it is an option, and I think we should either remove that option or improve it. As it stands its a buggy experience that can also de-anonyomize you
15:19:18 <clairehurst> (via linkability issues)
15:19:52 <PieroV> I think users want it
15:20:01 <PieroV> But yeah, linkability concerns are real
15:20:25 <ma1> yep, I had this conflicting conversation in person with more than one "power user" at the global gathering
15:20:49 <ma1> So, maybe we should keep it with big warnings (and even prompts on external links)?
15:21:17 <clairehurst> I like that idea
15:21:33 <clairehurst> since it might not matter for your use case, but it could be a big deal
15:21:53 <ma1> like an interstitial
15:22:29 <morganava> do we have an issue open for this?
15:22:55 <clairehurst> (and then obv would be nice to also clean up the user experience, like the link not actually opening if you aren't already bootstrapped, and having to open it again)
15:23:05 <clairehurst> I was looking and I didn't see one
15:23:12 <clairehurst> but there are some related ones
15:23:15 <clairehurst> I can make one
15:24:20 <morganava> i've had similar thoughts re interstitials for external links, etc butt  would be good to have a single place to cover all of the problems to solve
15:24:41 <morganava> clairehurst: plz do
15:24:53 <clairehurst> on it :)
15:25:17 <morganava> this will obv require design resoruces which i'm p sure at tapped out for 14.5 so this may be a shipped in 15.0 thing
15:25:27 <clairehurst> What does interstitial mean?
15:26:20 <ma1> A page in between the link and the destination
15:26:31 <ma1> like the error message for bad HTTPS
15:26:39 <clairehurst> gotcha thanks!
15:26:53 <ma1> So you can have a lot of explanatory text and buttons to go ahead or abandon
15:28:19 <PieroV> Possibly not a lot
15:28:22 <PieroV> But only two
15:28:27 <ma1> :)
15:28:30 <PieroV> Or users won't read ^_^;
15:28:37 <morganava> yeah that^
15:28:52 <ma1> of course if you're not connected yet, we could coalesce in a "Connect and go"
15:29:02 <PieroV> Maybe "Deanonymization risk!" in gigantic
15:29:13 <ma1> red on purple, thorin style
15:29:28 <clairehurst> Yeah a big warning + a learn more link
15:30:27 <clairehurst> Since the full explanation is kinda long, but the main idea is short
15:31:23 <morganava> :)
15:32:52 <morganava> ok, anything else?
15:33:20 <PieroV> I think we should discuss (maybe offline) what to do about cargo vet
15:33:21 <ma1> should TPI buy Chrome /dodging
15:34:10 <donuts> how many onion plushies do you think chrome costs?
15:34:36 <ma1> 3?
15:34:38 <clairehurst> I'd buy it for my one plushy
15:34:50 <morganava> wow hi rollers
15:34:53 <morganava> :p
15:35:09 <clairehurst> lol
15:35:44 <dan_b> i would like to be in the time line that follows the onion buying infowars with tor buying chrome
15:36:06 <morganava> we can use the remaining time for cargo vet chat (and folks can leave if they don't care about Lox build fun times)
15:37:16 <PieroV> How do we want to address cargo vet?
15:37:50 <PieroV> Basically, its idea is that build system with integrated dependency mechanisms might end up in very long chains of transitive dependencies
15:38:28 <PieroV> Which increases possibilities of importing bad code in the codebase
15:38:58 <PieroV> So, Moz decided that all Firefox's Rust depenencies must be audited before being vendored
15:40:02 <PieroV> Which is good... But for Lox it means we need to audit ~30 new crates
15:40:39 <tjr> Are none of the crates audited by anyone else?
15:40:56 <morganava> (and longer term, its a *lot* for arti if we want to do in-proc)
15:41:04 <PieroV> tjr: some crates might be partially audited from zcash
15:41:54 <dan_b> why do we have to audit them if vendored but not before?
15:42:56 <PieroV> Because we add the dependency on them, and if you want to use a crate on Firefox you have to vendor it first
15:43:21 <tjr> cargo-vet does include the ability to declare 'bankrupcy' or really 'start from existing' where you say "We haven't audited all these, but we've been using them and things seem alright and maybe we'll get to audit them in the future"
15:43:25 <PieroV> (but I guess the point isn't vendoring, it's more about adding new dependencies, but checks on the audits happens when you vendor)
15:43:39 <tjr> And then you audit version-bumps going forward (which are smaller and easier.)
15:44:43 <tjr> From a practical standpoint, you can use that ability to make sure you can accomplish what you want immediately, the broader question of how/do we audit these _fully_ in the future remains.
15:44:56 <PieroV> Yep, that's the point
15:44:58 <tjr> But presumably you have some amount of trust already since you've chosen to use them.
15:45:25 <tjr> ah gotcha, sorry
15:45:31 <PieroV> As a workaround I've added all the crates to audits.toml and reverted the changes
15:45:41 <PieroV> But that isn't a good practice
15:45:50 <morganava> PieroV: has there any been investigation into whether we can swap out any of these dependencies for audit'd ones with equivalent functionality?
15:45:59 <PieroV> (and I didn't know there was an official way to do it, so thanks for the information :))
15:46:12 <PieroV> morganava: I don't think we really can
15:46:30 <morganava> (and broadly, this is a planning+scheduling problem we should loop bellatchau into when it comes to future Lox funding and especially future arti integration work)
15:46:45 <dan_b> but weren't they always dependancies? just now "vendered"? wondering what about "Vendoring" chas changed the trust model only now requiring audit
15:47:01 <bellatchau> lets talk about this
15:47:14 <PieroV> Most of the dependencies are from crypto code (e.g., aes-gcm, curve25519-dalek, ed25519-dalek and transitive dependencies)
15:48:11 <PieroV> dan_b: so far we haven't added external dependencies, except for a couple of JS modules
15:48:40 <tjr> ( https://mozilla.github.io/cargo-vet/config.html?highlight=exemptions#the-exemptions-table is the official/supported way to do this )
15:48:54 <PieroV> But I've started playing with Rust dependencies, so it's a new thing just because we've never done that before
15:49:00 <bellatchau> ok, we need to sync to make sure we understand what can be added to the arti grant we are writing and what would need other sponsor
15:49:29 <bellatchau> morganava adding to tomorrow's agenda
15:49:44 <morganava> woo
15:49:47 <PieroV> tjr: do you know if other organizations are picking cargo vet up?
15:49:54 <dan_b> i mean arti uses tokio, and a ton of other deps, that seems like a lot to ask us to audit. esp since they and we and everyone else has been using it fine till now
15:50:21 <dan_b> not saying i entierly disagree, i have messy thoughts about rust deps, but wondering why the vendoring of existing deps is triggering audits
15:50:28 <dan_b> since the deps were always there
15:50:49 <tjr> PieroV: Yeah: https://github.com/mozilla/cargo-vet/blob/main/registry.toml
15:51:36 <PieroV> tjr: great, thanks! The fact that zcash is using it might be especially helpful for Arti :)
15:52:03 <PieroV> dan_b: many dependencies were already audited indeed
15:52:12 <PieroV> But I was working on Lox, not on Arti
15:52:17 <tjr> ZCash, Google, and Mozilla have all looked at parts of tokio for example
15:52:22 <dan_b> ah interesting, thats good
15:52:35 <PieroV> Lox doesn't use async stuff
15:52:46 <PieroV> So, it doesn't use tokio either
15:53:10 <dan_b> so our audit process will allow/absorb some existing third party audits? thats good
15:53:17 <PieroV> Yes, it does
15:54:30 <PieroV> But we have to decide if it's okay for us to postpone (or don't audit at all) some new stuff it doesn't pick up
15:54:41 <PieroV> The list is here: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096#note_3131583
15:55:41 <morganava> i think postponing is fine for alpha, not so fine for stable vOv
15:57:55 <PieroV> wfm
15:57:57 <tjr> As we seem to be nearing a conclusion, I wanted to throw one more thing out as I missed the front half of the meeting.
15:58:04 <tjr> Shravan and I realized - Mozilla could cut more libraries over to the wasmbox API - Firefox could leave them with a no-op sandbox (because they are unacceptably slower when wasmboxed) and this cutover should be almost no perf cost so it could be upstreamed.  But Tor could enable them to be wasmboxed - either by default, or possibly by the security slider (although that would require a browser restart, but the jit disabling already
15:58:04 <tjr> does...)
15:58:05 <tjr> Obviously this is in the category of "Decent ideas that require engineering resources so throw it in the list and we'll see if we ever get to it"; but a potential collaboration might be to work with grad students (who do the work) to give them a paper talking about how they did this work and shipped security improvements in a real target.
15:59:36 <morganava> neat :D
16:00:02 <morganava> ok folks its been lovelya s always
16:00:06 <morganava> have a good (shorter) week o/
16:00:11 <morganava> #endmeeting