[48309248302]

This sounds terrible. Does it mean that browsers will begin lying to users and say that the users are visiting the website's server when they are really visiting a restricted version of the website that is hosted in Google's cache? I don't want my content restricted or hosted in Google's cache.

AMP doesn't load in a privacy sensitive way. It's on Google's servers and it takes many seconds to load if you have JavaScript disabled.

Also, the feature only works on Google Chrome and possibly Edge, which gives another point to the article below.

https://www.zdnet.com/article/former-mozilla-exec-google-has...

AMP is a fundamentally bad idea that needs to disappear.

Edit: Mozilla has marked Signed HTTP Exchanges as harmful.

https://mozilla.github.io/standards-positions/

[gregable]

The browser displays the URL from the origin that digitally signed the unmodified content.

A browser already doesn't show you what server delivered the content. That would be your wifi AP, cell phone tower, or ISP node. The internet has already long established that we can trust content without trusting intermediaries.

There are two elements that are important: integrity and privacy. The content integrity is protected via a digital signature, the "signed" part of "signed http exchanges". The signature proves that the document hasn't been tampered with.

Regarding privacy: The intermediary (a search engine in this case) already has the content being delivered as a result of crawling it. It also knows the user clicked on a link to get that content, and knows the user's ip address. Even without AMP or Signed Exchanges, the privacy situation is the same. Once the page is loaded, all further interactions with the origin are normal https traffic, so later requests are not different in privacy either.

What this enables, for search results, is the ability to load the bytes of the content before the user clicks a search result. If the browser prefetched those bytes with the origin's awareness, then the user's privacy with respect to the search query would be violated, making prefetch problematic. With this setup, documents can be prefetched while preserving user privacy and after the user clicks all browser behavior continues as normal from that point forward.

[rando444]

AMP allows Google to see exactly how you interact with every page on the internet.

Just from the text of the pages you visit they can build a profile around you. What your interests are, how much of an article you're likely to finish, whether you're the type of person to highlight text as you read, etc.

Unless you live on an island with a poor satellite connection AMP is useless as anything more than a corporate user data collection tool.

[gregable]

AMP documents don't share user data with Google, which can be trivially seen by inspecting the network events that the page generates.

If the publisher chooses, they can send logging to Google Analytics, but this is not part of AMP.

The typical argument otherwise is that the AMP javascript is loaded from Google's cache, however these javascript resources allow for a very long cache lifetime (1yr if the page came from the Google Cache), so relatively few page loads will actually end up fetching them from the network for most users.

Edit: These resources are also on cookieless domains.

[Mindwipe]

> The typical argument otherwise is that the AMP javascript is loaded from Google's cache, however these javascript resources allow for a very long cache lifetime (1yr if the page came from the Google Cache), so relatively few page loads will actually end up fetching them from the network for most users.

Christ this is thin as a privacy argument.

[codedokode]

> AMP documents don't share user data with Google, which can be trivially seen by inspecting the network events that the page generates.

Is there anything preventing Google from changing this later?

[andrerm]

No, if Google can change the way web works from day one they can change anything they want. Don't forget Google is killing imap and dns already. Why not http to?

[codedokode]

Also, Google explicitly states that it is collecting data in AMP Viewer [1]:

> The Google AMP Viewer is a hybrid environment where you can collect data about the user. Data collection by Google is governed by Google’s privacy policy.

I assume they collect information from HTTP request the browser sends when requesting an AMP page.

[1] https://developers.google.com/search/docs/guides/about-amp#a...

[cced]

> AMP documents don’t share user data with Google

They might not now, but could ‘t Google start creating unique URLs on each page, allowing them to track you that way?

[meowface]

They can already do that, and are doing so, through Search, Analytics (maybe), ads, etc. That war is long lost.

[duozerk]

They can't if you block all their shitty domains and don't use google services. Things that many privacy-conscious users do.

[dwild]

We are talking about their AMP cache. If you don't use Google Service, except if you like to prepends their amp cache URL before your links, you'll never get there.

Their AMP cache happens only on their search service. They already know which links you click... having an AMP cache on top doesn't give them MORE information than they already get. The use of that cache also make sure the website doesn't get more information because it's preloaded.

[duozerk]

