Bug 376291 - New kde.org adds tracking by 3rd-party, googleapis.com
Summary: New kde.org adds tracking by 3rd-party, googleapis.com
Status: RESOLVED FIXED
Alias: None
Product: www.kde.org
Classification: Websites
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kde-www mailing-list
URL: https://kde.org
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-10 14:48 UTC by Friedrich W. H. Kossebau
Modified: 2017-02-21 20:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Friedrich W. H. Kossebau 2017-02-10 14:48:54 UTC
The new design introduces tracking by google, due to ttps://fonts.googleapis.com/, not so wanted.

The old site was fine there, please investigate to fix this :)
Comment 1 Ken Vermette 2017-02-12 10:58:52 UTC
Google doesn't use Google fonts as a tracking mechanism, at least, not in the way that any website doesn't do by nature with basic traffic logging.

See: https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users

Google doesn't have cookies for web fonts, uses heavy caching (meaning only the first hit a day for a font - from anywhere - may be logged), and other things. The only metrics Google states they collect from web fonts is "which fonts are popular", and "which websites use fonts", but neither of them are user-specific. Additionally, browsers properly implementing https should not provide referral information *at all* to included resources - not even the domain referring.

Noto is made by Google, and Google updates the web fonts regularly. I don't know how often the font is adjusted or added to, but it was a consideration. Serving the font ourselves will cost us a little extra load without the caching (nothing anyone will ever notice, but still - it can add up if we aren't careful), and the font may periodically fall out-of-date.

All that being said, while I personally don't consider the use of Google Fonts as a breach of privacy or introduction of tracking, I understand the concern. KDE also prides itself on privacy, and even the *opportunity* to gleam some small amount of information from our service could be considered an issue. Even the perception of tracking may be enough in some cases.

If someone really paranoid disables third-party resources to ensure no tracking can happen, the downsides will be marginal; either an existing noto on their machine will be used, or it will fall back to a similar looking sans font.

I'm neutral on moving the font resources to our server, but knowing that fonts are not a viable form of tracking to Google nor one that they claim to try using, I'd like to ask if this is still considered an issue; if it is, I'll go ahead and do the switch.
Comment 2 Albert Astals Cid 2017-02-12 22:58:37 UTC
"knowing that fonts are not a viable form of tracking to Google"
i disagree it's not a viable form of tracking, anything that is logged is a viable form of tracking.
Comment 3 Friedrich W. H. Kossebau 2017-02-13 16:37:46 UTC
Thanks for the detailed reasoning, Ken. While I see the advantages there are with using Google as central font delivery network, and I also acknowledge Google's official efforts to try to minimize data accumulation around font usage from their free service, in the end it still means that they as 3rd-party do accumulate data about people visiting KDE.org pages, like Ip address, time and then all the header stuff like user agent, which is often good enough to roughly identify people and thus do more statistics over them, if interested. They do not promise to not do it (and he, with evil forces on them they might even have to do it). Only one request per day (as currently, they could change that without anyone instantly noticing) still makes up to 365 samples per year with today's digital citizens, and then Google knows already more about my surfing than most of my relatives ;)

No need to create data that can be abused, unless unavoidable. That would be the rule I ask to follow here.

And I think we can avoid it, without paying too much for it. I assume that the updates Google does to the noto font are not that important to have them instantly available to KDE.org visitors, right? So hosting a copy on KDE servers and serving that instead should not be a risk, and we can still update it once in a while.

Using https also comes with a cost, but privacy sadly is not for free here.
Comment 4 Ken Vermette 2017-02-13 21:31:37 UTC
Alrighty, all that sounds reasonable. I'll put this on my Tuesday to-dos after I sleep off the jet-lag. ;)
Comment 5 Ken Vermette 2017-02-20 15:15:29 UTC
SVN commit 1483072 by kvermette:


Added Noto and Noto Bold to be hosted on-site. 

Modified header code to check if Capacity functions are being included, if they cannot, it will not break the system. This should make testing easier.



 M  +2 -1      aether/header.php  
 A             css/Noto-Sans-700 (directory)  
 A             css/Noto-Sans-700/LICENSE.txt  
 AM            css/Noto-Sans-700/Noto-Sans-700.eot  
 A             css/Noto-Sans-700/Noto-Sans-700.svg  
 AM            css/Noto-Sans-700/Noto-Sans-700.ttf  
 AM            css/Noto-Sans-700/Noto-Sans-700.woff  
 AM            css/Noto-Sans-700/Noto-Sans-700.woff2  
 A             css/Noto-Sans-regular (directory)  
 A             css/Noto-Sans-regular/LICENSE.txt  
 AM            css/Noto-Sans-regular/Noto-Sans-regular.eot  
 A             css/Noto-Sans-regular/Noto-Sans-regular.svg  
 AM            css/Noto-Sans-regular/Noto-Sans-regular.ttf  
 AM            css/Noto-Sans-regular/Noto-Sans-regular.woff  
 AM            css/Noto-Sans-regular/Noto-Sans-regular.woff2  
 M  +27 -1     css/aetherCore.css  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1483072
Comment 6 Friedrich W. H. Kossebau 2017-02-20 15:25:47 UTC
Thanks, Ken :)