15:01:13 <richard> #startmeeting Tor Browser Weekly Meeting 2022-03-29
15:01:13 <MeetBot> Meeting started Tue Mar 29 15:01:13 2022 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:16 <Jeremy_Rand_Talos_> Hi!
15:01:53 <richard> update that pad! ( https://pad.riseup.net/p/tor-tbb-keep )
15:02:01 <richard> clear out those kanbans
15:02:08 <richard> gogogo
15:03:15 <PieroV> can we clear old discussions? They're getting long :)
15:04:33 <aguestuser> o/
15:05:01 <boklm> PieroV: good idea
15:05:14 <richard> yeaah for sure
15:06:46 <PieroV> done, I've left only one point that was not marked as solved
15:09:01 * sysrqb sneaks in without any context
15:09:38 <aguestuser> o/
15:10:10 <richard> o/
15:10:50 <richard> ok lots of discussion points today
15:11:00 <richard> let's get started while they finish getting edited
15:11:05 <richard> pierov!
15:11:13 <PieroV> hey!
15:11:23 <PieroV> I noticed that Tor Browser contains a list of applied updates
15:11:42 <PieroV> As I wrote, don't we usually consider this disk leak/information about when a user started using Tor Browser?
15:11:56 <PieroV> It's true that one can also delete their installation and extract it again
15:12:24 <sysrqb> where is that list saved?
15:12:35 <PieroV> Near the updates, in general preferences
15:12:39 <PieroV> There's a button to do so
15:12:45 <PieroV> let me send you a screenshot
15:13:26 <boklm> I'm wondering if the timestamp of some files could be used to know when the user started using Tor Browser, even if we remove that log
15:14:05 <boklm> (but maybe this is something we can fix too)
15:14:28 <PieroV> https://share.riseup.net/#RVGZlX3qnT04dYwKzX_hmA
15:15:46 <richard> boklm: my thought as well
15:15:48 <sysrqb> ah, i see. interesting.
15:16:04 <PieroV> updating timestamps may be bad for backup systems, but hey, one can exclude it, and anyway TBB is not that heavy
15:16:34 <richard> but this makes it hella easy for forensics people so we should probably fix it :)
15:16:54 <boklm> removing all updates from that log except the last one sounds like a good idea
15:17:01 <richard> +1
15:17:13 <boklm> (or maybe even the last one)
15:17:27 <PieroV> yeah, and remove the button as well
15:17:36 <sysrqb> my current thought is: yes, this may be a problem that we should fix because it leaks information about user behavior, but I wonder whether this is still a valid threat in the Tor Browser threat model, in general
15:18:18 <richard> i suppose one could argue if you need amnesiac behaviour one should use TAILS not tor-browser on $(dekstop_os)
15:18:19 <Jeremy_Rand_Talos_> Seems like one could maybe make start-tor-browser run a recursive `touch` on the TBB directory, including the profile?  Which would reset the datetime metadata in the filesystem.
15:18:43 <richard> Jeremy_Rand_Talos wow that's cute
15:19:20 <sysrqb> that would increase startup time - which is something we wanted to reduce in the tor-launcher bootstrapping case
15:19:26 <sysrqb> but yep, that's an option
15:19:44 <PieroV> what about running the touch while starting TBB?
15:20:00 <Jeremy_Rand_Talos_> sysrqb, yes, though I wonder whether there are enough files that the additional time actually is noticeable.
15:20:17 <richard> yeah seems like something you could do in the background, or even within tor-browser itself so it works on all platforms
15:20:17 <sysrqb> PieroV: that could work
15:20:29 <Jeremy_Rand_Talos_> Agree with PieroV, that seems reasonably safe
15:20:45 <PieroV> +1 for the all platforms thing, though
15:20:49 <richard> but that's a separate issue to this discussion I think
15:20:49 <sysrqb> Jeremy_Rand_Talos_: i don't know, for sure. but i imagine on older spinning disks and cheaper usb drives (etc.), it could be noticable
15:21:05 <richard> (but also this will fingerprint exaclty the last time the user ran Tor Browser, which itself could be incriminating)
15:21:11 <boklm> or in start-tor-browser after exiting the firefox process, setting always the same time to avoid leaking when it was run
15:21:20 <PieroV> and touch with the release date?
15:21:21 <richard> boklm: +1 precisely
15:21:33 <sysrqb> PieroV: that's a nice idea
15:21:38 <PieroV> maybe after having applied the update itself? (and without caring of ctime?)
15:21:39 <Jeremy_Rand_Talos_> richard, I *think* `touch` allows you to choose what datetime it sets.
15:21:50 <PieroV> yes, it does
15:21:52 <sysrqb> (it does)
15:22:01 <PieroV> it can even set the atime if you want to
15:22:17 <sysrqb> but, i don't know about support on Windows
15:22:21 <sysrqb> because...Windows
15:22:33 <richard> ok, let's create a Tor Browser ticket for this whole discussion re Tor Browser file timestamps
15:22:45 <PieroV> sounds good to me
15:22:46 <richard> in the mentime, we should *also* fix this update history issue
15:22:52 <richard> in a separate issue
15:23:10 <boklm> we also need to check if firefox uses file timestamps for some things
15:23:24 <richard> yes that too
15:23:35 <boklm> and check if it's storing last run time in some prefs
15:24:01 <Jeremy_Rand_Talos_> (FWIW, my StemNS Windows service work currently leaks Tor Browser usage datetimes to disk, and I consider that a big enough bug that there's a scary warning about it in the docs and it's my highest priority bug to fix in that code)
15:24:50 <richard> ok, aguestuser how are things in android :)
15:24:51 <Jeremy_Rand_Talos_> So if by some chance Tor considers such bugs to be not bugs, I'd kinda like to know :)
15:25:12 <richard> Jeremy_Rand_Talos: I'd classify as a bug vOv
15:25:20 <boklm> app.update.lastUpdateTime.addon-background-update-timer for example looks like a pref that stores when addons were last updated
15:25:23 <Jeremy_Rand_Talos_> richard, thanks, agree
15:25:39 <aguestuser> richard: nothing new to report on the build other than what is in #tor-dev, but the build is failing in rather baffling ways
15:25:48 <sysrqb> fwiw, seems Browser/TorBrowser/UpdateInfo/updates.xml is contains the full history
15:26:18 <aguestuser> wanted to use the opportunity of the meeting to see if anyone had fresh perspectives?
15:27:02 <boklm> browser.laterrun.bookkeeping.profileCreationTime might also leak when the user started using tor browser
15:27:05 <aguestuser> upshot is: android-component step fails b/c geckoview .aar doesn't have tor-patches, but geckoview .aar was built off of git tree containing said patches
15:27:23 <aguestuser> (whoops. holding on next topic until we're done with current one!)
15:27:25 * sysrqb will need help with getting copy of backlog in #tor-dev
15:27:51 <richard> carry on agustuser :)
15:28:00 <aguestuser> that's all. stuck.
15:28:21 <aguestuser> happy PieroV is running a build. not sure whether mucking with linkers is at all in same territory
15:28:32 <aguestuser> would also like to find some "distiguishers"
15:28:42 <aguestuser> to tell apart an .aar that has the patches from one that doesn't
15:28:46 <richard> so are we to understand that geckoview is being built without our patches?
15:28:53 <richard> eg it's just a vanilla geckoview?
15:29:03 <aguestuser> well,  that's what this build failure normally means
15:29:20 <aguestuser> when android-components cant find `torSecurityLevel` and `spoofEnglish` and `origin`
15:29:27 <aguestuser> in 100% of cases i've seen that build error
15:29:41 <aguestuser> it's been b/c android-compomnents is trying to build on top of vanilla (moz) geckoview
15:30:19 <aguestuser> so i am assuming that this geckoview .aar doesn't have the patches but baffled as to why (b/c its name contains the commit hash of the HEAD of a tree that has the patches)
15:30:45 <aguestuser> sysrqb had some nice ideas for how to inspect the actual .aar to see if the patches are present (by inspecting classes.jar from unzipped .aar)
15:30:57 <richard> right that makes sense
15:31:04 <aguestuser> but i was unable to use this technique to find the presence of missing strings in .aars that we know *do* have the patches
15:31:09 <aguestuser> (build artifacts from past builds)
15:31:49 <aguestuser> so also don't really have a "baseline" to compare the broken .aar against to assess accuracy of assessment that it is weirdly missing patches we expect it to have
15:32:12 <aguestuser> in addition to not having working hypotheses as to why it would be missing patches given built off git tree that has them...
15:32:25 <boklm> it could also be that the patch are there, but due to other changes the linking doesn't work anymore
15:32:29 <aguestuser> in addition to not having working hypotheses as to why it would be missing patches given built off git tree that has them...
15:32:37 <aguestuser> boklm: yes... so this is where i'd welcome perspectives!
15:32:46 <aguestuser> seems like some change to the linker (made last week) might explain this?
15:32:59 <aguestuser> but i don't have a firm enough grasp on those changes and how they interact with the build to assess!
15:33:24 <boklm> it could be some changes to the linker, or some changes inside geckoview or inside android-components
15:33:55 <aguestuser> what sorts of changes inside geckoview or android-components?
15:33:56 <PieroV> about the linker, we rolled back to using NDK's for the build that aguestuser produced
15:33:59 <richard> sounds like there's no way around a multi-dimensional bisection...
15:34:01 <aguestuser> how would one go looking for them?
15:34:34 <aguestuser> richard: a multi-dimensional bisection across a 3-major-version-diff in 3 different projects?
15:34:41 <richard> :D
15:34:47 <richard> sounds like hell!
15:35:02 <sysrqb> aguestuser: just so you know, when i unzip classes.jar into another directory, then grep for "torSecurity", i get this:
15:35:05 <sysrqb> $ grep -rn torSecurity
15:35:08 <sysrqb> Binary file org/mozilla/geckoview/GeckoRuntimeSettings$Builder.class matches
15:35:09 <PieroV> we should look for an equivalent of nm in Java
15:35:52 <PieroV> err, for .aars, rather than Java. I found that `javap -private` may help
15:36:00 <aguestuser> sysrqb: ooh! assuming that grep is of a past-release .aar?
15:36:06 <sysrqb> yes
15:36:15 <aguestuser> lovely. okay. so baseline established.
15:36:16 <sysrqb> i believe for 96
15:36:44 <boklm> aguestuser: maybe you can check in the log the command line used for the linking, and compare it with an older build to see if anything changed there
15:36:44 <sysrqb> ah, yes, it's in the filename (lol): geckoview-beta-omni-96.0.20220602090101.aar
15:37:26 <aguestuser> okay. some leads!
15:37:42 <richard> fwiw also back in the day java classes have been trivial to 'decompile' ifyou're curious about what source was used to build a thing
15:37:59 <richard> vOv
15:38:05 <PieroV> true, but in this case we have JNI in the middle
15:38:30 <sysrqb> yeah, there's an `apktool` command that we've used for decompiling the apk/aar in the past
15:38:42 <sysrqb> occasionally useful
15:38:47 <richard> oh right, if we're confused about which geckoview was usd ot buil
15:38:59 <aguestuser> sysrqb: android studio has a very nice built-in UI for apktool
15:39:00 <richard> decompiling the top fenix layer probably not that informative
15:39:27 <richard> alright, shall we move on to your UI test qs?
15:39:33 <aguestuser> sure!
15:39:50 <aguestuser> as noted. not urgent (until alpha release done)
15:39:52 <sysrqb> but, in any case, it seems like aguestuser can confirm whether the geckoview he build contains tor browser patches and then go from there
15:40:03 <aguestuser> sysrqb: yes! will do right after meeting
15:40:15 <richard> (good luck!)
15:42:38 <aguestuser> grr.. sysrqb i just attempted to repro your search on geckoview-beta-omni-96.0.20141228000000.aar and got no results?
15:42:43 <aguestuser> can folo later!
15:42:58 <sysrqb> okay
15:43:00 <aguestuser> question about tests is regarding NoScript
15:43:02 <richard> boklm, sysrqb: do you have any insight as to why the allowed_addons.json step is where it is?
15:43:06 <boklm> aguestuser: what do you mean by "putting this file under version control"? putting it in fenix.git instead of tor-browser-build.git?
15:43:14 <aguestuser> boklm: sorry, yes
15:43:30 <aguestuser> in a manner that would be transparent to gradle tasks that build the apks for isntrumentation tests
15:43:57 <aguestuser> the problem currently is that the gradle task that builds the apks for the UI tests does not perform this step (which we perform in tor-browser-build)
15:44:06 <sysrqb> i believe it's in tor-browser-build because we wanted to make updating it as part of the release process, instead of tied to the fenix patches
15:44:07 <aguestuser> and thus all instrumentation test apks lack noscript addon
15:44:32 <aguestuser> which means it is impossible to generate an instrumented test apk that has noscript using only gradle
15:44:40 <sysrqb> but i doubt there is a requirement for that, and it can be moved into fenix, if that's a better place for it
15:44:45 <aguestuser> (which is the natural place in an android-studio dev flow to do it)
15:45:07 <aguestuser> sysrqb: that's sort of what i guessed
15:45:19 <aguestuser> (re: ease of updating as part of release cycle)
15:45:53 <aguestuser> but downside of that trade-off is you can't test expected state of the app without some contortions that would be nice to avoid
15:46:35 <richard> sounds like you have at least the beginnings of a plan
15:46:41 <sysrqb> it sounds like this goes back to the general question of how much we should support building tor browser outside of tor-browser-build
15:47:10 <aguestuser> so if i'm hearing right, the cost of trying to adjust this flow (to put allowed_addons in fenix.git instead of injecting into apk) would be generating a process for updating the allowed_addons as part of release cycle in commits to fenix.git that is acceptable to team?
15:47:36 <aguestuser> sysrqb: yes, but i think of it as more than just building... it's like can you run the tests at all
15:47:58 <aguestuser> you could in theory write a new test runner script
15:47:59 <richard> aguestuser: can you create a process for generating allowed_addons.json contanin gjust no-script for dev-builds in fenix?
15:48:10 <sysrqb> but tor-browser-build can inject the file into the instrumented apks, yes?
15:48:22 <aguestuser> sysrqb: that's what i was about to type
15:48:29 <richard> (and keep the existing process for the whole addons file?)
15:48:34 <aguestuser> so yes, if we wanted to run instrumented tests from (for example) a make script
15:48:52 <aguestuser> you could adjust how the instrumented tests are run, and interecept the intrumetned apk and inject some files
15:49:02 <aguestuser> which we'd then read and put into the `assets` dir at runtime
15:49:08 <aguestuser> but this seems massively convoluted to me
15:49:29 <aguestuser> when teh `assets` dir is something that is sitting there in the source code directory
15:49:42 <aguestuser> and we can literally put under version control for the project it's supposed to be for
15:49:56 <Jeremy_Rand_Talos_> sysrqb, I do think that building outside of tor-browser-build should be supported as much as feasible, given that tor-browser-build does not run at all on some systems (e.g. non-x86) and also does not cross-compile to many systems
15:49:57 <aguestuser> (rather than having another project inject it into the directory we could have just put it in?)
15:50:20 <sysrqb> sure, in some ways this current design is technical debt
15:50:24 <aguestuser> also: it means you *cannot* use the push-button functionality in android studio to run tests
15:50:27 <aguestuser> which is a bit of a bummer
15:50:29 <richard> aguestuser: so it seems to me like you're the primary stakeholder here, I'd say if it's a good idea for testing the ngo for it vOv
15:50:38 <sysrqb> i just want to recommend that battles are chosen wisely
15:50:39 <aguestuser> also: chewing lots of time
15:51:01 <sysrqb> if this is making testing painful, then it may be worth solving this problem
15:51:02 <aguestuser> i'm hearing that there are no non-obvious technical reasons why we did it that way
15:51:06 <aguestuser> it's process things
15:51:09 <richard> mmhm
15:51:19 <aguestuser> so if i want to do something else i should propose a process shift?
15:51:33 <aguestuser> (which in any case i don't need to do right now since it's far from the most urgent thing!)
15:51:49 <aguestuser> for context: why i'm interested in investing in tests is to avoid things like the download bug surprising us
15:52:07 <richard> aguestuser: that works for me
15:52:29 <sysrqb> (+1)
15:52:30 <richard> for my end it just seems like the change to releases is just where the 'updat allowed addons' script lives and is run
15:52:34 <richard> ok
15:52:35 <richard> donuts
15:52:36 <richard> real quick
15:52:37 <PieroV> (tests are always a good investment imho, maybe a boring one :))
15:52:39 <donuts> hello
15:52:43 <aguestuser> (but also (offline/later): i'm i'm wrong about the "this is a process thing" assumption -- feel free to correct me!)
15:52:44 <richard> PieroV: +1
15:52:45 <donuts> real quick
15:52:54 <donuts> I'd like to get the wheels moving on bundling https://tb-manual.torproject.org/ in TB 11.5
15:53:05 <donuts> ticket is tor-browser#11698
15:53:17 <donuts> but there is more background in tor-browser#31539
15:53:26 <donuts> tl;dr it exists as markdown in lektor atm
15:53:35 <donuts> we can turn that into static html
15:53:49 <donuts> my question is: can we do some custom CSS for it in TB so it looks more native?
15:54:01 <richard> donuts: most likely
15:54:13 <donuts> it'll just be the content we bundle obvs, not the full page (i.e. without the header and footer etc.) anyway
15:54:30 <richard> sounds like we'd need to add a tor-browser-manual project to tor-browser-build and package it up w/ firefox
15:54:44 <richard> and point tor-browser manual links/help to the local cached copy?
15:54:51 <emmapeel> yeah!
15:55:03 <emmapeel> sorry you were probably not asking me
15:55:09 <sysrqb> :)
15:55:09 <richard> :)
15:55:15 <donuts> yeahs in the chat
15:55:18 <donuts> \o/
15:55:29 <richard> so i don't know what the current state of things here is
15:55:48 <donuts> I can do some real lite design exploration but we can also talk about this more next week after you've managed to reread the tickets
15:55:50 <PieroV> Links are hardcoded with the full URL, but we could add a function to generate them
15:56:08 <richard> so we need some process for building/integrating the final html
15:56:34 <richard> could be as easy as you host a zip with the html in it somewhere which we pull in during build
15:57:05 <PieroV> and either a wrapper in an about: page, or something to allow that files
15:57:07 <boklm> we can probably find some markdown -> html tool we can use during the build
15:57:07 <richard> or adding an actual git repo with a build script that outputs said zip
15:57:19 <richard> boklm: +1
15:57:38 <sysrqb> pandoc might work - if you don't need lektor-specific metadata
15:57:39 <richard> so we've got like 2 months until 11.5
15:57:40 <PieroV> boklm: I think that we could use the same one used for the website, but with a different config
15:57:55 <sysrqb> but installing lektor might be easier
15:58:51 <boklm> ah yes, it seems there a lektor debian package
15:58:54 <emmapeel> you could rewrite the 'layout' template that has the sidebar etc
15:59:24 <richard> boklm: seems like the build integration stuffs would be on you, and PieroV the actual browser changes? (and donuts+emmapeel on design changes?)
15:59:37 <richard> alright anyway we can come back to it next time
15:59:38 <PieroV> okay
15:59:43 <boklm> ok
15:59:43 <donuts> sounds good to me
15:59:46 <donuts> thanks all!
15:59:47 <PieroV> (we have S96 meeting now)
15:59:56 <donuts> yesss
16:00:06 <richard> real quick, 11.0.10 is scheduled for this week so I'll need a builer but i'll ping y'all in #tor-dev later
16:00:09 <richard> byebebyebye
16:00:13 <richard> #endmeeeting
16:00:16 * boklm can be a builder
16:00:16 <PieroV> thanks all, bye!
16:00:17 <richard> #endmeating
16:00:19 <richard> #endmeeting