Page MenuHomePhabricator

Possible privacy break when loading font from toolserver
Open, Needs TriagePublic

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 the toolserver, 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);

Some weeks ago, without further notice, @Ajraddatz made a change per m:SRM asked by @Legoktm.

Currently the only way we have to put this font (that has been decided to use in Txikipedia) is using the toolserver 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 toolserver, 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

Theklan created this task.Nov 20 2018, 6:46 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 20 2018, 6:46 PM
MarcoAurelio added a comment.EditedNov 20 2018, 6:52 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"?

Aklapper closed this task as Invalid.Dec 2 2018, 12:11 PM

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 reopened this task as Open.Dec 2 2018, 3:08 PM
Krenair assigned this task to Legoktm.
Krenair added subscribers: zhuyifei1999, Krenair.

Original request: https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous/2018-10#Please_remove_privacy_violating_site_CSS
@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://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.

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 added a comment.EditedDec 2 2018, 7:09 PM

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

Krenair removed Legoktm as the assignee of this task.Dec 2 2018, 7:32 PM

thanks @Legoktm, putting the assignee back