GNU bug report logs -
#41848
Surfing with Tor
Previous Next
To reply to this bug, email your comments to 41848 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Sun, 14 Jun 2020 11:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Antonio T. sagitter" <sagitter <at> fedoraproject.org>:
New bug report received and forwarded. Copy sent to
bug-gnuzilla <at> gnu.org.
(Sun, 14 Jun 2020 11:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all.
Please, can anyone else confirm this bug on IceCat?
https://bugzilla.redhat.com/show_bug.cgi?id=1842171
--
---
Antonio Trande
Fedora Project
mailto: sagitter <at> fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Sun, 14 Jun 2020 15:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On 14/6/20 12:52, Antonio T. sagitter wrote:
> Hi all.
>
> Please, can anyone else confirm this bug on IceCat?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
>
Hi Antonio. Tor button doesn't work for me either on Archlinux v68.9.0.
Tried installing Firefox's official addon from
https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/ but
nothing.
Cheers
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Sun, 14 Jun 2020 15:58:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 41848 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The IceCat Internet Browser
Sunday, June 14, 2020
I use IceCat on a Linux Mint 19.3 machine, which dual-boot choice with
Microsoft Windows 10 Home, both _64_-_bit_, on a Hewlett-Packard
(_H_._P_.) Pavilion 17, with 8 GB in Installed Memory / Random Access
Memory (_R_._A_._M_.), and 1 TB of Solid State Drive (_S_._S_._D_.), but
IceCat is very erratic, but functional. On an _onion_ network, I use a
current Tor Browser, which I update not daily, but often...
Best wishes,
Lloyd
--
Lloyd F. Frazier
E-Mail - frazier <at> vivaldi.net
On 14/06/2020 05:52 AM, Antonio T. sagitter wrote:
> Hi all.
>
> Please, can anyone else confirm this bug on IceCat?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
[Message part 2 (text/html, inline)]
[7606527d.jpeg (image/jpeg, inline)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Sun, 14 Jun 2020 16:32:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 41848 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Joan.
Sure you're using a Tor network before switch on Onion proxy?
On 14/06/20 17:47, Joan Figueras wrote:
> On 14/6/20 12:52, Antonio T. sagitter wrote:
>> Hi all.
>>
>> Please, can anyone else confirm this bug on IceCat?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
>>
> Hi Antonio. Tor button doesn't work for me either on Archlinux
> v68.9.0. Tried installing Firefox's official addon from
> https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/
> but nothing.
>
>
> Cheers
>
>
>
>
--
---
Antonio Trande
Fedora Project
mailto: sagitter <at> fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
[Message part 2 (text/html, inline)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Sun, 14 Jun 2020 19:12:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Hi Antonio. Tor button doesn't work for me either on Archlinux v68.9.0.
> Tried installing Firefox's official addon from
> https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/ but
> nothing.
It doesn't work for me either, I have tor running at localhost:9050
--
qorg11
https://qorg11.net
https://kill-9.xyz
PGP: 343F C20A 4ACA 62B9, https://vxempire.xyz/pgp.txt
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Sun, 14 Jun 2020 19:12:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 41848 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yes:
figue <at> pluto ~ % sudo netstat -lnap | grep 9050
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN
38935/tor
The check says:
"Sorry. You are not using Tor"
And in network settings it says:
"An extension, Onion Browser Button, is controlling how IceCat connects
to the internet."
On 14/6/20 18:19, Antonio T. sagitter wrote:
>
> Hi Joan.
>
> Sure you're using a Tor network before switch on Onion proxy?
>
> On 14/06/20 17:47, Joan Figueras wrote:
>> On 14/6/20 12:52, Antonio T. sagitter wrote:
>>> Hi all.
>>>
>>> Please, can anyone else confirm this bug on IceCat?
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
>>>
>> Hi Antonio. Tor button doesn't work for me either on Archlinux
>> v68.9.0. Tried installing Firefox's official addon from
>> https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/
>> but nothing.
>>
>>
>> Cheers
>>
>>
>>
>>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto:sagitter <at> fedoraproject.org
> GPG key: 0x7B30EE04E576AA84
> GPG key server:https://keys.openpgp.org/
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Mon, 15 Jun 2020 05:28:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 41848 <at> debbugs.gnu.org (full text, mbox):
Hi Antonio,
> Please, can anyone else confirm this bug on IceCat?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
Thank you for bringing this to our attention.
It appears to be a bug in the "Onion Browser Button" add-on by Bentham
<https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/>
when used with Firefox ESR 68.
I was able to reproduce this problem both in the IceCat 68.9 preview on
Guix, and also on a Debian 9 system with Debian's stock firefox-esr
(68.9) package and the Onion Browser Button add-on installed via
addons.mozilla.org.
I'll note that this bug report applies to the 68.8 and 68.9 previews of
IceCat, which are the only IceCat previews to use the latest release
(0.1.8) of the Onion Browser Button. Earlier IceCat previews used
version 0.1.7. It was updated in the following commit:
https://git.savannah.gnu.org/cgit/gnuzilla.git/commit/?h=68&id=3cb3e92e55c4f22aaa7e520fea1a1d8fdbef72b4
I'm currently building a version of IceCat 68.9 with the above commit
reverted, to see if the bug also exists in version 0.1.7 of the Onion
Browser Button.
To be continued...
Regards,
Mark
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Mon, 15 Jun 2020 10:15:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 41848 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Mark.
I'm using IceCat 68.9.0 and Onion-0.1.8 button bundled into IceCat's
source archive, on Fedora 32.
I never noted this bug, sincerely.
On 15/06/20 07:24, Mark H Weaver wrote:
> Hi Antonio,
>
>> Please, can anyone else confirm this bug on IceCat?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
> Thank you for bringing this to our attention.
>
> It appears to be a bug in the "Onion Browser Button" add-on by Bentham
> <https://addons.mozilla.org/en-US/firefox/addon/tortm-browser-button/>
> when used with Firefox ESR 68.
>
> I was able to reproduce this problem both in the IceCat 68.9 preview on
> Guix, and also on a Debian 9 system with Debian's stock firefox-esr
> (68.9) package and the Onion Browser Button add-on installed via
> addons.mozilla.org.
>
> I'll note that this bug report applies to the 68.8 and 68.9 previews of
> IceCat, which are the only IceCat previews to use the latest release
> (0.1.8) of the Onion Browser Button. Earlier IceCat previews used
> version 0.1.7. It was updated in the following commit:
>
> https://git.savannah.gnu.org/cgit/gnuzilla.git/commit/?h=68&id=3cb3e92e55c4f22aaa7e520fea1a1d8fdbef72b4
>
> I'm currently building a version of IceCat 68.9 with the above commit
> reverted, to see if the bug also exists in version 0.1.7 of the Onion
> Browser Button.
>
> To be continued...
>
> Regards,
> Mark
>
>
>
--
---
Antonio Trande
Fedora Project
mailto: sagitter <at> fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
[Message part 2 (text/html, inline)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Mon, 15 Jun 2020 20:44:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 41848 <at> debbugs.gnu.org (full text, mbox):
Earlier, I wrote:
> I'm currently building a version of IceCat 68.9 with the above commit
> reverted, to see if the bug also exists in version 0.1.7 of the Onion
> Browser Button.
The same problem happens for me with version 0.1.7 of the Onion Browser
Button in the IceCat 68.9 preview. I guess that this add-on does not
work reliably (if at all) with Firefox ESR 68.x or its derivatives.
Maybe it works better with Firefox 77.
Unless someone has a better suggestion, I'm inclined to simply *remove*
Onion Browser Button from the IceCat 68 preview.
Long ago, the Tor Browser developers reached the conclusion that having
a simple toggle button was the wrong approach, and I agree.
https://blog.torproject.org/toggle-or-not-toggle-end-torbutton
One problem is that modern web browsers have a large amount of state
which can be used to identify you, and toggling the Tor button does not
clear that state. When you aren't using Tor, sites can learn the state
of your browser profile and associate that state with your identity.
Later, if you turn Tor on, all of that state is still there to identify
you, even if your network requests are routed through Tor.
I believe that in order to properly preserve your anonymity while web
browsing, at *minimum* each IceCat _profile_ should either be used
exclusively with Tor, or exclusively without Tor. In other words, you
should create dedicated profiles for use with Tor; when creating a new
profile, you should either configure it to use Tor, or not, and you
should *never* toggle a given profile between Tor-enabled and
Tor-disabled. This requirement is violated by a Tor toggle button,
whose sole purpose is to make it convenient to do the very thing that
you should never do.
Another more difficult problem is that browsers can be fingerprinted in
various ways to determine their specific feature set and configuration.
IceCat has a distinctive set of features disabled, and a distinctive
configuration to better protect your privacy, but ironically these
improvements can likely be used by an adversary to determine that you
are an IceCat user, even if you are using Tor. Since there are
relatively few IceCat users, this dramatically narrows down the set of
people that you might be, thereby reducing your anonymity.
I think we should acknowledge that providing proper anonymity in IceCat
will require more work, and that work has not yet been done. Therefore,
I think we should remove Tor support from IceCat for now, and start a
discussion of what the requirements are and how best to meet them.
To begin, I recommend that participants of this discussion should read
"The Design and Implementation of the Tor Browser", here:
https://2019.www.torproject.org/projects/torbrowser/design/
I can think of a few approaches we might take. The easiest approach
would be to give up on having the same browser support Tor and non-Tor
usage, as the Tor developers did. IceCat, based on Firefox ESR, could
be our non-Tor browser, and then we could start another project, based
on Tor Browser, for use with Tor.
Another approach would be to provide an easy UI for enabling Tor when
creating a new profile, and to teach users best practices for doing
this. This approach would involve cherry-picking patches from Tor
Browser, and possibly arranging for some of those patches to take effect
only in profiles where Tor is enabled. It would likely also involve
using a different default configuration for Tor-enabled profiles, to
more closely match Tor Browser's configuration, to make it harder to
distinguish IceCat users from Tor Browser users.
Yet another idea would be to arrange for "Private Windows" to use Tor,
and to convince ourselves (or not) that the remotely-detectable state of
Private Windows are sufficiently isolated from the state of normal
windows.
I welcome other opinions.
Regards,
Mark
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Tue, 16 Jun 2020 10:45:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 41848 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 15/06/20 22:40, Mark H Weaver wrote:
> Earlier, I wrote:
>
>> I'm currently building a version of IceCat 68.9 with the above commit
>> reverted, to see if the bug also exists in version 0.1.7 of the Onion
>> Browser Button.
> The same problem happens for me with version 0.1.7 of the Onion Browser
> Button in the IceCat 68.9 preview. I guess that this add-on does not
> work reliably (if at all) with Firefox ESR 68.x or its derivatives.
> Maybe it works better with Firefox 77.
>
> Unless someone has a better suggestion, I'm inclined to simply *remove*
> Onion Browser Button from the IceCat 68 preview.
Another removing (about:icecat is already gone)? Of the original IceCat
nothing is remaining...
>
> Long ago, the Tor Browser developers reached the conclusion that having
> a simple toggle button was the wrong approach, and I agree.
>
> https://blog.torproject.org/toggle-or-not-toggle-end-torbutton
>
> One problem is that modern web browsers have a large amount of state
> which can be used to identify you, and toggling the Tor button does not
> clear that state. When you aren't using Tor, sites can learn the state
> of your browser profile and associate that state with your identity.
> Later, if you turn Tor on, all of that state is still there to identify
> you, even if your network requests are routed through Tor.
>
> I believe that in order to properly preserve your anonymity while web
> browsing, at *minimum* each IceCat _profile_ should either be used
> exclusively with Tor, or exclusively without Tor. In other words, you
> should create dedicated profiles for use with Tor; when creating a new
> profile, you should either configure it to use Tor, or not, and you
> should *never* toggle a given profile between Tor-enabled and
> Tor-disabled. This requirement is violated by a Tor toggle button,
> whose sole purpose is to make it convenient to do the very thing that
> you should never do.
I'm incline to choose the Tor-Icecat, in this case IceCat browser will
be always Tor dependent.
And, if in future some way Tor will become a proprietary feature?
>
> Another more difficult problem is that browsers can be fingerprinted in
> various ways to determine their specific feature set and configuration.
> IceCat has a distinctive set of features disabled, and a distinctive
> configuration to better protect your privacy, but ironically these
> improvements can likely be used by an adversary to determine that you
> are an IceCat user, even if you are using Tor. Since there are
> relatively few IceCat users, this dramatically narrows down the set of
> people that you might be, thereby reducing your anonymity.
>
> I think we should acknowledge that providing proper anonymity in IceCat
> will require more work, and that work has not yet been done. Therefore,
> I think we should remove Tor support from IceCat for now, and start a
> discussion of what the requirements are and how best to meet them.
>
> To begin, I recommend that participants of this discussion should read
> "The Design and Implementation of the Tor Browser", here:
>
> https://2019.www.torproject.org/projects/torbrowser/design/
>
> I can think of a few approaches we might take. The easiest approach
> would be to give up on having the same browser support Tor and non-Tor
> usage, as the Tor developers did. IceCat, based on Firefox ESR, could
> be our non-Tor browser, and then we could start another project, based
> on Tor Browser, for use with Tor.
>
> Another approach would be to provide an easy UI for enabling Tor when
> creating a new profile, and to teach users best practices for doing
> this. This approach would involve cherry-picking patches from Tor
> Browser, and possibly arranging for some of those patches to take effect
> only in profiles where Tor is enabled. It would likely also involve
> using a different default configuration for Tor-enabled profiles, to
> more closely match Tor Browser's configuration, to make it harder to
> distinguish IceCat users from Tor Browser users.
>
> Yet another idea would be to arrange for "Private Windows" to use Tor,
> and to convince ourselves (or not) that the remotely-detectable state of
> Private Windows are sufficiently isolated from the state of normal
> windows.
>
> I welcome other opinions.
>
> Regards,
> Mark
+1 for a dedicated discussion about.
--
---
Antonio Trande
Fedora Project
mailto: sagitter <at> fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
[Message part 2 (text/html, inline)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnuzilla <at> gnu.org:
bug#41848; Package
gnuzilla.
(Mon, 22 Jun 2020 17:53:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 41848 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
We should decide before Firefox 78ESR is released (June, 29).
On 15/06/20 07:24, Mark H Weaver wrote:
> Hi Antonio,
>
>> Please, can anyone else confirm this bug on IceCat?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1842171
>
> Thank you for bringing this to our attention.
>
--
---
Antonio Trande
Fedora Project
mailto: sagitter <at> fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 4 years and 356 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.