371–380 of 381 posts
Earlier quoted context omitted.
In what ways is this different/similar from "content centric networking"? https://m.youtube.com/watch?v=gqGEMQveoqg (Google Tech Talk from Van Jacobsen on CCN many years ago)
AMP is happening and CCN is not.
Earlier quoted context omitted.
> By undermining the business model of many ad-supported websites, blunt approaches to cookies encourage the use of opaque techniques such as fingerprinting (an invasive workaround to replace cookies), which can actually reduce user privacy and control. https://blog.chromium.org/2020/01/building-more-private-web-... I'm going to copy paste my older comment on this: I find their "removing 3rd party cookies will incent…
Sounds a bit like: "By locking your door, you only encourage thieves to break your window, which can actually increase the damage they cause you."
Earlier quoted context omitted.
Technically yes, but not very practically. The domain is cookieless, so it would be difficult to even identify a specific user, other than by IP. Also, the JavaScript resource is delivered from the cache with a 1 year expiry, which means most times it's loaded it will be served from browser cache rather than the web.
How is google.com cookieless?
Earlier quoted context omitted.
> AMP is "faster" because it gets rid of all the nagware and JS crap that the original page has. AMP is faster only for poorly-optimized JS-heavy pages but the design is fundamentally flawed to require all of its own large amount of JavaScript to run before anything displays, whereas most of the traditional bloat doesn’t block rendering. That means any optimized page - Washington Post, NYT, etc. – loads noticeably fa…
Those tests show you don't understand why AMP works. It works because it prerendered, which is going to be faster than anything you can do.
AMP’s design is very fragile: if you are using Google search results, they correctly guess what you’re going to tap on before you do and your browser fully preloads it, it _might_ be faster to run all of that JavaScript before anything is allowed to load and render. If any part of that chain fails, it will almost certainly be slower or, because it disables standard browser behavior, prevent you from seeing content at all.
Earlier quoted context omitted.
I'm following. Imagine that example.com builds the bundle by pulling data from a database. If an attacker can find a way to store malicious content in that database (stored XSS) and that content ends up in a signed bundle that Google AMP serves (similar to cache poisoning) then users will see malicious content. When the stored XSS is removed from the database, Google AMP may continue to serve the malicous signed bund…
Signed exchanges can only serve static content, so it's not clear what you could do maliciously.
Earlier quoted context omitted.
The pattern is dangerous because it trains the user to dissociate URL and legitimate content, and the best tool at our disposal against phishing is still the ability to use the URL to ascertain the legitimacy of a content.
Do you really think most smartphone users look at the URL anymore? Or even know what a URL is? From the non-technical people I've talked to, the answer is no, they don't know what a URL is, and that was happening before AMP came around.
Had enough of HN ...
This place is bullsh!t.
Ban me.
Earlier quoted context omitted.
Those tests show you don't understand why AMP works. It works because it prerendered, which is going to be faster than anything you can do.
If that were true, AMP would be consistently faster. Since anyone who’s used it knows that it’s not, you would find it educational to learn about the issues with detecting user intent, reliably prefetching dependencies, and the relatively small / frequently purged caches on mobile browsers. AMP’s design is very fragile: if you are using Google search results, they correctly guess what you’re going to tap on before yo…
It is. AMP results load instantly for me.
> you would find it educational to learn about the issues with detecting user intent, reliably prefetching dependencies, and the relatively small / frequently purged caches on mobile browsers.
And you might find it educational to learn why AMP doesn't rely on these things. There are no dependencies that need to be fetched for the initial render.
This idea isn't surprising. Multiple other systems use the same ideas, including Apple News, many RSS readers, and Facebook Instant Articles. AMP just does it in a way that isn't anti-competitive (like the former) and allows for multiple monetization schemes and rich formatting (unlike RSS).
> if you are using Google search results, they correctly guess what you’re going to tap on before you do and your browser fully preloads it, it _might_ be faster to run all of that JavaScript before anything is allowed to load and render
AMP doesn't rely on fully prerendering the page, only the portion above the fold, which it can calculate because the link aggregator page knows the display size, and the elements allowed in AMP are required to report their dimensions. This allows multiple pages to be prerendered.
> because it disables standard browser behavior,
What standard browser behavior does it disable?
Earlier quoted context omitted.
> The issue is that the technical meaning of the URL is very far from what most user think of. My argument is not really concerned with what most users think of, but humor me, what do they think of? > So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? Yes, because HTTP/S scheme URLs…
I think the subtle shift of view here is that the URL shows the address where the content is located, more so than where the content was actually fetched from. An example of where this occurs today is caching. You could be hitting a cache anywhere along the way. Hell you could be seeing an "offline" version, but the website would still show you the "address" of the content. This is no different, you're hitting a diff…
The only sense in which content is located anywhere is as data on a memory device somewhere. With the traditional URI in which the host part of the authority is an address of or a domain name pointing towards an actual host, you have a better indication of where the content is located than you do if this is misrepresented as being some other domain name which in fact does not at all refer to the location of the content.
The shift, if any, is that people may be less interested in where the content is located and more interested in its publishing origin.
> An example of where this occurs today is caching. You could be hitting a cache anywhere along the way. Hell you could be seeing an "offline" version, but the website would still show you the "address" of the content.
Yes, because that's how domain names work.
> This is no different, you're hitting a different cache, but the "URL" you see is the canonical address of the content you are looking at, not where it was actually fetched from.
It's different in the sense that a host name as displayed by the browser then has multiple, conflicting meanings that have no standardized precedent.