Web Intents minutes 8/10/2011

[Sheridan Rawlins]

8/10/2011

Attendees: Mike Hanson, Tyler Close, Sheridan Rawlins, Greg Billock, James Hawkins

Proposed Agenda

• ➡ Go over agreement list from 7/27 mtg.
• ➡ Discuss standardization next steps. (over lunch).
• ➡ Continue discussion how to get into and out of intents (markup v. registry, callbacks, etc).
• ➱ Service mediator - can UA’s be free to develop (addon, extension, etc)?
• ➱ Document and discuss remaining open issues necessary for initial draft API.
• ➱ Open discussion.

Agreements

• [James] Attaching to a working group: Posting RFC in the WebApps working group. Will reach out to Ian Fette to get details on getting it started.
• Need 2 post methods - postResult(), postException().
• James: This was an idea for solving the login problem, but we did not agree on this solution (and it’s not necessary for initial draft).
• Ready for RFC webapps working group with today’s changes.

Followups

• For security discussion, what does UI look like for Intents fired from iframed content?
• Intent from an iframe - what does it look like to users to know that it’s unspoofed.
• Persistent data case?
• By delivering ports, enabled ongoing communication chain.
• Does UA provide the ability to send several RPC’s to same provider - Zimbra should be able to have permanent use of google contacts, e.g.
• [James] Talk to gmail about login problem.
• Go back to use-cases and code it up with window.getIntent()
• Can we make it work with gmail & twitter.
• Does it work for mobile safari with shim?
• Security considerations for browser(s)?
• Strawman secure shim to inject/callback intent.
• James: talk to Paul about not doing addEventListener
• James: update doc with postSuccess/postFailure as well as callbacks to client.

Discussion

