[tor-project] Tor Browser team meeting notes, 3 April 2018
Georg Koppen
gk at torproject.org
Wed Apr 4 07:16:00 UTC 2018
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.txt
and our pad items are:
Tuesday, April 3, 2018
Discussion:
-roadmap
(https://docs.google.com/spreadsheets/d/1joFGDiHaqlorGeXhytKakiSnWY9TqTDv5XqmbT3FkX8/edit#gid=0)
-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%2BcU71k2bU0azQxjy4-77ynQj1O%2BTKmgtaTKe59n7Bjub1y7Tg%40mail.gmail.com/#msg36282439
- 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/TorBrowserAndroid/Roadmap
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20180404/3bc60d1b/attachment.sig>
More information about the tor-project
mailing list