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"?

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://ar.wikiquote.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' );

Those look problematic, please open a task for that.

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.

In T209998#4792314, @zhuyifei1999 wrote:

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.

In T209998#4792387, @Legoktm wrote:

@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.

This happened again, but it doesn't seem to be any problem: https://eu.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-TxikipediaTab.css&type=revision&diff=7995779&oldid=6486369

In T209998#6334213, @Theklan wrote:

This happened again, but it doesn't seem to be any problem: https://eu.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-TxikipediaTab.css&type=revision&diff=7995779&oldid=6486369

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).

I understand the font is part of your visual identity, however, that cannot mean anything when we talk about privacy policy violations.

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