Design Review 2017-09-20 (amp-story, allowing the viewer to proxy XHRs, messaging amp-iframe)

[mrjoro]

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

Time: Wednesdays @ 1pm Pacific
Location: Video conference via Google Hangouts

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc 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.

If you are unable to make the 1pm Pacific time due to time zone issues but you have a design you would like to present please make a note of that and we will try to find a time that works.

[newmuis]

I'd like to present a proposal for stories in AMP (#11329).

[dreamofabear]

Bumped from last week, messaging amp-iframe: #9074 (comment)

From @zhangsu, allow viewer to proxy XHRs: #11294

[mrjoro]

amp-story

• are stories already achievable with AMP?

  • probably, if you tried hard enough :)
  • navigation through the story would be tricky to create
  • maybe you could leverage amp-carousel but then you're more tied to its interaction model
  • stories are becoming an entity more generally, so it makes sense to represent that in AMP

• does it work on desktop & tablet?

  • we are thinking through how to make it responsive
  • there will be a 3-up view with current view, previous & next
  • won't require additional markup

• how does this work in terms of validation?

  • all of these new tags will need to be whitelisted in the validator; those changes are coming soon
  • as the changes make their way into the amphtml repository we'll need to make the change in the validator

• are all stories valid AMP documents?

  • the only requirement is having the extension and having the "standalone" attribute on the amp-story tag
  • at the moment this would keep you from having other stuff in the body of the document
  • there's no indication in the tag (unlike A4A)
  • with this model you could in the future support multiple stories in the same page / relax the requirement that there not be other stuff in the body

• is it purely linear navigation? no way back/etc.?

  • you can navigate forwards & backwards; right-most 75% to go forward, 25% to go backward
  • at the moment we only support linear navigation
  • but we are thinking about branching, similar to carousel's ability to "go to slide X", e.g. to support quizes

• sounds like a full screen AMP carousel with CSS grid support; should this be decomposed into adding CSS grid support to AMP? this feels more prescriptive than other parts of AMP

  • we wanted to make it very easy for people to build these
  • we also wanted these to have a consistent user experience (e.g. the "click on the right 75%), which also has the benefit that integrating services can understand what a story is--e.g. if you're in browse mode and to look through multiple stories, services could build that

• can users provide their own templates?

  • you can use the grid-template CSS property on the amp-story-page tag, then use the grid-area attribute with their own named areas... but this is not currently supported because we enforce the template parameter
  • you can combine the templates in the spec to create new ones

• why does bookend need a custom way of loading stuff, why not just use amp-list?

  • we wanted it to be JSON based so publishers can re-use their lists of recirculation articles
  • main reason was that we found it to be very boilerplate; people were generally using the same format for each story, so this is a shorthand for it
  • but we should consider whether to let people specify it in the DOM

• if people already have a story platform that has all of the stuff they want, there's a good chance they have the data for it in JSON... so could you use amp-list to generate the stories?

  • we have a preliminary implementation that assumes amp-story-pages are direct decendents
  • but we could relax this restriction in the future

• if you have to start writing HTML to edit this, then you may lose a significant part of the audience

  • it may make sense to build a GUI/WYSIWYG tool for this?
  • that's definitely not out of the question for someone to create
  • but we should nail the format down first

• RTL support?

  • no internationalization at the moment, but we should tackle it
  • but if you just require the document to be explicit about the attribute in the html element (e.g. the "75% right to go forward)

• by having a prescriptive navigation layer it limits what you can do on the page (e.g. playing videos)

  • from a technical perspective it's not an overlay div; we do some click detection/math to achieve it
  • what is the user expectation? if I click somewhere on the screen is it a link or a system navigation? the choice we've made so far is to leave it publishers to be very explicit with their design choices--they'll still have the ability to put tappable things on the page and receive the click event, so they'll need to be aware of the convention to click forward

• if people have questions, comment on the design issue, or click on https://bit.ly/amp-story-spec

[mrjoro]

Allowing the viewer to proxy XHRs

• our current viewer trust concept is not strong enough to warrant a "god-mode" capability like this, so this should require document opt in (i.e. the document says "I am fine with my XHRs being intercepted by the viewer")

  • we could make it so the opt in isn't valid AMP; the use case for this is primarily a fully controlled situation where the viewer trusts the creator of the document, i.e. the "document delivery engine", e.g. the AMP Cache injects this non-AMP-valid thing that a viewer that trusts the AMP Cache looks for
  • big threat model is when there's a random document in the wild and you force it to have this
  • maybe the viewer cryptographically signs the request to trigger this when it loads the document

• how would this work for the use case of hiding the IP address?

  • the viewer itself cannot make the XHR call to hide the IP address; there's a server-side proxy to handle it
  • why not just have the AMP document talk to the proxy server? (why does the AMP viewer opt the AMP document into talking to this specific document); it's really the viewer that wants to protect the user not necessarily the document

[mrjoro]

messaging amp-iframe

• unlike the postMessage API, we should require the origin; you almost never want to send a message to someone you don't know who they are (and since you constructed the iframe yourself this is especially true)
• the iframe might have been navigated so we don't want to send the message to any iframe
• plan is to only allow this for src containing an origin (no srcdoc, no data protocol), and then force target origin to match; this sounds reasonable but we should double check with security experts
• does the postMessage itself as an action require higher trust?
  • yes
• calling the event postMessage would have made sense for the standard, worth considering us calling it message to match the standard
• we can use polyfill to ensure certain techniques for ensuring user action in the iframe (like we allow changing the size only if you have focus); browsers may support this natively in the future
• the concept of having scoped data changes is a little bit unclear
• do you need a return message from the host page?
  • generally the messages are pretty simple so you probably don't need it