Assigned To
None
Authored By
 Theklan Nov 20 2018, 6:46 PM2018-11-20 18:46:49 (UTC+0)
Referenced Files
 F31320183: Screen Shot 2019-11-27 at 3.55.25 PM.png Nov 27 2019, 9:57 PM2019-11-27 21:57:24 (UTC+0)

# Description

Hello!
In the Basque project Txikipedia we use the font-face "Gochi Hand" for making things more interesting to kids. This font is loaded in MediaWiki:Gadget-TxikipediaTab.css to import it from toolforge, instead of from Google Fonts:
Previous code

@import url('https://fonts.googleapis.com/css?family=Gochi+Hand');

Current code

@import url(https://tools-static.wmflabs.org/fontcdn/css?family=Gochi+Hand);

Currently the only way we have to put this font (that has been decided to use in Txikipedia) is using the toolforge fontcdn tool, because is the only way to have fonts without information being tracked.

If we can't have this call to a font in toolforge, we would need another way to have this typography deployed in our wiki, but I want to be sure that this is really a security breach before proceeding.

### Event Timeline

Restricted Application added a subscriber: Aklapper. Nov 20 2018, 6:46 PM

Hi @Theklan - I am not a Security member so you can disregard my opinion outright should you wish. However, as far as I know, importing external resources from domains we do not control is highly discouraged because it can result on outages or more serious things like privacy or security violations. If the font does exist within Wikimedia repositories, I'd say you should consider using those. If the font does not exist, maybe we could ask to bring it to our repos so it can be used withing the projects if there are no licensing concerns. But like I said, this is just my personal opinion. Best regards.

I think to deploy we'd need a Debian package which offers this font. (If I understand correctly.)

Thanks @MarcoAurelio! AFAIK using fontcdn is recommended exactly for this issue. And that's why we were advised to use it. I don't know if there are further problems with using the fonts there, but the project should specify that it can't be used inside Wikimedia if this is a real problem.

the project should specify that it can't be used inside Wikimedia if this is a real problem.

What is "the project" and what is "it"?

wmflabs.org and eu.wikipedia.org are both Wikimedia controlled. I don't see a "privacy break" here because no third party is involved.
If I misunderstand what this task is about, please elaborate and explain more what the potential problem is. Thanks!

Krenair assigned this task to Legoktm.

@Aklapper: wmflabs.org may be Wikimedia-owned but that's not enough to enable inclusion in wikimedia production JS. Indeed most wmflabs.org stuff would be unacceptable, though tools-static.wmflabs.org/fontcdn appears to be controlled by @zhuyifei1999 who is also in the admin tool, so I think they have an NDA. @Legoktm is there anything I'm missing here since you asserted non-NDA users have access?

Ah, thanks for clarifying! In that case these might also be checked?:

https://ar.wikipedia.org/wiki/MediaWiki:Common.js:	mw.loader.load( '//tools.wmflabs.org/imagemapedit/ime.js' );
https://he.wikipedia.org/wiki/MediaWiki:Common.js:	mw.loader.load( '//tools.wmflabs.org/imagemapedit/ime.js' );

Honestly, since when UA by itself is private information? If that were the case, the vast majority of toolforge tools would violate cloud ToU in this clause:

You should not collect or store private data or personally identifiable information [...] (“Private Information”) from the individuals using your Cloud Services Project (“End Users”), except when complying with the conditions listed below.

1. Clearly communicate to End Users a) that Private Information is being collected, b) how you will use it, and c) when you will delete it;
2. Inform the End Users that their information may be available to the Wikimedia Foundation, its volunteers, other Wikimedia Cloud Services users, or to the public;
3. Get express authorization from the End Users for the collection;
4. Hash, encrypt, or otherwise properly secure any Private Information you store;
5. Purge, anonymize, or aggregate any Private Information you store no more than 30 days after storing it;

(The sad thing is, the policy was never clarified T140486)

Regarding the technical side, tools-static.wmflabs.org/fontcdn routes directly to the static proxy (config added in T110027), with current config acting as a reverse proxy to google. UA is not removed in the process since we did not see it as a concern of privacy, and it is used by google to dynamically determine what font types a browser supports.

Honestly, since when UA by itself is private information?

To clarify this, my understanding is that the association of UA and other information, such as referrer, usernames, IPs, should be private. Without that, UA is essentially anonymous statistics.

The Wikimedia Privacy Policy explicitly says that user-agents are "personal information" (see https://meta.wikimedia.org/wiki/Privacy_policy#Definitions). Whether it truly is private information is out of scope - we have to follow the privacy policy here.

Toolforge maintainers have access to the UA, so while for now if @zhuyifei1999 remains the sole maintainer (or only NDA maintainers are added) it might be permissible, but sending it onto Google would make it definitely not. I would expect that Toolforge will be blocked using CSP in the future, so this isn't a sustainable solution in any case.

So, to respond to the original question on how to resolve the issue of needing a web font - first, we should see if the font is suitable for inclusion in UniversalLanguageSelector. If not, we can figure out an alternative way to deploy it, maybe something like the MontserratFont extension.

@zhuyifei1999 remains the sole maintainer (or only NDA maintainers are added) it might be permissible

The reverse proxy (tools-static) is only accessible to toolforge maintainers.

thanks @Legoktm, putting the assignee back

This comment was removed by sbassett.
JFishback_WMF moved this task from Intake to Backlog on the Privacy board.

Loading fonts from the Toolforge Font CDN is a violation of the Wikimedia privacy policy as it exposes users' User-Agent to Google. If a steward explicitly removed the font, you should not be reinstating it without discussing it with them.

That's why I'm not reinstating it, I'm trying to discuss it and find a solution, because that typeface is part of the project's visual identity.

Hello, removing steward speaking. I have removed the import statement, because it causes users to download the font from Toolforge, a place which is not covered by Wikimedia Privacy. As such, users have to be informed that if they do load this file, their PII may be forwarded to third parties (in this case, Toolforge, which forwards user agent, which is considered PII by Wikimedia Privacy policy, to Google).

If the font is freely licensed, it might get approved and installed at Wikimedia sites, at which point you would be able to use with no further issues. If it is not freely licensed, I'm afraid you would need to change your identity.

I believe this makes sense. Feel free to ask any questions here.

Best,
Martin Urbanec

Nintendofan885 renamed this task from Possible privacy break when loading font from toolserver (https://tools-static.wmflabs.org/fontcdn/) to Possible privacy break when loading font from toolforge (https://tools-static.wmflabs.org/fontcdn/).Oct 30 2020, 11:02 PM
Nintendofan885 updated the task description. (Show Details)

Assuming this can be closed nowadays

Aklapper renamed this task from Possible privacy break when loading font from toolforge (https://tools-static.wmflabs.org/fontcdn/) to Privacy break on eu.wikipedia.org loading font from toolforge (https://tools-static.wmflabs.org/fontcdn/).Jul 23 2022, 9:01 AM