Resigning from the AMP Advisory Committee

openasocket 2021-08-18 21:44:57 +0000 UTC [ - ]

> We were immediately told that we could not discuss an ongoing court case in the AMP advisory committee. That’s fair enough. But will it go both ways? Or will lawyers acting on Google’s behalf be allowed to point to the AMP advisory committee and say, “But AMP is an open source project! Look, it even resides under the banner of the OpenJS Foundation.”

Google's lawyers will most likely do something like that, though . But there's nothing stopping you from contacting the prosecution and offering testimony against the claim that AMP is open source. Unless the AMP advisory committee is somehow considered a party in the lawsuit? Though even then, depending on how the committee works, I don't think they could ban you from communicating with the prosecution.

Actually I'd expect members of the advisory committee to be deposed. The prosecution explicitly mentions the AMP committee in their suit: "Although Google claims that AMP was developed as an open-source collaboration, AMP is actually a Google-controlled initiative. Google originally registered and still owns AMP’s domain, ampproject.org. In addition, until the end of 2018, Google controlled all AMP decision- making. AMP relied on a governance model called “Benevolent Dictator For Life” that vested ultimate decision-making authority in a single Google engineer. Since then, Google has transferred control of AMP to a foundation, but the transfer was superficial. Google controls the foundation’s board and debates internally" . Both Google and the prosecution will likely depose members of the committee to get testimony regarding those facts.

ohazi 2021-08-18 20:14:40 +0000 UTC [ - ]

> So it’s best for everyone if I step away now instead of descending into outright sabotage.

It's best for other members of the committee, and perhaps for the sanity of the author, but I think you could make the argument that effective sabotage of the AMP project could actually be best for the public at large.

kevin_thibedeau 2021-08-18 21:03:52 +0000 UTC [ - ]

Why would Google take advice from non-employees? Committees like this only serve to shield Google from criticism. They aren't meant to accomplish anything.

throw_m239339 2021-08-18 21:39:50 +0000 UTC [ - ]

I don't like AMP. However, if I wouldn't use a mobile browser which didn't basically do the same (MITM websites), my DATA plan would be over by the fourth day of the month.

The mobile web, after all these years, is still so heavy.

No, devs don't need all images to be for retina display, they don't need to bundle 50 MB of JS on ever pages, they don't need to load custom fonts for text, auto start videos, ... then why are webpages still so big on mobile? What happened to mobile first? Seems to me like it's just native app first on mobile then some amount of responsiveness for desktop websites...

what happened? I'm not willing to visit or spend money on a website that drains all my data plan while I'm browsing for products...

For all the SEO tricks websites use to drive traffic, it doesn't seem like mobile page speed is relevant in anyway when it comes to SEO or we would have a very different web...

donohoe 2021-08-19 17:07:43 +0000 UTC [ - ]

To be clear, AMP pages are often the same size as regular webpages. Often they can be much much heavier.

ohazi 2021-08-18 22:08:22 +0000 UTC [ - ]

Firefox mobile allows you to use uBlock origin, which improves things tremendously.

Every time I accidentally end up in mobile Chrome, it's like being transported back in time 15 years with popups and overlays and modals that are deliberately designed to lag just enough for you to accidentally click on the ad rather than the tiny X button.

What happened? Google happened.

The mobile web is essentially the desktop web before ad blockers, and Google won't allow mobile Chrome to support extensions because "oh no, extensions are hard" -- they're lying. They know that a mobile ad blocker is the easiest and fastest way for us to hide their toxic cesspool of mobile ads.

dreamcompiler 2021-08-19 00:13:06 +0000 UTC [ - ]

Has anybody done an objective comparison between AMP vs a good adblocker (e.g. PiHole) w.r.t. how much bandwidth they save? I'd expect adblockers are as effective if not more.

albertgoeswoof 2021-08-18 22:09:54 +0000 UTC [ - ]

That’s only a problem in countries with poor network infrastructure, most developed countries have unlimited data plans at reasonable costs

throw_m239339 2021-08-18 23:21:08 +0000 UTC [ - ]

> That’s only a problem in countries with poor network infrastructure, most developed countries have unlimited data plans at reasonable costs

This is false, I live in Western Europe. Data cap is 50GB for a 30€ plan. This is farcry from "unlimited data plan" and there is 4G everywhere.

chrischen 2021-08-18 23:56:18 +0000 UTC [ - ]

I'm a pretty heavy mobile user and my Safari is reporting 1.9gb used last month (a travel month where I was on 5G most of the time). The biggest user wasn't web content, but apps like Spotify that used 5.5gb in the month. Even if web/Safari uses a lot of data, at the end of the day if you stream rich content like videos or audio, that will always outpace web content. So if a mobile plan with a data cap can't support web content then there's no hope of streaming Netflix...