That's not entirely true though, is it ? any link shared on reddit, or here, on on any social network by a chrome user can be an amp one.

[snaky]

If (or when) the share of that privacy-conscious users will rise, Google might motivate webmasters to compile GA scripts in the main JS script, and considering pretty much any website now a days just doesn't show content with no Javascript enabled, it would be much harder to avoid.

[duozerk]

I browse mostly without javascript on and that's not true; easily more than half of websites work just fine without it, and that number goes far up if you accept some lack of features. Though there are some that indeed don't work at all.

Although your point is well taken that there could be ways to sneakily track users eventually despite the aforementioned measures, and potentially even without javascript being required (though I doubt that share of privacy-concious users will ever raise significantly - most people simply don't care).

[gsich]

No excuse.

[48309248302]

Google can't tell if a link has been clicked if JavaScript is off and the `ping` attribute is removed, so AMP removes privacy there.

By forcing web publishers to host their content on a Google cache, they lose their server-side logging and the ability to determine how they set up they way they serve their own sites.

Also, why do you artificially slow page loads on AMP pages to 8 seconds when JavaScript is disabled? That is a privacy issue.

[gregable]

The linker (google in this case) could rewrite the link to use a redirector if they choose. If Javascript is off, AMP and thus Signed Exchanges are disabled on Google search results anyway.

You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified):

  <style>
    body { animation:-amp-start 8s steps(1,end) 0s 1 normal both}
    @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
  </style>
  <noscript>
    <style amp-boilerplate>
      body{animation:none}
    </style>
  </noscript>

See the noscript section: if javascript is disabled, the CSS displays the body immediately. If Javascript is enabled, but for some reason the AMP javascript fails to load, after 8 seconds, the page is displayed anyway. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.

[48309248302]

There are legitimate (privacy/speed) reasons to not load AMP's JavaScript while still not turning of JavaScript entirely. Google does have the capability to know when you're on an AMP page, because the JS loads from ampproject.org, which is registered by Google.

An 8-second delay seems like an intentional "bug" to coerce users to turn on JavaScript (and advertising).

[gregable]

The javascript is heavily cached, so will not give a request on every page load.

That is not the intention. If javascript is disabled entirely, Google Search won't even load AMP pages. The scenario you describe of a user loading an AMP page directly without javascript enabled is somewhat rare.

[48309248302]

Many people use tools to block third party JS from loading. AMP can't be called privacy-friendly while making it extremely difficult to use when tracking (AMP Analytics) is blocked. The 8-second delay happens to me every time I accidentally click an AMP URL in my browser.

[lucideer]

I don't use Google Search, and I frequently get sent to Google's AMP cache via other link sources (e.g. HN).

I don't have javascript blocked, but I do have Google's tracking blocked via standard tracking protection (which is now a built-in feature in most non-Google browsers), which means <noscript> tags are not triggered, and I get the 8 second delay due to non-loading JS resources.

I don't think my setup is as rare as you make out.

[UweSchmidt]

It is clear that the current developments on the web are worrysome and we need real privacy. We need to be able to find a website and visit it completely anonymous, unless we actively submit information to said website or a court order is issued.

A cell phone tower or ISP node is ideally just infrastructure, "plumbing". Google seems to be trying to advance their strategic position in that direction. Rather than just being one search engine among several, they are trying to become part of the infrastructure. This could prevent future privacy solutions (and even prevent competitions between search engines).

[codedokode]

The real reason to make this spec is not to improve integrity o privacy or something else but to make users stay on Google's domain instead of going to other site. Google wants to build its little walled garden, and this spec is needed to make users think that the walls aren't there.

> With this setup, documents can be prefetched while preserving user privacy and after the user clicks all browser behavior continues as normal from that point forward.

But Google can already preload and show cached version of the page without this spec. The only difference would be that address bar shows "google.com" instead of publisher's domain. There is no need for this specification.

[josteink]

> A browser already doesn't show you what server delivered the content. That would be your wifi AP, cell phone tower, or ISP node.

No. Incorrect. Completely backwards. Factually wrong. You just failed your networking-exam.

Those things you mentioned would be transparent networking nodes forwarding your TCP-packets and they have nothing to do with any layers above that.

The fact that you don’t even know this completely invalidates any other point you may have.

[ddalex]

