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

On Mon, Nov 21, 2011 at 5:38 PM, Paul Kinlan <paulkinlan@google.com> wrote:

>
>
> 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.
>>
>
Even same-origin requests to see if the service is registered could be
misused as a (weak) cookie. Our prototype Chromium code demands that sites
basically register every time, and the browser suppresses duplicate
registrations. We need a more sophisticated system, but that's the kind of
opacity we currently think is necessary.

Something that may become ergonomically helpful and be an acceptable
tradeoff is a client ability to request whether any services at all are
registered for a particular action/type. I'm leery even of that, though.



>
>> §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.
>

I think that should be unspecified (i.e., up to the user agent). The spec,
in my opinion, should focus on the discovery, invocation, and delivery
mechanisms, and leave unspecified what mechanism the UA uses to perform the
coordination.

In our prototype, we use an image and name provided by the service as this
persistent metadata. We plan on presenting that at registration time and
then again at invocation time.



>
>
>>
>> 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.
>>
>
Phishing-style impersonation attacks are almost impossible to rule out in a
decentralized way. For Chrome we plan on using the weakly centralized
malware list (safe browsing) to help guard against that. We will probably
need to augment the detectors to find this kind of attack.


>> §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
>>
>>
>
>

I'm understanding 'Hotswapping' to mean that users could select service A
one day and service B the next. Yes, I think that's critical. Ergonomics
may mean that implementing default settings is the way to go, but perhaps
the spec ought to suggest the UA "should" give an easy way to back out of
those defaults.