 |
From: Greg Billock <gbill...@google.com>
Date: Mon, 26 Sep 2011 11:05:59 -0700
Local: Mon, Sep 26 2011 2:05 pm
Subject: Re: Disposition documentation added
(I've been out on vacation. Will try to clarify a couple things inline.) On Wed, Sep 21, 2011 at 6:55 AM, Sean Eagan <seaneag...@gmail.com> wrote: The idea is that being displayed inline will be a more seamless user > > We envision the 'inline' display replacing the service selection > components > > of the picker UI. > If all of the service selection UI is replaced, what useful remaining experience -- they haven't really navigated away from the page, so they can enter descriptions, copy-paste text, etc. from the context page. The "window" disposition feels more like a navigation. Sometimes that's probably appropriate, but for many actions, it's a bit abrupt. > > For some intents, though, it might be There are definitely clickjacking and phishing concerns with iframes. > > better to basically layer on top of the existing (client) page context, > so > > the user can maintain a better mental image of what's going on with the > > intent work flow, and perhaps interact with the client page (i.e. > copy-paste > > a title or something). > We agree on the use case of keeping the service UI in context with the Developers have to pay a lot of attention to them. For this context, there's no way an intent service could know that it is being deployed in an iframe "involuntarily" and hence clickjacked. Since the services are likely to be ones that require login, that's a huge problem. > I agree the next best way to preserve context is to display the a way that web content can't copy -- the surface overlaps with browser chrome, which content cannot do. Whether this is a sufficient guard against phishing remains to be seen, but browsers are using this mechanism to defeat phishing, so users at least in theory are aware of the UI. > Also, it ought to be clear to the user from which context a given > So far we have mostly been discussing regular browsing contexts as much any of them. :-) The question of intent picker modality is open, as is that of simultaneous and nested intents. The mental model guiding us is that intents are only triggered by direct intentional user action. That is, some control they click or tap on. (Of course, that can be subject to exploitation, as pop-unders on clicking on text areas shows. We don't have a final answer for things like that.) The idea, then, is that when the user makes that action, they are presented with a UI within the current browsing context. The trade-off there is spoof-proofing the UI surface and anchoring it to the element of content which originated the action. But as you say, sometimes the UA itself may originate the action (i.e. a context menu). In trading off these various concerns, we've settled on a prototype that uses the spoof-proof bubble. > > Perhaps we'll conquer the problem of managing > Assuming the picker consists of a UI component which has not > > This is a great discussion. We've pretty much talked ourselves out of > My core arguments against the disposition concept as is are: > * It is a problem which all web content faces, not just > [1] http://wiki.whatwg.org/wiki/Component_Model > Thanks, unique (iframes, content spoofing, monolithic namespace among components on a page). The idea that services may want to vary their disposition based on platform is interesting, although presumably they can count on the registration platform not changing character when they register. (That is, they can adjust their disposition requests based on whether they see themselves on a mobile vs. desktop UA.) I definitely agree that the UA has veto power over the disposition, and the service can't dictate display constraints very strongly without degrading the user experience. -Greg You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||