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

Re: Web Intents: Opacity

From: timeless <timeless@gmail.com>
Date: Wed, 23 Nov 2011 14:37:44 -0500
Message-ID: <CAACrNNfEVa8jtF8j4Zv2BM-rVvSv0nt=ys+kFaAxoykmKj3yWg@mail.gmail.com>
To: WebIntents <public-web-intents@w3.org>
On Tue, Nov 22, 2011 at 5:40 PM, Paul Kinlan <paulkinlan@google.com> wrote:
> I suppose we should document the concern.

absolutely.

> A user visits a service that implements it own unique intent that is
> bespoke to the site.
> <intent action="anuniqueaction" type="*" />
>
> Other site checking to see if you have been to an app:
> window.navigator.checkActivity("anuniqueaction", "*") == true;  // Hey
> we know you are attached to the other site.

This is why I'd rather not support such an API at all. The web is
generally much better served by not having "may i do this" but just
having "i'm doing this <details included>".

> To note, as soon as another site implements "anuniqueaction", the
> probablity of knowing the exact site is reduced.

But not greatly. Fingerprinting by checking for some combination of
<uniqueactions> or other tendencies is still fairly viable.

> Further more, if the
> action is completed then we will likely know they are attached to the
> other site.

If the action is completed, then the user has decided they're willing
to do it. UAs could decide to warn users when they're being asked to
use a rare intent (this should definitely NOT be a MUST).

> So my thoughts are it is not the same as a:visited, but is it still a
> similar risk level.

> The ability to know if an action can be handled is a common feature
> request amongst developers that I speak to, they are concerned that if
> they can't detect that there is an app to handle it then it is a
> terrible UX.

I posted an example where a page could provide itself as a
local-provider for an intent [1].

This means that if there are 0 other registered providers, the UI for
choosing an intent only shows the user the page's own (which can be
defaulted or whatever) and the user isn't left alone.

> Current patterns that I have been playing with are:
> - Build a basic handler in the app for each action/type so that there
> is at least an app default, however this goes against the grain of the
> spirit of intents; that you don't need to implement functionality
> because it is delegated to another party.

Right, this is why I'd like to encourage §8 Partner Inspector and §10
Manual Providers [2],
>> Encouraging people to ensure that §7 and §8 are developed and shipped
>> / highlighted quickly will be necessary.

This is one of the reasons that I want a way to have §1-C "business
card links" [3] for other providers. If you don't want to implement
your own but know of a couple of services, you can hint to the browser
about them and even if it doesn't have a database or search engine, it
could pull them up as suggestions for the user.

> - Build a registry that contains all the known sites that support the
> action/type pair.

I didn't actually list a Directory as a deliverable, I think I
mentioned expecting there to be marketplaces / directories to happen
and I more or less expect most UAs to provide a default (and possibly
a way to switch). I'm not going to search for a reference on this
point. I certainly expect that major directory providers and search
engines and stores are likely to step into this space.

[1] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0036.html
[2] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0039.html
[3] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0010.html
Received on Wednesday, 23 November 2011 19:38:13 UTC

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