Change 969341 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Enable the TagManager plugin functionality on Matomo

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

The patch is ready to go. I'm just going to try to ascertain if there are any concerns about enabling the plugin by asking.

Adding Security-Team to request their review.
Has your team any concerns about our enabling the TagManager plugin for Matomo?
Thanks.

In T349910#9288036, @BTullis wrote:

Adding Security-Team to request their review.
Has your team any concerns about our enabling the TagManager plugin for Matomo?
Thanks.

Has the code changed significantly in the last 6 months or so? If not, this would likely only warrant a privacy review - I'll tag Privacy Engineering so it gets in their queue.

In T349910#9291873, @sbassett wrote:

In T349910#9288036, @BTullis wrote:

Adding Security-Team to request their review.
Has your team any concerns about our enabling the TagManager plugin for Matomo?
Thanks.

Has the code changed significantly in the last 6 months or so? If not, this would likely only warrant a privacy review - I'll tag Privacy Engineering so it gets in their queue.

No, the TagManager plugin was already a part of the Matomo codebase when it was originally installed. Thanks, we will wait on the privacy review.

Hi, all — I’ll share here a joint privacy review of the two proposed changes: enabling the TagManager and the Marketing Campaign Reporting plugins, as well as a succinct privacy risk assessment of the self-hosted Matomo instance, although it wasn’t specifically requested.

• T349910 aims at enabling the TagManager plugin for the Foundation’s Matomo instance. Enabling the Tag Manager plugin is not introducing any new privacy risk per se. Once enabled, the plugin will function as a "black box" allowing and containing all the analytics tags that will be created by additional plugins such as Marketing Campaigns Reporting.

• T319013 would enable the Marketing Campaigns plugin on that self-hosted Matomo instance, with the direct aim of tracking analytics information for the SoundLogo website using UTM parameters. The parameters proposed (utm_campaign, utm_source, and utm_medium) are not expected to store any identifying information. The only concerning data would be the utm_source parameter as it relates to the URL from which visitors came from. However, the plugin’s documentation suggests that full URLs will not be processed. Instead, only the refer’s domain will be captured. Furthermore, an initial inspection of the plugin’s codebase points that the information collected as tags (or UTM parameters) will not be shared with any external parties; data will remain within the Foundation’s premises.

• The privacy risk assessment of the self-hosted Matomo instance helped surface some good signals. The Foundation uses a self-hosted instance to gather statistics on a small number of its non-Mediawiki websites, including Wikipedia15, Wikimedia Foundation, Techblog, and the Developer Portal. The instance is restricted to staff and NDA’ed users, and sheltered by two authentication layers — LDAP credentials and Matomo specific user+password combination. By default, analytics data is only stored within the Foundation infrastructure. Additionally, the instance implements IP address anonymization with a 16-bit mask, making it difficult to infer even city-level information, though it’s still possible to determine the visitor’s country. While the Matomo instance collects some identifying information — ID, country details inferred from the masked IPs, User Agent, full referrer URL, the independence from third-parties, access control, and IP-masking help reduce the overall risk to a LOW level.

In light of the above, the privacy risk associated with the two proposed changes was categorized as LOW[1]. That being said, it is recommended that the AppSec team double check the codebase of the MarketingCampaignReporting plugin, if capacity allows it.

[1] Internal threat modeling documentation : https://docs.google.com/spreadsheets/d/1p1KxIHLBdbJzrEBNqPAK-UwqJgeQI6XPX2i8giX2ywQ/edit#gid=32059142

Change 969341 merged by Btullis:

[operations/puppet@production] Enable the TagManager plugin functionality on Matomo

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

In T349910#9325309, @sguebo_WMF wrote:

In light of the above, the privacy risk associated with the two proposed changes was categorized as LOW[1]. That being said, it is recommended that the AppSec team double check the codebase of the MarketingCampaignReporting plugin, if capacity allows it.

