status.wikimedia.org should have an alternative privacy policy
Closed, InvalidPublic

Description

[This bug post is partially inspired by MZMcbride's post to wikitech-l - https://lists.wikimedia.org/pipermail/wikitech-l/2018-March/089640.html ]

https://status.wikimedia.org is a status monitor site hosted by CA App Synthetic Monitor (I think prviously they were called watchmouse).

The page does include things such as google analytics (See T115945). This is deemed ok because it is an "external" site.

However, since the site is under .wikimedia.org domain, I believe it should clearly state that it is not subject to our normal privacy policy. Our normal privacy policy has this to say:

Wikimedia Sites with alternative policies

Some Wikimedia Foundation websites have alternative privacy policies or provisions that differ from this Privacy Policy. These websites include:

   Wikimedia Shop (covered by the shop's policy); and
    donate.wikimedia.org, including the donation process, such as clicking on a donation banner (covered by the Donor Privacy Policy).

These websites, and others like them, will provide a link to their privacy policy (if it stands alone) or to an explanation of any differing provisions (if the site's policy is based on this Privacy Policy).

And also of interest

Third parties

This Privacy Policy only covers the way the WMF collects and handles information. Third parties who might receive information when you use the Wikimedia Sites may include:

    Service providers whom we may use to help provide our services to you. For example, our actions regarding your information on our blog are covered by this Privacy Policy, but if our blog were hosted by WordPress, WordPress may also collect information sent automatically by your browser or through cookies that they set. If you are curious about any third-party provider's privacy practices, you should refer directly to their privacy policy.

My reading of all this [IANAL], is a site like status.wikimedia.org, which at first glance (due to domain) appears to be run by us, but isn't, and does things that would be unacceptable under normal privacy policy, should have an alternative privacy policy. Or at least clearly state its an external site.

I also have no idea what our relationship is with CA App Synthetic Monitor, but if we could convince them not to have google analytics on that page, that would be cool :)

Related: T199816: Sunset Watchmouse's status.wikimedia.org

Bawolff created this task.Mar 15 2018, 6:21 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 15 2018, 6:21 AM
Bawolff updated the task description. (Show Details)
Bawolff added subscribers: MZMcBride, APalmer_WMF.
Reedy updated the task description. (Show Details)Mar 15 2018, 1:56 PM
Reedy added a project: Operations.
Krinkle added a subscriber: Krinkle.EditedMar 15 2018, 11:34 PM

Quick brain dump:

In 2015 (per T115945), status.wikimedia.org was a direct alias to status.watchmouse.com. From their side, the page is dynamically varied (virtual host) for specific customers based on the incoming domain name. This is similar to how blog.wikimedia.org is hosted at WordPress VIP.

Nowadays, this is no longer the case for status.wikimedia.org. Instead, status.wikimedia.org (per Wikitech docs) is hosted in our off-site hosting at Rackspace which we do control. Its current implementation is an HTTPS-based proxy to CA-APM (previously: Watchmouse). As before, the third party remains in control of the page content (incl. use of Google Analytics). However, they are no longer in control of the HTTP-stack for the page itself.

Which means we can at least normalise incoming HTTP headers for things like User-Agent and Cookies. They'll still be able to read some of this (in theory) from the client-side JavaScript, but it's a good first step.

We should also consider reaching out to CA-APM and see if they're willing to disable Google Analytics for our pages.

Alternatively, we could see if they have a machine-readable API that we could use and display the data based on that in a page built directly by our proxy.

Alternatively (2), we could move it to a domain separate from our primary content wildcards. For example, wikimediastatus.net or status.wmfusercontent.org (similar to what Travis CI did with https://www.traviscistatus.com). That would mitigate security and privacy concerns related to our primary sites. We could keep the current sub-domain as a redirect.

faidon added a subscriber: faidon.Mar 19 2018, 12:19 PM

I don't disagree with any of that (if anything, they're all great ideas), but I'm not sure if we should be spending time on it right now. Revamping our status page and providing a proper status page that reflects our true status, and is also used for short text announcements by humans is definitely in my radar, and depending on how hiring and onboarding goes, might even happen in the next 18 months or so. Thoughts?

Dzahn triaged this task as Low priority.Apr 17 2018, 11:21 PM

I agree with what Timo wrote in T189763#4055149.

I remain puzzled that it's seemingly so difficult to remove some JavaScript from an HTML page.

I don't think creating yet another privacy policy is a reasonable solution here.

Revamping our status page and providing a proper status page that reflects our true status, and is also used for short text announcements by humans is definitely in my radar, and depending on how hiring and onboarding goes, might even happen in the next 18 months or so. Thoughts?

It'll take you all 18 months to figure out how to use Twitter? ;-)

Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)".Jun 19 2018, 3:22 AM
Framawiki updated the task description. (Show Details)Jul 19 2018, 10:46 PM
Framawiki added a subscriber: Framawiki.
fgiunchedi closed this task as Invalid.Jul 26 2018, 10:43 AM
fgiunchedi added a subscriber: fgiunchedi.

Parent task resolved!