I think you're missing the point of the GP. It says that you don't know and you don't care which particular server returns your content - is it a self hosted machine, is it a cloud machine, is it a CDN? No way of knowing unless you inspect the deeper stack. What you see very visible is which BRAND (I. E. URL) returned your content.

So this Amp exhange technology changes nothing in this regard. It's like Google provides its own Free CDN, it is just not done in a traditional manner.

[josteink]

> It says that you don't know and you don't care which particular server returns your content

Which is plain wrong. I care.

When the URL-bar says I’m looking at company.com, I expect my browser to have used my OS’s DNS-resolver to look that name up, connect to the IP-given and nothing else.

I certainly don’t expect it to send traffic to certainly-not-the-nsa.com which are MITMing my traffic and tracking/monitoring it.

If I can’t trust my browsers URL-bar to exclusively and accurately reflect what is actually requested, it is effectively lying to me, the user, it’s owner.

And then suddenly all URLs are phishing URLs because Google made URLs no longer matter or mean anything.

Completely unacceptable.

[ddalex]

My point is that even if you look at the URL bar currently and it says company.com, you don't know what you're connecting to. Probably you're connecting to CloudFlare/CloudFront/Akamai/Fastly/any other CDN which is set up with good-enough certs to impersonate the domain. Therefore you're not trusting a particular server, you're trusting a relationship that the domain owner built with her's service providers.

The proposed scheme is just another way to extend this kind of relationship that the publisher builds, a new mechanism if you will. There is nothing in there that requires more or less trust from your part than before.

You're complaining that need URLs to reflect what is requested - in fact, I argue that you want the URL to tell you what is being served. But this is not what's currently happening.

URLs are already lying to you.

I doubt that you WHOIS-lookup all DNS resolved-IPs to verify that the IP presenting a cert is assigned to the organisational entity that you want to connect to, and have a whitelist of those entities that you actually allow your browser to connect to. Because that's what currently required to make sure you don't go through CDNs and other intermediaries between you and the publisher.

[josteink]

Using a CDN currently means the company use trusted mechanisms like DNS to delegate certain traffic to other providers (like with Cloudflare). And it does so for everyone.

In which case the URL serves what was requested.

What AMP does is provide google.com content and lie to the user and says it comes from company.com.

Which isn’t true, and it only does so for users coming from google.com. Where I’m sure google will be happy for the additional tracking data.

This is NOT the url the user was lead to believe he requested. This is not what everyone else is served.

This is malware.

[chii]

> I don't want my content restricted or hosted in Google's cache.

how is this different than using your own domain, but pointing it to a github.io page? Or using medium, but with your own domain (but still being served from medium's servers)?

Is it just google you're adverse to, or the entire idea of someone else hosting your content?

[48309248302]

1) I want full control over my servers and to not be penalized in search engines for not hosting my sites on Google. Where are the server-side logs?

2) I want full control over how I publish my sites with real web standards. AMP is not a web standard, it's a Google format that they are strong-arming people into using.

3) Mozilla considers Signed HTTP Exchanges harmful. This technology is as bad as what Microsoft was doing with IE in the old days.

4) I don't publish on Github pages, but if I did, I would still have a choice over which servers I put the sites on.

5) There shouldn't be a single company (or few companies) that dictates how we publish online.

6) Shame on the people who are splitting the web with this fake-opensource technology. There's even a Google engineer over here referring to the Web like it's a Google product. https://news.ycombinator.com/item?id=19631136

[Operyl]

As per point 6, I wouldn’t take what was said there as a statement from Google, or potentially even an employee of Google. They did it as a throwaway .. anybody wishing to kick the hornets nest could have posted that, employee or not.

[48309248302]

It's not written like someone trying to kick a hornet's nest. It's written like someone who has been conditioned inside of a culture that has begun to view the Web as a Google product on some level.

[Operyl]

And if somebody was wanting to kick a hornets nest, that’s exactly how you’d want to write it :).

My point is, you cannot just blindly trust anonymous comments to be who they say they are, it’s an easy way to get yourself in trouble.

[laggyluke]

But if the comment was, say, digitally signed, on the other hand... ;)

[millstone]

DNS is the answer to the first two questions.

However the last question is a fair point - nobody complains about CloudFlare's caching of your web page as you designed it.

