Live data from Hacker News

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

twitter.com

401–410 of 566 posts

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

#402

Earlier quoted context omitted.

I couldn't agree more that AMP is terrible. I do everything I can to avoid it. Using DuckDuckGo certainly helps, but I will still occasionally stumble on an AMP site. I've created a hosts block list to help me avoid AMP as much as possible. It currently has 3,569 unique domains (works great with a PiHole!). I'm really concerned about Chrome's 'signed exchanges' where they can fake the URL completely. I hope Firefox w…

> I'm really concerned about Chrome's 'signed exchanges' where they can fake the URL completely. They're not faking the URL; a signed exchange contains data that can only have come from the original site. It's a secure way of handling caching/CDNs/etc, and it'll be a net improvement for security that allows sites to put less trust in third-party servers and scripts.

This is changing the semantics of fetching a URL to be agnostic how it gets resolved. That’s disturbing and downright deceitful to the end user.

Fifteen years ago, if you asked me how google search would look, I would have responded “mostly the same, maybe they’ll have cool features like asking me which meaning of ‘converse’ i wanted: the shoe brand or the logical relation.”

Instead, they’ve only subtracted functionality from the query engine (no more domain blocking), discouraged you from clicking through to sites by automatically scraping and rehosting them as “semantic” results, and now they’re trying to actively acquire 100% of the outbound traffic. Fuck google.

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

#403

Earlier quoted context omitted.

> The useragent (browser) enforces this. This assumes the user agent is actually an agent of the user, and not the AMP provider, which is demonstrably [1] not the case. [1] https://github.com/w3ctag/design-reviews/issues/467#issuecom...

Chrome does enforce the matching signature. Browsers without Signed Exchange support will not likely ever get a signed exchange as they do not advertise support for it in the `Accept` request header.

Chrome enforces that the signature being served by google is the same signature as the one being served by google. It's a useless verification. If Google were so inclined, they could very well just change the tag too.

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

#404
post #375

Earlier quoted context omitted.

> When you perform a GET request for these assets you are being monitored. You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. > PS: You work for Google. Do you work on this project? No, I work on mostly internal infrastructure. My inte…

> You'll only ever retrieve Google AMP cache results from the Google search page Uh, I keep seeing Google AMP URLs shared on social media, emails, etc etc. Which is quite annoying :(

The AMP team doesn't prefer these URLs shared either:

If you click the browser share icon, or trigger the browser native share intent, the origin URL will be shared, not the AMP Cache URL. Only if you explicitly copy the URL bar will the AMP Cache URL be shared.

The Signed Exchange spec that AMP has offered sites for a year now allows them to have their own URLs displayed in browsers that support it. In that case, the google.com URL will never be displayed and thus can't be accidentally shared.

All AMP documents on the AMP Cache contain `` and Google recommends that social media prefers the canonical URL. This is useful outside of AMP as there are often multiple URL variants for any article. The sharer and sharee may not ideally get the same version. As an example, a mobile vs. desktop article.

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

#405

How does anyone think this is a good idea? It should be clear which news site I am reading when I'm reading an article. Otherwise, how do I know which bias to apply? On iOS, the title bar says "google.com" whether I'm reading an article from CNN.com or WashingtonExaminer.com. Of all the anti-competitive actions google has taken around search results, AMP is by far the worst. I hope they get smacked down for it in the…

> How does anyone think this is a good idea? A while back on one of the AMP discussions here, someone from Google weighed in. They said the data was clear: users not only accept it, they love AMP. I asked how they knew that, because if it was, say, just tracking how many people tried the 2-3 tap process to get to the original URL compared to how many people just engaged whatever you showed them, then the data might b…

> Apple has its own problems with the URL bar -- they keep the domain but drop the rest of the URL. Not as bad as replacing the domain, but not great.

You can view the full URL in safari for iOS by tapping the URL bar. In Safari for Mac, you can modify your preferences to always show the full URL. Definitely not ideal, but also not anticompetitive in the same vein as AMP

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

#406

Earlier quoted context omitted.

> You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. I am not affected, I don’t use Google search. The problem is for individuals who use Google search and now don’t have an option to avoid in deep tracking. The difference between regu…

Nothing beyond the initial page load is served by the AMP cache. If you request additional dynamic resources or navigate to other pages, you'll go to the originating site. I'm confused.

In the example I saw, you could go through a mini site experience; you can “visit” the site without leaving the AMP. I don’t believe this one change, serving images from the AMP cache, is the issue. My concern is with the proliferation of AMPs. A lot of individuals will browse AMPs thinking their browsing is between them and the site publisher without realizing Google is in the middle. Honestly, Google has an okay track record of respecting people’s data. In their AdExchange, they are one of the few that obfuscates the IP address. However it is still concerning that a single entity continues amassing all those browsing patterns from billions of individuals. It can be abused easily, with intent or not.

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

#407

Earlier quoted context omitted.

> The useragent (browser) enforces this. This assumes the user agent is actually an agent of the user, and not the AMP provider, which is demonstrably [1] not the case. [1] https://github.com/w3ctag/design-reviews/issues/467#issuecom...

Chrome does enforce the matching signature. Browsers without Signed Exchange support will not likely ever get a signed exchange as they do not advertise support for it in the `Accept` request header.

@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.

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

#408

Earlier quoted context omitted.

> You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. I am not affected, I don’t use Google search. The problem is for individuals who use Google search and now don’t have an option to avoid in deep tracking. The difference between regu…

Nothing beyond the initial page load is served by the AMP cache. If you request additional dynamic resources or navigate to other pages, you'll go to the originating site. I'm confused.

@DevKoala, do you have an example where you encountered the "mini-site" experience? I haven't seen it, but it could be a bug that would be worth fixing.

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

#409

Earlier quoted context omitted.

The worst thing I've seen recently is amp URLs for reddit threads. It's one bad thing (new reddit UI) wrapped in a worse thing (AMP), and getting back to classic reddit takes a lot of gymnastics. The stupid part is that the amp page is indistinguishable from the (new) reddit page (the AMP page comes complete with the "download our app" popup). So I don't see how it's providing any speed/experience benefit.

>getting back to classic reddit takes a lot of gymnastics http://old.reddit.com still works, though Hope they are sane enough to keep it forever

This isn’t going to be the site that turns up in results, sadly.

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

#410
post #370

Earlier quoted context omitted.

I couldn't agree more that AMP is terrible. I do everything I can to avoid it. Using DuckDuckGo certainly helps, but I will still occasionally stumble on an AMP site. I've created a hosts block list to help me avoid AMP as much as possible. It currently has 3,569 unique domains (works great with a PiHole!). I'm really concerned about Chrome's 'signed exchanges' where they can fake the URL completely. I hope Firefox w…

Even better than blocking AMP is just redirecting to the proper page[0]. [0]: https://addons.mozilla.org/en-US/firefox/addon/amp2html/

Does that extension break with this most recent change though?
Post reply on HN