info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Tor Mode: To pref or not to pref?
59 views
Skip to first unread message
Mike Perry
Feb 1, 2015, 4:34:23 PM2/1/15
to dev-p...@lists.mozilla.org
Hey everyone,
As I mentioned in the "Isolating sites from one another and dealing with
multiple online identities" thread[1], the Tor Browser team is currently
trying to decide how to best prepare our patches to support a Tor Mode
in normal Firefox while still supporting our Tor Browser userbase in the
meantime, and without overwhelming engineering effort on our side.
On our own mailinglist, we're discussing how we think our privacy
options should be presented[2,3]. While the upstream Firefox UI/UX
aspects of a Tor mode feature may be premature to specify in a
fine-grained manner at this time, we do feel it is important to have our
target operation mode specified at least to the degree where we can
decide if it should be based on a pref, or channel attribute, or
AppId/Container isolation, so we can decide what governs when our
tracking prevention properties are enabled.
The benefit of having a pref or a few prefs is that implementation is
simple, and easy to deploy for Tor Browser. This is the approach we've
taken to date, and this approach is also consistent with the recent UI/UX
discussion that I linked to on our mailinglist.
The downside of the pref approach is that for stock Firefox, it will be
difficult to provide users with a concurrent Tor Mode window that
supports Tor in a way that is consistent with our notions of tracking
prevention. Basically, a pref-based approach means that users will have
to enable Tor mode independent of their tracking prevention choices, and
that their tracking prevention choices will need to apply to both
Tor-enabled windows and non-Tor windows, which may be undesirable for
many users.
The preference approach really starts to show its limitations when you
consider that for Tor windows, the user will want prefs like
'media.peerconnection.enabled' turned off to prevent proxy bypass. This
means that WebRTC calls will then fail for non-Tor windows, or the user
will be exposed to deanonymization in Tor Mode windows[4].
Does anyone on the Mozilla side have any strong opinions about this? The
recent isolation thread made me wonder if there are other new isolation
mechanisms that we should be leveraging too, or if we should be more
actively involved in future isolation and identity management
discussions.
1. https://groups.google.com/d/msg/mozilla.dev.privacy/XQza_CmYDr4/7hemg2vtyUYJ
2. https://lists.torproject.org/pipermail/tbb-dev/2015-January/000217.html
3. https://lists.torproject.org/pipermail/tbb-dev/2015-January/000219.html
4. https://diafygi.github.io/webrtc-ips/
--
Mike Perry
As I mentioned in the "Isolating sites from one another and dealing with
multiple online identities" thread[1], the Tor Browser team is currently
trying to decide how to best prepare our patches to support a Tor Mode
in normal Firefox while still supporting our Tor Browser userbase in the
meantime, and without overwhelming engineering effort on our side.
On our own mailinglist, we're discussing how we think our privacy
options should be presented[2,3]. While the upstream Firefox UI/UX
aspects of a Tor mode feature may be premature to specify in a
fine-grained manner at this time, we do feel it is important to have our
target operation mode specified at least to the degree where we can
decide if it should be based on a pref, or channel attribute, or
AppId/Container isolation, so we can decide what governs when our
tracking prevention properties are enabled.
The benefit of having a pref or a few prefs is that implementation is
simple, and easy to deploy for Tor Browser. This is the approach we've
taken to date, and this approach is also consistent with the recent UI/UX
discussion that I linked to on our mailinglist.
The downside of the pref approach is that for stock Firefox, it will be
difficult to provide users with a concurrent Tor Mode window that
supports Tor in a way that is consistent with our notions of tracking
prevention. Basically, a pref-based approach means that users will have
to enable Tor mode independent of their tracking prevention choices, and
that their tracking prevention choices will need to apply to both
Tor-enabled windows and non-Tor windows, which may be undesirable for
many users.
The preference approach really starts to show its limitations when you
consider that for Tor windows, the user will want prefs like
'media.peerconnection.enabled' turned off to prevent proxy bypass. This
means that WebRTC calls will then fail for non-Tor windows, or the user
will be exposed to deanonymization in Tor Mode windows[4].
Does anyone on the Mozilla side have any strong opinions about this? The
recent isolation thread made me wonder if there are other new isolation
mechanisms that we should be leveraging too, or if we should be more
actively involved in future isolation and identity management
discussions.
1. https://groups.google.com/d/msg/mozilla.dev.privacy/XQza_CmYDr4/7hemg2vtyUYJ
2. https://lists.torproject.org/pipermail/tbb-dev/2015-January/000217.html
3. https://lists.torproject.org/pipermail/tbb-dev/2015-January/000219.html
4. https://diafygi.github.io/webrtc-ips/
--
Mike Perry
sst...@mozilla.com
Feb 2, 2015, 11:14:41 AM2/2/15
to
On Sunday, February 1, 2015 at 4:34:23 PM UTC-5, Mike Perry wrote:
> Does anyone on the Mozilla side have any strong opinions about this? The
> recent isolation thread made me wonder if there are other new isolation
> mechanisms that we should be leveraging too, or if we should be more
> actively involved in future isolation and identity management
> discussions.
Could we use a separate profile for Tor Mode? It would appear like a "new window" but could have complete process and profile directory isolation from a non-Tor session.
> Does anyone on the Mozilla side have any strong opinions about this? The
> recent isolation thread made me wonder if there are other new isolation
> mechanisms that we should be leveraging too, or if we should be more
> actively involved in future isolation and identity management
> discussions.
-Sid
Steve Workman
Feb 2, 2015, 6:31:30 PM2/2/15
to Sid Stamm, dev-p...@lists.mozilla.org
Agree with Sid - adding in settings etc. it sounds like multiple profiles
is better here.
Mike, have you seen Switchy?
https://addons.mozilla.org/en-US/firefox/addon/switchy/?src=ss It exposes
some more profile management that might be of interest to you. What if Tor
had a similar addon that created a new profile with the correct prefs
set/unset as desired?
> _______________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
>
is better here.
Mike, have you seen Switchy?
https://addons.mozilla.org/en-US/firefox/addon/switchy/?src=ss It exposes
some more profile management that might be of interest to you. What if Tor
had a similar addon that created a new profile with the correct prefs
set/unset as desired?
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
>
Mike Perry
Feb 5, 2015, 6:46:08 PM2/5/15
to dev-p...@lists.mozilla.org
Just so there is a public record, I spoke with Sid and Steve yesterday,
and I am in agreement that a separate Tor profile and separate Firefox
process for Tor Mode is the best way to build a Tor Mode with good
usability and minimal engineering effort. It will allow us to use
pref-based tracking protection features, and worry less about layering
issues deep in the stack causing leaks between Tor Mode and normal
browsing.
If there is a simple UI like Switchy for launching these new profile
instances in a seamless way, it seems like a win.
I am also in favor of standardizing the way that Firefox communicates
with Tor as a privacy-preserving network layer, so that Mozilla is not
locked in to Tor as the only way of providing network privacy. I think
this property is important for motivating the feature set without
running into concerns that Tor would be the only possible consumer of
the tracking protection features we want, especially if there are still
concerns about Tor's scalability and performance (even though I believe
these issues are solvable).
Steve Workman:
Mike Perry
and I am in agreement that a separate Tor profile and separate Firefox
process for Tor Mode is the best way to build a Tor Mode with good
usability and minimal engineering effort. It will allow us to use
pref-based tracking protection features, and worry less about layering
issues deep in the stack causing leaks between Tor Mode and normal
browsing.
If there is a simple UI like Switchy for launching these new profile
instances in a seamless way, it seems like a win.
I am also in favor of standardizing the way that Firefox communicates
with Tor as a privacy-preserving network layer, so that Mozilla is not
locked in to Tor as the only way of providing network privacy. I think
this property is important for motivating the feature set without
running into concerns that Tor would be the only possible consumer of
the tracking protection features we want, especially if there are still
concerns about Tor's scalability and performance (even though I believe
these issues are solvable).
Steve Workman:
> Agree with Sid - adding in settings etc. it sounds like multiple profiles
> is better here.
>
> Mike, have you seen Switchy?
> https://addons.mozilla.org/en-US/firefox/addon/switchy/?src=ss It exposes
> some more profile management that might be of interest to you. What if Tor
> had a similar addon that created a new profile with the correct prefs
> set/unset as desired?
>
> On Mon, Feb 2, 2015 at 8:14 AM, <sst...@mozilla.com> wrote:
>
> is better here.
>
> Mike, have you seen Switchy?
> https://addons.mozilla.org/en-US/firefox/addon/switchy/?src=ss It exposes
> some more profile management that might be of interest to you. What if Tor
> had a similar addon that created a new profile with the correct prefs
> set/unset as desired?
>
> On Mon, Feb 2, 2015 at 8:14 AM, <sst...@mozilla.com> wrote:
>
> > _______________________________________________
> > dev-privacy mailing list
> > dev-p...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-privacy
> >
> _______________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
--
> > dev-privacy mailing list
> > dev-p...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-privacy
> >
> _______________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
Mike Perry
Dave Huseby
Mar 2, 2015, 11:40:44 AM3/2/15
to dev-p...@lists.mozilla.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/05/2015 03:44 PM, Mike Perry wrote:
> I am also in favor of standardizing the way that Firefox
> communicates with Tor as a privacy-preserving network layer, so
> that Mozilla is not locked in to Tor as the only way of providing
> network privacy.
This is a double-plus good idea. I have pitched the idea for a
network-only process that exposes an API via xpc/webidl. On Firefox
OS we'd be able to use PID-based iptables rules to force all DNS/TCP
traffic from the net process through Tor--or any proxy for that matter
(e.g. VPN, etc). You could also look at as adding some
security-by-isolation.
- --dave
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJU9JJnAAoJEJ7v31qiCP4gRX8P/0pKB12+Zii0O8YU3uuG+4VG
ArdKIBP6cf9UFjiTIhKlfyLEvuaYGMWYUaEBWqmtXdaYgkmgSOB0tyqGlstGdVDA
Z2jWAbr6Aw2vlJEwFPPc+04TvGTYPqVFAo3941KjDZs4eG5UDqVmOApDvktg3cMV
76eLqzVzvlYcThh+TCP61AgKjTh4+IwzccdRbFmhV3Qad9Mz6E6HWaWPub8KsEvl
flzMRib5dsCcUdQh9418OWIBlJWocy9byuv6NY7o7clDH7KtL9hpqJeU0JNxzio6
XwxTQN5zsGfMKAn62vaJgrtZlnwX4AiSc1AjqczLVTFT1ToNJ1CAAgtLrjGYUQf7
6JcQ8/aEauw+5jEtIkcRWpuUedWaesEIuJ14rFFBWnpuEr/S/e+wYl+sXS1eqLuQ
qlsnaVwJJ8TqqWBOTa1iHd8Mp6j6pc2qPXOH9JM1RD5xq8bjxoE5FIdp4ZoozNcp
9J5c7q9852flcxcAydJnaY8tuwbbjk/YtcmDg32+CVz9foz1K61J3KDcF27cYiW+
w2gJDjg+xm62MJ3zwrZwGpKp9IMeZAaJzaRP0ie93Z2dXHkc+I3YVsKEOHo0MB6H
+/c/QQEd94D+wp20bdMmxp84aH7zBJlV4Fvhgn9gHYM04g0feBFnjlEZN+oCutP3
C305EZWNN3wJ6QaAhj0q
=FXac
-----END PGP SIGNATURE-----
Hash: SHA1
On 02/05/2015 03:44 PM, Mike Perry wrote:
> I am also in favor of standardizing the way that Firefox
> communicates with Tor as a privacy-preserving network layer, so
> that Mozilla is not locked in to Tor as the only way of providing
> network privacy.
network-only process that exposes an API via xpc/webidl. On Firefox
OS we'd be able to use PID-based iptables rules to force all DNS/TCP
traffic from the net process through Tor--or any proxy for that matter
(e.g. VPN, etc). You could also look at as adding some
security-by-isolation.
- --dave
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJU9JJnAAoJEJ7v31qiCP4gRX8P/0pKB12+Zii0O8YU3uuG+4VG
ArdKIBP6cf9UFjiTIhKlfyLEvuaYGMWYUaEBWqmtXdaYgkmgSOB0tyqGlstGdVDA
Z2jWAbr6Aw2vlJEwFPPc+04TvGTYPqVFAo3941KjDZs4eG5UDqVmOApDvktg3cMV
76eLqzVzvlYcThh+TCP61AgKjTh4+IwzccdRbFmhV3Qad9Mz6E6HWaWPub8KsEvl
flzMRib5dsCcUdQh9418OWIBlJWocy9byuv6NY7o7clDH7KtL9hpqJeU0JNxzio6
XwxTQN5zsGfMKAn62vaJgrtZlnwX4AiSc1AjqczLVTFT1ToNJ1CAAgtLrjGYUQf7
6JcQ8/aEauw+5jEtIkcRWpuUedWaesEIuJ14rFFBWnpuEr/S/e+wYl+sXS1eqLuQ
qlsnaVwJJ8TqqWBOTa1iHd8Mp6j6pc2qPXOH9JM1RD5xq8bjxoE5FIdp4ZoozNcp
9J5c7q9852flcxcAydJnaY8tuwbbjk/YtcmDg32+CVz9foz1K61J3KDcF27cYiW+
w2gJDjg+xm62MJ3zwrZwGpKp9IMeZAaJzaRP0ie93Z2dXHkc+I3YVsKEOHo0MB6H
+/c/QQEd94D+wp20bdMmxp84aH7zBJlV4Fvhgn9gHYM04g0feBFnjlEZN+oCutP3
C305EZWNN3wJ6QaAhj0q
=FXac
-----END PGP SIGNATURE-----
0 new messages