frosted-flakes 2021-08-19 00:02:54 +0000 UTC [ - ]

50 GB is effectively unlimited though, and for incredibly cheap. I would have to really try to use that much data on my phone. I have a 20 GB plan in Canada for much more than that, and have never exceeded 10 GB of usage. Up until about 3 years ago, I had a 500 MB plan for the same price, and still got on fine.

tasogare 2021-08-19 01:51:19 +0000 UTC [ - ]

I'm living fine with a 3GB data plan (yes 3, not 30). It's only problematic if using tethering otherwise I have hard time understanding how people can consume more data just by browsing the web. Too much adult movies maybe?

kazinator 2021-08-19 02:06:55 +0000 UTC [ - ]

1.5Gb here. I can self-adjust that month by month. I had more but I down-regulated it since I wasn't using it. It was a waste of money.

Sitting there streaming video content is a nonstarter just from a battery life point of view alone; I wouldn't do it even on Wi-Fi.

Speaking of which, 1.5Gb is enough that I don't bother looking for Wi-Fi hotspots.

The mobile plan is such that if it goes over the cap, it will just stop, rather than incurring extra charges. So until it stops, why would you mess with Wi-Fi.

forcemajeure 2021-08-18 22:13:57 +0000 UTC [ - ]

Not true in Australia

8ytecoder 2021-08-18 22:29:38 +0000 UTC [ - ]

Again as the OP said, “ That’s only a problem in countries with poor network infrastructure”.

Australia is a victim of its geography. (Plus last I heard the National fiber backbone didn’t go as planned either). I’m would expect a high bandwidth wired backbone is required to support scaling up mobile data throughput.

shakna 2021-08-19 00:21:09 +0000 UTC [ - ]

Whilst Australia's NBN rollout was plagued with problems, in the end I would say it did go as planned - the design, as implemented, was intended to be crap. It was outdated when it was conceived, and could not possibly serve the country for the next thirty years as it claimed.

throw_m239339 2021-08-18 23:20:33 +0000 UTC [ - ]

Still not true and I live in Western Europe. Data cap is 50GB for a 30€ plan. This is farcry from "unlimited data plan".

j-bos 2021-08-18 23:45:43 +0000 UTC [ - ]

Or for poor residents of developed countries.

gregable 2021-08-18 22:02:04 +0000 UTC [ - ]

I won't try to address every part of this writing, but there is one claim that I feel is false: namely that the AMP validation rules are not open source.

Here is the code: https://github.com/ampproject/amphtml/tree/main/validator

