If I wanted to get a javascript library published to the ajax CDNs hosted by Google or Microsoft, what would I have to do?
Are there any formal requirements for this, like number of users etc?
I doubt there are any formal requirements except that the lib has to be wildly popular, and probably will have to be regarded to be of high quality by the companies running the CDNs.
Google's Ajax libraries main page has this to say:
Google works directly with the key stake holders for each library effort and accepts the latest stable versions as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.
I'd say if you feel your library is popular and good enough - seeing as Google for example are hosting 12 projects at the moment, yours would have to be in the world wide top twenty by some measure though! - simply talk to Google and Microsoft and see what they say.
Here is a blog post that could provide you with some contacts to approach. Also, the author seems to be somehow affiliated with Google (he's talking about "we").
The Google Ajax Library Blog may also be a good resource.
Related
I (or a lot of German people) need your help.
In Germany, more and more website operators are receiving a legal letter with a warning and are supposed to pay around €170. The problem is that it doesn't stop there, which means that if you pay the €170, someone else can come right away and warn you again.
It's about Google Fonts. Many Wordpress websites use themes that load Google Fonts. The German court has decided that it is not allowed to send the IP address to the Google because of Google Fonts and this is a violation of the rights of the customers.
Since I run a few websites, I'm now looking for a solution, but to be honest I'm coming up against technical limits. So I want to open this thread to discuss possibilities.
I have listed issues below, I will add them to my solutions.
I can think of the following options:
Create a child theme and then load the Google fonts locally. (Issue: 1st 2nd 3rd 4th)
Service worker that rewrites the URLs
(Issue: 5.)
Nginx rewrite, rewrite the php output and replace google fonts url
(Issuing: 1. 4.)
More?
Issues:
If you have e.g. integrated a script (Google Maps, Recaptcha, Intercom, ...) it can happen that Google Fonts are reloaded by Javascript.
Theme updates.
A lot of work when multiple customers.
Plugins load elements on certain pages or only later after it can happen that google fonts are loaded again.
Only works if the service worker is installed
I am open for any idea. It looks like Google will not fix this.
There is no easy technical fix. The only long-term fix is to review how you include any third-party content on your websites, in case this embedding causes any visitor personal data to flow to such third parties.
This is not a new development. A lot of the relevant compliance steps already entered the (German) mainstream in the early 2010s when the problem was Facebook's “Like button”. The generally accepted solution for that is that the third party content is not loaded directly. Instead, a placeholder widget is rendered that indicates which content would be available there. Then, the user can give consent with one click and the actual embedded content is loaded.
With Google Fonts, no such consent flow is needed or appropriate. All of the fonts on Google Fonts are Open Source licensed – you are allowed to use and distribute them for free, but subject to the license conditions (like making the license notice available to users). So on a technical level, it is easy to self-host the fonts in question.
What is tricky is efficiently rewriting the requests caused by your websites to point to your own servers instead of to the Google servers. You have identified a couple of approaches and have identified their pros and cons. Some comments:
Client-side rewriting sounds very fragile, I'd avoid it.
Server-side rewriting can be very powerful, but would also be somewhat fragile. The main advantage of such rewrites would be that it doesn't just handle Google Fonts embeds from your themes, but also requests inserted by server-side plugins.
Updating the theme is the only reliable long-term solution. Creating a child theme might be a suitable stop-gap measure until the theme developer fixes the problem. Similarly, it may be necessary to temporarily modify WordPress plugins.
I think that as a band-aid, server-side rewrites will be good enough to prevent many automated scanning tools used by these cease-and-desist lawyers from sounding the alarm on your sites.
However, you have correctly identified that especially JavaScript could cause problems for achieving actual compliance. This is why you should revisit your decisions about what plugins and scripts you have integrated. Loading third party JavaScript has pretty much the same legal consequences as loading fonts from Google, so you should only do it if it's actually necessary for your site (where necessity depends on the user's perspective), or if the user has given valid consent. For example, you can use the placeholder widget technique mentioned above for embedded content like Google Maps or Intercom, whereas loading a Captcha may indeed be strictly necessary on some pages.
For testing these issues, I'd recommend installing Firefox with the uBlock Origin addon, and setting the addon to hard mode. This will block all third-party/cross-origin requests. You can then allowlist those domains that are under your direct control, or are provided by your data processors (who are contractually bound to only use the personal data as instructed by you, and are considered first-party for GDPR purposes), or domains for which you have a legal basis to share the data (e.g. a “legitimate interest” to load stuff that is strictly necessary for your site to work, or to investigate what requests are made when the user gives consent).
IANAL but the two sections may be relevant.
Using their APIs. From what I can tell nothing here explicitly forbids proxying.
API Prohibitions on sublicensing. The last part of the statement and offer it for use by third parties means you're okay as long as you're not offering it for other people to use.
I do have Google Fonts Proxy Docker Image which I use for my own stacks, I don't offer the use of my running proxy for use with other services. It does not mean you can't simply deploy my image on your own servers.
This won't resolve your 3rd party Google services such as Maps though.
The Problem
We want to be able to securely add third party javascripts into our site to enable functionality. This could be Google Tag Manager, AppCues, MixPanel, etc. Third party javascript may be hosted on a third party site or CDN. These domains are not owned by us and should not be inherently trusted - because as we know, if they are hacked, that means when we include this code, our site is now owned.
SubResource Integrity
The W3C (and browsers) have attempted to address this issue with SubResource Integrity. This works well for libraries that are well versioned. When you update the version, you update the integrity hash. However, this works terribly for javascripts like GTM, or Mixpanel that want to provide seamless updates and have constantly changing integrity hashes.
Proposals
Its very surprising this issue is not well solved in 2021. There are some academic approaches to this here and here that discuss using signatures to solve this issue. There is even an approach to solving this using blockchain here!
The question
So, am I missing something? Is there a more recognized way to solve the security of including third party javascripts? We solved signing files, and software libraries, why can't we digitally sign javascripts? Could JWT or PGP/GPG be used?
In particular, I am wondering if there is a strategy that could leverage some basic coordination between the 3rd party javascript author and the including code. For instance, could the 3rd party author publish integrity hashes that were signed, so we as the including application could pull signed hashes and validate them?
UPDATE
This is related to this SO back in 2016 before SRI was fully adopted. This question is the 2021 version. I believe this to be a relevant question in 2021 because of the advent of SaaS services which were not as prevalent in 2016. Many of these services provide hosted javascript files and specifically do not version them because they want to provide constant updates.
For a project we're looking at a mechanism to import gadgets (friends lists, todo lists, etc) from other sites, something that OpenSocial is supposed to be great at. However, I'm concerned about whether or not OpenSocial is dead. Many of the API pages for OpenSocial 0.9 haven't been updated since April 2009. The few recent updates I have seen are just spambots posting links to cheap german pharmaceuticals (for example, see this history page).
Is OpenSocial alive? Or has it, like so many other grandiose ideas, been abandoned to the wastes of the Internet?
Indeed OpenSocial is definetely not dead. Although the OpenSocial spec has started as an alternative or competitor to Facebook platform to be used in consumer oriented social networks, the spec and accompanying open source implementation Shindig evolved into a more general API framework and a common data model which adresses use cases from consumer to enterprise portals and groupware solutions. While Facebook platform dominates consumer web and may be a natural choice for external identity support or content distribution, OpenSocial is being used inside ever increasing products and integrated to various cloud applications.
Current work in progress spec version is 2.0 and an active community discusses several new features that contribute to building a more open social web. You may see what is being developed here (http://wiki.opensocial.org/index.php?title=Spec_Changes) or join the community to monitor progres or contribute to the spec here (http://groups.google.com/group/opensocial-and-gadgets-spec).
Regarding your use case, OpenSocial may help you by supplying a client side JS based mash up container. With recent Open Ajax support and a JS container, OpenSocial (and Shindig) may easily serve as a dashboard or client side portal. We could sucessfully developed on top of Shindig a self service portal that can integrate gadgets from third parties or of our own developed ones. The Rest API also helps in developing server side applications.
So I strongly recommend to look deeper in OpenSocial for your specific needs.
It's well known that Google and Microsoft host several common javascript libraries on their CDNs (content distribution networks). Unfortunately neither seems to host JSON2.js.
I'm aware that I could upload a copy of JSON2.js to my server and serve it myself, but there are a number advantages CDNs offer that I would like to take advantage of.
So with that in mind, are there any publicly available CDNs that host JSON2? If not, any idea why? Is there some sort of copyright reason?
Checkout cdnjs.com
http://cdnjs.com/libraries/json2/
Might also be worth investigating Json3
http://cdnjs.com/libraries/json3/
UPDATE: Some of the information was out of date, changed to better links.
json2.js can be found on Yandex CDN servers.
Full version: http://yandex.st/json2/2011-10-19/json2.js
Minified: http://yandex.st/json2/2011-10-19/json2.min.js
HTTPS also works.
I think probably it's too early to expect the big CDNs to start doing this. When enough sites are using a library, the benefits become clear: greater availability, more frequent use, reduced client requests, increased performance for the end user. If only a few sites are using it, chances of client having a copy in their cache already is low and all performance boosts are lost. So all that's left is that MS and Google offset your bandwidth charges, which is not their intention. Thus, the solution is to get more developers to use the library.
Plus the library is so tiny. The code is still only 3.5KB using conservative minification. For comparison, jQuery is 24KB and ext-core is 29KB. I'd personally recommend folding the library into your own site's base JS and get your performance boost there. At least until there's wider acceptance.
Plus, it's funny I'd have expected the JSON library to be hosted also at Yahoo, but I can't find it. I mean Crockford works there.
Thomas from cdnjs.com here with two quick reasons why there is no minified version.
1) The script may not possibly function as the author intended using the method of minification we choose.
2) As a security step we ensure that all files checksums match the original authors hosted files so community submitted updates cannot contain malformed minified code.
So for now that leaves us hosting Crockfords hosted un-minified version;
https://github.com/douglascrockford/JSON-js/raw/master/json2.js
There is now.
Douglas Crockford recently put JSON2 on github, this url will always link to the most recent version.
Edit:
Its not a good idea to use this method, see my comment below.
The Yahoo Javascript library (YUI), JQuery and less so Google maps all allow you to reference their files using the following format:
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/yahoo-dom-event/yahoo-dom-event.js"></script>
This does a request for the script from their servers, which will also pass to their web server the HTTP referrer. Do Yahoo etc. use this to produce statistics on which websites get what traffic? Or is this a conspiracy theory?
Of course their servers most of the time will be a lot faster than any small company would buy, so using the hosted version of the script makes more sense.
Chris,
I work on the YUI team at Yahoo.
We host only YUI on yui.yahooapis.com; Google hosts YUI and many other libraries on its CDN. I can tell you from the Yahoo side that we don't monitor site usage of YUI from our CDN. We do track general growth of yui.yahooapis.com usage, but we don't track which sites are generating traffic. You're right to suggest that we could track usage -- and we state as clearly as we can in our hosting docs that you should only use this kind of service if the traffic logs generated on our side don't represent a privacy concern for you.
In general, though, I don't regard CDN traffic for library usage to be a reliable measurement of anything. Most YUI usage, even at Yahoo, doesn't use yui.yahooapis.com or Google's equivalent, and I'm sure the same is true for other libraries. And even when a site is using YUI from our servers, we wouldn't have comprehensive traffic data of the kind you'd get from Google Analytics or Yahoo Analytics -- because not all pages would use YUI or the CDN uniformly.
Given the advantages of the hosted service -- including SSL from Google and YUI combo-handling from Yahoo -- I see the CDN as being a big win for most implementers, with little downside.
-Eric
Of course they produce statistics - at minimum they need to know how many resources they spend on hosting these scripts. And it's also nice to know who uses your code.
I don't think it's a bad thing.
And using a hosted version makes even more sense because your visitors might have the script already cached after visiting another site.
Sure, they can easily have statistics about which sites use YUI and how often, and also which parts of YUI API are more populare (among small sites). However, they cannot know what exactly web site visitors do with their libs.
Given, that they (Google & Yahoo) index a lot of web pages, they can get an even more precise statistics if they analyze their indexes. So you cannot hide that you are using YUI if your site is public.
The same applies to Google maps and jQuery.