Re: Web Intents - User Agent Features (part 3)

On Tue, Nov 22, 2011 at 1:21 AM, timeless <timeless@gmail.com> wrote:

> I think we need the following from User Agents:
> §2 Opacity
> §3 Persistable metadata for Partner Providers
> §4 Profiles
> §5 Hubs
> §6 Hotswapping
>
> Specific examples below are representative only.
>
> §2 Opacity
>
> Devices with no Actions must be invisible, they only enable fingerprinting.
> Also, Discovery/Transport must be hidden from Clients -- all that
> should matter to them is that when they request an Action, one may be
> selected for them by the User and returned by the User Agent.
>
> §3. Persistable metadata for Partner Providers
>
> We definitely need a way to have persistent names, and we need to have
> persistable + shareable metadata (which often should *not*) be
> importable as trusted data upon Discovery.
>
> First, an explanation of why we need persistable metadata:
>
> My initial example [1] was the "representative" who ceased to be the
> representative. You obviously need to remember it's no longer relevant
> to you.
>
> If the reason it isn't relevant to you is that you moved, then your
> metadata decision isn't something which the "representative" would
> hand out.
>
> In the case of a "representative" dying or retiring, his office can
> return a Fatal error message during the Intent connection. The UA can
> offer to update its metadata after presenting this explanation to you.
>

Right, cool.  The assumption if the service has gone away webapp/site or
device then it should no longer be listed after the attempt to launch.

In your representative example, is it returned to the Individual (client
app) or does the User Agent allow the User to pick another Partner
(Representative).  On failure we were planning on letting the user reroute
the data.


>
> Security consideration here:
> Why shouldn't metadata be automatically imported as trusted during
> Discovery?
>
> There's value to providers stealing requests to Partners:
> It's trivial for someone simply having a copy of a pointer for someone
> else's service with additional annotations. And for HTTP (or weak
> HTTPS), there are cases where there could be a MITM [2] or Hackers [3]
> attacking to trigger DoS [4], etc.
>
> In my representative example [1], if Lobbyist E (evil) can provide a
> suggestion to voters of a Partner "S" which sounds like the Right
> Partner "R" (which happens to be someone who would oppose E), but
> where this Partner "S" either MITM and relays traffic (possibly
> tainted) or simply captures and drops it, then we have problems.
> -- This is the argument against all metadata being sourced at Partner
> Discovery: "just trust me" is incredibly dangerous.
>
> §4 Profiles
>
> Most peripheral systems (including Bluetooth [6], USB [7], and UPnP
> [8]) provide a way for a Device to advertise its complete list of
> Services, each service is typically a Profile [9][10]. I'd like to
> encourage this model. Here in place of a "Service" or "Profile", we
> have an "Action".
>
> §5 Hubs
>
> In some peripheral systems, users can also get Hubs and combine
> Devices by attaching them through these Hubs. I'd like to encourage
> this model by enabling Clients to hint that they'd like to have an
> Action related to an already retrieved Action.
>
> §6 Hotswapping
>
> Ideally, UAs would enable Users to hot-swap Providers transparent to
> Clients.
>
> Example A. USB with PnP OSs Today:
> I have a USB keyboard (HID [5]) with a USB exposed integrated
> touchpad. I also have a USB keyboard and a USB mouse. When I swap
> these, my Applications aren't told (the OS, my UA is and it hides
> these details from most applications). When I resume typing or
> "mousing", my applications get Input through their standard channels,
> blissfully unaware of this change. They're also generally unaware when
> the typist at the keyboard changes -- it's none of their business.
>
> Example B. Use Case for Web Intents -- Thermometer:
> I propose that a Thermometer have one primary service:
> <get-temperature>. If it wants to have a supplemental service
> <get-location>, that's fine, but it should be a distinct Action.
>
> A User-Agent should make it easy for Users to select related services
> from an already selected Provider in response to additional Action
> requests from a Client.
>
> Technically this could be QoI, but hopefully most UA form factors will
> support/favor this.
>
> How would this work in practice?
> I have a Bluetooth GPS and I have a digital thermometer with an LCD.
>
> (1) I visit a site that wants to map Temperature/Locations using
> crowd-sourcing.
> (2) It ask for a <get-temperature> Action.
> (3) I select my "Manual Provider" from my UA's list of possible
> <get-temperature> Action Partner Providers*.
> (4) The "Manual Provider" prompts me for a reading.
> (5) I read my Digital Thermometer and enter its value.
> (5a) This value is sent by the Provider to the Client (web site) by my UA.
> (6) The site can then ask for a <get-location> Action.
> (6a) It should be able to hint in this request that it would like it
> to be paired with the Opaque Representation of the Action (opaque to
> the Client, but not to the User Agent/User) it was already given in
> (3) .
> (7) In my case, I'll be told by my UA that Client wants a
> <get-location> Action for my "Manual Provider" from (3).
> (7a) QoI, my UA tells me when it (the Manual Provider for
> <get-temperature>) was last used and other metadata upon my request.
> (8) Since my Partner (3) doesn't have a <get-location> Action (and
> answering that is tedious), I'll instead select my Bluetooth GPS as
> the Partner-Provider.
> (8a) My UA can QoI remember/offer to remember it for this
> <get-temperature> Action†.
> (9) Since I've now paired two Providers for a Client, my UA should
> offer a way for me to disconnect them as a unified device‡.
>
> * This Provider may be something that the UA natively supports, that
> it discovered while I was browsing, or that it automatically searched
> for on the fly.
> † This is merely a suggestion by my UA the next time a request for a
> <get-location> Action with this <get-temperature> Action Partner even
> for a different Client, but no Client sees this suggestion, only the
> Partner I select.
> ‡ Just as one can eject a USB device with multiple sub resources, the
> Client is told the entire bundle has gone away atomically.
>
> [1]
> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html
> [2] http://en.wikipedia.org/wiki/Man-in-the-middle_attack
> [3] http://en.wikipedia.org/wiki/Hacker_(computer_security)
> [4] http://en.wikipedia.org/wiki/Denial-of-service_attack
> [5] http://en.wikipedia.org/wiki/Universal_serial_bus#Device_classes
> [6] http://en.wikipedia.org/wiki/Bluetooth
> [7] http://en.wikipedia.org/wiki/USB
> [8] http://en.wikipedia.org/wiki/Universal_Plug_and_Play
> [9] http://en.wikipedia.org/wiki/Bluetooth_profile
> [10] http://en.wikipedia.org/wiki/USB_human_interface_device_class
>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan