[tbb-dev] Tor/Mozilla Meeting Notes on tor-in-firefox integration

Hi everyone! Attached are the meeting notes from the video conference call we just had with Mozilla folks to talk about the ongoing project to integrate tor into Firefox's private browsing mode. This mostly concerns the Network and Browser teams, but towards the end the UX team was mentioned a lot as well. Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt -------------- next part -------------- # -*- mode: org; coding: utf-8; -*- Tor Project / Mozilla meeting notes <2017-11-06 Mon> * One Mozillian asks how tor works? tor speaks the tor protocol to the network, over tls tor expects apps to direct to an open port, via socks5, now also for HTTP CONNECT based tunnels tor usually expects to have a directory to store it's file IPC API is via controlport, it's text-based protocol * Mozilla's current plan - ship tor in FF - launch tor process - talking socks to tor from FF - do IPC via controlport (They only just learned about the thread-in-process work, so this plan might change.) * Mozilla/Tor questions/wants *** General - strip binary down, make it smaller - use less bandwidth *** tor launcher and firefox integration Should tor launcher be a web extension? web extensions can't talk to other processes via TCP **** possibility: add experimental TCP socket feature in FF? Moz would prefer to not to that and modify tor. **** possibility: web ext could maybe talk via stdin/stdout? nickm recommends against, because of how windows select() expects to operate on sockets **** possibility: tor launcher as "system addon" Old-style addons won't exist anymore, but Mozilla retained the ability to make those themselves, would need to be signed with Mozilla's key. *** tor and firefox integration **** WIP: tor as a thread inside a process nickm is working on it, and have a controlport-protocol things which uses file descriptors to talk to it. There are namespace problems if tor is running twice in the same process space. **** possibility: unix domain sockets for IPC? This won't work on Window because the named pipes (windows equivalent of unix sockets) won't work with select(). **** possibility: tor switching from libevent to rust's mio? Mozilla sounds very interested in this, but Tor can't promise this right now on any specific timeframe. nickm mentions this might help the story with select() issues on windows. **** Mozilla might want to reimplement tor and standarise it? Every Tor person warns this would be ~~VERY LONG TERM~~. This would take forever, Tor Project doesn't have the resources to deal with this and still get work done. nickm also warns that the tor protocol is still constantly evolving, and it's not really a hack-n-forget project. Roger warns that we've not done a good job specifying high-level behaviours, we mostly only spec wire formats and low-level behaviours. Tor Project wouldn't mind help with shepherding/standardisation. **** Getting tor to build against libnss instead of openssl This would remove a huge chunk of the binary size. **** tor modularisation Getting tor to build only as a proxy or only a client, etc. **** Mozilla operation support Mozillian asks: Once we're past the prototype stage, what does moz need to do to continue to include tor in FF? LTS releases would be the way to go, include one of those in FF. Internal APIs are pretty stable and tor doesn't break things lightly, but that said, there are very few public APIs: socks/http proxy, ctrlport, thread-in-process, commandline, config files. **** Tor Network capacity/scaling Tor Network wouldn't crash if every FF user started using it right now, but it wouldn't be pretty. On the Tor Project side, we need to make sure we have the engineering capacity to study and support scaling things properly. Mozillians ask about warning/talking with us before turning on things in order to figure out what the load is going to look like. *** UX and informing users Mozilla doesn't want people to say "oh they have tor, but it's not as good as Tor Browser". The easiest thing would be if they were just the same thing. Roger mentions it would be good to have a section in the TB design doc that says "these are the categories of things you need to deal with to call yourself a 'tor browser'". It would be good to have, for example, Moz's Mobile UX team and other UX teams talk with our UX team to work together on an user onboarding story, and how to explain things to users and what the privacy/security/usability tradeoffs and possible hurdles which might come up. Arthur mentions it'd be interesting to look at the positive things that people are looking for, e.g. would it be useful, when FF sees someone is going to WebMD, to suggest that they use Private Browsing mode with Tor enabled? * Moving forward Would be helpful to have a list of intra-org meetings scheduled for relevant people to attend. Some of us will be meeting in person at the Mozilla All Hands in Austin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1240 bytes Desc: Digital signature URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20171106/62ecd3a4/attachment.sig>