As a nice side effect of Google pushing Web Packaging, we get one step closer to having web apps that are signed with an offline key and served with a clear version number.
This would mean you could have at least a TOFU security model, where a web app that you trust can't be replaced (without you knowing) by an insecure version you haven't seen before.
Add some binary transparency [1] logging on top of that, and it might be possible to make browser-based JavaScript crypto almost as secure as the equivalent desktop app.
You could do this quite simply by requesting trusted apps to be identified by Named Information (ni:// or nih://) URIs (see https://tools.ietf.org/html/rfc6920 ) using a digest algorithm of sufficient strength. But the ability to "seamlessly" replace web apps is something that many websites would insist on, I think. Of course ni:// and nih:// can be applied to documents as well. They work on the IPFS model, where you enter some digest of the desired content as your URI (it's actually a URN, not a URL!) and then it's the user agent's job to fetch it from wherever, perhaps in a decentralized way.
> ... then Chrome gets to decide what name to show you in the address bar - potentially a name that has very little to do with the actual location of the document
That doesn't seem to be the opposite of what the parent post is describing, it seems to be an implementation of it.
How so? The web package comes from the real source you see. The only reason Google needed to serve the content from its own domain is because of security and limitation of content delivery. But with this, they can serve you a "package" that's identical to what you get from the source.
Common techniques like relative paths will allow the proxy-cache to see much deeper into a site than the end user is aware. The url bar might say that you're on some site you trust but your traffic may all still be openly readable by Google (or some other proxy). Of course, Google is always going to know about links that users click in its search result list and a huge number of sites blindly run Google (or other third party) scripts anyway but this opens up a new vector for Google to see into your traffic.
Didnt read past the first section since that appears outdated already. AMP Project is run similar to nodejs by adopting an open-governance model. This was first announced here - https://amphtml.wordpress.com/2018/09/18/governance/ and the went live later that year.
> AMP Project is run similar to nodejs by adopting an open-governance model.
OK, but the only thing I want out of AMP is for it to not exist. Is there any chance that I can get involved in AMP's open governance with a "stop existing" goal?
It is already quite surprising that AMP has gone in the direction of "We'll accept signed webpackages and publish those so we aren't acting as the origin". But my goal is that even this should not need to exist: websites that genuinely load fast on their own, comparable to downloading the webpackage, should be ranked as high as AMP websites. And it's preferable for websites to do that. So there should be no boost for AMP websites, just a boost for fast pages, and if AMP does anything it should just provide guidelines for how to build fast pages. Examples of fast pages include HN and most things published before 1998.
At the end of the day AMP exists because it's privileged by Google Search, and AMP is privileged by Google Search because Malte Ubl has whatever amount of influence he does within Google and has convinced them that AMP is a good idea (or other people have decided it's a good idea and have put Malte Ubl in charge of making sure it happens, or whatever). No matter how many non-Google people you put on the steering committee you won't change that. You don't have the internal access to change Google's mind about it.
This is like saying that it's okay that I should be happy living in a city that always votes $party because I can get involved in the party. If my personal political views are $opposing_party, that statement is technically true but completely useless.
> OK, but the only thing I want out of AMP is for it to not exist. Is there any chance that I can get involved in AMP's open governance with a "stop existing" goal?
You can choose not to use it. It's just like when you find a project on Git(hub|lab|etc) and it uses a language, tool, or package manager you've never seen before. You either try to work with it or look at other projects.
If you don't want to deal with AMP, you can click the link icon at the top of the page, then click the link so that you actually end up on the webpage you wanted to visit. You can't force everyone to adopt the "amp shouldn't exist" model just as much as you can't force "electron shouldn't exist and everyone should write native apps" on others.
1. I do in fact click the link icon. Half the time it takes me to an AMP version of the website (not the google.com/amp version, but example.com/amp/ or something) instead of the full version.
2. Why is it being framed as me forcing everyone to adopt the "AMP shouldn't exist" model, instead of Google forcing everyone to adopt the "AMP should exist" model?
3. You're talking about me as a consumer. As a publisher, I don't want to use AMP, but I want the favorable SERP placement that comes with using AMP. I think that my website satisfies the actual goal behind AMP, of loading fast. But that isn't enough, and I have to use AMP - and force my visitors to either use AMP or click through AMP (making it slower, and defeating the point of everything). As a publisher I'm actually pretty excited about the webpackage stuff (and it'll be straightforward since I'm using a static site generator), but it's still not the same as being able to run a real website that actually loads quickly.
4. None of this answers my question, which is not "How do I, personally, avoid using AMP" but "Does the AMP open governance model, in which people can allegedly become involved in setting the direction of AMP, allow people the opportunity to make AMP cease to exist"?
5. Google's monopoly power in search results and vertical integration makes everything more complicated. Electron does not have monopoly power on native apps, and nobody is giving an artificial boost to native apps that are written in Electron. Any advantage to Electron is due to Electron's own technical merits.
My bet is that the majority of people on the AMP advisory committee are primarily there because they need to avoid unfavorable placement on the Google SERP and so they're forced to implement AMP and want to make sure they can still render half-decent web pages using AMP, not because they inherently like AMP.
The number one reason I constantly use desktop mode is so that I don't get AMP pages. I've even switched search engines to get rid of them, but still have to sometimes use Google search because it finds what I'm looking for.
>You can't force everyone to adopt the "amp shouldn't exist" model just as much as you can't force "electron shouldn't exist and everyone should write native apps" on others.
Considering that the reason AMP is even used is because Google puts AMP results higher in search results you could argue that Google might be leveraging their market position into using a technology under their control.
> If you don't want to deal with AMP, you can click the link icon at the top of the page, then click the link [...]
Apart from that that is "dealing with AMP," why is it so hard for Google to offer a "no amp in search results" setting? It's not like there is no case or desire for it.
Until they take that simple step, I see no reason to assume that pushing AMP isn't on an ethical par with distributing crapware. Google should know better.
> my goal is that even this should not need to exist: websites that genuinely load fast on their own, comparable to downloading the webpackage, should be ranked as high as AMP websites.
My understanding is this is also Malte's goal, and the goal of the Google Search folks. We need a way that Search can know that a website (a) will perform well and (b) can be preloaded in a privacy preserving manner. Right now only AMP can do this, but with Web Packages people will be able to do this without AMP. Once you can get (a) and (b) without AMP I will be super surprised if Search still prioritizes AMP.
(Disclosure: I work at Google, on making ads AMP so they don't get to run any custom JS. Speaking only for myself, not the company.)
I don’t want web packages, nor AMP, how do I get the ranking bonus and lightning bolt icon with my website (which has Google Pagespeed of 100 and Chrome Lighthouse Pagespeed of over 95)?
That’s the goal. Killing web packages and AMP, and actually ranking websites by its actual speed.
With web packages or AMP, if I navigate from Google Search to Page A, and then from Page A to Page B, Google can see that I went to page B. This is wrong. In an ideal world, Google wouldn’t be able to track anything, but as they are able to, we should limit this. As web packages and AMP lead to more ability for Google to track stuff, they need to be eradicated.
> I don’t want web packages, nor AMP, how do I get the ranking bonus and lightning bolt icon with my website (which has Google Pagespeed of 100 and Chrome Lighthouse Pagespeed of over 95)?
First, those metrics say how well optimized your site is, not how long it takes to load. For example, a tiny site that's text and a single poorly compressed image might load in 500ms but get a low score, while a large site that loads in 5s can still get a perfect score if everything is delivered in a completely optimized way. These are metrics designed for a person who is in a position to optimize a site, but not necessarily in a position to change the way the site looks. When speed is used as a ranking signal [1][2] Google isn't using metrics about optimization level, it's using actual speed.
But ok, metrics etc aside, Google could switch to using loading speed instead of AMP to determine whether a page is eligible for the carousel at the top, and whether to show the bolt icon. But AMP means a page can be preloaded without letting publishers know that they appeared in your results page. You can't just turn on preloading without solving this somehow. AMP is kind of a hacky way to do this, and I'm really looking forward to WebPackages allowing preloading for any site in a clean standard way.
> With web packages or AMP, if I navigate from Google Search to Page A, and then from Page A to Page B, Google can see that I went to page B.
No, web packages don't allow this, what makes you think they do?
(Disclosure: I work at Google on making ads AMP so they don't get to run custom JS. Previously I worked on mod_pagespeed which automatically optimizes pages to load faster and use less bandwidth. Speaking for myself and not the company.)
AMP isn't "run openly" because everything key to Google's business is non-negotiable, and at the end of the day, Google will do what Google wants. This is what I found out when a few of us tried to talk about AMP4Email, where before threatening us with the code of conduct (for bringing up valid security concerns), Malte Ubl admitted that AMP4Email would be implemented however the Gmail team wanted to implement it, and that no amount of community concerns on the GitHub were going to have any say in the matter.
The reality is the "open governance" AMP spec means nothing, because as a monopoly, the only AMP cache which actually matters is Google's. And it's implementation is Google's proprietary business, not part of what they allegedly allow open governance of.
Oh god I'd forgotten about AMP4Email. It's such a blindingly obvious bad idea, and the GitHub response was overwhelmingly negative. They do not care at all.
> AMP Project is run similar to nodejs by adopting an open-governance model
I won't believe this until I see the tech lead and the committee go from being totally opaque to actually answering direct questions.
So far "after months of research" they can't even provide a description of how working groups are selected, which are the criteria, what exactly they govern and many other things described, e.g. here: https://github.com/ampproject/meta/pull/1#pullrequestreview-...
Or, e.g. they are going to have an AMP4Email working group. For a feature that no one asked for, no one wants, no one was discussed with. How did it get there? Oh "Gmail team said they are going to do it". But yeah, the "Approvers" working group will surely have something to say about this. Riiiight.
This would mean you could have at least a TOFU security model, where a web app that you trust can't be replaced (without you knowing) by an insecure version you haven't seen before.
Add some binary transparency [1] logging on top of that, and it might be possible to make browser-based JavaScript crypto almost as secure as the equivalent desktop app.
[1] https://wiki.mozilla.org/Security/Binary_Transparency