15:01:44 #startmeeting Tor Browser Weekly Meeting 2024-09-03 15:01:44 Meeting started Tue Sep 3 15:01:44 2024 UTC. The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:44 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:01 hi folks, it's that time fo the week once again 15:02:04 pad per usual -> https://pad.riseup.net/p/tor-tbb-keep 15:03:05 last weeek alsmith, bella, and myself worked on some additional revisions for the OTF esr128->140 grant for next summer, and that was submitted last week 15:03:28 o/ 15:03:32 so hopefully we're done with that until they come back with a yes in some months 15:03:37 Summer + Spring please :) 15:03:47 oh cool 15:03:56 yes well, everything is in flux always 15:04:00 but in any event 15:04:15 /o can't ebelieve I made it 15:04:21 14.5a3 went out last week and our android crashes are now back to baseline because of the search fix 15:05:05 \o/ 15:05:37 and I mentioned last week on IRC I've been going through our ~14.0 Stable && !~14.5 Stable issues and reviewing, closing or assigning them to folks based on my whims at the time i looked at it 15:06:20 i've not gone through a second pass and load-balanced so basically if you have a million issues on your plate plz don't panic i'll fix it 15:07:42 Ok, PieroV it looks like you've a few discussion points 15:07:51 for background re the useragent for folks 15:07:53 Yes, but first an update about stable 15:08:00 ah ack go ahead 15:08:10 Today Firefox 130 and 115.15 were released 15:08:24 I've prepared and boklm reviewed and started a build on tb-build-02 15:08:33 I've already finished to build locally 15:08:37 * boklm is still building 15:08:45 y'all are saints 15:08:49 (in a good way) 15:08:51 morganava: should I assign it to you, in case boklm's build ends up before the end of your day? 15:08:54 backports checked out fine with official release 15:09:17 Great :) 15:09:24 PierOV: yes please, i'll have to take off earlier than usual today, but I can sign+publish in the evening 15:09:39 ack 15:10:11 and then we'll go through sign+publish training for increased beach factor :) 15:10:22 yesss 15:10:26 Also, about releases 15:10:34 I'd like to push 14.0a4 by a couple of day 15:10:50 I forgot to check the updater MR last weekend 15:10:55 So, I merged it only yesterday 15:11:04 ma1: can you create a confidential issue to be added to the signing infra and assign to me 15:11:16 So today's build was the first one with the patches 15:11:23 PieroV: that's fine with me 15:11:35 aim for a Thursday release? 15:11:45 I'd like to wait to see if it updates to tomorrow's build successfully (it would be a surprise if it doesn't) 15:12:07 So, not before tomorrow, but Thursday even better 15:12:55 that works for me 15:13:06 morganava, ok 15:13:31 ma1: in tor-browser-build 15:13:48 mentioning PieroV as well 15:14:23 Thanks 15:14:27 ok, shall we move on to the useragent? 15:14:31 Yes 15:14:44 I'm a bit worried, because they end up also in logs 15:15:22 So, that will be recorded by more people, basically anyone unless those who use a no-log policy 15:15:32 right so some background for people 15:15:38 i don't understand the concern, it's only 4 OSes, so what? 15:15:40 What's the background on why MB started sending the actual OS in HTTP headers? (I assume that's what's being discussed here?) 15:15:41 I don't think it'll be that big deal, but it still seems a kinda important change to our threat model 15:16:09 useragent is accessible in (at least?) 2 places, via navigator.userAgent in JS and in HTTP headers 15:16:20 So, I wonder if we have also some literature supporting this change to the threat model 15:16:33 historically we've spoofed HTTP headers to minimize the utility of passive logging 15:17:01 but this causes web-compat issues allegedly :3 15:17:44 Is the argument basically "JS can figure out your OS anyway, so why try to hide it"? 15:17:55 that's why we don't bother spoofing in JS 15:18:00 and also webcompat^ 15:18:08 Yeah so, 15:18:25 the argument is routers and servers upstream from ones exit node shouldn't get the tor browser user's OS 15:18:28 AFAICT the question of what JS can do is not really pertinent, because Safest mode exists 15:18:33 so the issue is not about JS, you can't hide the OS anyway due to feature detection - the issue is it causes compat and is a red flag to anti-fraud bots 15:18:40 of course, that's less of a concern now than it was back in the day, now that everyone and their mother is HTTPS now 15:18:49 And damaging the anonymity set of Safest mode seems extremely bad 15:18:52 so it then boils down to passive when in safest mode 15:19:01 (where everyone is some high percentage) 15:19:20 (i thought the argument for allowing it in javascript was: otherwise stuff like google docs breaks because they give you the wrong keyboard.) 15:19:30 in safest mode 95% of FPing diffs are removed 15:19:35 arma2: that's covered under webcompat 15:19:40 ok great 15:19:59 arma2: but yes that too, and websites that offer downloads based on their perceived platform, etc, etc 15:20:34 so if you really wanted to be smart (like thorin) you could get NoScript to spoof the OSes to 2 in safest mode - I doubt you can do much wihtout JS on sites these days anyway, so no compat issues IMO 15:21:15 Re anonimity set of safest: it's not the objective of the security level, but an appreciated consequence 15:21:34 we could, but the user-agent is a a privacy/linkability issue, not a security/anonymity one 15:21:37 Yeah so if we are confident that JS leaks this info anyway (I think we are?) then it seems reasonable to key the behavior on the security level, and continue hiding the OS in Safest mode 15:21:40 right, what PieroV said 15:21:57 But breaking it doesn't feel very good, fwiw 15:22:26 (I personally would like to see things improve to the point that the OS stays hidden even with JS enabled, but I realize that is maybe not a feasible goal given our budget) 15:22:54 FPing protection is all about breaking web standards - but that doesn't mean we shouldn't be plausible or cause paradoxes 15:22:55 Jeremy_Rand_Lab19[m]: there are too many things you'd have to do 15:22:58 To be clear, my preference is to keep hiding the OS on all security levels, but if I'm outvoted on that, I think at the very least we should keep hiding it in Safest mode 15:23:51 PieroV: right, I'm aware that Tor's current budget can't hide the OS from JS -- I'd just like to see that improve one day, and one way to help facilitate that is to not actively make it worse 15:24:43 "my preference is to keep hiding the OS on all security levels" - you can't - we give it away on non-safest, and even on safest you can still determine the OS via sniffing things (it just takes more work) 15:24:55 What would be a good process for introducing such change? 15:24:59 have we got somewhere a list of all the ways JS could detect the OS? 15:25:00 jeremy: i'm not sure you appreciate the scale of the problem re hiding the OS, unless you don't care about having a meaningfully working web-browser 15:25:10 (beside navigator.userAgent of course)? 15:25:48 ma1: fonts is the other obvious one 15:25:49 thorin: tor protects also from fingerprinting the TCP implementation and so on, because it's at stream level 15:26:19 PieroV: you can still detect the OS via font without JS 15:26:24 morganava: you're correct that I haven't looked at it in detail, I'm more interested in hiding the architecture in Safer mode since that seems maybe like lower hanging fruit 15:26:35 yep, it's a lost battle. And just 3 buckets (Android is its own league) 15:26:38 ma1: I think you'd have to go through all the math things as well, to check what's implemented with the shared math lib 15:27:20 in any event, re process 15:27:21 anyway I realize that I am probably outvoted on non-Safest mode 15:29:03 this is a somewhat significant departure from past behaviour, but perhaps paradoxically it makes no practical different for the majority of sessions 15:29:04 ma1: you probably can get a list of ways to detect the OS on TZP 15:30:30 and tbh i'm having some difficulty imagining any actual harm that can can from this for the majority of our users 15:30:59 morganava: I wonder if there's anything in the literature 15:31:06 and i suspect the types of extreme scenarios where it could cause harm, people should be using Tails no? 15:31:25 * ma1 was fantasizing of a "os detection" capability, but realizes it was a jetlag-induced allucination and it would take importing the whole JShelter as a submodule :P 15:32:20 Or maybe if there's a way to communicate we want to do it, and give some time to provide reasons not to 15:32:21 PieroV: literatuur as in research about tracking users via http user-agent 15:32:28 PieroV: FWIW regarding math library issues, I've been wanting to experiment with statically linking the math library. Again, I'm not saying this is easy or straightforward, but it's the kind of thing that some cypherpunks and/or university researchers might want to work on, and it would be cool if things didn't actively get made worse. 15:32:46 Jeremy_Rand_Lab19[m]: Moz is already doing it 15:33:06 Jeremy_Rand_Lab19[m]: check RFPTarget::JSMathFdlibm in Firefox's source code 15:33:19 Ah interesting 15:33:21 Hadn't noticed that 15:33:43 morganava: rather than tracking disruption in web compat caused by this as an anti-tracking/linkability measure 15:33:56 yeah Math is mostly solved - there is still entropy in android but that;s not the issue re reporting mac/linux as windows 15:35:01 if we think it's liable to cause a ruckus 15:35:28 we can push the fix in 14.5a1 and get feedback over the winter 15:35:48 and sync w/ pavel if we feel like a communication plan is needed 15:36:01 morganava: ESR transition would be nicer 15:36:38 But probably we don't have the time to at the moment to also get feedback 15:36:47 ^exactly 15:37:12 and tbh i'm not confident feedback is going to be particularly useful in this case 15:37:25 beyond 'website broken now' 15:37:37 i don't even see what they can feedback on - ooh look, less breakage? 15:37:49 right^ 15:38:04 Reasons not to implement this we don't see 15:38:29 It's still a relaxation of our threat model 15:38:41 Just Do It (nike) and then decide if we want NoScript to mod the accept header in safest 15:38:50 thorin: no NoScript needed 15:38:53 no it's not - it's about being smarter 15:39:03 I implemented a pref to enable/disable this behavior 15:39:29 wot? don't put this behind a pref for users to meddle with - totally against that 15:40:02 You even suggested a possible pref name :) 15:40:06 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/234#note_3001294 15:40:07 lol 15:40:40 that was back in the day for MB - the issue is a clone 15:40:53 so we could use flip it for MB but not TB 15:41:02 * ma1 rejoices seeing thorin converted to the NoScript gospel :) 15:41:18 ma1: I can fingerprint NS :) 15:41:39 and JShelter :P 15:42:25 So, what's the plan? 15:42:27 ok 15:42:29 Asking Pavel for suggestions? 15:42:52 so there are a few places i'm aware of we gther feedback 15:43:08 blog post, forum (same thing practically), and the tor-dev mailing 15:43:10 list 15:43:18 which actually also goes to the forum lol 15:43:29 we don't need feedback 15:43:42 We can also backport the patch and leave it off for starters if people want to play with 15:44:03 in stable? 15:44:17 No, no 13.5 15:44:21 In 14.0a4 15:44:43 hmm 15:44:47 oh i see what you mean 15:44:53 yeah ok 15:45:03 backport the patch, leave it off by default 15:45:15 Yes. Sorry, cherry-pick to TBB from MB 15:45:21 do our due diligence re asking for feedback in the variou splaces 15:45:23 (but let's change the MB prefix please :)) 15:45:43 and presuming nobody comes up with a good reason to keep it off, turn it on in 14.0 RC1 15:45:56 yeah i can update the MR 15:46:10 Do we have a way to make it big in the blog post? 15:46:17 did anyone ask what feedback MB got? if any? This passive FP metric is basically invisible to users 15:46:17 Like give its own heading 15:46:28 thorin: MB is different 15:46:32 PieroV: yeah easily done 15:46:34 it's just markdown 15:46:40 why do we even need to consult users? Do we do that for all our other FPing patches? or upstream changes to RFP? 15:46:44 jokes aside, it could be the bare minimum kernel of a "os detection" capability (on by default), If off, NoScript could spoof both HTTP and JS useragent, independently from other capabilities and we could turn it off in Safest (+ one day users could temporary "unbreak" sites which are confused by this) 15:47:01 thorin: it's not a FPing thing only 15:47:02 ~label future 15:47:08 It's a change for the threat model 15:47:18 PieroV: then what else is it? 15:47:28 it's additional protections 15:47:33 not relaxations 15:47:46 that doesn't make any sense to me 15:48:07 ma1: pointless to spoof them if JS is enabled - save your time 15:49:38 we're going to spend the entire meeting talking about the accept header 15:49:46 anything else besides that? 15:49:56 pref audit i think is next on the list 15:50:21 Does anyone want to take it this year? 15:50:29 It might be good to have a different take on that 15:51:11 ma1, dan_b: either of you have cycles free for this? 15:51:15 in b4 we end: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42243 will get no love from upstream in time, if ever (since it's UI involved) - we'll need to do this ourselves before 14 hits stable IMO 15:52:05 thorin: ack 15:52:38 morganava I'm a little lost on what "this" is at this point? 15:52:43 * ma1 trying tor-browser#42467 from the note, but a bit confused 15:53:09 dan_b: ma1: nope, the pref review 15:53:20 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42356 15:53:38 right 15:53:41 aah k 15:53:41 tldr; we need to review all our existing prefs, and purge any that no longer exist and also review all the *new* prefs and see if they need to be twiddled from default 15:53:42 wrong line :) 15:54:13 maybe next year this ought to be tag-team task like the bugzilla triage 15:54:28 morganava, I can take it this year. 15:55:02 This year the purge will be long indeed 15:55:04 (it seems to have some intersection with the audit) 15:55:09 i think? i'll have time soon. only 3 or 4 more review tickets. but i've been out of desktop for a bit, and haven't done much anti FP work so would be a bit slow on the review process from that side. but could give a go 15:55:10 And we could do two separate takes 15:55:25 One for purging and one to review the remaining 15:55:30 there's been a lot of deleted prefs? 15:55:38 Yes, there's a meta about deleting unused prefs 15:55:48 https://bugzilla.mozilla.org/show_bug.cgi?id=1773039 15:56:05 ma1: ack 15:56:09 oph. so read through that and compare to ours? 15:56:21 Maybe we can make a script to scrape that page and create a list for us 15:56:30 well at least thats got traction. Id be unsure how to start that otherwise 🙂 15:56:45 all deprecated prefs have already been compiled at arkenfox 15:56:56 brilliant 15:57:07 oooh 15:57:13 well, spread over 13 releases/issues :P but easy to combine 15:57:23 thorin: is this the query? https://github.com/arkenfox/user.js/issues?q=is%3Aissue+label%3Adiffs 15:57:33 yeah 15:57:36 PieroV, do we really need to scrape that page or just look at the live esr128 snapshot? 15:58:13 ma1: I think we could intersect a list of our prefs with a scraped list 15:58:18 indeed 15:58:26 Like a regex that matches what looks like a pref in titles 15:58:37 Hopefully Bugzilla's JSON includes the referenced tickets 15:58:42 And a regex for our pref 15:58:53 I don't think it'll take too long and it might be effective 15:58:58 I'm not suggesting to do it by hand 15:59:00 ok, the purge part seems my kind of fun 15:59:06 :D 15:59:10 hehe 15:59:16 Even though in last year I looked for every pref in the codebase ^_^; 15:59:24 ok 42 seconds left 15:59:27 Long-term I'd like to split the pref file 15:59:29 In categories 15:59:38 if there's anything else tough luck 15:59:40 Like 002-fingerprinting 003-disk-leak etc 15:59:45 we can continue in #tor-browser-dev ;) 15:59:51 toodles 15:59:56 in the meantime, have a good week everyone o/ 15:59:58 #endmeeting