Change 601663 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/QuickSurveys@master] [DNM] Remove Do Not Track support

https://gerrit.wikimedia.org/r/601663

I might miss something, but as argued in T253112#6176031 I don't understand why "do not track" even shows up in the QuickSurveys code. Giving the user the choice if they want to participate in a survey or not is not "tracking". That's not how the HTTP header is meant to be used.

The only thing "do not track" should stop from happening is any kind of initial tracking that is done before the user interacts with the survey. Does the extension do something like this?

The code was introduced in 2016 via https://gerrit.wikimedia.org/r/273036 by @bmansurov. Unfortunately the ticket T127980 doesn't explain the reasoning. It just states an "I do not want" in a user story. Was it an actual user requesting this? If not, who came up with this requirement? Was it advised by the legal team?

@Volker_E wrote,

@awight Waiting for you to remove [DNM] tag from commit title…

:-) Thank you for the +1's in the codebase! I was thinking of waiting a week or two before merging, since it'll have some impact on the product owners. For example, assuming that 1/3 of our traffic has DNT enabled, making this change will cause a 50% increase in survey responses and I want everyone to be prepared for that discontinuity.

And of course, I'm still interested in hearing any reason that we should continue to honor Do Not Track. It's the Internet that could have been...

In T254224#6190402, @thiemowmde wrote:

The only thing "do not track" should stop from happening is any kind of initial tracking that is done before the user interacts with the survey. Does the extension do something like this?

Yes, I believe that's exactly why the Do Not Track logic was introduced. It uses a refreshingly noninvasive event schema, but in 2016 at least, the theory was that DNT users would be disappointed to see Wikimedia Foundation sending itself impression events.

Was it advised by the legal team?

Just to respond to this, I very much doubt it. Do Not Track has only ever been a voluntary constraint on the behavior of website owners. The EventLogging capsule itself includes much more identifiable data (which I'm not thrilled about), so I assume this schema is as acceptable as any other event topic from the GDPR perspective.

Looks like this was originally proposed by @dr0ptp4kt in T127980 so I wonder if he can remember the background here?
I agree with @kaldari's assessment in T252438#6126402 FWIW

As I recall (@leila please chime in if you have contrary info), in order to to correlate a Google Form survey response with the reading and survey CTA impression funnel, it was necessary to have a token in the event logging table and in the Google Form. Showing a form and having a user fill out the form but having no tie back to the reading funnel would chop off one half of the funnel, so such responses would need to be disincluded from the result set. The point here was not to bother such a user with filling out a form if the data wouldn't be used for research purposes because of a severed funnel (stated differently, we also didn't want polluted data sets inasmuch as that's to be avoided). Does that help?

That's independent of the matter of whether to honor or not honor DNT, of course, just wanted to share the history as best as I can remember. Thanks @Jdlrobson for finding that task!

Not as a blocker but I just wanted to mention that we currently "use" DNT to avoid that QuickSurveys "mess" with the expected results in our Two-Column-Edit-Conflict-Merge selenium daily browser tests on the beta cluster. I would appreciate e.g a cookie setting to disable QuickSurveys but all that could be discussed in the ticket linked above.

@Lena_WMDE - looks like this is all done. Feel free to sign this off, or let us know if you would like us to - either way works.

In T254224#6209918, @WMDE-Fisch wrote:

Not as a blocker but I just wanted to mention that we currently "use" DNT to avoid that QuickSurveys "mess" with the expected results in our Two-Column-Edit-Conflict-Merge selenium daily browser tests on the beta cluster. I would appreciate e.g a cookie setting to disable QuickSurveys but all that could be discussed in the ticket linked above.

Thanks for pointing this out! We should track that on the other ticket or a new one, and IMO if necessary skip our sensitive tests until fixed. Ideally, our tests would be compatible even with a rendered QuickSurvey.

In T254224#6210369, @awight wrote:

Thanks for pointing this out!

I get it now--you already created the ticket. Thank you again :-)

Change 601663 merged by jenkins-bot:
[mediawiki/extensions/QuickSurveys@master] Remove Do Not Track support

https://gerrit.wikimedia.org/r/601663

In T254224#6194100, @dr0ptp4kt wrote:

As I recall (@leila please chime in if you have contrary info), in order to to correlate a Google Form survey response with the reading and survey CTA impression funnel, it was necessary to have a token in the event logging table and in the Google Form.

confirmed.