• Lunch:
• Do we need to discuss the need for UA to support login so that there is a path forward when a provider authentication is stale or non-existent.
• Tyler: what do we do with intents that are fired from iframes?  How do we give notice to user that a sub-frame is requesting the intent?
• Mike: if we’re getting Intents involved in login flows, do we reintroduce click-jacking in some way?
• Should we have a visual popup of sorts, pointing to the iframe in question.
• Mike: may be bikeshedding about the name of Intents v. Activities, will table for this discussion :)
• Invocation:
• Mike: if page has event microdata, can the page/UA pass it on to an intent which handles that type?
• If infrastructure is in place (addon/extension) then UA can rewrite/map to intents.
• Mike: one concrete case for UA would be if you have an image, right-click and see a context menu for intents you can fire on it.
• James: possibly doesn’t scale for UA handling this, but there are some common types, which we can handle.
• James: event listener or callback, what if there is a significant delay in displaying content based upon whether you’re an intent or not.
• Mike: activities suggests that destination/URL is unique for handling that intent, so that it knows that it’s for intents.
• Mike: seems to be bias from Chrome to have one page with many intents, and for FF to have many separate pages; one for each intent/activity.
• Mike: will each instantiation instantiate a new context?
• James: yes.  app is responsible for saving state if it needs to; will be new context.
• Mike: could have new disposition of “go to singleton context”...
• Greg: are there JS people who will be resistant to putting things on window object (since it’s the implicit global - if you say var intent, it overrides window e.g.).
• Mike: we put it on the navigator object.
• Tyler: navigator exists in worker threads, so do we fork the API and provide a different one for visible contexts vs non-visible ones?
• Mike: maybe allowing webworkers fire intents wouldn’t be a bad thing...
• James: issues with registerHandler
• when you call registerHandler do you have to notify the system?  What if the system has already onloaded, but hasn’t called register.
• James: race condition - how do we solve this?
• When UA has data, but provider isn’t ready or client hasn’t given data, how do we allow async js activities?
• James: you should be able to call registerHandler anywhere and it should be able to handle; no constraint on calling before onload.
• Mike: felt weird to see state passed in window object, but realized that we really are writing a pipe utility in javascript.  eventhander registry felt more natural from a JS developer point-of-view.
• James: Like the explicitness of delivering payload as soon as you get there - you open a new context, and as soon as you start running, you can do stuff with it.
• Mike: window.intent depends upon security of nobody can set window.intent.
• Mike: having a closure/callback “makes me feel good”.
• Greg: with event model, if I got iframed, how would I know that someone sent me a bogus event?  What shielding is available in event handler.
• Mike: there was quite a bit of time to get postMessage correct?
• James: are we relying on some contract from UA to ensure that the event cannot be spoofed/hijacked - answer: yes.
• Greg: if someone could frame you and set window.intent, then it’s game over - can spoof anything.
• Mike: two scopes of persistence:
• persistence of connection/context.
• persistence of choice of provider.
• User would like to initiate connection to n providers.
• James: if you do want to do that, there could be a meta provider which shoots to all of the other providers. If UA comes up with a solution for selecting/interacting with multiple providers, it shouldn’t change the API - is doable.
• James: started with registerHandler,
• Mike concerns for invocation implementation:
• performance
• developer ergonomics - how easy to shoot in the foot
• UA-implementation complexity
• James: preference of priorities devel ergo, performance (no jank) then UA-implementation.
• Mike: RE: ua-implementation, don’t want to do anything which means can’t get into mobile-safari at some point.
• James: Should find go-nogo’s before too late, so can remove UA-implemenation as a governing factor.
• Greg: if there is a strong security-problem, could be a no-go, but UA’s should be able to react quickly
• James: for ergonomics, window.intent seems to be the least for developers to do, but needs a switch.
• Mike: example code doesn’t check the code - just shoves the data into an href.
• James: if you register a page to handle something, you should get what you expect.
• Greg: if you register a handler and nothing happens, how do you know?  Timeout?  If you have window.intent, then you can take action immediately.
• Tyler: If you give a callback to the client, to provide data - where do you wait?
• Mike: after picking, fire off to client, then wait for data, then bring up provider.
• Tyler: security issue for window.location?
• page load starts, then surrounding page changes window.location - what does UA do with the intents property?
• James: if the URL doesn’t agree, don’t show the intent.
• Mike: are there any other properties which are flushed when the window.location changes?
• Paul: eventlistener seems natural, registerHandler named wrong?
• Mike: concedes the point.
• Mike: what about payment provider case?
• James: for more extensive connections, can pass a port.
• Mike: how do we handle multi-login case?  Google is only one with multi-login solved? Wouldn’t work for twitter.
• Mike: What if there is a credential object along with data? Or something like method intent.loginResult() which returns string of username...
• Mike: 2 problems:
• Multi-user login problem - which identity do I use?
• Shared computer problem - which account do I use?
• Mike/Greg: hmmm... What if we can implement multi-login for the masses?
• Mike: If we don’t solve this, then facebook might need a landing page to say which account you need to use.
• Tyler: are registerHandler and addEventListener the same?
• addEventListener has many reasons why we should take it off the table - James can communicate with Paul.
• Mike: window & registerHandler fail DRY test - intents must agree with logic/handling/switch.
• James: issue with one context-per page we need to open a new context/page per activity.  What if we reset the intent/page/DOM when we send a new intent?
• Mike: don’t like this - it violates everything we’ve trained people on how web pages work.
• James: FYI, the shim must wait for onload in order to get the intent.
• Tyler: how does shim store the data?
• Greg: stores it on localStorage bound to the webintents domain and passes it around.
• Paul:  It is pushed in via window.name on the intent initiation, so it is there prior to window.onload
• James: proposal to complete - get feedback on window.intent
• Mike: depends on the use cases - if most messages are fire and forget, window.intent makes sense, if there’s more of a chat session, then registerHandler may be better.
• Mike: must do interesting stuff after window.intent check otherwise can be framed.
• Mike: can get rid of login if we give another message: postException - then provider can request further information - possibly merchant-id for payment intents, or login/identity-name for login or share when user has multiple identities.
• Mike: suppose we have federated case or payment:
• whitelist - I accept these 3 payment or login openid providers.
• Callback to ask for more data
• James: requires mediator?
• Mike: picker could have it - extra data, provided only to providers of coice - here’s info for {paypal: ‘pp-id’, google-checkout: ‘gc-id’} after picking, data is provided...  added to intent.data? intent.extra?
• James: I don’t understand how multiple intents/actions for a provider requires mediator to know how login happens?
• Mike: does facebook raise an authentication exception, then if facebook has login intent, then fire that first and then return to facebook.
• Greg: if has login and fired before, then be smart and re-use that response/auth.
• Mike: don’t want to redirect away from your intent page - want to somehow keep user connected to intent they’ve already chosen with opportunity to get past mini-hurdles gracefully. Do we need to handle openauth in this case? facebook could take oauth... need separate stacked intent?  Does this go all the way back to the client or does UA guide them through it?
• James: if it failed, take the user back to the picker possibly with a circle-slash through the one(s) that failed.
• Tyler: worried about how the shim will work and what the security implications are for it and/or code which relies on it.  Is it possible for provider implementers to get “iframed” where someone fakes the intent and gets data or pwned in some way?
• Mike: could do window.getIntent(fn(intent) {...})
• SCR: how is this different from navigator.registerHandler?
• Mike: it’s recursive and called immediately; not a callback from a message at some point.
• Mike: worried about not working in mobile safari.  Would this (shim) technique work there by providing a window.getIntent method which called its function with the intent?  Could be non-immediate in shim case - post an event back to webintents.org and get the result at some point, but in browser impl, it’s immediate.
• Tyler: if the UA provides the ability to remember selection for a client, but the server/provider doesn’t agree, it may need to send the boolean of whether the user took action or not...  If foobar gets pwned, then the owner shouldn’t get access to contacts, etc.
• When asking for KVstore, should get handle to KVstore, not persistent connection.  Client can store the result.
• SCR: Do providers need to specify that they can’t be default action (always need user choice) such as payment providers.

scratchpad/whiteboard: 3 invocation styles (4 if you count introducer)

// 1:
<intent …> // Mike: XSS vulnerability
<script>

• James: like window.intent, but not realistic due to 5MB image/video.  Will the intent be ready by the time it’s loaded? slow.  
• Greg: however, this solves sequencing - it’s there from get-go.
• Mike: could fall off the end of the switch without actually handling
• Greg: can bind intent only when it’s there; not in the IDL to be always there...
• Greg: if we want to give one context per intent, then this model fits very well.
• James: User has given permission to do this one action to this one provider - like this clarity.

if (window.intent) // available at beginning
window.onload = fn() {
window.intent.data...
switch(intent.type, intent.action) // James: don’t like this much
window.intent.postResult()...

// 2:

• Mike: This style could work for big data to load look & feel while data is prepared/serialized/sent.
• Mike: similar to the registerHandler if you add a type to the message name.
• Mike: Would need an IDL for intent event.
• Greg: comes with baggage.
• Mike: weird cross-frame attacks (XSS anywhere on site can attack this).
• Mike: intent is not an event - could make an event with intent. Is there a magical means of preventing spoofing of this?  James: would be find to take it off the table.

doc.addEvtListener(“on-intent-data”, fn(intent) {
… postResult...
};

// 3:

• Mike: what if two registers happen?  First one wins? second?
• Greg: when do you call registerHandler?
• Mike: UA is required to queue an intent until it can be received and may fail to complete or hang up for some time
• Paul/Mike: confusing name, race condition at startup? Web workers don’t work for navigator.
• Mike: XSS vulnerability
• James: not firmly opposed to this, but likes the “here’s your payload” model of the window.intents one.
• Greg: benefit if we require this to be called before onload completes - signal to browser that if something is not registered, then it will never finish; UA can scrap it.

navigator.registerHandler(“intent”, …, fn(intent) { // intent is explicit list of actions
 intent.data...
 intent.postResult();
});

// 4:

• Tyler: can do things with accepting/filtering/blocking origin
• Mike: a little racey - accept must be called by X time
• Mike: this one could not call read and message falls onto the floor.
• Tyler: also could read and drop on the floor; UA can’t tell the difference.
• Mike: port has poor replayability (but not vulnerable to replay attacks, persistent, handoff to other contexts, toolchest, bidirectional, can start loading provider before client has delivered data).
• Mike: XSS vulnerability

// Mike: Introducer for completeness’ sake.
introducer.accept([intents you handle], function(port, [intents...], origin) {
 port.read();
 port.write();
});
</script>