All of the rules are written in human-readable config language. Here are the rules for common HTML elements (https://github.com/ampproject/amphtml/blob/main/validator/va...) and there are rules per-amp-tag (example: https://github.com/ampproject/amphtml/blob/main/extensions/a...)

You can build it, run it locally, etc. There are open-source implementations that run in the browser, in a vscode plugin, on the command line via NPM, etc. Other entities can and do use the same code for their validation of AMP. Pull Requests are accepted from anyone and those changes land in Google production and all of the aforementioned tooling targets within a few days. There is documentation on how to contribute to and edit these files (https://github.com/ampproject/amphtml/blob/main/docs/compone...).

tyingq 2021-08-19 02:15:08 +0000 UTC [ - ]

The real important part of AMP that isn't open source is this, from the AMP HTML Specification[1]:

  Required markup
  AMP HTML documents MUST
  ...(some deleted)
  - contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag.

That's the magic that allows google to inject the AMP header onto the top of your page, hijack the back button / left-right swipe on your page, etc, when someone visits your page from the carousel. It's hard to call something open source when the spec says "You must include this javascript url (and therefore, code) that you don't control". And the validator does seem to make sure it's there.

[1] https://amp.dev/documentation/guides-and-tutorials/learn/spe...

dmitriid 2021-08-18 22:15:43 +0000 UTC [ - ]

> namely that the AMP validation rules are not open source. Here is the code

Yes. That's the trick big corps play on you. They develop some code, and push it to GitHub.

- all of the decisions where the code is going belong to the corp

- all (or at the absolute vast majority) of contributions come from the corp's developers

- there's little to no insight into why things are the way the are. Sometimes you can be big enough to gain acces, or important enough. Before "open governance" it was some publisher group set up by Google that was supposedly there to monitor

But sure, it's open source.

> Pull Requests are accepted from anyone and those changes land in Google production

1. What's the ratio of PRs from Google employees to those from "anyone"?

2. Indeed. They land in Google production. The company with $183 billion in yearly revenue thanks you for your unpaid contributions (if they ever make it)

---

BTW, there are 1 500 open issues in that repo. Quite a lot for some validation rules.

gregable 2021-08-18 22:30:00 +0000 UTC [ - ]

I did some hacky analysis and roughly half of the PRs originated in GitHub and the majority of those are not google employees.

Most changes have a github issue attached with discussion, all of the changes have descriptive commit messages regardless of who authored them and there is significant effort to document the decisions and decision process throughout.

I can't speak for the release frequency for other organizations' production that consumes this code. That includes many publishers, as well as other AMP caches such as Bing and webmail clients like Yahoo.

The repo is for all of AMP, not just the validator. The validator related issues are handled by the "caching" working group (since caches are the consumer of the validator) and you can search for them with this query: https://github.com/ampproject/amphtml/issues?q=is%3Aissue+is...

dmitriid 2021-08-19 06:20:51 +0000 UTC [ - ]

> PRs originated in GitHub and the majority of those are not google employees.

How did you figure that out? There are people don't list their company, but their only activity on GitHub is contributing to AMP.

Some people don't list Google, but are a part of the AMP org on GitHub.

> all of the changes have descriptive commit messages

Please show me all the open decisions that introduced AMP for email.

(hint: you can't)

As I mentioned in a sibling comment: why are people so surprised that it's Google's product driven by Google's own needs?

jsnell 2021-08-18 22:32:45 +0000 UTC [ - ]

You're simultaneously complaining about how all the commits are coming from the company and that they're exploiting anyone making commits. You can't have it both ways, pick one.

The repository has 1k contributors over 20k commits. That seems like an exceptionally diverse contributor base.

dmitriid 2021-08-19 06:14:52 +0000 UTC [ - ]

> The repository has 1k contributors over 20k commits. That seems like an exceptionally diverse contributor base.

Go to the contributor tab and look at main contributors. It's entirely a Google-driven product.

Why is this a surprise to anyone? Because it's on GitHub?

thepangolino 2021-08-18 19:53:46 +0000 UTC [ - ]

I really never got the point of AMP being anything else than a set of recommendations for lighter mobile pages. A sort of remnant of the time where you got redirected to another version of the website you were visiting if you were doing so from a mobile device.

rakshazi 2021-08-18 21:09:07 +0000 UTC [ - ]

The ironic part of AMP is that it's heavely relies on js. External js.

For example, you have a lightweight website with size of 140kb for everything (html, CSS, js, images) without AMP. It works blazing fast and you get 100/100 scores on any website speed meter.

But it was not enough for google, because you don't use their super-duper AMP tech.

You known what? Your website doubles in size when you implement AMP, because you must load several additional scripts to make AMP work, and not only size increases, load time (from click on your website link till full render) will increase too, because additional js processing to make AMP work.

The only benefit was preloading and heavely caching by Google, so user feels like website shows instantly.

I "optimized" several lightweight websites with AMP and every time I had exactly one thought in mind - that's useless stuff adds more problems than benefits, except mobile search ranking.

Thanks God now AMP is not mandatory to be in google mobile search top

esprehn 2021-08-18 21:26:48 +0000 UTC [ - ]

Do you have some examples of sites where the regular site is faster than the AMP one?

2021-08-18 21:41:54 +0000 UTC [ - ]

dbbk 2021-08-18 22:48:10 +0000 UTC [ - ]

Literally anything that doesn’t use JS and is CDN cached?

esprehn 2021-08-18 23:42:48 +0000 UTC [ - ]

Do you have real world examples of that though? Nearly every real world news, facts, recipe, cooking blog, etc I can find loads huge amounts of JS.

Ex. Here's Snopes: https://www.webpagetest.org/result/210818_BiDcQB_f0db4233292...

For sure a static site is faster than AMP, but I'm pretty sure AMP is faster than most sites regular folks visit on a daily basis.

lwansbrough 2021-08-18 23:50:57 +0000 UTC [ - ]

You’re using one right now.

esprehn 2021-08-19 03:55:39 +0000 UTC [ - ]

For sure hacker news is pretty light weight, but it also seems they didn't feel any pressure to use AMP (and also have historically not cared about SEO).

pornel 2021-08-18 20:56:48 +0000 UTC [ - ]

The AMP project allowed Google to dictate how ads can be served, and host publishers' pages themselves. Don't forget Google is a tracking-based advertising company.

It was very convenient that these things could be bundled in a package with some webdev best practices, a JavaScript framework, and marketed as a (questionable) speed improvement.

I've worked for a publisher that abandoned serving their own fast no-JS article pages in favor of half-assed AMP pages full of slow iframes, because Google favored any use of AMP over actual page speed. It took Google many years to ease that AMP favoritism.

vasachi 2021-08-18 20:03:16 +0000 UTC [ - ]

The point is to prevent user from leaving google.com.

heurisko 2021-08-19 07:08:10 +0000 UTC [ - ]

I also remember that if you also tried to share the webpage, it was awkward to try and get the non-AMP page, taking the other user to Google.com.

SevenSigs 2021-08-18 20:47:43 +0000 UTC [ - ]

The main problem with AMP is that everything loads from Google's servers... so it is not worth using even if sometimes it can be faster (Google itself should probably use it instead of their javascript mess that slows down everything for no reason).

DrBenCarson 2021-08-18 20:13:06 +0000 UTC [ - ]

The point is Google keeps users captive and content publishers hostage. All for a glorified CDN serving “light” static pages.

2021-08-18 21:11:00 +0000 UTC [ - ]

dmitriid 2021-08-18 22:02:56 +0000 UTC [ - ]

AMP was first and foremost an answer to Facebook's Instant Articles (or whatever they were called), and, as an extension, a death grip on publishers.

Everything else in AMP served that.

PedroBatista 2021-08-19 01:05:15 +0000 UTC [ - ]

This whole thing is a ruse.

These "committees", "work groups", "boards" and even the "foundations" are just ways to legitimize things that tend to be illegitimate.

Every dictatorship has a "parliament", "courts" and a "constitution", there is nothing new or original about this AMP ordeal.

SquareWheel 2021-08-18 22:41:26 +0000 UTC [ - ]

I'd be curious if there has been any effort made towards encouraging wider use of the Amp Cache. After CloudFlare dropped theirs, now only Google and Microsoft maintain an Amp Cache.

Large search engines are probably the primary audience for that technology, so would there be interest from Baidu or Yandex?

jsnell 2021-08-18 23:06:02 +0000 UTC [ - ]

Twitter still runs one, right? In general it'd make sense for any app where link sharing is a major use case. Reddit, for example.

It'd also make sense for Facebook and Apple, except they have their proprietary formats for exactly the same use case that people have no problem with (Facebook Instant Articles and Apple News). So not a lot of incentive to switch.

gregable 2021-08-18 23:34:52 +0000 UTC [ - ]

My memory (might be incorrect) is that both Twitter and LinkedIn use the Google cache directly, rather than running their own.

jsnell 2021-08-19 00:52:06 +0000 UTC [ - ]

Thanks, looks like you're right.

skybrian 2021-08-18 21:48:42 +0000 UTC [ - ]

He seems disappointed but it sounds about what I’d expect from an “advisory committee.” I would expect giving advice to be a form of influence rather than power. You’re only as good as your persuasive skills and their willingness to listen.

MrStonedOne 2021-08-18 22:18:38 +0000 UTC [ - ]

I'm gonna re-post the rant I posted last time this came up:

> As a mobile user, I hate it.

> I hate that every fucking google search result on mobile web has its stupid little icon

> I hate that there is no way for me to disable it as a user

> I hate that it has muddied the waters in what the url bar means

> I hate that it has trained users to not question fake url bars.

> I hate that cloudflare so thoroughly jumped on its dick

> I hate that we invented a way to fake the address in the url bar just for this stupid fucking feature.

> I hate that we now have a system where somebody can share a page url with a friend, and that friend can view it on the same device model using the same browser with the same settings, and will get a different page because one was viewing an amp page but shared it's real url.

> I hate that every fucking amp page is lower featured in some way, and almost never works in desktop mode.

> And most of all, I hate that it leads to everybody offloading shit onto google's servers.

> AMP is not fast because it's served from google's CDN. AMP is fast because it's incompatible with 99% of the bullshit client cpu heavy tracking and ad libraries, so they don't get included inside AMP pages.

junon 2021-08-18 23:45:22 +0000 UTC [ - ]

Agreed with all of your statements but would love some links to prose or examples of your last point.

josefrichter 2021-08-18 22:25:38 +0000 UTC [ - ]

Btw it’s Potemkin, not Potempkin

redis_mlc 2021-08-19 10:39:28 +0000 UTC [ - ]

I laughed off AMP when it was announced, and I'm glad I did.

Before and after AMP I've been using static HTML for homepages - can't get any faster, compatible across any device. Bam!

stefan_ 2021-08-18 20:22:32 +0000 UTC [ - ]

This is a bit embarrassing. You joined the committee when AMP was already dead in the water and even now it seems this has not been made to clear you.

SevenSigs 2021-08-19 01:08:07 +0000 UTC [ - ]

even if you are telling the truth, you are being downvoted for talking bad about a specific individual... have my upvote.