Design Review 2017-06-21 (action trust levels)

[mrjoro]

Note that we will not have a design review the week of June 28, 2017.

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.

[dreamofabear]

I'd like to sanity check our current spec for action trust levels. Context: #9954

Questions:

• Allow un-muting video from checkbox/radio toggle? Perhaps bump those events to high and navigateTo to super-high?
• Allow amp-bind mutations without relayout on low trust events?

[mrjoro]

• video case: should desktop behave the same as mobile? on mobile can unmute/play and it won't have an effect without user action (based on browser control); we should defer to browser behavior here
  • would this change current behavior? depends on browser implementation so we'd have to look into it
  • we can make it more strict than the browser but not less strict (because the browser just ignores you)
  • e.g. not allowing video play on submit success, it seems reasonable ("thank you for buying my product!" video)
    • but will this create a disruptive experience? should we limit it to e.g. muted video? (but browsers allow playing an unmuted video on user action, so it seems like we should allow it)
• play is a low trust action if the video is muted, making video support more complex
• navigate and go back should be bound to user actions
• currently "happening in the context of a user action" is essentially implemented via a timeout in the browser (not by specification, but by implementation)
  • one idea is a token based approach (get a token when a user interacts and you can pass it around, perhaps even between pages--which would allow e.g. if you play a video on a page and navigate to another page, you should be able to start playing the video on the next page); browsers probably won't do this any time soon (if at all) but we could implement a similar idea
  • we should avoid timers if at all possible
  • token would allow something like different logic based on form submit success; form can do a redirect on success, but maybe you want to be able to do other logic based on form response and choose whether to navigate or not (e.g. wait for an error from the server and show a custom UI, else navigate)
  • should "video end" inherit what the abilities granted by "played video"; no they are tied to an event
• we've tried different ways of determining "was this generated by a user action" (e.g. try to play an invisible video)
• if bind changes a checkbox, do we trigger a change event? since bind is always triggered by user interaction it should
• trust as a proxy for user expectation; there are things that we might allow because we trust it, but it might be disruptive to the user (e.g. playing an unmuted video after form submit is allowed, but may be disruptive)
  • if I put my finger on a screen or put my finger on a keyboard, then you get to play a video (doesn't matter if there was a checkbox, form submit, etc. in between); abuse risk is low because it still depends on user action
  • we have to decide where we want to be more strict than the browser; we should categorize the actions can only happen based on user intent and whether the events indicate user intent
• the initial user intent should carry through, e.g. if a form submit happens based on scroll event the form submit doesn't carry forward user intent, whereas form submit on click would carry forward user intent
  • instead of low/medium/high, let's just use "comes with user intent" and "doesn't come with user intent", click is the former, scroll event is the latter
  • some things felt like they fell in between which is why we had the "medium" before
  • for the events that indicate user intent, it's basically "intentful tap" and "intentful press/click"; there are no actions that we wouldn't allow based on intent
  • with this, navigation could happen based on carousel slide change (since that's a user press), which was part of the reasoning for having "medium" before
  • @choumx will discuss with @ericlindley-g before making changes to reduce granularity
• actions vs. attributes could cause different levels of trust, e.g. for sidebar we say the action to open it requires user intent, but it can also based on an attribute which can be set via setState
  • will setState require user intent?