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