1865032 - 'Do Not Track' option in the settings should be grayed out when ETP Strict is enabled

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[bugdiscovery]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

In settings about privacy i ticked off the option related to "Do Not Track".

Actual results:

"Do Not Track" is still being sent to web sites.

Expected results:

"Do Not Track" should be disabled.

I think the issue is that "Do Not Track" is triggered by the "strict tracking protection" being enabled. But if that's the case, the stand-alone option about "Do not Track" should be grayed out or something.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emma Zühlcke [:emz]]

Attachment: old-dnt-controls.png

Comment 3

[Emma Zühlcke [:emz]]

I agree that this is pretty confusing, before we had a checkbox to switch between "always" or "only when set to block known trackers" (ETP strict, or ETP custom with TP enabled). We still seem to follow that behavior, but the UI with the checkboxes suggests that you can disable DNT / GPC in ETP strict/custom.

Ben, could you take a look?

Comment 4

[Benjamin VanderSloot [:bvandersloot]]

Thanks for the report!

We do still follow the original behavior of "only when set to block known trackers" when the DNT checkbox is unchecked. This was a design choice to try to make the control more intuitive. The logic here is that there are a lot of things that just get turned on when ETP Strict or Private Browsing are enabled, and we don't need to push all of this complexity into each selection.

I admit allowing it to still be unchecked is confusing, and that greying it out but checked would be better.

Comment 5

[bugdiscovery]

Thanks for the feedback everyone.

I think it's good to reduce complexity, but it's not good when behaviour become unpredictable as in this case. I don't have any reasonable solution with the current design. If the idea is to gray out and tick the option, I think a notice explaining it's forced by ETP should be added as well.

In the current situation I'd consider to just remove DNT from ETP. Since the choice is there for the user and should be respected.

Comment 6

[Ciprian Georgiu, Desktop QA]

I'm confirming the bug status to NEW, and I think the enhancement label is more suitable since the current behaviour is intended per comment 4. Maybe the suggestions in this bug are going to be considered in a future UI change.

Comment 7

[Ciprian Georgiu, Desktop QA]

I'm not sure what's happening, it seems that it cannot be changed to enhancement.

Comment 8

[Donal Meehan [:dmeehan]]

(In reply to Ciprian Georgiu, Desktop QA from comment #7)

Not sure what happened with the enhancement label. Changing it back.

Since it has a regression keyword and a regressed by bug, bugzilla will automatically set it as a defect.
If it is required for this to be an enhancement, then you need to clear those. You could set the regressor as a see also. Otherwise, it will keep being set as a defect.

Comment 9

[Ciprian Georgiu, Desktop QA]

(In reply to Donal Meehan [:dmeehan] from comment #8)

Since it has a regression keyword and a regressed by bug, bugzilla will automatically set it as a defect.
If it is required for this to be an enhancement, then you need to clear those. You could set the regressor as a see also. Otherwise, it will keep being set as a defect.

Thank you for the explanation. In this case I think we can leave as it is for now.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1830623

Comment 11

[:Gijs (he/him)]

I think any decision here needs to come from the anti-tracking team, even if UI implementation would happen in settings, so moving over there for further triage.