18:59:37 <sysrqb> #startmeeting Tor Browser meeting 23 November 2020
18:59:37 <MeetBot> Meeting started Mon Nov 23 18:59:37 2020 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:44 <sysrqb> welcome, welcome
18:59:53 <sysrqb> pad: https://pad.riseup.net/p/tor-tbb-2020-keep
19:00:41 <Jeremy_Rand_Talos> hello!
19:03:41 <gaba> o/
19:07:11 * sysrqb realises "crypto safety" is "cryptocurrency safety"
19:08:45 <sysrqb> acat: i thanks for reviewing sanketh's MR
19:09:01 <acat> np
19:09:24 <sysrqb> but i'll add a comment asking for changing the commit message to crytocurrency (or something chorter but not "crypto")
19:09:31 <sysrqb> unless you want to include that in your review
19:09:41 * Jeremy_Rand_Talos is one of the rare cryptocurrency devs who enjoys pointing out that crypto means cryptography
19:09:56 <sysrqb> :)
19:10:09 <acat> sysrqb: that
19:10:13 <acat> 's fine
19:10:58 <sysrqb> okay
19:11:01 <acat> i can also add the comment, whatever you prefer
19:11:24 <sysrqb> i would like to maintain one definitoin of "crypto" and not make it context-sentaitive, if we can help it :)
19:11:33 <sysrqb> (in Tor Browser land, at least)
19:11:49 <sanketh> Jeremy_Rand_Talos: haha, I'm a cryptography dev (?) who uses crypto for cryptocurrency. :)
19:12:04 <sysrqb> sanketh: o/
19:12:24 <sysrqb> we can talk about this after the meeting, if needed
19:13:36 <sanketh> (sorry for crashing the meeting.)
19:13:47 <sysrqb> no worries, you are welcome here, too
19:14:00 <sysrqb> i just don't want to side-track the meeting with this specific discussion :)
19:14:18 <sysrqb> acat: did you already begin integrating fenix tests into the testsuite?
19:14:30 <sysrqb> or is that part of the work you are planning this week?
19:14:33 <Jeremy_Rand_Talos> sanketh, I hereby rename a TLS ClientHello as Initial Ciphersuite Offering (ICO), shall we do a hostage exchange?  :)
19:15:17 <sanketh> Jeremy_Rand_Talos: perhaps we should take this to a different channel. :)
19:15:37 <acat> sysrqb: yes, i already begun. i plan to start creating a MR prob. tomorrow starting with changes in Fenix, then tor-browser-build, and then the testsuite
19:15:47 <Jeremy_Rand_Talos> fair enough, I'm done joking around
19:16:05 <sysrqb> acat: okay, so you already having something working?
19:16:07 <acat> basically my idea is that the nightlies also build the test .apk, which can be fetched and then ui tests run
19:16:58 <acat> yes, but unfortunately i did not manage to even get the fenix tests passing for fenix in my machine (only round 75% pass, if i recall correctly)
19:18:09 <acat> so i did not do an effort to fix these for tor-browser, since it's hard to know whether we actually broke them or we need some other environment for these to pass
19:18:40 <sysrqb> yeah. this is good progress though, thanks
19:20:30 <sysrqb> i think building a debug variant in addition to the nightly variant for the nightly build is a reasonable compromise
19:21:22 <acat> ok. yeah, that's another issue, since by default tests are run against the debug build
19:21:56 <sysrqb> i don't know how much of the tests rely on having debuggable archives for the many dependencies we build (mozac, in paricular, i'd guess)
19:22:09 <acat> but building the tests apk also works for beta and release, with some changes
19:22:47 <sysrqb> ah, i see
19:22:56 <sysrqb> i forgot they added a special test variant, too
19:23:25 <acat> i'm not sure there, since right now i'm not sure we check that the debug variant is working
19:23:57 <acat> and also there's always the possibility of sth working in debug but not in release or alpha
19:24:05 <GeKo> yeah
19:24:06 <sysrqb> yep
19:24:17 <acat> but fenix does not run tests for release or beta
19:24:44 <GeKo> really? that's surprising
19:25:04 <GeKo> i though they'd like to know whether their shipping product is exploding or not beforehand
19:25:08 <GeKo> *thought
19:25:57 <acat> *i think*
19:26:03 <acat> i saw some github issue
19:26:09 <acat> https://github.com/mozilla-mobile/fenix/issues/16120
19:26:20 <sysrqb> they may not run tests using the specific release/beta variants
19:26:39 <acat> ok, maybe they do now
19:27:05 <sysrqb> ah, yeah, Android is hard
19:27:21 <sysrqb> "The problem we have is that UI tests run against the debug build type by default, and the debug build type/variant is configured to use GV Nightly."
19:28:21 <acat> the thing is i'm not sure how much of the testing config is in the repo
19:28:23 <sysrqb> okay, so this may be fixed on Fenix beta/nightly now
19:28:52 <sysrqb> all of taskcluster is in the repo, and relies on the gradle config
19:29:01 <sysrqb> i don't know anything about how mozilla are using firebase
19:29:24 <sysrqb> so that could be a different configuration
19:31:10 <acat> well, it's nice if they end up supporting this, our patch will hopefully be smaller
19:31:12 <sysrqb> based on the copmments in that issue, i'm guessing the successful Beta UI test was not using the main fenix branch
19:31:21 <sysrqb> *comment
19:31:32 <sysrqb> acat: yeah
19:32:23 <sysrqb> acat: okay, we don't need to get into all of the details unless you want to discuss anything else specifically
19:32:51 <acat> i'm good
19:32:53 <sysrqb> i'm glad you made progress on this
19:32:56 <sysrqb> cool
19:33:51 <sysrqb> okay
19:33:56 <sysrqb> for the Boards
19:33:58 <sysrqb> https://gitlab.torproject.org/groups/tpo/applications/-/boards
19:34:23 <sysrqb> on Thursday, Gaba and I went through an triaged the placement of many issues
19:34:49 <sysrqb> one area of focus was on S58 tickets
19:35:13 <sysrqb> where we moved tickets with the S58 label into Next, or we deleted the S58 label
19:35:27 <sysrqb> with the intention of finishing S58 within the next month
19:35:56 <sysrqb> meaning any of those items should be near the top of our list now, if they weren't before
19:36:46 <sysrqb> please make sure the boards current reflect the issues/tasks/projects you're working on
19:37:47 <sysrqb> it's possible we made a mistake, so please ensure they look good to you
19:40:08 <sysrqb> and the last item i'd like to discuss is Tor Browser's default search engine config
19:40:50 <sysrqb> https://lists.torproject.org/pipermail/tbb-dev/2020-November/001170.html
19:41:34 <sysrqb> I tihnk many (if not all) of are are aware of the issue with returning to DDG search results after clicking a link
19:41:45 <sysrqb> s/of are/of us/
19:41:49 <antonela> ye
19:42:54 <sysrqb> and this related to tor-browser#40153, as well
19:43:16 <sysrqb> but i wonder if we can justify the current behavior
19:43:33 <sysrqb> i don't remember why we switched the config from GET to POST
19:43:59 <sysrqb> GeKo: do you remember why, and do you think it is useful?
19:44:37 <GeKo> because of GET requests landing in logs
19:44:43 <GeKo> leaking search terms
19:45:13 <GeKo> i find it useful, yes
19:45:22 <acat> there's tor-browser#33878
19:45:31 <GeKo> the question, though, is whether that outweights the costs
19:45:32 <sysrqb> ah, server logs
19:45:35 <GeKo> yes
19:45:52 <sysrqb> okay, that is a decent argument for POST
19:46:15 <acat> which logs?
19:46:16 * Jeremy_Rand_Talos generally concurs that private data should be kept out of GET requests when feasible; too much stuff logs URL's
19:46:28 <sysrqb> tor-browser#33878 is a little different, because that relies on DDG's server config
19:46:48 <sysrqb> because that is how DDG is redirecting requests from ddg.com to html.ddg.com
19:47:18 <sysrqb> maybe we can change that internally in tor browser, when the security level is changed
19:47:18 <acat> ok, server logs, didn't see that sorry
19:47:45 <sysrqb> but that is separate issue
19:47:51 <GeKo> yep
19:48:08 <GeKo> so, it seems we should get ddg to fix their things?
19:48:16 <acat> but why wouldn't ddg log post requests?
19:48:16 <sysrqb> i think one liminting argument for using POST in the browser search config is that ddg use GET in any follow-up queries on their site
19:48:18 <GeKo> or is that plan already discarded?
19:48:31 <sysrqb> but, leaking the first one is not necessary
19:48:57 <sysrqb> GeKo: apparently they are aware of it and don't intend on fixing it
19:49:11 <GeKo> i see
19:49:14 <sysrqb> i'd like to reach out to them and understand why this is a limitation
19:49:27 <sysrqb> but that's one more thing on the list
19:50:08 <Jeremy_Rand_Talos> it's not just server logs, lots of things log URL's more liberally than POST data (e.g. POST gives some defense in depth against referrer leaks)
19:50:11 <sysrqb> Peter found that on https://duckduckgo.com/privacy
19:50:24 <sysrqb> they say:
19:50:25 * antonela we could ask yandex to use POST :p
19:50:28 <sysrqb> "You can turn on POST requests on our settings page, but it has its own issues. POST requests usually break browser back buttons, and they make it impossible for you to easily share your search by copying and pasting it out of your Web browser's address bar."
19:50:48 <GeKo> hm
19:51:04 <sysrqb> obviously the former is more of our concern than the latter
19:51:14 <sysrqb> antonela: heh
19:51:37 <acat> but what does it fix? the query in the referrer? i hope that's not an issue
19:51:47 <acat> "Another way to prevent search leakage is by using something called a POST request, which has the effect of not showing your search in your browser, and, as a consequence, does not send it to other sites."
19:51:54 <antonela> for real, i wonder if asking users to pick a search engine in a onboarding is something we can explore for the future (instead of setting a default)
19:52:26 <sysrqb> acat: don't we strip the query string in the referrer?
19:52:34 <sysrqb> (for cross-origin)
19:53:14 <acat> yeah, so i wonder how this would be sent to other sites without POST
19:53:15 <sysrqb> antonela: we could
19:53:46 <sysrqb> but we should think about how that effects a user's uniqueness
19:54:35 <sysrqb> acat: i think the main concern is the query string landing in DDG's web server logs
19:54:46 <sysrqb> but maybe they are already logging post requests anyway
19:55:05 <sysrqb> and POST vs. GET is not really meaningful in that regard
19:55:33 <acat> yeah, that was my thought
19:55:35 <sysrqb> (logging post request payloads)
19:56:16 <acat> i mean, i don't see that they say that they will not log if it's POST but they will if it's GET
19:57:14 <sysrqb> yeah
19:57:21 <sysrqb> i'll finish opening a ticket about this
19:57:35 <sysrqb> and we can decide how we should proceed
19:57:53 <sysrqb> and feel free to jump into that mail thread, too
19:58:34 <sysrqb> alrighty
19:58:38 <sysrqb> thanks everyone
19:58:43 <sysrqb> have a good week
19:58:47 <sysrqb> #endmeeting