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

[isis agora lovecruft]

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>