3 ms·

> 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 req

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

Wowfunhappy 8y ago
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.)
- tiles 8y ago
  And isn't that available today with `<link rel="preload">`?
  - Wowfunhappy 8y ago
    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.
- lern_too_spel 8y ago
  You didn't solve requirement #2.
  - Wowfunhappy 8y ago
    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.
    - lern_too_spel 8y ago
      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).
- joshuamorton 8y ago
  > 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.
  - Wowfunhappy 8y ago
    > 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.
    - joshuamorton 8y ago
      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.

Wowfunhappy 8y ago

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

tiles 8y ago
And isn't that available today with `<link rel="preload">`?
- Wowfunhappy 8y ago
  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.
lern_too_spel 8y ago
You didn't solve requirement #2.
- Wowfunhappy 8y ago
  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.
  - lern_too_spel 8y ago
    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).
joshuamorton 8y ago
> 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.
- Wowfunhappy 8y ago
  > 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.
  - joshuamorton 8y ago
    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.