Live data from Hacker News

Google no longer providing original URL in AMP for image search results

twitter.com

541–550 of 566 posts

Re: Google no longer providing original URL in AMP for image search results

#541

Earlier quoted context omitted.

So how long until AMP is exploited in a wide range phishing campaign? I know that it is getting harder and harder to distinguish phishing emails from non-phishing emails, but this move is not helping at all. It clearly helps google though. The annoying thing is, average user will not notice and/or care.

All it would require is an AMP website that mimics the Google login page. It already says "google.com" at the top of the browser, and we've told users to trust that, so...

The google.com domain would also probably trigger autofill recommendations from some password managers, which would make things even more convincing and seamless.

Re: Google no longer providing original URL in AMP for image search results

#542
post #307

Earlier quoted context omitted.

Your priors are terrible. Extrapolation from past experience is a perfectly valid form of reasoning: it's called “induction”, and most people consider it a valid form of reasoning. https://en.wikipedia.org/wiki/Inductive_reasoning Or, to mirror your tone: Being paranoid does sound like an issue! However, just because other people's personal incredulity hasn't been a great form of evidence in the past , that doesn't m…

I understand that a lot of people genuinely do not trust Google. It's been their experience, and thus their priors, that Google is attempting to assert control over all aspects of the web. Perhaps someone can find some evidence that allows for deductive reasoning on this subject. I would really like it. Otherwise, all we've got is competing lines of perfectly valid incompatible inductive reasoning. Then people choose…

> Perhaps someone can find some evidence that allows for deductive reasoning on this subject.

Such evidence would be admissible in a court of law, and would probably lead to the breaking up of Google (and Alphabet, and various holdings) under antitrust. Yes, that'd be nice, but you're asking for a lot; even given the premise, it's unlikely to materialise until the statute of limitations has passed, if that.

> Otherwise, all we've got is competing lines of perfectly valid incompatible inductive reasoning.

Not quite. Because you can ignore the lines of the reasoning, take into account the evidence, and then come to a conclusion yourself. If you don't quite trust yourself to do it properly (and who would, honestly? the bias you've highlighted is enough on its own, and it's just one), there's mathematics to do so: Bayes' theorem. (Of course, you have to estimate the conditional probabilities properly, but I find it easier to notice when I'm leaning on the scales when there's a level of indirection like that.)

Most predictions are made with inductive reasoning. If your comment doesn't contain some flaw (even if not the one I pointed out), then it suggests that predictions should be much harder than they actually are. Super-predictors should do not much better than chance. And yet, we find that, in reality, even the little-trained masses do pretty well: https://predictionbook.com/predictions You can see confirmation bias in the graph there, but it's not as significant as my model of you expects.

Re: Google no longer providing original URL in AMP for image search results

#543

Earlier quoted context omitted.

@freeone3000, that's incorrect, in the case of Signed Exchanges. Chrome will verify the document's signature against the publisher's public certificate. This will be `nytimes.com` for example. It is not using Google's certificate for this verification, and Google does not possess the private key required to modify the content and update the signature.

The actual mechanism by which a signed exchange is implemented is prone to man in the middle attacks by removing the Signature field wholesale. You are not requesting info from nytimes.com, you're requesting info from amp.google.com and trusting that the backing data is accurate. There's no need for a certificate to be presented at ALL! Unless it can be determined that such a header should exist, there's no way to ve…

All this means is that any server can choose to present any bytes, even with TLS, as a response to any request. This isn't a novel observation.

If a signed exchange includes a URL, that URL must be signed for the browser to respect the field.

Re: Google no longer providing original URL in AMP for image search results

#544
post #509

Earlier quoted context omitted.

That's really quite useless. I rarely share links by clicking weird "share link" buttons. I usually have half a message already composed in mail/messages/slack, and I just want to cmd-L cmd-C in the browser and cmd-V in the message I'm writing. Also, "the google.com URL will never be displayed" is a world with an internet I don't want to be a part of.

Google never displays AMP documents on desktop (sans mobile emulation), this won't be an issue.

The workflow I described goes for mobile and tablets just as much as desktop; for the cases where a keyboard is not connected please mentally replace "cmd-l cmd-c" with "tap in address bar to select, tap copy".

Also, others might share an amp link from their mobile devices, which I then end up clicking in a desktop slack/mail/messages app, and there we go again with the amp virus even on desktops.

Re: Google no longer providing original URL in AMP for image search results

#545

Earlier quoted context omitted.

Yes. Signed Exchanges mean the publisher signs the content using their private key. A third party can provide delivery like a CDN, but they cannot modify the content, or the signature would no longer match. The useragent (browser) enforces this. This gives the secure control of the content back to the publisher, unlike the trust model of CDNs or the AMP Cache.

>A third party can provide delivery like a CDN, but they cannot modify the content, or the signature would no longer match. To make sure I understand, does this mean that in principle a third party other than Google can deliver the AMP pages? Is google working to facilitate that AMP hosting is open to everyone and calibrating their searches point to any and all alternative AMP hosters?

I want to break down this question slightly.

> Can a third-party other than Google deliver an AMP page?

Yes. Examples: Bing runs their own AMP cache and also delivers AMP pages. LinkedIn and Twitter also link to AMP pages, but they don't currently run a cache. IIRC, Twitter links to the Google AMP cache and LinkedIn links directly to the AMP variant on the publisher origin. They could run an AMP Cache. Cloudflare ran one for some time, but shut theirs down recently.

