W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

Re: Non-visible intents

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 06 Dec 2011 23:40:40 -0800
Message-ID: <4EDF1878.3050800@jumis.com>
To: public-web-intents@w3.org
I appreciate the cases.

To be clear: Notifications API.
http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html
http://dev.w3.org/2006/webapi/WebNotifications/publish/

And major issue:
http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
"A script event is considered a user gesture if it directly resulted 
from the user using an input device, and the event is generated by the 
user agent, not a script"

There are currently no means of pushing a user gesture across contexts.

That said, for my purposes, Chrome has a notifications permission, and 
so I still get what I want if users have installed additional permissions.

This kind-of comes up with Chrome background pages:
http://code.google.com/p/chromium/issues/detail?id=99160
One can't push a full screen call from a background page onto the 
current page, because the user gesture will not transfer.

Anyway, given all that, I'm proposing that a "disposition=notification", 
would register permission to send a notification, when that intent is 
installed.

This allows me to do these "invisible" intents, while providing feedback 
if necessary, per timeless and Greg Billock's comments.
It avoid the hack of doing non-visible inline areas, and explicitly 
supports notifications through registration of the disposition, so the 
user gesture issue is not an issue.


-Charles


On 12/6/11 8:25 PM, timeless wrote:
> Offhand, I'd say "no. Notifications almost certainly doesn't cover that case".
>
> * Windows 7 uses a notification to tell you that the wifi network to
> which you've connected seems to require additional credentials.
> * I've had notifications from Windows and Outlook that my credentials
> are bad/expired/expiring.
> * Technically, when my credit card is misused, I get a "notification"
> from my credit card company.
>
> That said, the notifications I get from each of these are more
> persistent than I expect a notification api would be, and yet the
> concern is fairly equivalent.
>
> Let's consider a simple case:
> 1. I /think/ I'm @eBay.
> 2. I want to make a purchase.
> 3. It triggers a "transfer-money" action.
> 4. UA offers me PayPal and Discover as choices.
> 5. I select Discover.
> 6. Somehow Discover is configured to automatically dispense simple transactions.
> 7. Unfortunately, there's something wrong with this transaction.
> A. Perhaps eBay wants more money than my preapproved per transaction limit.
> B. Perhaps I've hit my monthly limit.
> C. Perhaps my card was suspended.
> D. Perhaps the merchant is suspect.
> 8. Discover wants to tell this to me.
>
> Let's make some changes to this scenario:
> 1a. I'm not buying from eBay, instead it's eBay market place.
> 1b. I'm actually at eBoy.
>
> I haven't had time to look over the Intents proposal. And I haven't
> spent any time reviewing the display bits. I'm hoping to play with a
> demo build next week....
>
> On the topic of Notifications... Generally, I believe that we do *not*
> want Notifications to outlive the sites which trigger them. It's too
> easy for an evil site to do a hit and run notification asking you for
> something.
>
> If the site I'm visiting is evil and is trying to con me out of money,
> then a system where it can make a request and then navigate away to
> prevent me from seeing my wallet provider's complaint/warning would be
> bad. Now ideally, Discover would contact me by Phone, and the same
> should be said for PayPal, but I don't think all intent providers
> would have that provision and some will probably have a reasonable
> requirement to express a message that the user will actually see.
>
> Sure, we could require users to allow Intent Providers to have access
> to persistent Notifications, but I don't think that's a good
> requirement. Some Intent Providers will be truly trusted and
> trustworthy, some will just be convenient, transient, hacks, or
> hackable/unreliable, but all of them will probably be used by users
> without much consideration -- just like the rest of the web.
>
> --
> I won't have time this week to reply to other messages on the list
> (short vacation starting Wednesday night and I generally send my
> replies after work).
>
> On 12/6/11, Charles Pritchard<chuck@jumis.com>  wrote:
>> Does the notifications mechanism work for this?
>>
>>
>>
>> On Dec 6, 2011, at 3:46 PM, Greg Billock<gbillock@google.com>  wrote:
>>
>>> James, Paul, and I have spent quite a bit of time discussing this. We
>>> have always come back to the question of how do you let the user deal
>>> with exceptional circumstances and status updates. There has to be
>>> some UI surface for a background disposition service, so that the user
>>> can get to it to shut it down if need be. So then we've always ended
>>> up thinking that that UI surface ought to be where the service can
>>> display status messages or perform error handling. But at that point,
>>> it basically looks like an inline disposition.
>>>
>>> We've discussed various permutations of Web Workers, invisible tabs,
>>> and so forth, but so far at least, the above line of thinking has
>>> always seemed more compelling.
>>>
>>> For an example, think about a 'login' intent. This might often run to
>>> completion with no problems whatsoever. But suppose even in the case
>>> of a success, the service wishes to display a warning: "someone from
>>> this unusual IP address has tried to access your account", or
>>> something more functional: "You enabled two-factor auth, and you need
>>> to enter your credential again." Or even something mechanical, like a
>>> 503 error from the login service. That needs to be displayed
>>> somewhere. Leaving a temporary UI surface for the service to display
>>> an in-process throbber or progress bar is even useful -- it lets the
>>> user know something is happening, and it doesn't look like the client
>>> page is being unresponsive -- so that it's possible for the user to
>>> know to attribute the slowness to the service provider.
>>>
>>>
>>> On Tue, Dec 6, 2011 at 2:57 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>>>> There are now two disposition types: inline and window, I'm considering a
>>>> non-visible type, which would essentially be a zero-height/width inline.
>>>>
>>>> Consider a backup service, the user merely means to backup, or "copy"
>>>> their
>>>> file, to a service like dropbox, but has no interest in a window popping
>>>> up,
>>>> nor seeing an<iframe>  confirmation.
>>>>
>>>> Is that a consideration worth extending, or should<iframe>  be used
>>>> regardless?
>>>>
>>>>
>>>> This is a case most often handled, in the present web, by using OAuth and
>>>> creating a new window when authentication fails (or has not taken place).
>>>>
>>>> In intents, it might be two-fold, having a "login" intent, and a "backup"
>>>> intent.
>>>>
>>>> I've found that OAuth logins are sufficient for checking credentials:
>>>> I've
>>>> not needed OpenID.
>>>>
>>>> Though sites haven't standardized on an end-point, most APIs have a
>>>> callback
>>>> that return a user name and associated information.
>>>>
>>>>
>>>> Let me point out that an OAuth login intent is always useful. Even if a
>>>> user
>>>> has logged in, there's every reason to think they may want to "switch
>>>> users".
>>>> As for this backup concept, again, I don't need to see a popup window
>>>> every
>>>> single time I choose to backup a file.
>>>>
>>>> While the<iframe>  concept works, it's a bit of a kludge. I'd prefer that
>>>> the author check for confirmation from the target intent and display it
>>>> in a
>>>> more integrated manner, such as saying "All files have been backed up".
>>>> That's not something an end-point has enough information to state.
>>>>
>>>>
>>>> -Charles
>>>>
>>>>
>>>>
>>
Received on Wednesday, 7 December 2011 07:41:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 December 2011 07:41:15 GMT