32

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

8
  • 1
    (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. Aug 7, 2019 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, 2019 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, 2019 at 10:02
  • They could implement a js fallback, but I guess they don't want to do that. Aug 9, 2019 at 15:06
  • 1
    Where would that fallback point to?
    – Cerbrus
    Aug 10, 2019 at 0:17
  • 1
    Adding a remark into your question about being suspended and that your comments were removed tends to be detrimental to how people see this discussion, particularly given that your description of the reason is A) nearly certain to be biased towards your point of view, and B) appears completely irrelevant to this discussion.
    – Makyen
    May 8, 2021 at 1:28
  • 1
    I'd also note that this is tagged as discussion and support, which means that you're asking for a discussion about how to solve the issue for you only. The answers provide you with options. If you were wanting to make a suggestion that SE make a general change to their site, then this should have been tagged as a feature-request and neither discussion nor support. Note that it's probably considerably too late to change this into a feature request (if you want one, then it would be better to create a new question with a clearly written request for change).
    – Makyen
    May 8, 2021 at 1:34
  • 1
    I've rolled-back your recent edit. The only relevant information which was provided in that edit was that you consider one of the answers to be "the" answer. On Stack Exchange, the way that is indicated is that you should accept the answer.
    – Makyen
    May 8, 2021 at 1:40

4 Answers 4

29

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.

7
  • addon installed! Thank you, but I also would like to know the technical reasons for using google resources on SE sites. Aug 7, 2019 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, 2019 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, 2019 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 Aug 8, 2019 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. Aug 19, 2019 at 22:43
  • @PedroLobito: All opinions are allowed here. It's how one chooses to express them that can be problematic.
    – Cerbrus
    Aug 21, 2019 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. Aug 21, 2019 at 14:06
11

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.

9
  • 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, 2019 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, 2019 at 6:05
  • 2
    (And yes, SO works just fine without analytics, but breaks without jQuery, which makes sense...)
    – Cerbrus
    Aug 8, 2019 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, 2019 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. Aug 9, 2019 at 22:04
  • 2
    @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, 2019 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, 2019 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, 2019 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 Aug 10, 2019 at 8:00
8

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.

7
  • 3
    SE does run a relatively high-scale CDN though (cdn.sstatic.net). Of course, traffic isn't free.
    – Erik A
    Aug 7, 2019 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. Aug 7, 2019 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, 2019 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, 2019 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, 2019 at 16:37
  • 3
    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, 2019 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, 2019 at 0:16
-1

jsDelivr is a public CDN and a perfect replacement for Google CDN. Better, it's optimized for China. I see no reason why SE can't load jQuery from jsDelivr, other than the management being too stubborn to push forward this change.

In case jsDelivr is blocked by enterprises "for security concerns", Cloudflare provides CDNJS which is most of the times accessible from China. And of course, jQuery is literally everywhere.

Disclaimer: I am not affiliated with jsDelivr or Cloudflare.

12
  • It's not only about being stubborn, it's also about giving their friend google an insight over our browsing patterns.. May 7, 2021 at 20:47
  • Stack Exchange founder sees no reason why we would want block Google, and even considers that idea a bit "crazy". To me, that says a lot about his ignorance regarding privacy. May 7, 2021 at 20:50
  • 1
    @PedroLobito And ignorance of Chinese users (Google is state-blocked here). May 7, 2021 at 21:08
  • Note that there's also a security issue. jsDelivr is, as stated, a public CDN, on which people can host basically anything they want, just by putting the content on GitHub. As such, the domain is likely to be blocked by default by organizations which are concerned about security.
    – Makyen
    May 8, 2021 at 1:10
  • This suggestion would probably be viewed significantly more positively if the answer, and the comments on this answer, didn't include disparaging remarks.
    – Makyen
    May 8, 2021 at 1:17
  • @Makyen In fact, the same suggestion has been left alone for more than a year. No way "this one would have been ...". May 8, 2021 at 1:19
  • @iBugsaysReinstateMonica I don't see how that has any relevance, other than to explain the frustration which you've expressed by making disparaging remarks, to the detriment of your answer. You should already be aware that SE commonly takes a long time to do most things and/or address issues (the main example I use is that it took 2 years and multiple Q&A on Meta Stack Overflow to get 5 words of text changed in one review queue's help text). This issue has been brought to their attention. I understand it's frustrating, but it's better to express that frustration constructively.
    – Makyen
    May 8, 2021 at 1:48
  • I'd note that it is usually much more effective to make arguments in terms the people you are trying to convince truly care about. For a business, that usually means explaining how they will make more money, or loose less money (which is basically the same thing), by doing what you're suggesting. So, explain the number of users which they are leaving as unable to use the site with the current configuration. Equate that to the amount of money they could be earning by enabling those users to use the site, but which they are choosing not to earn.
    – Makyen
    May 8, 2021 at 1:58
  • @Makyen I really appreciate and admire your professionalism and patience here on Stack Exchange. Granted, there are many, much more wanted features that SE simply turns down for no good (e.g. Markdown table until September 2020, seeing own deleted posts, and more), and this is just one more of them. May 8, 2021 at 2:10
  • @Makyen Regarding your latest comment: I'm not up to the task of generating the numbers for the management. I'm sure they know better than me how much the Chinese market worth and how the change benefits. Even Elon Musk cares about China. It's only a matter of the slighest attention. May 8, 2021 at 2:12
  • Thank you for the complement. Yeah, there are lots of areas where SE could use significant improvement. One frustrating thing is that they could tap a lot of free engineering and design talent, but choose not to do so, often specifically ignoring it. Yes, putting this suggestion, or other suggestions, in terms which most clearly show the advantage of improving in this area does take time and effort, and SE is in a much better position to get actual numbers, but getting at least part of the way to showing that information shouldn't be too hard.
    – Makyen
    May 8, 2021 at 3:12
  • To be clear, I do agree that this is an area which can and should be improved to make SE available to a wider audience. Quite some time ago, I did take a decent look at the code SE was using for bootstrapping. At the time, I did feel it was... significantly less capable of handling common faults, like the CDN for jQuery being blocked, than would be desirable (or that I'd consider basic). I also agree that improving in that area is not that difficult, with the benefits likely significantly outweighing the costs (both development cost and ongoing cost).
    – Makyen
    May 8, 2021 at 3:14

You must log in to answer this question.

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