The AMP Project maintains a list of known AMP Caches here: https://github.com/ampproject/amphtml/blob/master/build-syst...

And provides some guidelines for running one here: https://github.com/ampproject/amphtml/blob/master/spec/amp-c...

It's non-trivial, but absolutely supported.

> Can a third-party other than Google deliver a Signed-Exchange?

Yes. Cloudflare generates them for their customers who opt-in via their "AMP Real URL" product. "Generates" in this context implies delivering them. To date, I'm unaware of any large scale implementation that is delivering Signed Exchanges for third-party origins other than the Google Cache though this may change. The tech stack absolutely supports this.

Re: Google no longer providing original URL in AMP for image search results

#546

Earlier quoted context omitted.

> users not only accept it, they love AMP. As a user, I will absolutely say I love AMP. AMP pages load incredibly fast with much less bullshit. The real problem is that AMP isn't necessary. Google created AMP and is encouraging (nearly forcing it) it in a very hamfisted way because web developers couldn't figure out how to make responsive, fast-loading web pages without a huge company like Google spelling it out for…

Often, it's not the developers that are at fault. Middle managers, cross-functional people, etc. ask developers to cram garbage into otherwise would-be lean pages. Developers often have no authority to push back, and stakeholders often don't fully understand "why" the garbage they're asking developers to insert into pages is detrimental to the user experience. With AMP, the little badge (the verification), serves as…

Makes sense. Middle managers love their analytics and dashboards.

Re: Google no longer providing original URL in AMP for image search results

#547
post #436

Earlier quoted context omitted.

This concern, Google controlled/hosted JS, is independent from Signed Exchanges and specific to AMP. At the same time, the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google.

Will this mean that sites will be able to finally lock in a version of AMP? The idea that there is one place right now that is required for all AMP sites that can dynamically update the behavior of all such pages is, in fact, terrifying to me; like, I went into reading this discussion thinking AMP wasn't making anything worse and being super unhappy that anyone even thought to denigrate signed exchanges (as I want th…

Yes and No, mostly yes:

On publisher origin, the plan-of-record does not involve any validation of the contents of the AMP javascript files. When an AMP Cache (eg: Google) crawls one of these AMP documents, the same is true - the contents of the javascript files will not be relevant to the decision of whether or not the document is considered valid AMP. The files will likely not even be crawled by the Cache.

However, when the AMP Cache serves one of these files, it will rewrite them to the latest* version for serving to users. This is necessary since the javascript runs in a somewhat privileged context in search results.

https://github.com/ampproject/amphtml/issues/25873

* There is also a mechanism for publishers to opt-in documents to a "Long-Term Stable" release, rather than the latest evergreen version: https://amp.dev/documentation/guides-and-tutorials/learn/spe...

Lastly, and there is still some discussion around this, it is likely that Signed Exchanges may be able to load the publisher's own version of the javascript in the future, even in search results. This is because the execution context of the javascript is different for Signed Exchanges.

Re: Google no longer providing original URL in AMP for image search results

#548

Earlier quoted context omitted.

If a site is cached locally, it isn’t loaded from ‘their’ servers when you request it. Or maybe it’ll come from a CDN rather than origin. What’s shown in the URL bar has long been divorced from the HTTP request(s) that are made. > It blows my mind that anyone thinks that’s an acceptable idea It blows your mind that different people have difference opinions and values than you?

What is stored in your cache was loaded from their servers when you originally visited. Also, you can clear your cache at any time you choose to re-fetch the original content from the provider. Also, a provider uses a CDN at their discretion. Giving them the ability to invalidate or update cached records at times of their choosing. Or remove the CDN entirely if they choose to. This is Google using their weight to be…

I sort of agree with you, but robots.txt is a thing.

I know it seems impossible but nobody has to use Google.

Are there any copyright implications of amp? They're essentially republishing your property.

Does the original publisher get their ad revenue?

Re: Google no longer providing original URL in AMP for image search results

#549
post #442

Earlier quoted context omitted.

This amp nonsense has long annoyed everyone and I'm puzzled why it's still around. It makes everything harder and confuses deeplinking, sharing, identifying sites and general navigation between pages.

When you say everyone you mean a tiny minority of developers. The actual users don't care or even know what it is. If anything they like it because it loads the page faster.

I disagree that amp doesn't bother normal users. It is easily noticeable when you click on a search result and go to a page that says amp.google.com?blah=blahhhh and all that. When, as a normal user, you try to copy that link, you'll end up finding this junk and no straightforward way to see the original link. When you click on a link on the AMP page, it forces a full browser refresh. Sites which force people to use apps don't even work with AMP, because these links confuse the deep linking big time. I haven't even seen AMP pages to be any faster than the actual website itself.

Re: Google no longer providing original URL in AMP for image search results

#550

Earlier quoted context omitted.

The actual mechanism by which a signed exchange is implemented is prone to man in the middle attacks by removing the Signature field wholesale. You are not requesting info from nytimes.com, you're requesting info from amp.google.com and trusting that the backing data is accurate. There's no need for a certificate to be presented at ALL! Unless it can be determined that such a header should exist, there's no way to ve…

All this means is that any server can choose to present any bytes, even with TLS, as a response to any request. This isn't a novel observation. If a signed exchange includes a URL, that URL must be signed for the browser to respect the field.

Right, but this means proposing signed exchanges as a solution to AMP's strategies is kind of nonsense, since it's a semantic problem whether a page is acting as a proxy for another, and a technological solution doesn't work here.
Post reply on HN