gregable

Weird. The site is served by cloudflare and backed by an s3 bucket. Totally static. You shouldn't get forbidden unless cloudflare or your isp are doing something odd.

That's a good point. It's not as though adding a little demand is likely to do anything other than increase supply in this case.

I've sort of wondered if recycling plastics is actually maybe bad from a CO2 angle.

It seems that using mined virgin oil for plastics that gets tossed in a landfill means that at least a little more of the oil we are mining ends up not getting burned and emitted as CO2. In this way, we're creating non-global warming demand for oil which competes with the energy demand in the market. I don't know if this is a reasonable way of thinking about it.

Of course, the energy required to haul a bottle of water hundreds of miles is huge, so I'm not arguing for buying more plastic waste, just not sure how recycling existing plastic waste affects global warming in particular.

Worth noting for anyone who thinks "why bother recycling", this is specifically about plastics.

If you have metal, aluminum especially is a very valuable recyclable, so definitely keep recycling that.

That's fair.

I'm not sure I agree in the usual case. This is sort of what sourcemaps are for. Provide a link in a comment in the resource source to a prettified or at least non-minified version at a separate URL. The typical user won't need to download the extra bytes, but you can still access the original if you want.

I was curious about this. It looks like it has numerous individual plugins that provide the actual functionality. Do you know if some of the plugins are lossless, while others lossy? It may be possible to pick and choose the lossless ones.

AMP documents are delivered with a Content-Security-Policy which instructs the browser not to load javascript resources outside the AMP origin, including inline scripts. The AMP Cache ensures no remote images or other remote resources can be loaded in preload.

When using signed exchanges, the preload does not even parse the document until navigation, as per the signed exchange spec.

Analytics loading is deferred until after user navigation, which makes sense as the user has yet to navigate to the document.

The AMP Cache serves publicly cached HTML documents, and the static fonts/images within those documents. If a document wants to render user specific data, it can load that directly from the publisher's origin upon navigation (not routed via the AMP Cache). See, for example https://amp.dev/documentation/components/amp-list/. Analytics, ads, etc are all fetched directly from the vendor or publisher origin and the AMP Cache will neither proxy nor otherwise see this data.

Yes and no. The browser is making an HTTPS request to the AMP Cache for the document. The document's integrity is ensured by the cryptographic signature of the publisher's origin which the browser verifies. As far as the integrity of the document, this is the same conceptually as the fact that your wifi router is actually serving the document to your browser. The AMP Cache cannot modify the document, and the publisher may choose what to sign or not sign.

Entering the URL directly will make an HTTPS request to the URL's origin server, as it always has. There will be no AMP Cache involved in that request, but it will work just the same.

It's also worth noting that the cache is necessary for prefetching. Without the cache, the prefetch would leak user's query intent to an origin that the user has yet to decide to visit. This would violate the user's privacy, therefore a cache is necessary to achieve prefetch.

This is a misunderstanding. Browser requests to ad and analytics networks are never proxied by the AMP Cache. They are made directly from your browser to the vendors listed. You can verify this in network tools. The AMP Cache proxies: AMP Pages, images, fonts. That's pretty much it, since those are all that's needed for prerendering.

See https://webmasters.googleblog.com/2019/04/instant-loading-am... which addresses the concern about the URL. You can see it for a number of sites already. For example, search for an AMP result from collins dictionary.

As reported in the paper, prerendering only affects amp pages in the first viewport of the search results, which is reported as 10% of the results in their sample. Prerendering does not have any security issues. AMP guarantees that all resources in preload are served by the AMP cache, and custom javascript is prevented by your browser via CSP.

Javascript based analytics works fine, with support for all major vendors and custom setups.

#1 is being fixed for supporting browsers (Chrome so far). https://webmasters.googleblog.com/2019/04/instant-loading-am...

You can see it for a number of sites already. For example, search for an AMP result from collins dictionary.

If you encounter this again in the future, I'd love to take your bug report with the specific page in question. You can email me directly. My email is pretty easy to find from my profile.

Locks are often fairly weak against real attackers.

I enjoyed this youtube video of another smart (fingerprint?) lock being broken due to a digital reset. It has a plastic panel on the front where the fingerprint reader is. If you remove the panel with a razor blade (it's just attached with glue), it even has a reset button exposed which resets the fingerprint. https://www.youtube.com/watch?v=uVvEkcN5tW8

The reason prefetching is particularly difficult to do for regular pages is the privacy implications. The act of preloading the page is a network event that is observable by the server serving that page.

If the server is the same as the linking page, for example Google search result -> Google Cache, there is no new information transmitted. That server already knows the user did query X and it knows that the page was going to fetch cache page Y, since the query page X instructs the browser to do so.

If the server is distinct from the linking page, for example Google search result -> https://healthsite.example/, then the browser will make a request to the healthsite server without the user having clicked the result. The healthsite server will learn the IP of the user, and some information about the query from which page is loaded, all without the user ever "visiting" that site. This is a major privacy violation.

AMP Pages solve this by a) being loaded from Google's cache and b) Guaranteeing no off-cache subresources will be loaded before the page is navigated to. (a) requires Google's cache to serve the page. (b) requires that the document author gives up some control over scheduling resource loading in the prefetch.

Until recently, AMP was the only game in town that could achieve this. Chrome recently shipped with Signed Exchanges, which is a network-level technology that could allow prefetching arbitrary content from a cache. This would still involve a Google cache, but does not require coordination with the document loading. Google AMP now supports this (https://webmasters.googleblog.com/2019/04/instant-loading-am...), but it would also work with non-AMP pages.

AMP hides the entire page to avoid what is known as a Flash of Unstyled Content (FOUC). The document unhides as soon as a single AMP javascript resource loads, or an 8s timeout if that fails. That javascript is very cacheable and is often already in the browser cache to begin with.

Do tenants really decide like that? Moving is costly and insulation is hard to judge on a tour?

The intermediary (Google in this case) can choose not to serve an expired exchange.

The share button simply calls the browser's share API, for example: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

> The Navigator.share() method invokes the native sharing mechanism of the device as part of the Web Share API.

If a Google search results page instructs your browser to request some bytes to preload from a Google server, that request does not reveal anything new to anyone. Google already knows it instructed your browser to preload, so knowing that your browser mechanically followed that request tells it nothing new about you or your behavior that it didn't already have another way to know.

Let's consider the alternative. Imagine you searched for [headache] and a preload request was made to mayoclinic from your browser for their headache document. Your browser when making that fetch would send to mayoclinic your ip, any stored mayoclinic cookies, and the document URL that you prefetched (not the precise query, but the approximate query is easy to guess). This is sent to mayoclinic _even if_ you never click on that document at all, which is not what you would expect privacy-wise.

Once you do click, mayoclinic can very easily log this visit even if the document bytes were preloaded from elsewhere. They can use javascript analytics or simply even load an image on their server (https://amp.dev/documentation/components/amp-pixel). And you as a user are not surprised that clicking on mayoclinic shares your interest in the document with mayoclinic.

There is in fact some draft language around this kind of a mechanism to update a signature to extend the lifetime of the document by fetching a remote URL. See https://tools.ietf.org/id/draft-yasskin-http-origin-signed-r... .

Doing this on every page load breaks either user privacy (by making the origin fetch before the user clicks) or the preload performance gain itself (by blocking load while waiting for this round trip).

Bandwidth increases do not fix latency. If a document has to round trip from the other side of the planet, that adds about 200 milliseconds until we break the speed of light. If that same document must make several round trips to be able to initially load (very common!) this adds up rather quickly. The only solutions are localized caching and prefetching.

Good question.

If you make a search query, but have not clicked on any results, you have a privacy expectation that the web servers of the search results you have not clicked on will not know you performed this query, your ip address, cookie, etc. For example, if you search for [headache] and then close the window, mayoclinic.com knowing that you made this query would probably be a surprising result.

With naive preloading, you would preload a search result from that origin. Your browser would make an HTTP request to the site and that site (sending an ip address, the URL you are preloading, and any cookies you may have set on that origin). So, this approach would violate your expectation of privacy.

Instead, if the page is delivered from Google's own cache, the HTTP request goes to Google instead of the publisher. Google already knows that you have made this query, and are going to preload it (the search results page instructed your browser to do so in the first place). The request will not have any cookies in it except for Google's origin cookies, which Google already knows as well. Therefore this type of preload does not reveal anything new about you to any party, even Google.

AMP has been doing this for a long time in order to preload results before you click them. However, until Signed Exchanges the only way to do this was that on click the page would need to be from a Google owned cache URL (google.com/amp/...). With Signed Exchanges, that can be fixed. The network events are essentially the same.

Note that once the page has been clicked on, the expectation of privacy from the publisher is no longer there. The page itself can then load resources directly from the publishers origin, etc.

To your last point, if someone posts a link on twitter to an AMP page on a publisher domain, and then you click it, your browser will make a network request to the publisher's origin. Google will not be involved in this transaction in any way. If someone explicitly posts a link to an Google AMP Cache Signed Exchange, then yes this will trigger a request to Google but this will be far less likely going forward as these URLs will never be shown in a browser. For example, try loading https://amppackageexample-com.cdn.ampproject.org/wp/s/amppac... using Chrome 73 or later. This is a signed exchange from one domain being delivered from another. You'll never see that URL in the URL bar for more than a moment, so it's unlikely to ever be shared, like I'm doing now.

Currently, it's difficult to implement however unlike rewriting a page in AMP, signing the page is a purely mechanical operation. All that's required is to improve the tooling, it is theoretically possible to be a one-click change for any website out there. Initially adding gzip support to a web server was difficult and out the reach of many webmasters, now it's basically universal.

This is true with TLS as well, though it also requires man-in-the-middling (MITM) the connection. MITM is usually rather easy compared to stealing a private key.

I appreciate the comment. My goal here is simply to correct some of the misunderstandings about the format, rather than express opinions.

AMP documents don't share user data with Google, which can be trivially seen by inspecting the network events that the page generates.

If the publisher chooses, they can send logging to Google Analytics, but this is not part of AMP.

The typical argument otherwise is that the AMP javascript is loaded from Google's cache, however these javascript resources allow for a very long cache lifetime (1yr if the page came from the Google Cache), so relatively few page loads will actually end up fetching them from the network for most users.

Edit: These resources are also on cookieless domains.

Good question. The publisher signs an expiration timestamp in the Signed HTTP Exchange. The publisher can choose this timestamp and the browser will not respect signatures with expirations in the past. Note also that the specification requires, and browsers enforce, that the expiration cannot be more than 7 days in the future.

You could prove the document was signed using the source's private key. That does prove the document was signed by the source if you can prove that only the source had access to the key.