Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

251–260 of 340 posts

Re: AMP pages displaying your own domain

#251
post #119

This is such a strange reaction from HN. The AMP cache URLs have been a top 3 complaint about AMP here. "I can't copy-paste URLs, it's hard for users to understand which site they are on, it looks like the content is provided by Google rather than the real provider", etc. Now there's a solution that preserves the preloading and validation benefits of AMP caches but maintains the original URLs, in a way that's cryptog…

Because literally the entire private reason for AMP is a power grab. Not the public reason, but absolutely the private reason. If Google, Apple, Amazon, Microsoft, or whatever publicly traded company makes a move its for money and power and preferably power, since that yields even more money. AMP on web and email is the perfection of embrace, extend and extinguish

Power grab from whom? Bing serves AMP too.

https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...

Re: AMP pages displaying your own domain

#252
post #70

Earlier quoted context omitted.

> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache. On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches. > uses tons of unnecessary JS, Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below t…

> On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches. My test device is a Huawei Ideos X3 on a 56kbit/s throttled 3G connection. The same effect also applies with a Pixel 1 on the same connection, or either of the devices on a modern 3.9G LTE connection. (Tested on O2 net in Germany, works reliably better than AMP…

> AMP uses megabytes of JS for that purpose

What? Where are you pulling these numbers? Also, what do you mean by hot cache? I'm starting to suspect that you don't even understand that the AMP page (the JavaScript for sure, and often the entire HTML and above-the-fold images as well) is already on the user's device, while your page is not.

Re: AMP pages displaying your own domain

#253
post #224
post #180

Using the signed exchange mechanism means you allow anyone to serve your content. You will no longer know when it has been served and by whom. Instead, Google will know more about what your users are consuming on your website than you - despite HTTPS! Also, there is no mechanism to limit who is allowed to serve your content for you. I see no technical reason why the content has to be prefetched from Google instead of…

> You will no longer know when it has been served and by whom I'm OK with publishers knowing less about the people seeing their content.

They just have to access the data via Google. Who can cross-link it with all the other data they have. No real privacy gain here.

Re: AMP pages displaying your own domain

#254
post #180

Using the signed exchange mechanism means you allow anyone to serve your content. You will no longer know when it has been served and by whom. Instead, Google will know more about what your users are consuming on your website than you - despite HTTPS! Also, there is no mechanism to limit who is allowed to serve your content for you. I see no technical reason why the content has to be prefetched from Google instead of…

The reason it has to be prefetched from not-you is to protect the users privacy. Until they click a link it is not considered acceptable to leak their search to the potential destination. Links have to be fetched from a third-party who the search engine trusts not to share the data, that at the moment is Google but will hopefully expand.

Edit: I completely misread the comment, but can't delete it anymore a minute later because someone already commented. So oops.

Re: AMP pages displaying your own domain

#255
post #119

This is such a strange reaction from HN. The AMP cache URLs have been a top 3 complaint about AMP here. "I can't copy-paste URLs, it's hard for users to understand which site they are on, it looks like the content is provided by Google rather than the real provider", etc. Now there's a solution that preserves the preloading and validation benefits of AMP caches but maintains the original URLs, in a way that's cryptog…

People here have been complaining that AMP is a power-grab from the very start. So I do not see this as a strange reaction.

Re: AMP pages displaying your own domain

#256
post #254

Earlier quoted context omitted.

The reason it has to be prefetched from not-you is to protect the users privacy. Until they click a link it is not considered acceptable to leak their search to the potential destination. Links have to be fetched from a third-party who the search engine trusts not to share the data, that at the moment is Google but will hopefully expand.

Edit: I completely misread the comment, but can't delete it anymore a minute later because someone already commented. So oops.

[deleted]

Re: AMP pages displaying your own domain

#257

Earlier quoted context omitted.

The reason it has to be prefetched from not-you is to protect the users privacy. Until they click a link it is not considered acceptable to leak their search to the potential destination. Links have to be fetched from a third-party who the search engine trusts not to share the data, that at the moment is Google but will hopefully expand.

Google already can do this by preloading a cached page from its own domain. So this specification is unnecessary. I think the real reason is that Google wants to build a walled garden, but doesn't want the walls to be noticeable. Even with AMP, they display a header that looks like a browser's address bar [1] Also, on that page Google admits that it uses AMP Viewer to collect information about users: > Data collectio…

> Google already can do this by preloading a cached page from its own domain.

That's what AMP already did. This spec is better because it ensures publishers retain control over their own content, and doesn't confuse users by showing "www.google.com" in the URL bar for content that didn't originate from Google.

Re: AMP pages displaying your own domain

#258
post #200
post #180

Using the signed exchange mechanism means you allow anyone to serve your content. You will no longer know when it has been served and by whom. Instead, Google will know more about what your users are consuming on your website than you - despite HTTPS! Also, there is no mechanism to limit who is allowed to serve your content for you. I see no technical reason why the content has to be prefetched from Google instead of…

The caching doesn't necessary need to be by Google. https://blog.cloudflare.com/announcing-amp-real-url/

I think that product is still cached by Google. Cloudflare is just providing the cryptography for Web Packaging so that the browser will show the url from the original page instead of the Google cache.

Re: AMP pages displaying your own domain

#259
post #224
post #180

Using the signed exchange mechanism means you allow anyone to serve your content. You will no longer know when it has been served and by whom. Instead, Google will know more about what your users are consuming on your website than you - despite HTTPS! Also, there is no mechanism to limit who is allowed to serve your content for you. I see no technical reason why the content has to be prefetched from Google instead of…

> You will no longer know when it has been served and by whom I'm OK with publishers knowing less about the people seeing their content.

That statement is also false, because publishers can still track when the page is served via JS.

Re: AMP pages displaying your own domain

#260
post #18

Earlier quoted context omitted.

"Your website has been banned for illegal activity and all content has been deleted. The suspension is immediate and indefinite. Please consider using another Internet" Also, their algorithms mistook live streaming of Notre Dame fires as 9/11 incident. How can live stream be a past incident? https://abcnews.go.com/Business/youtube-mistakenly-flags-not...

You are confusing the term “live stream” to mean something actually happening at that moment in the real world. All a “live” stream actually is to Youtube or FB or any other streaming service is just incoming RTMP packets. Youtube matches incoming streams against their ContentID database just as they do for normal uploads. I would bet that the same thing would have happened if the same footage were uploaded normally…

https://support.google.com/youtube/answer/2474026?hl=en

"YouTube Live is an easy way to reach your audience in real time. Whether you're streaming a video game, hosting a live Q&A, or teaching a class, our tools will help you manage your stream and interact with viewers in real time."

Youtube live is supposed to be streaming of live events. My point is that their algorithms incorrectly decided a live stream was a past event. Even google/youtube acknowledged it was incorrect to tag a live event.

Post reply on HN