10 years ago, Employer blocks jQuery from Google, DOH! question was posted and Jeff Atwood (SE Founder) answered the following:

We looked at this, but unfortunately the fallback from failure-to-load-JQuery is quite difficult, as we can no longer use the standard JQuery ready event -- which we use all over the place.

In all honesty, unless this is a really prevalent problem, you're better off trying to get google unblocked.

(Also: who blocks Google? That is a little crazy.)

( I do, using pi-hole )

5 years later, another question was made regarding the same subject: Use of ajax.googleapis.com not China friendly

The official answer (quite outdated) seems to be the same over and over again:

For technical reasons, we use the Google CDN for the jQuery files (a CDN is a Content Delivery Network - a bit of technology that makes distributing things like images and JavaScript libraries across the world faster) - that's what is hosted on ajax.googleapis.com. This is something many many sites do and as result many people will already have this library on their computer.

Since google domains were blacklisted on my local network, I'm no longer able to use SE websites.

  1. Why do SE still include google resources on their source code, when it's well documented [2] [3] [4] that they use it to track user activity?
  2. What are the technical reasons for this? Do they still apply 10 years later?
  3. How can I use SE websites without loading jquery from ajax.googleapis.com?

enter image description here

  • (2) the more popular the CDN is, the more people have the ressources already cached in their browser, and thus initial loadtime gets reduced a lot. – Jonas Wilms Aug 7 '19 at 8:31
  • 1
    I can't tell if this would work on production or not, but I can't see why they can't check if loading from the CDN failed, unless they have something against this method, which has been around since at least 2009 – Zoe Aug 7 '19 at 9:36
  • 1
    @Zoe they probably want to keep it simple. And not hosting that js file themselves. But I assume fastly should be able to take away some if not most of that burden. – rene Aug 7 '19 at 10:02
  • They could implement a js fallback, but I guess they don't want to do that. – Pedro Lobito Aug 9 '19 at 15:06
  • 1
    Where would that fallback point to? – Cerbrus Aug 10 '19 at 0:17

For point 3 (How can I use SE websites without loading jQuery from ajax.googleapis.com?):

You can use a browser plugin to locally store jQuery, and redirect requests to use the local plugin, instead of downloading a fresh copy from googleapis. This also can gain you a load time bump and reduce network traffic.

An open source (MPL 2.0) plugin that offers this functionality is Decentraleyes, available on both Chrome and Firefox. I'm not affiliated with the plugin.

  • addon installed! Thank you, but I also would like to know the technical reasons for using google resources on SE sites. – Pedro Lobito Aug 7 '19 at 7:39
  • 8
    Me too, so by all means don't accept this answer to indicate it hasn't been fully answered. That's why I lead with for point 3. – Erik A Aug 7 '19 at 7:44
  • 4
    It's also available for Opera (see decentraleyes.org). It doesn't help with the mobile variants of Chrome, or Safari (it doesn't support it). Mobile Firefox users can still use it (as it supports plugins - Chrome doesn't). Not sure about mobile Opera, or the same browsers on iOS – Zoe Aug 7 '19 at 9:32
  • Modern opera and a surprising subset of browsers are chromium forks. A side effect of this is being able to use chrome extensions in say opera – Journeyman Geek Aug 8 '19 at 10:50
  • I couldn't give you the bounty because my account was suspended. Only certain opinions are allowed around here. Thank you for letting me know about decentraleyes, thanks to it, I can use SE sites without loading any resources from the "don't be evil" company. – Pedro Lobito Aug 19 '19 at 22:43
  • @PedroLobito: All opinions are allowed here. It's how one chooses to express them that can be problematic. – Cerbrus Aug 21 '19 at 13:09
  • @Cerbrus Just like the options we make in life, some choose to work for ONG's and others for big corps, like google. – Pedro Lobito Aug 21 '19 at 14:06

There are 2 libraries being loaded from a google domain:

