Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

AMP F2F 2019-03-27/28 in London


Day 1


What is the TSC

  • Technical Steering Committee.
  • Inspired by NodeJS style terminology.
  • Responsible for handling project day to day activity.
  • Roadmap, direction. Project management / tech lead distributed throughout a group.
  • TSC delegate to working groups.
  • 3 out of 7 members are from Google for now.
  • Goal is that no more than 1/3 of members are from the same company.

Scope and Role of the AC

  • AC is Advisory to the TSC.
  • Advice is non-binding.
  • AC can provide opinions / advice / findings.
  • Once we have a Foundation, we will have a board
    • AC should be represented on the Board
    • TSC should be represented on the Board
    • The Board will be responsible for finance, IP, and governance
  • AC should advise on Foundation's formation
    • Membership cost
    • Diversity
    • Policies
  • Should AMP be a "sub-group" of W3C?
  • W3C is an SDO (Standards Developing Organization), so probably not right.
  • But probably needs a channel to W3C / WHAT-WG
    • If W3C/WHAT-WG work together, AMP should work with them (but not be a part of them)
    • Liaison with SDOs is part of the AC's mandate.

Membership of AC

  • At the moment a mix of personal invitees, companies which have been working with AMP for a while, and people who signed up.
  • AMP Vision -
    • Right intent but too vague
  • issue meta#9
    • No - AMP AC needs "critical friends"
    • We think that the vision / mission needs works
    • Vision: A strong, user-first open web forever.
    • AI(@edent, @ljwatson): draft an AC opinion on the topic.
    • Once that opinion is drafted and published by the AC, and depending on the resolution of the TSC, the AC will revisit issue meta#9. The current sentiment is that those restrictions shouldn't apply as long as the AC's membership is properly balanced.
  • How do we get more members and more involvement from existing members?
  • Target size of AC is 6 - 12 member.
  • Current size is 16.
  • No fixed size.
  • AC must be representative of different stakeholders
  • Ideally, we'd love for AC members to be elected? In practice, that's impossible.
  • We've received requests from people to join
  • Membership length is 1 year.
    • Members in good standing will be asked to rejoin.
    • Members are under no obligation to rejoin
    • Year starts on Jan, 1st.
    • Members can resign at any time
    • We need a concept of "Good Standing" (see for example W3C's definition), still TBD.
  • AI(@tobie): open a pull request against the AC's work mode document to reflect agreed upon term durations.
  • Current AC members approve any new AC member
    • Consensus based process
    • AC want to ensure a diverse group of representative (diversity of location, thought, industry, gender, disability, race, etc)
    • "It is the AC's duty to ensure the AC is as representative and diverse as possible. When AC membership places are available, AC members commit to proactively reaching out to groups who are not currently represented. AC members will use Single Transferable Vote to select new members in a secret ballot."
    • AI(@tobie): open a pull request against the AC's workmode document to include a description of how new AC members are elected.

Is AMP a product or an Open Source Project

  • Currently the perception is that it is a Google Product.
  • Only Google employees can merge requests for now (plan is for this to move to <33%)
  • Majority or changes are by Google employees
  • AMP Cache is not open source. (Reason: it's too tied to infrastructure to make sense open sourcing it. It couldn't be re-used.)
  • The perception is that AMP is beneficial to Google - not for the open web.
  • AMP needs to be separated - and seen to be separated - from Google. Too much interplay between Search, Browser, and AMP.
  • AC may advise both the TSC (open source) and the wider community (products).
  • AMP must share their user research openly.
  • User research data must be available to the AC/TSC to allow them to make decisions.
  • AI(@edent, @ljwatson): draft a paper on results of user research.

AMP Letter

Discuss AMP Letter in preparation for meeting with signatories.

  • disclosure: 2 members of the AC present are AMP letter signatories.
  • URL Problem
    • Dodgy sites get to use the URL
      • Users find this confusing
      • It is seen as breaking the web
      • This is an unfortunate byproduct of early design decisions
    • WebPackaging being the answer?
      • Not a standard (yet)
      • Not supported in all browsers (Firefox, Safari)
    • Given that the URL problem is a user-unfriendly pattern, and that two major browsers are unlikely to support WebPackaging, the AC needs to provide advice to the TSC on fixing this.
  • Issue with pref search treatment
    • How do we account for web pages "cheating" on performance test? Dieselgate style.
    • You have to use AMP to be in Google News Carousel. Discovery experience. This is perceived as discriminatory.
    • Developers don't want multiple pipelines for their content. They have been incentivised by being at the top of search results.
    • Would like to see a decoupling of AMP and Search results / News.

Meeting with AMP Letter Signatories

Joining the meeting:

Bypassing paywall issues

  • Websites may be abusing AMP to bypass paywalls.
  • Full content is often in the DOM - even when there is a paywall.
  • Would a server-side paywall solution solve this issue? There's a 2 year issue for this.


  • Perceived criticism of AMP is "there are just bugs that will be fixed in time."
  • Failure of imagination of AMP to see the other side of the argument.
  • If you publish on the web, you are the owner of that content and you maintain that address and infrastructure. WebPackaging breaks that link.
  • What happens when a large company insists that you serve their content through them?
  • CDNs lose traffic if others can distribute the content that they have packaged.
  • Is WebPackaging a centralising technology? Content will get served by the fastest provider - or whoever is the referrer.
  • WebPackaging - how do users sign in? How to track? How to paywall? Analytics?
  • Publishers resent being forced to use AMP in order to get premium placement.
  • If a non-Google company made their own AMP (like Baidu MIP) would they get the same placement?
  • Feature Policy seen as a good way to speed things up.
  • Never Slow Mode
  • Prefetch - speeds things up but doesn't protect user privacy. Also means analytics can't tell whether it is a "view" or a "preload".
  • Does WebPackaging support a privacy preserving prerendering mode?

Outage issues

  • How do AMP caches report their outages / uptime?
  • Need to be open to report performance issues
  • AMP product partership team - how do small publishers contact people?
  • How do people contact AMP caches?
  • What recourse do publishers have to the caches?


  • Some clearly voiced concerns that the AC doesn't actually have any teeth and cannot impact the project in ways that would run counter to Google's commercial interests?
  • IETF unconvinced that Google is fully committed to the WebPackaging standard.

Day 2



  • ad-tech primer -> define what the AC's role would be in that space
  • organise verticals in groups (AC/TSC dependant?) issue #5 issue #15
  • foundation update
  • meeting around outreach w/ Ben Morss
  • accessibility + issue #5
  • AMP for email
  • Document AMP architecture + update standard list


  • Tobie gives overview
  • Who is the target membership?
  • How are they going to be contacted? Outreach process.
    • Outreach could be done by the foundation itself
    • Ask AC/TSC membership would they be interested in joining the foundation
    • At what price point?
    • Whether we want the foundation limited to just legal/accounting or include outreach/etc.
  • Foundation should act as a steward for content when / if AMP caches are turned off.

Ad-tech primer / revenue

  • Joe gives overview
  • containerized in AMP (sandbox)
  • system:
    • good doc on the topic in the AMP doc
    • container in the page
    • add server
    • inside the code that comes back from the ad-server
  • As a result: limitations
    • creative
    • data (lower access to targeting data)
  • "Auction"-based ad-style weren't supported at first
  • Ad-network's role: supply/demand aggregator
  • Creative limitations big burden on publishers
  • built on safe-frame
  • benefit from a user's perspective: speed
  • AMP HTML Ads => AMP in the ad itself, served on any kind of Web page
  • Who guarantees the AMP format validity in that case?


See issue #5.

  • Many of the components are not sufficiently accessible.

  • Accessibility tree - usually used by browsers - they understand whatever HTML element does.

    • AMP doesn't rely on native elements enough
  • Media Player is a real concern. Controls show up as list boxes rather than buttons

  • Same kinds of issues for the carousel

  • Some bits are good - like collapsing

  • Is there a process for accessibility checking before a component is added?

    • No - but there needs to be
    • The AC would like to see a process in place by 2020-01-01
  • The AC would like all components to meet WCAG 2.1 before release

  • By the AMP Contributor Summit - produce a roadmap and timetable for raising the existing components up to the expected standard

  • AI(): reach out to TSC/Accessibility WG and ask for audit of existing components.

  • AMP documentation should specifically show how to make elements accessible

  • AI(): reach out to TSC/Documentation WG to ask for related improvements to documentation.

  • AMP Validator should fail pages which do not pass automated a11y tests (100% score on lighthouse?)

    • Byproduct - AMP Caches should not serve pages which do not validate against a11y tools
  • Offer our help to the WG

  • AI(@tobie): organize meeting with a11y WG. Either invite them to AC meeting or join one of their calls.

  • Add horizontal review requirements in the existing process.

  • AI(): author review requirements for a11y. Share them with the TSC/a11y WG.

  • We don't have a clear measure of privacy

  • what are the privacy/security requirements to ship a new feature?

  • AI(): reach out to TSC to ask for list of privacy/security requirements required to ship a new feature.

  • Avoid fingerprinting as a target?


  • Ben Morss joins the meeting over VC
  • Would love the help of more companies evangelizing for AMP
  • Evangelising is essentially about explaining AMP in terms of a Web-component library
  • DevRel direction inside of Google?
    • Small extension
  • Google Sales are incentivising people to use AMP
  • Too few people writing documentation
  • Desire to make it accessible
  • wrt accessibility, everyone thinks it's someone else's job

Organise verticals in groups

See issue #5 and issue #15.

  • Should these vertical groups be AC or TSC dependant?
    • Vertical groups could be AC, while horizontal review is clearly TSC.
  • Goal is to be more inclusive
  • The AC suggests W3C-inspired "interest groups."
    • Open membership
    • Conversations are public
    • How do we create a group?
    • Non-binding advisory role
    • Similar creation requirements as working groups
    • AC responsible? TBD
  • AI(@tobie): update the relevant issues with the AC's proposal.

AMP for email

  • Outcomes?
  • Formal user needs? User research?
  • User needs cannot be well understood by developers without user research
  • Publish the research (suitably anonymised)
  • Needs stakeholder engagement prior to launch: large email player (e.g. university mail server) not made aware of this shipping or how to handle it.
  • Archiving issues with dynamic email
  • Spam? We don't know what preventative measures there are.
  • Spoofing risk?
  • What's the standard for this?
  • What's the privacy mode?
  • What's the architecture?
  • Lack of understanding as to what AMP (designed to improve mobile Web perf) has to do with email ("This is absurd to me").
  • This needs to be an open standard.
  • AI(@tobie): figure out how the AC can learn more about AMP for email.


  • AI(@tobie): how to distribute "findings?"

The Advsisory Committee would like to thank Akamai for hosting the meeting, Vox Media for sponsoring the food, and Google for sponsoring the social event.