Looking at the TagManager and MarketingCampaignsReporting plugins for Matomo, the AppSec team could likely perform some basic third-party / vendor reviews of the code, but that's about the most we are able to do for massive vendor codebases. Those requests would need to be filed separately via our Application Security Reviews process.

Change 975058 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Configure Matomo's TagManager to write to existing tmpdir

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

Change 975058 merged by Btullis:

[operations/puppet@production] Configure Matomo's TagManager to write to existing tmpdir

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

Change 975311 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Fix an issue with the matomo TagManager configuration

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

Change 975311 merged by Btullis:

[operations/puppet@production] Fix an issue with the matomo TagManager configuration

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

Change 976686 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Add another public endpoint to our matomo installation

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

I have added the required configuration to our apache2 site template for matomo in
976686: Add another public endpoint to our matomo installation | https://gerrit.wikimedia.org/r/c/operations/puppet/+/976686

https://matomo.org/faq/on-premise/how-to-configure-matomo-for-security/#other-tips

The requirement is listed here: https://matomo.org/faq/on-premise/how-to-configure-matomo-for-security/#other-tips

Change 976686 merged by Btullis:

[operations/puppet@production] Add another public endpoint to our matomo installation

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

Oh, it looks like that's not working. I deployed that change, but it seems that I am still receiving 302 redirects for that URL.

btullis@marlin:~$ curl https://piwik.wikimedia.org/js/container_HBF2fCC3.js
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://idp.wikimedia.org/login?service=https%3a%2f%2fpiwik.wikimedia.org%2fjs%2fcontainer_HBF2fCC3.js">here</a>.</p>
</body></html>

This is the log entry.

2023-11-22T13:52:11	616	2620:0:861:103:10:64:32:137	-/302	286	GET	http://piwik.wikimedia.org/js/container_HBF2fCC3.js	-	text/html	-	<my IP address>, 10.80.0.14	curl/8.2.1--	-	-	2620:0:861:103:10:64:32:137	ce3cda02-1b91-4e48-9e7e-0ac74635460f	91.135.7.94

I'll continue to investigate.

Change 976750 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Fix Matomo TagManager functionality

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

Change 976750 merged by Btullis:

[operations/puppet@production] Fix Matomo TagManager functionality

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

There has been an improvement, but it's still not working correctly.
Here's a screenshot from the page with the preview container embedded.

The second is that the plugin attempts to retrieve some specific URLs from Matomo and is redirected to the single-sign-on mechanism.
I can update the Apache configuration to allow those, but the CSP is outside of our control, I believe.

Change 977057 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Matomo: permit public retrieval of specific CSS and JS files

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

Hi @SCampos-WMF

I've tested the settings in https://gerrit.wikimedia.org/r/977057 manually, and they seem to be working, but the stylesheet is still blocked on the site's CSP.

The current security policy seems to be:

default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://piwik.wikimedia.org https://stats.wp.com https://pixel.wp.com https://www.youtube.com https://player.vimeo.com http://localhost https://localhost http://localhost:8080; frame-src 'self' https://www.youtube.com https://player.vimeo.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://piwik.wikimedia.org https://wikipedia.org https://upload.wikimedia.org; font-src 'self' data:; connect-src 'self' wss://public-api.wordpress.com https://*.wikipedia.org

I think that you would need to add https://piwik.wikimedia.org to the style-src section in order to have this work, but I believe that it outside of our control.

It's notable that the https://pixel.wp.com request is also refusing to load because it's not permitted by the img-src policy, but I don't believe that's relevant to this particular ticket. That's a different mechanism from a third-party.

Apart from the style sheet in preview mode though, I think that the TagManager functionality should now be working. Please feel free to let me know how you get on with testing it and updating the CSP of the site(s).

Hey @BTullis, thanks for addressing this issue! I'll generate a ticket and share it with our technical partners to address it in our current Sprint. I'll keep you updated on the progress.

Change 977057 merged by Btullis:

[operations/puppet@production] Matomo: permit public retrieval of specific CSS and JS files

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