从技术上讲，是的，谷歌可以做很多这样的事情。也就是说，当您在您的网站中“使用 JQuery”时，您实际上是指您网站的页面引用了那段 Javascript，任何浏览您的网站的人都会自动从 Google 的服务器下载它，让 Google 很容易知道是谁下载了它，什么时候，以及在哪个站点中找到了链接（由于Referer标题）。这很容易做到，对你来说是无法察觉的，所以应该假设谷歌做到了（如果他们符合他们的声誉，那就是）。

阅读您的网页是另一回事。他们可以通过修改该文件的内容来玩恶作剧jquery.min.js，以便对您的网站页面执行各种操作，包括读取其中的部分内容并将其发送回某个服务器。但是，这将带来被检测的风险，因为这将是一种主动攻击。谷歌的座右铭是“不作恶”，他们只能在他们永远看起来不作恶的情况下才能坚持下去。沉迷于主动攻击可能会严重损害他们的形象，而且我怀疑他们会因为阅读您的网站这样微不足道的事情而冒险（好吧，我不知道您的网站是做什么的，但我怀疑它包含的内容是否匹配谷歌本身的净资产 ——我希望你不会在比较时感到被冒犯）。

就跟踪而言，这与链接到任何第三方/外部资源没有任何不同。将列表限制为在其标头中发送的最相关的 HTTP 请求信息，这些信息可被内容服务器读取并可用于跟踪用户活动：

• Cookie - 客户端软件应该将外部服务器可以检索的 cookie 限制为仅那些domain和path路径属性与接收请求的服务器的域和路径匹配且未过期的 cookie。此外，当 cookie 中存在此标志时，它们仅限于存在secure只能通过安全连接访问的标志。Cookie 可以读取和写入，因此从技术上讲，Google 可以将新的跟踪 cookie附加到其响应中，并以这种方式跟踪用户代理（网络客户端软件）。到目前为止，我还没有注意到任何写入跟踪 cookie的请求，或者在请求 jQuery API 时附加到 Google 服务器响应的任何其他目的的 cookie。大多数客户端软件还具有警告用户存在第三方 cookie 和/或阻止它们的能力，具体取决于客户端偏好。由于欧盟的cookie 法要求所有网站运营商明确警告在任何这样做的页面上使用 cookie，因此 Google 无法真正改变主意，并突然通过附加跟踪 cookie而不触发警报来开始跟踪请求。

• 引用者- 这是请求外部资源的网页的地址 ( URL )。“referrer”一词在 RFC 以及大多数实现中都有拼写错误。确实没有什么可以阻止 Google 将这些数据用于统计/跟踪目的，因为它是标准 HTTP 请求的一部分。虽然可以通过在链接到 Google 外部资源的服务器上重定向请求或通过其他匿名外部请求的方式来删除 HTTP 请求中的引用信息（或更改为非公开 URL），但实际上并没有多少网络服务器这样做。该信息本身并不重要，但可以与其他 HTTP 请求数据链接，以更准确地识别请求发起客户端。

• User-Agent - 此请求字段通过使用用户代理字符串来标识客户端软件。它们通常包含有关您的客户端软件及其功能（浏览器类型、浏览器版本、扩展、操作系统、操作系统版本、Web 客户端使用的库...）的各种信息，并可用于识别唯一的Web客户端在不同程度上。例如，查看Panopticlick项目并测试您的浏览器在迄今为止测试的所有浏览器中的独特性。User-Agent当然可以由客户端软件更改以包含更少的识别信息（例如TOR 浏览器对每个“更改身份”用户的请求进行处理），但大多数用户不会意识到他们的浏览习惯可以通过这个 HTTP 请求字段单独识别，当然也不会对此采取任何行动。谷歌可以使用这些信息来更独特地识别网络客户端和/或用于其他统计目的。这是您作为链接到外部资源的发布者无法控制的事情（它附加到客户端的请求标头，并且您自己的 Web 不会以任何方式处理对文档中链接的外部资源的 HTTP GET 请求服务器）。