To answer your points:

  1. Yes, usage can be tracked from those CDN links. That said, as explained in the answer you linked to, What they can track isn't very exciting. It's completely insignificant compared to the data SE themselves track, using google's analytics.
    I wouldn't worry about the CDN, if all the data is being sent to google using their library, any way. Even if you were to cut out the CDN, you'd still have analytics being sent to the big bad Google.

  2. Google Analytics is a commonly used and quite extensive library for all things analytics. I'm pretty sure it's up there in SE's most used tools in regards to target audience research and what have you. You can call it a core feature.
    jQuery, while no longer strictly necessary, is embedded all over SE's source code, and would probably take way too much work to remove for little (if any) gain. You'd lose a lot of backwards compatibility with older browsers.

  3. As Erik A answered, you can use extensions to load the file locally.

  • 2
    I guess people's problem here is that Google Analytics, if prevented by a local network, (presumably) does not stop them using SO, while the googleapis thing does. Also GA is less 'hidden'. From a GDPR perspective, if googleapis is storing IP addresses, the SO privacy notice should say so, I would think. – MandyShaw Aug 8 '19 at 5:59
  • 1
    @Mandy: The CDN is a logical choice for serving commonly used libraries like jQuery. If one doesn’t want any traffic going through google’s CDN, it is up to that user to redirect that traffic. It’s not Stack Exchange’s responsibility to “just work” if a user deliberately blocks a library. Whether or not the data usage is mentioned in SE’s privacy notice isn’t really sudject of discussion on this question. – Cerbrus Aug 8 '19 at 6:05
  • 2
    (And yes, SO works just fine without analytics, but breaks without jQuery, which makes sense...) – Cerbrus Aug 8 '19 at 6:06
  • Completely agree with you @Cerbrus, just wondering why anyone would block Google for their developers in the first place, given the value of Google searches in problem solving... I know other search engines exist, but are they necessarily any less of a privacy issue? – MandyShaw Aug 8 '19 at 16:51
  • "What they can track isn't very exciting. It's completely insignificant compared to the data SE themselves track, using google's analytics. - Sure, but I can block google analytics without breaking SE sites usability, something I cannot do with jquery (googleapis.com), unless I use an extra addon. Compared to analytics, the data exposed via googleapis may be insignificant, but it's not small and their importance shouldn't be discarded or minimized. – Pedro Lobito Aug 9 '19 at 22:04
  • 1
    @PedroLobito: Recognizing that removing jQuery is not an option, what would you suggest SE does? I don't think it's reasonable to expect any site to work just because you don't like the CDN they use. As a visitor of that site, you're deliberately blocking essential files. I think it's then your own responsibility to add a workaround, if you want the site to be functional. – Cerbrus Aug 9 '19 at 22:54
  • I mean, if I were to order a car, but I don't want the engine, because the company building the engine has bad business ethics, I can't expect the car to function, can I? – Cerbrus Aug 9 '19 at 22:54
  • What it boils down to, is that you expect SE to stop using a commonly used CDN just because you don’t like it. Hosting the library themselves will have a significant impact on server load and will increase users’ loading times, epecially considering the google cdn version is likely to be cached already, any way. Unless you can come up with convrete examples of why google’s CDN is bad, backed up with data confirming your claims, I’m not convinced it’s worth the effort and cost to switch. – Cerbrus Aug 10 '19 at 0:15
  • 3
    Just to say - lets keep it constructive, and lots of stuff can rely on external resources - sometimes silly things (leftpad?). That said, if your main concern about the use of google is ideological, things like "bad business ethics" or even practical concerns like GFW - there's options to mirror and block these things. Sometimes folks have gotta make their own choices, rather than expecting folks to live their lives, and build their projects according to their preferences. I'm seeing a concerning amount of personal attacks cause people disagree - and that's not cool – Journeyman Geek Aug 10 '19 at 8:00

Not being an SE employee, I can't answer what their motivation is. However, I can still make an educated guess for 1 and 2:

  • It's massively cheaper than running your own high-scale CDN
  • A more popular CDN benefits the most users

It's a low cost way to minimise load times (and outages) for the highest number of users. While a more privacy-focussed CDN could be used instead, it will cost to switch, may cost more in subscription, and will benefit fewer users.

  • 3
    SE does run a relatively high-scale CDN though (cdn.sstatic.net). Of course, traffic isn't free. – Erik A Aug 7 '19 at 13:42
  • 1
    I guess we've to redefine the concept of benefits in the age of no-privacy. What do I benefit form google knowing which sites I visit? A 300ms faster page load? Do I want to exchange that for my privacy, no I don't. – Pedro Lobito Aug 7 '19 at 14:09
  • 3
    Reduced loading times / data usage are significant benefits. Do they outweigh the (debatable) reduction in privacy? That's up to the individual user. – Cerbrus Aug 7 '19 at 14:11
  • 1
    @ErikA the sudden spike when every active user requests it for the first time doesn't sound pleasant either. – OrangeDog Aug 9 '19 at 15:59
  • @OrangeDog That doesn't need to happen. You can just do a phased rollout. We know SE does AB testing, that's often extensible to do phased rollouts. – Erik A Aug 9 '19 at 16:37
  • 2
    Probably worth noting that the biggest value of using a widely-used CDN for a widely-used library is that even casual visitors will likely already have the library in their browser cache - so it doesn't need to be served at all. That advantage drops for a less-common CDN, and disappears as soon as you move to your own CDN, no matter how good your CDN is. – Shog9 Aug 9 '19 at 22:51
  • @Shog9 indeed, using your own CDN has more or less none of the advantages a proper CDN has, with all the drawbacks of hosting the file yourself... – Cerbrus Aug 10 '19 at 0:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .