Opened 4 years ago

Closed 4 years ago

#16727 closed defect (fixed)

Tor Browser about:healthreport shows Data Sharing ON

Reported by: teor Owned by: gk
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-5.0-regression, tbb-fingerprinting, TorBrowserTeam201508R
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I open Help > Tor Browser Health Report or about:healthreport in Tor Browser 5.0a4 on OS X 10.10, I see a toggle saying "Data Sharing ON" in the top right corner.
I can't change that toggle to off.

Is data really being shared? With who?
If not, can we remove this page entirely? It doesn't seem to work under the medium-high security level anyway.

Child Tickets

Change History (9)

comment:1 Changed 4 years ago by cypherpunks

Priority: normalmajor

comment:2 Changed 4 years ago by gk

Keywords: tbb-5.0-regression tbb-fingerprinting added
Owner: changed from tbb-team to gk
Status: newassigned

As far as I see it there is no data sharing going on. "Data Sharing ON" is visible as the content script which is updating the button according to our settings is forbidden to run due to your security slider settings. If you chose medium-low or use the default setting you'll see that Data Sharing is shown as "off".

It seems the browser is requesting a localized version of the page given that the default report URL, datareporting.healthreport.about.reportUrl, points https://fhr.cdn.mozilla.net/%LOCALE%/. That alone is already concerning. I think we should use our data:text/plain, "workaround" which leaves a blank page as teor requested. I'll add links to patches shortly.

comment:4 Changed 4 years ago by mcs

Your patches look OK. But to avoid user confusion, it would be better to remove the health report feature entirely. Inclusion seems to be triggered by MOZ_SERVICES_HEALTHREPORT=1 and it looks like we would have to patch browser/confvars.sh or add a new configure option to disable it. A similar argument can be made for disabling MOZ_TELEMETRY_REPORTING.

comment:5 in reply to:  4 ; Changed 4 years ago by gk

Replying to mcs:

Your patches look OK. But to avoid user confusion, it would be better to remove the health report feature entirely. Inclusion seems to be triggered by MOZ_SERVICES_HEALTHREPORT=1 and it looks like we would have to patch browser/confvars.sh or add a new configure option to disable it. A similar argument can be made for disabling MOZ_TELEMETRY_REPORTING.

I was thinking about that while looking for a way to fix this issue (MOZ_DATA_REPORTING might come to mind here as well?). But what I fear is weird breakage as this is a non-standard way of building Firefox which might not be supported at all. I thought this might be a bit risky at least for the stable one. The other reason why I am a bit reluctant is that I want to get our patch queue shorter and not longer :).

But generally, yes, if users are confused about that we should think about getting rid of these features at compile time.

comment:6 in reply to:  5 Changed 4 years ago by mcs

Replying to gk:

I was thinking about that while looking for a way to fix this issue (MOZ_DATA_REPORTING might come to mind here as well?). But what I fear is weird breakage as this is a non-standard way of building Firefox which might not be supported at all. I thought this might be a bit risky at least for the stable one. The other reason why I am a bit reluctant is that I want to get our patch queue shorter and not longer :).

Those are valid points. Compiling Firefox in unusual ways will probably hurt us someday if it hasn't already. I am not sure how confused people are so I am not sure how to decide which is the best solution.

comment:7 Changed 4 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

I have not seen much confusion about this. Neither in the blog nor on #tor nor elsewhere. Thus, I went ahead and merged my patches (with commit d0fc4f07bbae57b13298be569adceb0bf4bfa455 for 5.0 and c1bde5752a0116b2b99b061c4a3192ef13d2c100 for 5.5). I am open for a more invasive approach, in case people are showing up and are complaining.

comment:8 Changed 4 years ago by mikeperry

Resolution: fixed
Status: closedreopened

We dropped this from 5.5a2 and 5.0.1 due to the urgency of the release. Reopening so we remember to re-merge this after Thursday's release.

comment:9 Changed 4 years ago by gk

Resolution: fixed
Status: reopenedclosed

This is commit 5ae8e3145026ed9ba40d33105a0478ff58089137 (tor-browser-38.2.1esr-5.5-2) and commit 6fec465fa4e2feea64526850387c91f7f67c2446 (tor-browser-38.2.1esr-5.0-2) now.

Note: See TracTickets for help on using tickets.