The critique of AMP is that it receives privileged placement in search results, and that content authors are being pressured into adopting this de-facto Google-controlled spec, where they host your content and control its presentation. Anything that furthers AMP helps Google in this effort.

[skybrian]

That's a good point! Domain owners can host their websites wherever they like, and yes that includes Google's cloud.

If they go through a content network like Cloudflare, you can't even tell who's hosting the site by looking at the IP address.

It drives home the point that websites are abstractions that have no necessary relationship to any particular physical hardware. Network tools may or may not tell you a bit more about the source, depending on if there are any leaks in the abstraction.

[48309248302]

There is a difference between the web publisher controlling that abstraction and a web publisher that has been strong armed into one abstraction or another.

[skybrian]

There are incentives, but publishers still make their own decisions.

[48309248302]

Being penalized in the search results is outright coercion, not an incentive.

[sandov]

I didn't even know about "HTTP Exchanges", and I'm more interested than ~98% of the population about this kind of stuff.

Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design.

Good on Mozilla for marking it as harmful.

[jedberg]

> Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design

Does it though? If you use Cloudflare or Akamai or Cloudfront or Netlify or etc. etc. then what shows up in the URL bar is not the server where the content is actually hosted. Well, it is the server where it is hosted, it's just one of the many domains hosted by that server.

[luckylion]

That has never been different. Cloudflare & co are reverse proxies, for all intents and purposes from a user agent view, they are where the content is coming from. They are the ones pointed to in DNS, and they have valid SSL certs.

[jedberg]

And how is this all that much different? In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package. If anything, I'd have more faith in this changing my URL than a proxy via DNS.

Just because Google invented it doesn't make it bad.

[lol768]

> In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package

How is it more secure? If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".

[jefftk]

> If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".

Spoofing DNS to clients is much easier than spoofing DNS to certificate authorities. Otherwise domain-validated HTTPS certs wouldn't mean much.

[luckylion]

> And how is this all that much different?

It changes the meaning of the address bar from "this is who I'm talking to" to "this is who (at some point in time) signed this content".

[jedberg]

But when there is a CDN there, "who I'm talking to" is really just an intermediary who pretends to be you, and may have in fact modified the content. With this, it is still an intermediary pretending to be you, but at least now the package is signed and can be verified.

[dwild]

This is just semantic.

Do a trace route on any domain and you'll see that the server isn't the one that give you the answer, but some intermediary. Sure in that case when you did the request, the content is fresh and the server answered RIGHT NOW, but that cache still get the content from the server, it's just a bit older.

[jazoom]

I decided it's time to give DuckDuckGo another shot. I just realised it's a lot nicer to scroll through its results than Google is now.

[kelnos]

I've been using DDG for at least a year now. On some occasions I can't find what I need and end up checking Google, but in those cases, Google usually can't find what I need either.

[sebazzz]

Signed HTTP exchanges may be harmful, but Google is beginning to get enough dominance so they implement it and browsers with a minor market share must follow or are left behind.

[millstone]

What happens if other browsers don't implement it? It seems like they'll just show CloudFlare or Google's domains, instead of the signing domain?

[gregable]

The behavior for browsers without support is to show the google.com/amp URL as before, along with a small html-based bar with additional information about the original domain and share intents.

[mthoms]

With a button to disable AMP results entirely if that's the wish of the user?

Yeah, I didn't think so.

[username223]

> share intents

Does that mean that the Google+ button is coming back? Seriously? Why not just serve the content and leave it at that? Is the tiny bit of extra data you get from a unique "share on Facebook" URL worth it?

[gregable]

The share button simply calls the browser's share API, for example: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

> The Navigator.share() method invokes the native sharing mechanism of the device as part of the Web Share API.

[username223]

I didn't know the Web Share API existed, but based on the RFC, it looks like yet another Google-driven "standard." I still don't see why it needs to be added to the page.

[lern_too_spel]

> AMP doesn't load in a privacy sensitive way. It's on Google's servers

Only if you load the page from a Google SERP, in which case, Google would already know if you visit the page. If it's loaded from a Bing SERP, it's served from a Bing server, and the same for Baidu and other AMP caches. This is far more privacy preserving than preloading a page from some third party web server that the user might never visit.