• IP 地址- 不是标准HTTP 请求标头的一部分，而是TCP/IP请求本身（传输协议级别）的一部分，此地址唯一标识请求发起的网络客户端，因此可以将响应发送到其预期的接收者。有一些方法可以通过使用各种代理或VPN解决方案使用 IP 地址来绕过此识别。但并非所有这些都一样有效，并且一些代理会将附加标头附加到 HTTP 请求（例如X-Forwarded-For），这可能导致暴露请求的 IP 地址，或者使用代理服务器（例如Via）来检索服务器的 HTTP 响应.

此 Wiki 页面中列出了所有可能的 HTTP 请求标头信息，其中一些可用于跟踪单个 Web 客户端的指纹，而从这个意义上说，大多数实际上是良性的，并且对于所有 Web 客户端或多或少都保持相同，并且是因此无法用于识别目的。

不过确实会好一些。由于您通过DOM作为外部资源链接到 Google API ，因此解析其内容并生成外部请求的客户端软件将使用GET 方法来检索其内容，因此没有属于POST 方法主体的数据（例如表单数据）可以通过此类请求读取，无论使用什么 HTTP 请求方法来获取链接到此外部资源的文档内容。

不过，这可能是也可能不是一个好消息。例如，如果您通过使用通过URI字段值传递给服务器的会话令牌来授权用户访问服务器上的资源，那么您不会在服务器上使用HTTPS，而是使用协议链接到 jQuery API - less URL 以 开头//，这些 URI 字段将在“referer”字符串中重复，Google 将在对其服务器的请求中看到它们。在其他情况下（您使用 HTTPS，或通过 POST 请求进行身份验证并使用 cookie/用户存储/会话存储将会话令牌写入客户端），此“引用”信息不会包含在 GET 请求中（POST 中使用的 HTTP正文字段方法不会泄漏到 HTTP标头中新请求上的字段），或者不会通过它泄露任何用户数据（HTTPS 协议在对外部资源的请求中不包含“引用”信息，无论它们通过什么协议提供服务）。

至于你问题的另一部分——这个链接是否能让谷歌阅读我的网页——是的，当然有可能。基本上，您通过自愿链接到您无法控制的外部资源来启用XSS类型攻击，从技术上讲，Google 可以轻松接管您链接到此 jQuery API 的网页并完全更改它们以他们的喜好。不过他们不会那样做，因为这对他们来说意味着游戏结束了。对 Google 帮助发布的这些库的任何更改也相对容易跟踪，方法是将 Google 发布的接收文件与官方 jQuery 页面上发布的文件进行比较，或者通过计算MAC接收文件的签名，并根据jQuery 页面上文件的 MAC 签名检查其数据完整性和真实性，或者简单地逐行比较文件。

所以简而言之，是的，谷歌有可能通过检查与请求外部资源（如 jQuery API）相关的 HTTP 和 TCP/IP 请求值来跟踪用户的浏览习惯，谷歌帮助在其服务器上发布，但如果他们这样做，他们不会通过将跟踪 cookie附加到他们的响应来进行主动跟踪。这将限制他们为统计目的以外的任何目的成功/唯一识别 Web 客户端的能力。使用 TOR / Proxy / VPN 服务器，或者您在自己的服务器上发布 jQuery API 都无法绕过这种缺乏 Web 客户端的情况。然而，在不被发现的情况下更改此 API 以包含恶意代码几乎是不可能的，并且会给 Google 的声誉带来灾难。

不过请注意，我们在这里并没有真正排除任何中间人攻击，这种与外部资源的链接确实为潜在的攻击者提供了额外的好处，可以简单地将任何此类请求替换为攻击者选择和使用的位置它是一种恶意的有效载荷工具。

阻止所描述的此类威胁的最佳选择是在您自己的服务器上简单地发布 jQuery API。它确实为您的每个用户请求带来了一些成本，即您的 Web 服务器必须处理一个请求并增加服务请求所需的带宽，但它会消除所描述的所有风险，无论它们多么合理可能。