Web Intents - User Agent Features (part 3)

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.

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

Received on Tuesday, 22 November 2011 01:22:01 UTC