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

Re: Web Intents and abuse

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 23 Nov 2011 18:16:42 -0800
Message-ID: <4ECDA90A.5050102@jumis.com>
To: Paul Kinlan <paulkinlan@google.com>
CC: Tom Sepez <tsepez@chromium.org>, public-web-intents@w3.org
On 11/23/11 2:04 AM, Paul Kinlan wrote:
> On Tue, Nov 22, 2011 at 8:28 PM, Tom Sepez<tsepez@chromium.org>  wrote:
>> Hi folks,
>>    Saw the email from James go by and thought I would send out a few comments
>> following a cursory read
>> of www.chromium.org/developers/design-documents/webintentsapi
>> - Intent Provider Discovery:
>> The User Agent discovers Intent Providers as a side-effect of visiting a web
>> page.  Presumably, before these are added to the User Agent's catalog of
>> providers, there is user interaction required, in the form of a pop-up
>> dialog or an infobar explaining that the Intent Provider site wants to
> We should document that it should only happen for newly discovered
> intents.  I newly discovered intent is one that it is not in the UA's
> dictionary, based off a action/type tuple.
> The assumption here is that it is ok to change the href as it is in
> the same origin without prompting the user for action.
> The UA should remember denial of permission, if permanently selected
> by the user, however that is not the case for a basic dismissal will
> temporarily revoke the UA from installing the intent.
>> How does the user know that the title="" of the service actually matches the
>> provider?  Can I trick users into revealing their data by claiming to be
>> title="picassa service" on my own evli website?  Is the URL also displayed
>> at registration time? This would be a strong suggestion.
> Our demos show the domain of the service at invocation time and when
> we register an intent it says something like "www.xyz.com would like
> to add ... "

This reminds me of the obtrusive behavior that was in Firefox for client 
side storage / applicationCache. It was most frustrating because 
applicationCache, like <intent> was static and in the markup. When I 
showed people my application, they were prompted with a permissions 
request, and that was always an unwelcome distraction.

I got to the point of thinking that I really needed an "app.html" in 
addition to "index.html", but app.html would have the manifest/installed 
app semantics. I didn't follow-through with that, I just dropped app 
cache altogether during that period, so that users wouldn't be pestered 
when I was demonstrating an app to them on their machine.

Now If I'd had access to API methods, I could have had a nice little 
"Install" or "Save" button, and that -would- request elevated 
permissions (to install app cache, etc).
That seems to be the direction things are going with Chromium and it's 
chrome.app.install() style.

Received on Thursday, 24 November 2011 02:24:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC