I was browsing Goodreads.com with uBlock origin installed on my browser. I'm not a web developer but, I understand that some websites send requests to "ajax.googleapis.com" in order to design their UI. This website (security.stackexchange.com) does it too.

enter image description here

From the above screenshot, it's clear that ajax google APIs were used without sending a request to google.com on this page. So, I conclude that

Using ajax google APIs doesn't require the website to send a request to "google.com".

Green on the left side of uBlock origin panel means that requests were sent to these domains while visiting this page and thus those domains know about your presence on this website. Red represents that an attempt to was made to reach the domain but, it was blocked.

That being said, when I visited the stat page of Goodreads, I couldn't load the graph.

enter image description here

So, to fix it, I started unblocking the requested domains one at a time. When I unblocked "google.com", I noticed that requests were made to Google's Ajax APIs only after I unblock the request to "google.com".

enter image description here

This made me wonder why have the designers of this website programmed it that way it is? Why didn't they called Ajax APIs directly? The only reason I could think of is that it's a way of enforcing users to disclose their presence to Google. But, I'm open to the idea that I might be wrong. Could someone provide a technical clarification to what's happening here?

Is Goodreads letting Google know of my presence on their website?

EDIT: Sorry to use the term "Selling" I don't want to get political. Just looking for a technical explanation to this scenario and want to know if there's a possibility that there's a reason to sending requests to google.com other than letting Google know of my presence.

  • Your title says "selling" - that's a very specific act that I'm not sure we could acertain
    – schroeder
    Dec 12, 2019 at 12:37
  • @schroeder : I realized it after reading your comment. I'm sorry to use the term. I'll change the title of my question. All I want to get is a technical explanation to this scenario without getting political about it.
    – 7_R3X
    Dec 12, 2019 at 12:40
  • Although you are worried about privacy, this is actually just a web programming question. Why are sites built this way. And there are tons of legitimate reasons. Do any of those reasons impact privacy by exposing your activity to a 3rd party? Sure.
    – schroeder
    Dec 12, 2019 at 12:43
  • First of all, it's not goodreads.com that makes the request; it's you. If the site wanted to sell your personal data, they would not instruct you to do it for them.
    – user163495
    Dec 12, 2019 at 12:54
  • @MechMK1: I believe it's a Goodread's Javascript that makes the request from my computer. So, saying that I made the request wouldn't entirely be correct. It's debatable, I guess.
    – 7_R3X
    Dec 12, 2019 at 12:56

1 Answer 1


This is not really a question about security, however I understand that people may be confused by the way things are usually implemented on websites. What happens depends entirely on the order in which assets are loaded in the page.

First your plugin blocks all the scripts. The plugin will only show you the external scripts that can be found in the page, which are blocked. Then, when you allow those scripts, those scripts will execute and in turn they might load other scripts, which will be blocked again by the plugin. If you allow these scripts again, they will execute and they might load yet other scripts, and so on. That's why you sometimes have to keep allowing scripts, and more will appear.

Your page (note: registration is required): https://www.goodreads.com/review/pub_year_graph/37991099

In that page you have this code:

<script type="text/javascript" src="//www.google.com/jsapi"></script>

That script contains the following line, along with a lot of other code:

google.loader.GoogleApisBase = 'https://ajax.googleapis.com/ajax';

So first the page loads a script from google.com, and that script in turn loads other javascript from ajax.googleapis.com. Why do scripts load other scripts from other domains, instead of just loading what is needed from one domain? It's usually just the way they organize their APIs and services, and it might make sense because you can manage everything easily from one API, instead of having to worry about several different scripts and domains.

But if you are asking why they didn't place the script on the googleapis.com domain, and instead they loaded it from google.com, and so your browser ended up sending your google.com cookies along with the request, then I don't have an answer. Users' data is Google's business, so that choice might well have been on purpose. I don't know, I guess it would be interesting to ask Google why, maybe there's a technical reason, or maybe not. However, if you are in Europe, Google is not really at fault here. GDPR (General Data Protection Regulation, European law on privacy) requires that the websites check what they are doing with their users' data. So it's technically goodreads.com that is at fault here, for using Google's services in that way, no matter if they have a choice or not. In practice though nobody cares about Google, data, privacy or any laws about privacy. For now, at least.

  • loading from google.com ensures a likely hot (cached) DNS lookup, reducing overhead and increasing performance. nothing sinister.
    – dandavis
    Dec 12, 2019 at 21:13
  • 2
    @dandavis, wouldn't the same be true of googleapis.com? That's a very common domain too, and even if it wasn't, it would become common as soon as everybody started to use it on every website. Like it happens for fonts.googleapis.com, used virtually everywhere today.
    – reed
    Dec 12, 2019 at 23:40
  • Note that GoodReads supports Google login. This requires the use of google libraries and Google cookies. Most implementations of third-party login unconditionally load third-party libraries. It would be a bit nicer, privacy-wise, to do so on demand. However, most third-party login systems don't support this.
    – Brian
    Dec 17, 2019 at 14:18

You must log in to answer this question.

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