Hello all!

We had another team meeting yesterday. The chat log can be found on

http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-03-18.59.log....

and our pad items are:

Tuesday, April 3, 2018 Discussion: -roadmap (https://docs.google.com/spreadsheets/d/1joFGDiHaqlorGeXhytKakiSnWY9TqTDv5Xqm...) -Mozilla All Hands from the browser side - Wednesday's sync with UX team at 1900utc #tor-meeting - isa will send email to the list with agenda

GeKo: Last Week: -https://bugzilla.mozilla.org/show_bug.cgi?id=1442406 (still not done, alas) -#25481 (made quite some progress) -update to the security control redesign proposal -continue triaging ages old bugs -during my Easter holidays came up with a fix for #21537 -prepared for IRC interviews This Week: -more IRC interviewing -more work on #25481 -monthly admin stuff -bug triage -getting back to #21777

mcs and brade: Last week: - Finished patches for #25405 (cannot use Moat if a meek bridge is configured). - Created an updated patch for #21850 (Update #16940 patch for e10s (about:tbupdate)). - Commented on #24309 (Activity 4.1: Improve how circuits are displayed to the user). - Spent a little time on #25663 (Downloaded files are corrupted). - Reviewed all of the updater bugs that have been fixed in Firefox since ESR52. [I am excited about the LZMA support that landed. I wonder about all the pieces we need to switch on our side for that, do we get that for free? GeKo] This week: - Review the team roadmap. - Help with code reviews including #25126 (about:tor should work on small screens). - Create tickets for some ESR60 updater-related tasks. - Start rebasing the Tor Browser updater patches for ESR 60.

tjr: (may not make the meeting, feeling sick) - Got a MinGW x64 Build going in TaskCluster: https://bugzilla.mozilla.org/show_bug.cgi?id=1434316 - Don't have it running. Currently messing with --disable-install-strip to try and get usable symbols

Might be a MinGW bug https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CA%2BcU7...

- Have done some easy P2 Resist Fingerprinting Bugs: - Canvas Learn More Link in the Permission Prompt (Not uplifted to 60. Do you want it?) [Geko: that one looks like we would be interested] - WebGL Debug Info - uplifted to 60 - Spoof English Gets Reset https://bugzilla.mozilla.org/show_bug.cgi?id=1447592 Not uplifted yet. I have to figure out how to reproduce this, if anyone knows what they're talking about... [I think we don't need that one uplifted, GeKo] - Local IP Address Leak via WebRTC (being debated, not uplifting to 60 unless you want it) [I think this is nothing for ESR60 either for us, GeKo]

igt0: Last week: - Took a look in the domain isolator to verify if it was possible to make it available for the alpha release. Final Status: The effort to make it work would be too hard since for the alpha release we will use the android vpn service. - Helped out sysrqb debugging the https-e race condition (it is still magical for us). - Investigated why cloudfare captcha doesn't render the image for Orfox users. This Week: - Keep investigating about cloudfare captcha and Firefox. Looks like if user is behind tor and the user agent is mobile, even the firefox desktop doesn't render the captcha image. [See my theory about "There is no ESR 52 for Android, therefore your browser is outdated and insecure and therefore we won't serve you content idea"? GeKo] [yep, i am using the latest fennec useragent and it didn't work (Mozilla/5.0 (Android; Mobile; rv:59.0) Gecko/59.0 Firefox/59.0) - igt0 Aha, so we need a different theory the, good. GeKo]

boklm: Last week:

- finished publishing of the new releases

- started reviewing patch for #25483 (Windows reproducible build of snowflake)

- worked on binutils reproducibility issue (#16472)

This week:

- continue work on toolchain updates

- fix #25318 (Add Tor Browser nightly builds email notification)

- work on getting the testsuite running

sysrqb: Last week: Built Orfox (52.7.3) - still waiting for release

https://people.torproject.org/~sysrqb/Orfox-tor-browser-52.7.3esr-7.5-1.apk

Made progress on updating https-everywhere add-on (25603) - still debugging

Started troubleshooting #25659 (race condition during add-on installation?)

Documented some TBA roadmap items on the wiki

https://trac.torproject.org/projects/tor/wiki/org/teams/ApplicationsTeam/Tor...

Updated (a little) the Application team wiki page

https://trac.torproject.org/projects/tor/wiki/org/teams/ApplicationsTeam

This week: Merge Orfox https-everywhere update Start rebase onto mozilla-central

sysrqb: gk, what should the review process look like? Will tor-browser.git have two new branches, one more for stable and another for alpha? [Okay, we'll wait on the rebase done by arthur; sysrqb and igt0 will help with the mobile parts. once done and reviewed we rebase the resulting patches onto mozilla-central used for tor browser alpha on mobile GeKo]

pospeselr:

Last week:

Investigation on #20283 (Tor Browser should run without a /proc filesystem)

Got a complete list of all open and openat sys calls requesting something in /proc in firefox and plugin_container process (for 64 bit linux)

About 8 different scenarios found, majority of which currently handle failure gracefully

2 instances are dead code

mozilla::ThreadStackHelper::GetThreadStackBase() is the remaining problem (pointed out by Yawning in the bug report)

current stack address is used as a sort of heuristic in several places in the code

seems to be ranges certain types of JS are allowed to recurse down to (system native, system js, user js)

from what I've been able to glean, the only way to get this information on linux is via the /proc/self/maps file (this is file parsed by pthreads calls)

stack size is queryable via getrlimit syscall

best thing I've been able to come up with is bouncing up the rbp register until we get an address that's out of range in order to get a good estimate of where the stack memory map begins/ends

seems unlikely this sort of hacky bs would get upstreamed

breaks as soon as the compilation options are changed to omit frame pointer usage (-fno-omit-frame-pointer flag is required on amd64)

I've started investigating what we would need to do to refactor FF to not need the stack memory layout, but this seems to be a security-ish feature?

Have not investigated whether any fstat or other file related syscalls are called on things in /proc but easy enough to do once this GetThreadStackBase issue is sorted

arthuredelstein: Last week: * Worked on rebasing patches to ESR60 * Worked on FPI of permissions patch https://bugzilla.mozilla.org/show_bug.cgi?id=1330467 * Revising circuit display patch: https://trac.torproject.org/projects/tor/ticket/24309 This week: * Try to finish rebasing desktop patches [mcs: where are you doing this work?] [arthur: it's on a local branch atm. Tends to get re-ordered a lot, but I could post a snapshot if needed.] [mcs: we don't need it yet but would be useful soon-ish; maybe let me know which patches brade and I should work on][arthur: will do, thanks] * Post revised circuit display patch * Try to finish permissions patch, continue Save As patch * AFK (vacation) on Thursday and Friday

isabela: Final report for sponsor4 - vixe! Working on sponsor8 Q1 2018 report Reviewed all roadmap and created a tab for the things ux team is involved and i am organizing all that on ux (stakeholders) side question for arthur -> this item: "Click your flag" design - I will want it to be a test not really a feature we ship - if its related to the 'one click solve all censorship problem'. Something like this need to be tested well before we put it on alpha.

Georg