Hacker News Reader

Comment by Meai | Hacker News Reader

I have to agree with this but if Google's goal is to make the web faster then the AMP mission can still be done almost exactly as they are doing it today. Just publish a profiling tool (expanding Lighthouse maybe) that reports the numbers back to Google and then you either get to use their cache and edge servers and get ranked higher or not based on whatever metric that Google wants us to care about. Maybe I'm missing something but that really seems like a much more obvious approach to solving the problem without going through this weird extra webcomponents library, different URL schemes and all that.

View on HN

> use their cache and edge servers

Using the amp cache requires pre-loading content in the end user's browser. That makes things really fast (there is zero request latency to "load" and AMP page), but has security implications. If I stick `window.onload(send a bunch of user analytics to my personal server);` in a preloaded page, than anyone who does a google search where my resource is a result unintentionally loads my page and then has data leaked to me, a random nefarious internet person.

So given these two requirements:

1. 0 request latency

2. Prevent data leakage to third parties

Come up with a scheme that is different from AMP. Or you can argue that either of these requirements is wrong: that data leakage is okay, or more likely that some low-but non-zero level of latency is alright. But my understanding is that the options are either use something amp-like and get approximately 0 latency, or use something non-amp like, and have latency of 50-100ms minimum on good, wired, HTTP/2 connections for well designed websites, and that becomes really bad, really fast, if you're on a 2g or 3g HTTP/1 connection in rural $wherever that's dropping some packets.

Perhaps give browsers the ability to load cached content across domains? So, Google would tell my browser to cache this resource, and then when another website requests it, it's already available in my cache.

I'm sure there are some security/privacy implications that would need to be worked through, but they don't seem insurmountable? It can't be worse than letting websites show fake URLs...

(Security-wise, the primary thing that comes to mind is you'd want to store and check a hash of any asset cached by a third party, to make sure they're actually the same file.)

And isn't that available today with `<link rel="preload">`?

I don't think one domain can preload content for another domain from their own server, but I may well be wrong. If I am, great, Google could do this today.

You didn't solve requirement #2.

How does the third party know the asset was cached if I don't actually visit the third party's page?

The CDN (Google) knows all, but that's true with AMP too.

If that's what you're describing, you've described exactly how AMP works today (though AMP goes one step further and prerenders above the fold, making it instant instead of merely fast).

> I'm sure there are some security/privacy implications that would need to be worked through, but they don't seem insurmountable? It can't be worse than letting websites show fake URLs...

Prefetching cross-domain means that now anyone who loads google.com has the potential to also ping mywebsite.com/trackingendpoint, which is a resource that you have to cache. So I get some information, likely less than if you actually execute the page, but still enough to be worrisome.

> It can't be worse than letting websites show fake URLs...

I really don't get this complaint. I can absolutely understand the unease people have about "fake urls" but a lot of urls already lie. How many are really cloudflare or aws? It's completely possible I'm missing something, but as far as I can tell, signed http exchanges are more secure than a CDN, since they're signed.

I guess that potentially since I, a nefarious person, can re-host your signed content, there might be data leakage possible there, but given that AMP is mostly static, I think that's mostly mitigated. Could be wrong here, I'm not a security (or AMP) expert, but I don't get the fear.

> Prefetching cross-domain means that now anyone who loads google.com has the potential to also ping mywebsite.com/trackingendpoint.

Sorry, I'm not suggesting prefetching cross-domain. I know for a fact this works already, as I've done it.

I'm suggesting that one domain should be able to load assets cached by another domain. They can check the hash to ensure it's the correct, unmodified asset.

I had a longer reply to this but lost it.

There's some significant security concerns with this (I start claiming to cache the pornhub css file), it's not at all clear how it works when you have other caches (if Bing refers me, how do I decide to use bings cached version of my asset vs Google's). I guess you might mean that google can cache something as my site, but I'm pretty sure that would also allow me to maliciously overwrite Google's js in your cache.

And it still has the latency issues: to connect to your site I now have to establish an initial https connection and load the main html page. That's significantly more than 0 latency.

Shouldn't storing and checking a hash solve most of the security problems? That way, you know the asset hasn't changed at all. It doesn't matter if there's multiple caches because unless you've managed to break sha256, they should all be the same file.

The actual html can also be cached, which should make it zero latency. However, I am realizing now that I'm not sure where the checksum gets stored...

(I'll readily admit this was a spur-of-the-moment idea that I haven't actually thought through intensively.)

> if Google's goal is to make the web faster

It's not. It's just a means to an end - lock-in publishers, and lure consumers.

Reply on news.ycombinator.com