Hi tor devs!
I've spent today getting ramped up on building/debugging tor-browser and investigating a solution to issue #13398 https://trac.torproject.org/projects/tor/ticket/13398 (NsUserInfo object scrapes user's name, username, email, and domain).
My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since the issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo object ( https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ).
So my question to you is in this case, do we prefer to completely excise the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system implementations with a single 'mock' implementation which returns empty string (or errors) for each property getter?
Having read the design-doc (particularly the parts on finger printing) it seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old the API is and that vanilla Firefox still has it) and potentially break Add-Ons using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain that on windows the username (at least) will always return *something* so getting empty string here would also point to Tor Browser.
All that said, I suspect either of the above solutions are preferable to leaking user identifying information.
What do you think?
best, -Richard
Hi Richard!
Richard Pospesel:
Hi tor devs!
I've spent today getting ramped up on building/debugging tor-browser and investigating a solution to issue #13398 https://trac.torproject.org/projects/tor/ticket/13398 (NsUserInfo object scrapes user's name, username, email, and domain).
My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since the issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo object ( https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ).
So my question to you is in this case, do we prefer to completely excise the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system implementations with a single 'mock' implementation which returns empty string (or errors) for each property getter?
Having read the design-doc (particularly the parts on finger printing) it seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old the API is and that vanilla Firefox still has it) and potentially break Add-Ons using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain that on windows the username (at least) will always return *something* so getting empty string here would also point to Tor Browser.
All that said, I suspect either of the above solutions are preferable to leaking user identifying information.
Indeed. Identifying the browser as Tor Browser is not such a big deal. It's probably not even possible to hide that fact. But we should avoid breaking extensions. Although we are strongly discouraging the installation of additional extensions, users should be free to override this decision and retain a functional browsing experience.
Thus, returning an empty string (or the same non-empty values for every Tor Browser user) would be a good solution. Bonus points for binding that to a preference in case there are indeed extensions out there that rely on that kind of information being somewhat accurate. And having the preference govern this behavior should make it easier for us to upstream the patch to Mozilla (which is one of the important goals for writing all those patches in the first place).
Georg
What do you think?
best, -Richard
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
If we return *something* rather than empty string are there any localization concerns? I would assume we would want to return the same thing regardless of locale, since other similar info is normalized to be the same (like how timezone is standardized to UTC rather than exposing the user's real timezone).
thanks, -Richard
On Thu, Jul 20, 2017 at 1:00 AM, Georg Koppen gk@torproject.org wrote:
Hi Richard!
Richard Pospesel:
Hi tor devs!
I've spent today getting ramped up on building/debugging tor-browser and investigating a solution to issue #13398 https://trac.torproject.org/projects/tor/ticket/13398 (NsUserInfo
object
scrapes user's name, username, email, and domain).
My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since the issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo object
(
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ).
So my question to you is in this case, do we prefer to completely excise the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system
implementations
with a single 'mock' implementation which returns empty string (or
errors)
for each property getter?
Having read the design-doc (particularly the parts on finger printing) it seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old
the
API is and that vanilla Firefox still has it) and potentially break
Add-Ons
using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain that
on
windows the username (at least) will always return *something* so getting empty string here would also point to Tor Browser.
All that said, I suspect either of the above solutions are preferable to leaking user identifying information.
Indeed. Identifying the browser as Tor Browser is not such a big deal. It's probably not even possible to hide that fact. But we should avoid breaking extensions. Although we are strongly discouraging the installation of additional extensions, users should be free to override this decision and retain a functional browsing experience.
Thus, returning an empty string (or the same non-empty values for every Tor Browser user) would be a good solution. Bonus points for binding that to a preference in case there are indeed extensions out there that rely on that kind of information being somewhat accurate. And having the preference govern this behavior should make it easier for us to upstream the patch to Mozilla (which is one of the important goals for writing all those patches in the first place).
Georg
What do you think?
best, -Richard
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Richard Pospesel:
If we return *something* rather than empty string are there any localization concerns? I would assume we would want to return the same thing regardless of locale, since other similar info is normalized to be the same (like how timezone is standardized to UTC rather than exposing the user's real timezone).
Yes, there are localization concerns. Thus, if we report something back then it should be exactly the same string for all users irrespective of locale, time zone etc.
FWIW: sorry that nobody of us could help you yesterday on IRC. Not sure why you get the mach error. I suspect it is because you are trying to run mochitests but there are non under the xpcshell directory (running the xpcshell tests there works fine for me). There is no special guide for running Tor Browser mochitests, thugh. The Firefox docs should be enough in this case. Regarding the argument for --with-tor-browser-version I updated the wiki page. "4.5a4" should have done the trick but just pointing to our values we use for our nightly builds seems more future-proof.
Hope this helps,
Georg
thanks, -Richard
On Thu, Jul 20, 2017 at 1:00 AM, Georg Koppen gk@torproject.org wrote:
Hi Richard!
Richard Pospesel:
Hi tor devs!
I've spent today getting ramped up on building/debugging tor-browser and investigating a solution to issue #13398 https://trac.torproject.org/projects/tor/ticket/13398 (NsUserInfo
object
scrapes user's name, username, email, and domain).
My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since the issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo object
(
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ).
So my question to you is in this case, do we prefer to completely excise the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system
implementations
with a single 'mock' implementation which returns empty string (or
errors)
for each property getter?
Having read the design-doc (particularly the parts on finger printing) it seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old
the
API is and that vanilla Firefox still has it) and potentially break
Add-Ons
using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain that
on
windows the username (at least) will always return *something* so getting empty string here would also point to Tor Browser.
All that said, I suspect either of the above solutions are preferable to leaking user identifying information.
Indeed. Identifying the browser as Tor Browser is not such a big deal. It's probably not even possible to hide that fact. But we should avoid breaking extensions. Although we are strongly discouraging the installation of additional extensions, users should be free to override this decision and retain a functional browsing experience.
Thus, returning an empty string (or the same non-empty values for every Tor Browser user) would be a good solution. Bonus points for binding that to a preference in case there are indeed extensions out there that rely on that kind of information being somewhat accurate. And having the preference govern this behavior should make it easier for us to upstream the patch to Mozilla (which is one of the important goals for writing all those patches in the first place).
Georg
What do you think?
best, -Richard
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
No worries. I was hoping to add an automated test as part of my submission, but unless I can get this working in the next couple of hours I'll have to resort to manual verification via a dummy extension. Unfortunately, my weekend is almost completely booked so I'm not confident I'll be able to verify with an automated test before the 24th deadline.
The 4.5a4 version built just fine, but I wanted to be sure my patch was against latest :)
best, -Richard
On Fri, Jul 21, 2017 at 2:49 AM, Georg Koppen gk@torproject.org wrote:
Richard Pospesel:
If we return *something* rather than empty string are there any localization concerns? I would assume we would want to return the same thing regardless of locale, since other similar info is normalized to be the same (like how timezone is standardized to UTC rather than exposing
the
user's real timezone).
Yes, there are localization concerns. Thus, if we report something back then it should be exactly the same string for all users irrespective of locale, time zone etc.
FWIW: sorry that nobody of us could help you yesterday on IRC. Not sure why you get the mach error. I suspect it is because you are trying to run mochitests but there are non under the xpcshell directory (running the xpcshell tests there works fine for me). There is no special guide for running Tor Browser mochitests, thugh. The Firefox docs should be enough in this case. Regarding the argument for --with-tor-browser-version I updated the wiki page. "4.5a4" should have done the trick but just pointing to our values we use for our nightly builds seems more future-proof.
Hope this helps,
Georg
thanks, -Richard
On Thu, Jul 20, 2017 at 1:00 AM, Georg Koppen gk@torproject.org wrote:
Hi Richard!
Richard Pospesel:
Hi tor devs!
I've spent today getting ramped up on building/debugging tor-browser
and
investigating a solution to issue #13398 https://trac.torproject.org/projects/tor/ticket/13398 (NsUserInfo
object
scrapes user's name, username, email, and domain).
My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since
the
issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo
object
(
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ).
So my question to you is in this case, do we prefer to completely
excise
the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system
implementations
with a single 'mock' implementation which returns empty string (or
errors)
for each property getter?
Having read the design-doc (particularly the parts on finger printing)
it
seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old
the
API is and that vanilla Firefox still has it) and potentially break
Add-Ons
using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain
that
on
windows the username (at least) will always return *something* so
getting
empty string here would also point to Tor Browser.
All that said, I suspect either of the above solutions are preferable
to
leaking user identifying information.
Indeed. Identifying the browser as Tor Browser is not such a big deal. It's probably not even possible to hide that fact. But we should avoid breaking extensions. Although we are strongly discouraging the installation of additional extensions, users should be free to override this decision and retain a functional browsing experience.
Thus, returning an empty string (or the same non-empty values for every Tor Browser user) would be a good solution. Bonus points for binding that to a preference in case there are indeed extensions out there that rely on that kind of information being somewhat accurate. And having the preference govern this behavior should make it easier for us to upstream the patch to Mozilla (which is one of the important goals for writing all those patches in the first place).
Georg
What do you think?
best, -Richard
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
-
Georg Koppen -
Richard Pospesel