Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

Post reply on HN
Print view View original

331–340 of 340 posts

Re: AMP pages displaying your own domain

#331

Post by username223 »

gregable wrote: post #327
username223 wrote: post #245

Earlier quoted context omitted.

> 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?

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.

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.

Re: AMP pages displaying your own domain

#332

Post by e12e »

gregable wrote: post #315
e12e wrote: post #222

Earlier quoted context omitted.

Wouldn't it be better to borrow from HTTP and allow a head request to the original source - with a reply of a current signature? Isn't this whole exercise really just adapting public key signatures on top of old school caching? With a http proxy you ask for an url, the proxy fetches or serves on behalf of the owner. This adds some circumvention around the way tls/ssl breaks that type of caching. But it should still b…

There is in fact some draft language around this kind of a mechanism to update a signature to extend the lifetime of the document by fetching a remote URL. See https://tools.ietf.org/id/draft-yasskin-http-origin-signed-r... . Doing this on every page load breaks either user privacy (by making the origin fetch before the user clicks) or the preload performance gain itself (by blocking load while waiting for this round…

But if the signature is expired, preload would fail anyway, which would trigger a regular load "on click" - but that click should maybe result in a head request for possibly just getting an updated signature?

Re: AMP pages displaying your own domain

#334

Post by pvorb »

codewiz wrote: post #329
pvorb wrote: post #304

Earlier quoted context omitted.

But Google controls my browser.

Have you tried changing browser? -- Written from my Chromium browser installed from the Fedora Linux package repository.

I actually use Firefox and avoid Google products where possible, but for the majority of users Google is controlling their browser.

Re: AMP pages displaying your own domain

#335

Post by lern_too_spel »

kuschku wrote: post #326
lern_too_spel wrote: post #321

Earlier quoted context omitted.

Your claims disagree with the facts on the ground, where latency is the main factor affecting page load time. This is the driving force behind CDNs, HTTP2, QUIC, and pretty much every speed optimization that people have been working on in the past few years. https://www.afasterweb.com/2015/05/17/the-latency-effect/ Your claim that your page loads faster also reeks of wishful thinking. Pretty much every AMP page I hav…

As mentioned, I've done testing on actual devices on actual high-latency low-bandwith connections, hundreds of times. That's the "facts on the ground". If you say pretty much every AMP page you've loaded has been instant, please post the specs of the devices and network you've been using for testing. Additionally, if the latency between the device and the nearest server is over two seconds, the latency to a far serve…

> As mentioned, I've done testing on actual devices on actual high-latency low-bandwith connections, hundreds of times.

And as I've mentioned, you've been testing the wrong thing by not understanding the whole point of AMP (safe preloading).

> instead the number of connections needed becomes much more important

A page preloaded from an AMP cache needs at most one TCP connection, usually zero if it uses QUIC.

> and bandwidth also becomes a much larger factor.

Which also works in AMP's favor because the device doesn't need to load your custom JavaScript or potentially unoptimized images, just the tiny HTML and optimized images above the fold. The weight of this (and the associated gain) is tiny, which is why bandwidth is a relatively unimportant factor.

> On bad mobile connections HTTP/2 actually increases latency

You're mixing up dropped packets with high latency. That's neither here nor there because Google's and Cloudflare's AMP caches both use QUIC — my point was that latency is the key factor that all modern web speed technology has attacked, including AMP.

Re: AMP pages displaying your own domain

#336

Post by tytso »

RubenSandwich wrote: post #176
tytso wrote: post #174

Earlier quoted context omitted.

There was an attempt to address Mozilla's concerns[1], but Mozilla never responded, unfortunately. If the Mozilla community chooses not to respond, that might cause people to consider whether or not their position should be given much weight. [1] https://github.com/mozilla/standards-positions/issues/29#iss...

What do you mean they never responded? They say they are working on a response[0]. Taking time to respond and informing the other party that it will take a while is not "never responded". [0] https://github.com/mozilla/standards-positions/issues/29#iss...

3 months is a long time.... how long is someone supposed to wait for a response before you just move ahead? If the answer is "forever", it becomes trivial to perform a denial of service attack on a standard. Mozilla specifically said, "this is not high priority for us". If it's not high priority for them to respond, that's fine, but waiting forever doesn't seem like a reasonable thing to require.

Re: AMP pages displaying your own domain

#337

Post by ddalex »

josteink wrote: post #282
ddalex wrote: post #212

Earlier quoted context omitted.

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 provid…

> 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…

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.

Re: AMP pages displaying your own domain

#338

Post by gregable »

e12e wrote: post #332
gregable wrote: post #315

Earlier quoted context omitted.

There is in fact some draft language around this kind of a mechanism to update a signature to extend the lifetime of the document by fetching a remote URL. See https://tools.ietf.org/id/draft-yasskin-http-origin-signed-r... . Doing this on every page load breaks either user privacy (by making the origin fetch before the user clicks) or the preload performance gain itself (by blocking load while waiting for this round…

But if the signature is expired, preload would fail anyway, which would trigger a regular load "on click" - but that click should maybe result in a head request for possibly just getting an updated signature?

The intermediary (Google in this case) can choose not to serve an expired exchange.

Re: AMP pages displaying your own domain

#339

Post by josteink »

ddalex wrote: post #337
josteink wrote: post #282

Earlier quoted context omitted.

> 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…

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 prop…

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.

Re: AMP pages displaying your own domain

#340

Post by frostbyte3 »

IgorPartola wrote: post #206

I can’t believe there is no way to opt out of AMP as the end user. The UX is so terrible. Often times I will search for something and have a Reddit result come back. When I tap the link, I get the AMP page which: * does not show all comments, often ones I am actually looking for * does not let me collapse comment sections * uses the default white background theme which burns my retinas if I am looking at my phone in…

It's not really google's fault Reddit's amp sucks. AMP sucks, IK, I'm working on my company's AMP pages right now and they are a PAIN. But with enough tweaking, they can be gotten right. So I wouldn't blame Google for Reddit's devs.
Post reply on HN