Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not Google, but the reason is obvious to anyone who understands AMP. Only AMP can be guaranteed safe to preload through static analysis, and a carousel lets the search results page figure out which pages to preload trivially (the results currently visible in the the carousel).


> Only AMP can be guaranteed safe to preload through static analysis

This isn't how static analysis works. Yes, the halting problem says you can't determine safety of any possible input in a Turing-complete language, and yes, JS is Turing-complete. But it doesn't say you can't determine safety of some inputs. You can write an algorithm that outputs "Yes," "No," and "I don't know" just fine. Google can, if they desire, specify some rules / annotations that would help its analyzer answer "Yes" to more pages. They've chosen not to do that, and instead to only build an analyzer for AMP.

Besides, preloading pages is about fetching content, not rendering them, I think.


> specify some rules / annotations that would help its analyzer answer "Yes" to more pages

Isn't that exactly what AMP is? Whatever "rules" Google specifies will in fact, define a DSL/subset of HTML that can efficiently answer "yes". As people demand more and more capability in this ruleset, eventually you'll end up with something like AMP, only the syntax will be slightly different, but the fact that it is a weird subset of HTML will remain.


In a way yes, but isn't one of the "rules" that is has to be cached/re-served from Googles servers as well? That is a rather problematic one, especially wrt antitrust issues...


No, those rules guarantee that the page is safe to preload. It will also be cached and preloaded by Bing, Baidu, and Cloudflare.


AMP doesn't allow arbitrary JS. It only allows a fixed set of components. That's what makes it amenable to (trivial) static analysis -- just verify that the page contains only the elements allowed by AMP.


> Only AMP can be guaranteed safe to preload through static analysis

No, AMP pages can't be proven safe, because with AMP you can include ads which are a very common vector of malware.(if I understand your comment)


Ads aren't preloaded in AMP pages.

Also, I don't think you understood my comment. I mean safe as in not deanonymizing the user to pages they don't visit. If you preload a non-AMP page, you have deanonymized your user to a third party publisher and the ad servers on that page.


> Ads aren't preloaded in AMP pages.

That does not make a big difference.

> Also, I don't think you understood my comment. I mean safe as in not deanonymizing the user to pages they don't visit. If you preload a non-AMP page, you have deanonymized your user to a third party publisher and the ad servers on that page.

Sorry I still don't get it, with AMP it's exactly the same except that 3rd party is the Google AMP server. You can also load analytics & trackers with AMP as well. There's no privacy in the AMP design goals.


If Google allowed arbitrary pages in the carousel, and then preloaded those pages, then BBC and BuzzFeed could insert trackers that let them know what you searched for even if you never click on a result.

This is not true for AMP analytics because Google define the JS and can defer sending analytics events until after the user has clicked on an item in the carousel.

Google can either preload content, allow non-AMP pages, protect users from data leakage, but not all three at once. They have chosen to sacrifice non-AMP content.


> If Google allowed arbitrary pages in the carousel, and then preloaded those pages, then BBC and BuzzFeed could insert trackers that let them know what you searched for even if you never click on a result.

There's nothing you can do with the carousels that they can't do by just parsing the content or meta tags they could have defined. And when you click on the carousel, it could have redirected to their page.

And before you talk about the "speed" of preloading like I've seen this argument over and over again on AMP threads, AMP could have defined an HTTP header which would have made the browser understand it's an AMP page and load the cached AMP JS (among other stuff like refusing to load non-AMP content), there's no technical need for an AMP server.


Google can choose to sacrifice non-AMP content. But the header above this feature should read something like "AMP Content," not "Top Stories." The latter strongly implies that those are the most relevant results from the user's web search, but they are not. They are a subset of the most relevant results from the user's web query. A more precise and less misleading heading would be appropriate.


Cannot this problem be solved by producing a text-only version of the page using Firefox's reading mode algorithm that removes everything except the article text? This way publishers don't have to invest resources in making a second version of their site.


Good luck browsing news stories with video content or image slideshows. Also publisher analytics, advertising, and all the other basic staples of web journalism. But yes, if you completely change everything about the business model of online news, reader mode might be viable.


> *Also publisher analytics, advertising, and all the other basic staples of web journalism. But yes, if you completely change everything about the business model of online news (...).

Yes, this is the solution and should be the ultimate goal to fight for. Those "staples" are precisely what's ruining the web journalism, and the Internet at large.


Let me introduce you to USA Today European Experience: https://eu.usatoday.com

It’s possible to create a non-bloated fast news website. Neither publishers nor Google are interested in that.


> Neither publishers nor Google are interested in that.

See previous comment about the way the online news business works.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: