AMP is a scourge. It's a bad idea being pushed by bad actors.
I think what Spivak is saying though is right. If we could move from location addressing (dns+ip) to content-addressing , but not via the AMP cache servers, in general, anyone could serve any content on the web. Add in signing of the content addressing, and now you can also verify that content is coming from NYTimes for example.
Also, I'd say that the internet (transports, piping, glue) is decentralized. The web is not. Nothing seems to work with each other and most web properties are fighting against each other, not together. Not at all like the internet is built. The web is basically ~10 big silos right now, that would probably kill their API endpoints if they could.
I don't think this should be shoehorned into the URL bar or into some meta info that no one ever reads hidden behind some obscure icon.
It actually makes perfect sense in Doublespeak. /s
But AMP is a much narrower technology, I’d imagine only Google would be able to impersonate other websites, essentially centralised as you say. The generic idea would just be a distraction to push AMP.
Everything would be so much better if the original websites were not so overloaded with trackers, ads and banners, then there would be no need for these “accelerated” versions.
Could there be net-neutrality-like questions in all this as well?
Create a new “original URL” field or something.
What you're saying would be described as distributed... Not decentralized.
Stated another way, with a typical CDN setup the user has to trust their browser, the CDN, and the source. With signed exchanges we're back to the minimal requirement of trusting the browser and the source; the distributor isn't able to make modifications.
What a bummer.
(Disclosure: I work for Google, speaking only for myself)
And by hovering, or one-clicking, a popup could show both the distributor's address (say, CloudFlare), and the content's/publisher's address (say, NyT)?
https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec... is a thing now.
To put it simply, Cloudflare still controls the content. The proposal here would avoid that, by allowing Cloudflare to transmit only pre-signed content.
Google controls the AMP project and the AMP library. They can start rewriting all links in AMP containers to Google’s AMP cache and track you across the entire internet, even when you are 50 clicks away from google.com.
Really? Could you publish how you are inspecting an unknown program to determine if it exhibits a specific behavior? There are a lot of computer scientists interested in your solution to the halting problem.
Joking aside, we already know from the halting problem[1] that it you cannot determine if a program will execute the simplest behavior: halting. Inspecting a program for more complex behaviors is almost always undecidable[2].
In this particular situation where Google is serving an unknown Javascript program, a look at the company's history and business model suggests that the probability they are using that Javascript to track use behavior is very high.
def divisors(n):
for d in range(1, n):
if n % d == 0:
yield d
n = 1
while True:
if n == sum(divisors(n)):
break
n += 2
print(n)
Also, if I execute a program and it does exhibit that behaviour, that’s a proof right there.
The same kind of analysis can be applied to Google’s scripts: look what data it collects and where it pushes data to the outside world. If there are any undecidable problems along the way, then Google has no plausible deniability that some nefarious behaviour is possible. Now, whether that is a practical thing to do is another matter; but the halting problem is just a distraction.
Tracking doesn't require reading any of your data. All that is necessary is to trigger some kind of signal back to Google's servers on whatever user behavior they are interested in tracking.
> or communicate with third parties
Third parties like Google? Which is kind of the point?
> [example source code]
Of course you can generate examples that are trivial to inspect. Real world problems are far harder to understand. Source is minified/uglified/obfuscated, and "bad" behaviors might intermingle with legitimate actions.
Instead of speculating, here is Google's JS for AMP pages:
https://cdn.ampproject.org/v0.js
How much tracking does that library implement? What data does it exfiltrate from the user's browser back to Google? It obviously communicates with Google's servers; can you characterize if these communications are "good" or "bad"?
Even if you spent the time and effort to manually answer these questions, the javascript might change at any time. Unless you're willing to stop using all AMP pages every time Google changes their JS and you perform another manual inspection, you are going to need some sort of automated process that can inspect and characterize unknown programs. Which is where you will run into the halting problem.
Be cool if you did ;)
This has nothing to do with the halting problem because that is concerned about for all possible programs not some programs.
We obviously know if some programs halt.
while true: nop
X = 1
Y = X + 2
More complex behaviours can be easier. Neither of my programs there make network calls.
Likewise, AMP pages are mostly accessed from Google search that's already tracked.
Publisher hosted copies are in the pipeline, as I referenced in the parent comment. My choice of verbiage was a bit confusing it appears.
AMP's documentation seems to indicate that the LTS is stable only for one month (new features released via the same URL each month), and so is not compatible with SRI (see https://github.com/ampproject/amphtml/blob/master/contributi...)
You can specify a version (ie, https://cdn.ampproject.org/rtv/somenum/v0.js), but the AMP validator complains about that.
Yes, and? What’s your point? It’s actually a security weakness to include third party JS. The whole thing runs on trust.
"AMP HTML documents MUST..."
"The AMP runtime is loaded via the mandatory <script src="https://cdn.ampproject.org/v0.js"></script> tag in the AMP document <head>."
Do a whois on ampproject.org:
"Registrant Organization: Google LLC Registrant State/Province: CA Registrant Country: US Admin Organization: Google LLC"
Note that jQuery, as mentioned in some GP comment has no such requirement. Google AMP is quite unique in this regard. This is NOT some general CDN type issue. Also...agreed, WTF is "open intent"?
They cannot be allowed to become the gatekeeper for the web.
It seems to me, a lot of the security concerns come from the requirements to make pages served live and pages served from bundles indistinguishable to a user - a requirement that really only makes sense if you're Google and want to make people trust your AMP cache more.
I'd be excited about an alternative proposal for bundles that explicitly distinguishes bundle use in the URL (and also uses a unique origin for all files of the bundle).
https://m.youtube.com/watch?v=gqGEMQveoqg
(Google Tech Talk from Van Jacobsen on CCN many years ago)
I don’t support ads but I also don’t support Google serving a version of the page that steals money from content creators. So, therein lies the problem: choice.
I can imagine a future where amp is ubiquitous and Google begins serving ads on amp content. Luckily, companies have to make money and amp is not in most people’s or company’s best interests.
If amp was opt-in only, this would be much more ethically sound.
Google has never injected ads into any cache served AMP document (technically if the publisher uses AdSense, this is false, but that's not the point you are making).
It's difficult to follow what definition of theft is being suggested. The cache does not modify the document rendering, it's essentially a proxy. In a semantic sense, this is no different than your ISP delivering the page or your WiFi router.
Perhaps that's a great thing to do, but it's not something to do quietly.