Design Review 2021-10-27 20:00 UTC (Americas)

[github-actions[bot]]

Time: 20:00 UTC (add to Google Calendar) Location: Video conference via Google Meet

The AMP community holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc or issue by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[apatronl]

I would like to discuss adding a volume attribute in amp-video for use in web stories #36381

[processprocess]

I would like to discuss template rendering in amp-story-shopping.

[AnuragVasanwala]

I would like to discuss regarding I2I: ✨ Create Bento Components for Advertisement #35989 I have prepared a proposed plan and would like to discuss about the feasibility and possible suggestions/correction.

Hello folks, we are going to revisit this component and it might change so we will discuss this in next design review meeting.

[summercms]

I would like AMP-HTML team to discuss and explain the following leaked information:

Google uses its scale in search to punish publishers that use header bidding.
245. Google also started using its economies of scale in the search market to strongarm
publishers and advertisers to stop using header bidding and re-route trading through Google’s ad
server. Header bidding is only possible if publishers can insert JavaScript code into the header
section of their webpages. To respond to the threat of header bidding, Google created Accelerated
Mobile Pages (“AMP”), a framework for developing mobile web pages, and made AMP
essentially incompatible with JavaScript and header bidding. Google then used its power in the
search market to effectively force publishers into using AMP.
246. 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
Case 1:21-md-03010-PKC Document 152 Filed 10/22/21 Page 94 of 173
90
domain, ampproject.org. In addition, until the end of 2018, Google controlled all AMP decisionmaking. 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 whether AMP communications should come from Google or the
Google-controlled AMP board.
247. Google ad server employees met with AMP employees to strategize about using AMP
to impede header bidding, addressing in particular how much pressure publishers and advertisers
would tolerate. First, Google restricted the AMP code to prohibit publishers from routing their bids
to, or sharing their user data with, more than a few exchanges a time, thereby severely limiting
AMP’s compatibility with header bidding. However, Google made AMP fully compatible with
routing to exchanges through Google’s ad server. Google also designed AMP to force publishers
to route rival exchange bids through Google’s ad server so that Google could continue to peek at
their bids and trade on inside information. Third, Google designed AMP so that users loading AMP
pages would directly communicate with Google cache servers rather than publishers’ servers. This
enabled Google’s access to publishers’ inside and non-public user data. AMP pages also limit the
number of ads on a page, the types of ads publishers can sell, and the variety of enriched content
that publishers can have on their pages.
248. After crippling AMP’s compatibility with header bidding, Google went to market
falsely telling publishers that adopting AMP would enhance page load times. But Google
employees knew that AMP only improves the “median of performance” and AMP pages can
actually load slower than other publisher speed optimization techniques. In other words, the
ostensible benefits of faster load times for a Google-cached AMP version of a webpage were not
Case 1:21-md-03010-PKC Document 152 Filed 10/22/21 Page 95 of 173
91
true for publishers that designed their web pages for speed. Some publishers did not adopt AMP
because they knew their pages actually loaded faster than AMP pages.
249. The speed benefits Google marketed were also at least partly a result of Google’s
throttling. Google throttles the load time of non-AMP ads by giving them artificial one-second
delays in order to give Google AMP a “nice comparative boost.” Throttling non-AMP ads slows
down header bidding, which Google then uses to denigrate header bidding for being too slow.
“Header Bidding can often increase latency of web pages and create security flaws when executed
incorrectly,” Google falsely claimed. Internally, Google employees grappled with “how to
[publicly] justify [Google] making something slower.”
250. Despite the speed benefits Google falsely touted, publishers did not want to use AMP
because AMP pages caused their advertising revenue to decline: publishers make less money
selling advertising on AMP pages than they do on their regular web pages. AMP also degraded
quality by restricting content and ad types.
251. Just as publishers have the freedom to make their webpages mobile or desktop
compatible, publishers still have the freedom to decide whether to build their pages using the AMP
framework. However, Google uses its scale in search to punish publishers that do not chose AMP.
Specifically, Google Search ranks non-AMP pages lower in search results and reserves the top
placements in the “Search AMP Carousel”—the top search results placements with pictures—to
publishers using AMP.
Case 1:21-md-03010-PKC Document 152 Filed 10/22/21 Page 96 of 173
92
Google search results for “Dallas Cowboys”; AMP results are displayed in the carousel along
the top:
252. Google gave publishers a Faustian bargain: (1) publishers who used header bidding
would see the traffic to their site drop precipitously from Google suppressing their ranking in
search and re-directing traffic to AMP-compatible publishers; or (2) publishers could adopt AMP
pages to maintain traffic flow but forgo exchange competition in header bidding, which would
make them more money on an impression-by-impression basis. Either option was far inferior to
the options available to publishers before Google introduced AMP. Just how inferior? According
to Google’s internal documents, 40 percent less revenue on AMP pages. 

Court documents: https://storage.courtlistener.com/recap/gov.uscourts.nysd.564903/gov.uscourts.nysd.564903.152.0.pdf Parts 245 -252

Question: If a webmaster removed AMP-HTML from their website design and moved to a different framework - will Google lower their search engine rankings?

---

Google AMP Project Design Goals:

1. Create and allow a Header Bidding extension.
2. Allow developers to use other open source frameworks without lowering their Google SEO search rankings.
3. Release a full statement addressing these concerns.
4. The AMP steering committee to be made up of less Google employees and become a real open source project.
5. Google is totally lying telling people serving a cached version of their websites on Google servers is improving performance! The truth in the court documents clearly saying Google is only doing this to create a monopoly on analytical data - which is used for Google's Ad Networks. The AMP-HTML project should give developers an option to opt-out of having their websites cached on Google servers and allow webmasters to have complete control over their analytical data! This is breaking EU GDPR laws.

[kristoferbaxter]

Takeaways

1. volume attribute in amp-video looks great: but we want to delay allowing volume to be 0 until we have some performance data to understand the impact of shipping a video with audio that is not intended to be presented.
2. template rendering in amp-story-shopping: investigate using JSX instead of amp-mustache.
3. Create Bento Components for Advertisement: Delaying until next week for more data.