Device APIs Working Group Teleconference

03 Nov 2011


See also: IRC log


tpac, jlebar, Dominique_Hazael-Massieux, Anssi_Kostiainen, Frederick_Hirsch, Robin_Berjon, Laszlo_Gombos, Ernesto_Jimenez, Travis_Leithead, Jose_Cantera, Bryan_Sullivan, Marco_Marengo, Anders_Isberg, David_Yushin_Kim(obs), Kihong_Kwon, spoussa, Cathy_Chan, Christophe_Eyrignoux, Ingmar_Kliche, Soonbo_Han, jerome_giraud, Soonho_Lee, Jongyoul_Park, Niklas_Widell, Linuz_S_Lee, SungOk_You, Sakari_Poussa, Rich_Tibbett, Kepeng_Li, Josh_Soref, Justin_Lebar, Mounir_Lamouri, Jean_Claude_Dufourd, mahalingam_mani, update, Adrian_Bateman, Ilkka_Oksanen, Jari_Alvinen, Balaji_NV, Jean-Francois_Moy, npdoty, Cullen_Jennings, Philip_Gladstone, Jonathan_Jeon, Daniel_Appelquist, Kangchan_Lee, Virginie_Galindo, Olivier_Thereaux, Matt_Hammond, JC_Dufourd, Youngsun_Ryu, Dave_Raggett, Clarke_Stevens, Kaz_Ashimura, aizu, Art_Barstow, Richard_Bardini
Frederick_Hirsch, Robin_Berjon
Josh_Soref, Travis_MSFT


<trackbot> Date: 03 November 2011

<dom> Chair: Frederick_Hirsch, Robin_Berjon

<bryan> scribenick: bryan

fjh: introduces the DAP wiki working mode etc

<fjh> http://www.w3.org/2009/dap/wiki/ApiCheckList

<Zakim> dom, you wanted to say something

<shunan> shunan fan Huawei terminal company

<spoussa> *Sakari Poussa , Intel

fjh: agenda review

review of the minutes

RESOLUTION: Minutes from 12 October 2011 are approved.
... Minutes from 26 October 2011 are approved, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0076/minutes-2011-10-26.htm

Battery API

anssik: battery API intro

anssi: expect that folks have looked at the draft, its pretty stable and nearing last call stage

jose: main concern is no way to specify event rate

<AnssiK> http://www.w3.org/mid/4EB03375.3070702@lamouri.fr

anssi: Jonas (Mozilla) wants to leave that up to the implementation

robin: seems fine

jose: what does that mean to the app, does it need to filter the events?

anssi: the app can measure the delta

<jcantera> My concern is the event rate at which receive battery events

anssi: events too often don't help as they may not be true changes
... devs will need to handle various firing speeds

bryan: don't we have the ability to threshold?

anssi: no

<Cathy> http://dev.w3.org/2009/dap/system-info/battery-status.html

bryan: dropping threshold events is an issue

anssi: this was based upon implementer feedback (Mozilla)

dom: the orginal spec was 1% change events... if we have platforms that don't send events consistently that won't be helpful to developers

<Travis_MSFT> Firing events too often could be counter-productive to saving battery...

<AnssiK> http://lists.w3.org/Archives/Public/public-device-status/

bryan: I will join the task force and review the comments on the list, to see how we can restore the threshold events if possible

lazlo: what about the use case on scaling back work when the battery is getting low?

anssi: it's in the use cases in the spec

<fjh> laszlo notes we need to consider both browser implementer concerns and web page author concerns

jose: the monitoring of the battery will impact the battery, if it depends upon handling continual events

anssi: we all agree that we don't want to impact the battery by the use of the API
... thresholds were not hard coded as in the future we don't know how they might apply or not

<AnssiK> Justin Lebar

<spoussa> The time units in the specs might be difficult to get in some platforms. That is, it might be very hard to get time value.

anssi: the spec is designed to use defaults for charging time

spoussa: its hard to estimate charging/discharging time on different platforms
... the example in the spec won't work with the defaults

darobin: we got feedback that complex examples are helpful

ingmar: how is app initialization done?

darobin: mounir has been working on the battery status in Mozilla

anssi: one concern raised about the semantic events being dropped
... if the web code gets too many events as a result
... our concensus was that would not be an issue if implemented correctly

mounir: we don't have the critical etc info from the battery
... it would be the same if the web page measured the level against some expected value

dom: another approach is to set a delta threshold

mounir: sending a lot of events does not seem to be bad

<AnssiK> [I'll rework the example to check also against level if dischargingTime is not available]

mounir: about too many events, an email was sent to the list

<fjh> http://lists.w3.org/Archives/Public/public-device-status/2011Nov/0000.html

darobin: if the underlying system provides too many events, the user agent would be expected to block the events

dom: we may be missing a valuable thing for implementations, as the high/low/critical values may be useful to the implementation as a way to optimize its battery monitoring also

robin: with 1% thresholds (implementation approach) we are talking 80 events

<fjh> dom notes that optional threshold parameter would have value and low cost, avoid issues that developer might not recognize

dom: if the developer does not know the battery level before doing resource-intensive DOM actions, it can impact the battery even more

<dom> (note that I wasn't talking about "high/low/critical" events, but having a parameter to define the threshold (set for dischargingtime, or level) from which to send the events)

anssi: on the list, it was stated that we don't know how the battery backends behave, so it's good to leave it to the implementation

<jlebar> So you guys have to break about now? Are we getting to vibrator before then, or is that coming later?

mounir: if we have native extension listening to battery events, the platform is also optimizing the rate of events

<dom> jlebar, I think we'll probably take it after the break -- will ask the chairs to confirm

<Josh_Soref> [ Conversation to confirm we're switching from Battery to Vibration to help jlebar ]

<Josh_Soref> [ Conclusion: Vibration @10:45am Pacific ]

spoussa: additional comment to adding the level... there are backends that are already optimizable

anssi: the platform should already optimize it without webapp help

<fjh> sounds like this is a potentially useful optimization

josh: the system can determine when to send events based upon whether the apps need them - when do they care

darobin: wakeup is important

josh: preventing the need to wake up just to handle the events, needs a different approach

dom: an optional threshold setting would allow the app to optimize events

richt: the platform would still need to listen to the underlying events
... if those optimizations were wide-spread, it would be fine but it depends upon that

dom: in many cases being able to request less events would be an optimization

<fjh> richt the design of the API to include a sync 'level' attribute prevents threshold really bringing any significant optimizations to imps

anssi: we still have the sync interface which allows the app to get fewer events
... the app can poll the sync interface

<fjh> ernesto notes could have seven apps polling, want to avoid drain from executing javascript

darobin: even if the underlying interface needs to poll the platform continually for the sync API, it does not need to deliver the events to Javascript

jcd: could use the constructor approach to prevent the sync API from being used when not needed

<jcdufourd> jcd: how about a field for the author to indicate whether he will use the sync part

richt: the current API was not designed for optimization

<richt> + I'm not convinced by adding threshold optimizations based on the current design

darobin: we need to have a proposal for the options and this will be the last major change so we can move on to other things

<dom> ACTION: Sakari to draft a proposal for a threshold parameter for Battery events [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action01]

<trackbot> Created ACTION-459 - Draft a proposal for a threshold parameter for Battery events [on Sakari Poussa - due 2011-11-10].

<Mani> Sorry s/update//

<Josh_Soref> Scribe: Josh_Soref

darobin: jlebar welcome back, thanks for joining us

Vibration API

[ darobin opens the floor to jokes ]

darobin: two weeks ago, AnssiK took what Mozilla implemented and drafted a specification out of it

AnssiK: Mozilla has been working on an implementation known as WebVibrator

<darobin> http://dev.w3.org/2009/dap/vibration/

AnssiK: I took the liberty of naming it Vibration
... i'd like to hear your opinion of what i've written

<jlebar> thanks.

AnssiK: the api is simple, it lets you ask the device to vibrate for a certain period of time
... it doesn't support intensity, it was proposed by huawei
... the main use cases are games
... and it's limited to the active web content/task

darobin: i'd like to make sure everyone agrees that this is very simple for a version 1
... if there's interest in a more complex version, we can do a vibrator 2
... we have a normative dependency to page visibility
... i think that's actually in LC

AnssiK: i'd like to reuse much of it
... if page visibility is progressing on REC, then we can rely on it
... i think mozilla is depending on mozHidden
... we public the FPWD after we get confirmation from jlebar to confirm it's ok
... and then we can bike shed about naming

<Zakim> dsr_, you wanted to request a repeat count as an optional parameter as per android's vibrator API

dsr_: i've been doing an impl for android
... and there's a need for a repeat count for a pattern

AnssiK: what's the UC?

dsr_: it's to avoid repeating yourself
... wouldn't it be easier to do it in the api?

darobin: i think on iOS you can only just vibrate

ernesto_jimenez: at least the phonegap iOS it only vibrates

AnssiK: i'm not opposed, i just need UCs

<jlebar> I agree: I'm in favor of a compact API surface.

jcantera: what you're suggesting wouldn't work
... dsr is suggesting vibration slots

<richt> I'll mention my point now while it's relevant: I'd prefer a vibrateend event, so I can perform a js loop of the vibrate behaviour as many times as I like (rather than specifying an optional repeat parameter)

jcantera: and repeating the slots as many times as you want
... basically the Array

AnssiK: my point is that it's a convenience

<bryan> I don't see the repeat count as more than an optimization, a convenience

AnssiK: JS has a way to do stuff natively to Arrays

<richt> ... I could also then trigger some action on vibration end.

darobin: jcantera is talking about vibration patterns

<bryan> It's easy to create a pattern that has a certain length and repeat it at will until an event causes the app to cancel it

darobin: if you want to repeat it, you'd need to when it's going to end
... if you want to start it again

<Zakim> bryan, you wanted to note the API as defined looks to have the essential features, but I'm not sure about the disabling when in background

bryan: to me, a repeat option is an optimization
... it's a convenience
... my pattern itself can repeat

AnssiK: i don't see it as a big issue

bryan: the API as defined looks to have the essential features, but I'm not sure about the disabling when in background
... i think there are use cases when my page is in the background
... and it wants to notify

AnssiK: Out Of Scope
... that should be covered by the notification API

<dsr_> Adroid's vibrate API has a method that takes a pattern just as in the current draft spec, and a further parameter that is a repeat count. This is a convenience for developers.

AnssiK: it could be by Heating Up
... at least some devices do that

[ Laughter ]

darobin: WebNotification
... If you have a tab/page in the background
... you use WebNotification, and it will use the user's preferred way of being notified
... it might heat up in your pocket,
... or it might vibrate, or make sound, or show something on screen

bryan: so notification api gives me a way to vibrate in the background?

Josh_Soref: the notification api lets you trigger a notice, if the user chooses that it be a vibration, then you're triggering a vibration

[ Time Check ]

bryan: i don't think my UC benefits from WebNotification
... my web app wants to control how it interacts with the user

darobin: if you have a UC not covered by WebNotification or Vibration, then please send feedback to the list
... I wanted to ask jlebar (on the call)
... in terms of functionality, are you happy with what you have in the api?
... or are you looking to add things?

jlebar: this isn't a notification api
... the ability to turn vibration on
... and turn it on with a given pattern is all we need

AnssiK: what about intensity?

jlebar: I do think it's interesting
... but i don't know how we do that
... i don't know enough about devices
... to speak to that
... we'd have to survey devices

AnssiK: makes sense to me

jcantera: in Android, you don't have a way to control intensity by default
... but with a given device, you may be able to use Immersion to control it
... maybe we can provide optional parameters to do it
... intensity, style, whatever
... provide some extensibility for it

AnssiK: i suggest jcantera send a proposal to the list
... it would be helpful for someone to survey the native apis

jcantera: i think the api can be opened to such a feature

dom: this could be a v2 feature

AnssiK: we need to be very careful about scope
... we have lots of haptic feedback mechanisms out there

jcantera: having an optional parameter in the method

dom: then you need to define how that works

darobin: you need to define how things are interpreted, ignored, etc

fjh: dsr_ was asking about a repeat parameter
... usability for authors is important
... even if it's just syntactic sugar
... i think we can do a FPWD w/o things being perfect
... we can publish regardless

darobin: we can say that the implementation just multiplies the array

<Zakim> Josh_Soref, you wanted to talk about different haptics and constraints

<ernesto_jimenez> Josh_Soref: in nokia we had to look at hap haptics and we had to worry about buffers

sicking: pass

<fjh> Josh_Soref: bandwidth of buffer might be another reason for repeat count

sicking: while repeat pattern makes things easier
... it does mean an extra parameter that we have to care about
... it makes it a bit harder for extending later
... i would like to see a solution for intensity
... is intensity support in devices common?
... for advanced gaming systems you have a lot of that

darobin: for AGS, you have multiple devices
... clearly a v2 feature

<Zakim> adrianba, you wanted to talk about stop

adrianba: given that you can dispatch this pattern
... what if you want to stop it?

darobin: i think if you call vibrate, it interrupts the previous pattern

<dom> (or vibrate(-1) ?)

darobin: calling vibrate(null) will stop
... we could add a close method
... but we're moving to navigator
... so we need to be careful about not canceling navigator

Kepeng: understanding of the vibrating api
... is to invoke the device to vibrate
... do we have a way to ask if the device is vibrating?

AnssiK: we don't support that
... i proposed events for starts/stops
... but we didn't have a UC for it

<fjh> we need use cases if we need this

darobin: if you have a UC for it, please send it to the list

Kepeng: ok

richt: i like Kepeng 's idea
... i'd like to know when my vibration ends
... so i can know i can do my next action
... but there's a need for a timeout
... and i get some latency/jag

darobin: agree, send UC to list
... objections to a FPWD?

<fjh> ACTION: fjh to send cfc for FPWD for vibration [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action02]

<Travis_MSFT> Created ACTION-460 - Send cfc for FPWD for vibration [on Frederick Hirsch - due 2011-11-10].

[ none ]

darobin: implementers, please send us feedback
... now would be nice
... jlebar, if you've had the time, it would be good to get feedback

jlebar: offhand it looks mostly good

darobin: any other implementers looking at it?

richt: i'd like to see a path from a v1 to a v2 in the spec

<bryan> on thinking about the possible use cases for background vibration, I think there are perhaps some corner use cases but no central ones, and the possible unwanted side-effects (e.g. conflicts between multiple background pages) would need to be considered - so for now I don't plan to submit any use cases for that

richt: like supporting multiple targets

darobin: thanks jlebar for joining us

<dom> thanks, bryan

Media Capture

<jlebar> Bye, everyone. I"ll send mail to the list soon.

Travis_MSFT: I have remarks

darobin: Media Capture, there are two drafts
... the one thing we're missing for media capture
... is for someone to tell us which attributes they want
... right now, it's bikeshedding
... first implementer to suggest hints, it'll probably be adopted
... [this is <input> style]
... the second case is programatic input
... the proposal is to have a joint list between WebRTC and DAP
... concerns of a joint work with WebRTC?

dom: until recently, DAP had adopted the Media Capture API
... getUserMedia()
... and there was something similar in WebRTC
... the proposal was to make this a joint proposal, to replace the existing work

jcantera: does need a security model getUserMedia() give a preview?
... but you need a way to capture

<dom> [the existing DAP Media Capture API http://dev.w3.org/2009/dap/camera/Overview-API.html ]

darobin: no specific concerns to the task force, i'll set it up

Travis_MSFT: Travis, I joined this group recently
... I've been in WebApps since 2006
... I've been working on Web pages/ the IE team, Trident, 7, 8, 9, 10
... my primary interest in the short term is Media Capture
... I recognize there's a lot of prior history here
... putting that behind me
... i'm a proponent for the TF
... it's a way to get our point of view form the Local MC perspective
... and trying to merge that with the remote point of view from WebRTC
... in Feb of this year, the Speech team at MS sent feedback

<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0015.html

Travis_MSFT: they expressed concern of enumerating device characteristics of the Camera
... those things are conspicuously absent from the WebRTC proposal
... with getUserMedia(), we now have a way to put user consent
... which was lacking before

<bryan> privacy concerns due to the use of this info for fingerprinting or otherwise?

Travis_MSFT: we can hide things behind that layer
... direct access to the Stream rather than brokering

darobin: quite a lot of agreement on that

<Travis_MSFT> At the same time, the recent Streams proposal [http://html5labs.interoperabilitybridges.com/streamsapi/] is another potential vehicle for previewing a capture device--it's lightweight and works for the basic scenario of hooking a capture device up to a VIDEO tag. We should think about the benefit that a Stream might provide both in terms of recordings as well as preview. Of course, the use

<Travis_MSFT> of MediaStream will certainly be necessary if the local capture scenario transitions into an RTC scenario.

<bryan> http://html5labs.interoperabilitybridges.com/streamsapi/

Travis_MSFT: consuming Streams instead of Fixed Blobs could be useful
... either for getting or previewing

[ a couple of people have looked at the Streams proposal ]

adrianba: the WebApps group agreed to adopt it as a deliverable

AnssiK: is WebRTC discussing using it?

[ Maybe ]

Travis_MSFT: the other thing from the speech people
... was the concept of endpointing
... when i open myphone
... and perform a search
... when i click here
... it's listening to me, and it knows when i stop talking
... it can make value judgments about when to capture data
... very useful for speech recognition


Travis_MSFT: i don't have a solution, but we have an interest
... if we consider MediaStream as the starting point
... there are scenario conflicts that are interesting that i'd like to bring up

<dom> WebRTC Editors draft

Travis_MSFT: a MediaStream represents a continuous source of Video and/or Audio
... there's a series of tracks
... (that's in flux)

<dom> WebRTC Media Stream

Travis_MSFT: and it's possible to turn them on or off
... I couldn't come up with a UC for turning off Audio when i'm just recording Audio
... i'd just stop recording Audio in that case
... it just seems strange

<bryan> How does the stream API proposal relate to what is referenced from the File API as the "Stream API" (http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html)

Travis_MSFT: as jcantera mentioned,
... devices tend to have an optional mode they switch to to take a picture
... the WebRTC proposal is missing a way to switch into that mode

darobin: and it prevents a way to get good pictures
... because the time cost results in downgrading your camera by 5 years

dom: and it has privacy concerns

Travis_MSFT: our local proposal needs to have a way to "take a picutre"


scribe: there's a concept of whether a stream is Mutable/immutable
... as to whether tracks can be dynamically added/removed from a Stream
... which this group should provide feedback
... when yous tart recording from the camera, you merge audio+video

<fjh> s/picture"/picture", switching to higher resolution mode for video camera/

scribe: and having to split that up requires a lot more mwork

s/yous tart/you start/


scribe: three more things

Travis_MSFT: the spec says you Record
... taking things from the Stream and start to save it to memory/disk
... the api today provides the ability to create overlapped recordings
... i don't know if that's intentional, or just fallout
... i'm not sure it makes a lot of sense
... for end users to create multiple recordings, and start and stop them
... the api might benefit from refactoring

darobin: i don't know of a professional camera that allows that

Travis_MSFT: I attended WebRTC as an observer on Tuesday
... everyone was in agreement that not having a way to stop a recording was crucial
... you start a recording, and get a blob back
... and it just keeps going, for hours
... there's a lot of small capabilities we might add: volume control
... image stabilization, video effects, brightness, saturation
... things you might see in camera settings
... i have a desigfn philosophy, build something for the common scenarios, and make them easy
... but for other things, push them out to v2
... but keep them in mind


Travis_MSFT: i'm suggesting to consider more, an then make a smart selection of a subset
... and push the others out of scope into v2

darobin: we might support 0 in the first version

Travis_MSFT: also viable

darobin: it seems orthogonal to capturing stuff

<Zakim> fjh, you wanted to mention consent item

fjh: one q, one c
... on privacy
... i looked at the EU opinion on privacy
... and have an email concerning consent on the mailing list
... consent needs to be informed
... i'm not sure information about what's going to happen
... is presented
... the other, is privacy implications to metadata
... i'm not sure you have an opinion on it
... i think you're saying none of it provides any

darobin: in terms of things
... the api won't expose metadata
... but the device might embed exif
... whicih might disclose your geolocation

<fjh> note on privacy and consent, http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf


richt: our objectives...
... specifically local media capture
... you've talked about local UCs
... not excessively redoing
... WebRTC has stuff
... there is the ability to copy to canvas
... you can detect silence w/ audio apis
... I want to recapture those UCs because they got lost in WebRTC

<fjh> privacy and consent, correct link -> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0091/dap-privacy-wp187.pdf

ACTION Travis to submit UCs

<trackbot> Created ACTION-461 - Submit UCs [on Travis Leithead - due 2011-11-10].

<dom> action-461?

<trackbot> ACTION-461 -- Travis Leithead to submit UCs -- due 2011-11-10 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/461

<fjh> s/note on privacy and consent,/ignore this line/

ACTION rich to submit UCs

<trackbot> Sorry, couldn't find user - rich

ACTION richt to submit UCs

<trackbot> Created ACTION-462 - Submit UCs [on Richard Tibbett - due 2011-11-10].

bryan: the stream api was discussed in webapps in the context of fileapi
... there's a reference coming from whatwg
... the goal is to ensure
... we apply them consistently in as many places as possible
... writing, reading, pushing, etc.
... is that a goal?

trackbot: i share richt 's view that we should reuse things from the platform

<trackbot> Sorry, Josh_Soref, I don't understand 'trackbot: i share richt 's view that we should reuse things from the platform'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

darobin: i think we can make progress!
... you didn't talk about html Media Capture

<fjh> thanks to travis for comments and work on this

Travis_MSFT: it's come up internally
... in terms of UCs
... personally
... there is sufficient room on the web for declarative (not requiring scripts) and imperative (programmatic)
... and i don't think they have to be mutually exclusive

darobin: one thing that would be useful is
... finalizing that hint
... again, first suggestion will probably ship

sicking: our current approach
... first step is deciding on a UI
... for declarative
... once we get our UX people
... we'll figure out attributes in order to support those UCs
... a constraint, if we need a dramatically different page ui
... then we'll need a way to do things which lets pages opt in
... because that would otherwise break page layout

darobin: any early drafts?

sicking: not really

Travis_MSFT: i thought through this a bit
... when you want to capture only audio
... it seems entirely different from video
... and it seems fairly hard w/o a hint

richt: android stock browser has a declarative approach
... and things get passed off to the native control
... which controls resolution, quality, etc
... a user cchoice

darobin: which is good, right?

[ Yes ]

richt: i agree, we do a design, and see if there are any hints
... sicking is right, we get the UI right, and then decide on params

darobin: we won't be working on HTML MC before we get UI feedback

<Zakim> dom, you wanted to talk about next steps wrt WebRTC TF

dom: we talked about getUserMedia()
... we're interested in a Joint TF
... that has logistic consenquences
... a new TF to join, a new mailinglist
... WebRTC hasn't agree to it yet
... darobin and i were at WebRTC where it was discussed, but not approved

ACTION darobin to draft a joint TF proposal with WebRTC

<trackbot> Sorry, couldn't find user - darobin

dom: one thing we'll need to do is provide resources, such as an editor

adrianba: we found Travis_MSFT

fjh: what's next?


ACTION berjon to draft a joint TF proposal with WebRTC

<trackbot> Created ACTION-463 - Draft a joint TF proposal with WebRTC [on Robin Berjon - due 2011-11-10].

dom: We'll need the right API to get-web-user-media nicely for WebRTC to build on

darobin: since they're coming from the network point of view
... they don't care much
... but we'll need to provide something, otherwise our UC might be painful

Travis_MSFT: I have thoughts

richt: they're also on a fast schedule

darobin: i think everyone's happy about that

dom: Travis_MSFT, you'll be on calls?

fjh: our calls are 10a Eastern

dom: but TF might be different

fjh: back at 1pm
... talking about sensors
... we'll skip network info

darobin: we'll move network info to tomorrow morning?
... in the second session

[ Lunch ]

<Travis_MSFT> scribe: Travis_MSFT

[Round of introductions]


Sensor API

<dom> Sensors API editors draft

<fjh> s/Topic: Sensors//

jcantera: I will be presenting the Sensors API.
... current draft is 2 months old.
... we've been creatingn a prototype to demostrate the feasability of the current specification

<bryan> The link (http://dev.w3.org/2009/dap/sensors.html) for "Latest editor's draft:" is incorrect

jcantera: I will be presenting the results of the prototype. Later I will present the conclusions that represent the current issues.

darobin: you have demos?
... yes. Will show them
... First, establish a connection to a sensor.
... Then you start watching the sensor (having provided the options, such as interval)
... Then you get info via an event handler.

<Josh_Soref> s/... yes./jcantera: yes./

darobin: There's also a way to determine what sensors are available.
... list the sensors.
... The prototype is on Android. Using SDK and NDK to get access to the sensors
... NDK to be able to interact with the sensors in C++.

<fjh> http://developer.android.com/sdk/ndk/index.html

darobin: The also use a web browser component.


scribe: From the web view, a JavaScript->Java conversion takes place, then a Java->C++ to get to the sensors themselves.
... Sensor metadata is partially implement.
... [presenting the demo]

<fjh> jose notes logical sensors provide a view on other real sensors, e.g. linearAcceleration ignores gravity

<ernesto_jimenez> s/Present+Balaji_NV/Present+ Balaji_NV/

<dom> [Sensor.name and Sensor.vendor create fingerprint issues]

scribe: units appear to be different even among different Android devices.
... not sure if they are using different units.

[all] applause!

scribe: any requests or anything else you'd like to see?

richt: This appears to look like the system infomation API?

dom: There is some overlap, though it's not exactly the same. I share some of your concerns.

<Marcos> +q Marcos

dom: one of the concerns with system API is using a vocabulary-based approach and an API that relies on that vocabulary.

richt: system API had too many features...
... but it's design paradigms are valid.
... With the sensors API, some of the richness is now lost in this version

Marcos: I have a similar question: If I have multiple sensors (like in my car and out), how do I determine that.
... How much feedback are you looking for?

darobin: all feedback.

Marcos: can you just say "new Sensor" and then get the options?
... I'm a little worried that this is tied too much to mobile devices...
... Can we make this more of a general use API. Specifically looking at Magnetic fields interface....

<richt> this definitely relates to the "web of things" concept.

Marcos: Seems to duplicate what other WG's are doing (orientation)

<richt> i.e. a sensor is a thing (a service).

jcantera: One of the open issues is to rename the interfaces to avoid confusion.

Marcos: Can you capture all 100,000 sensor types? What is the scope of this specificiation?

<Josh_Soref> s/specificiation/specification

jcantera: We've been discussing this. Like discovery of sensors that are not on the local device

Marcos: Like sensors composed of other sensors?

dom: Every year a new device comes to market with a new sensor

jcantera: If there is some kind of logical sensor--an aggregate of the physical sensors, you could deal with it that way.
... the API is flexiable enough to be extensible.

<Zakim> Josh_Soref, you wanted to ask what will you do with the data on average?

jfh: Point is it's not a generic API that can handle future sensors.

<fjh> s/jfh/fjh/

Josh_Soref: What do you expect to be able to do with the sensors?
... Discovery of the sensors independently may not have sufficient value and could lead to privacy concerns

<fjh> s/Point is it's not a generic/I believe Marcos is saying it should be a generic/

Josh_Soref: Also, no two devices have the same level of accuracy. On the web it's nice to have an API that's slightly less capable, but can be used on the Web.
... When the high-precision device is available in a limited set of devices, then it's not as useful on the web.
... Example, Geoloc. has a precision. Noted, that precision might not be to the inch. Geoloc spec has a generic location.

<Marcos> +q Marcos

<dom> [sensors.list() would at the very least minimization, by which you could get a list of sensors per type]

Josh_Soref: A game might be able to say it supports only specific devices w/sensors, but that's exclusionary rather than inclusive on the Web.

<fjh> s/ack nvbalji//

Balaji: having a generic sensors API--we should be careful.
... privacy requirements are different.
... if trying to do a generic service, we should be careful about privacy.
... where everything can be discovered and used in the same way.

Marcos: that's orthogonal to the privacy problem.

fjh: getting a little confused.
... Is this an attempt to be a generic sensor intrface that can handle many things; I also think Marcos was suggesting this.

<dom> s/intrface/interface/

<nvbalaji> Privacy sensor may have different privacy requirement compared to Location sensor

fjh: but if this is so generic we might not be able to handle the plethora of devices.
... didn't really understand Josh's comments
... I understand that precision matters.

Josh_Soref: the raw orientation scares me.
... I don't see any use cases for that other than having-or-not that sensor.

Marcos: vendor attribute -- I have concerns about that as well.,

<Josh_Soref> +!

<dom> a big +1 on not duplicating deviceorientation

<Josh_Soref> s/+!//

<Josh_Soref> +1

<dom> and another +1 on exposing vendor

Marcos: A vendor identification should not be exposed because it risks that an app can be built around just that vendor.

<fjh> vendor issue for fingerprinting

jcantera: It does't invalidate the API

<Josh_Soref> s/does't/doesn't/

<dom> s/jcantera:/jcantera:/

Marcos: Just because the data is there, doesn't mean it must be exposed.

Josh_Soref: isn't this already resolved?

fjh: Yes, resolved.

Marcos: Android has this exposed. I wonder why they added it? What was there use case?

<richt> lgombos: do we have vendor interest in implementing this?

<dom> [or maybe they added it because they could; that's what it sounds like we would be doing as well]

bryan: Be careful to avoid not standardizing a device just because it might be disenfranchied.
... For use cases, in a lot of cases, you want to personalize your experience (see augmented reality, games, etc.)
... yes, don't dup functionality exposed elsewhere.
... Web platform will suffer if this data is exposed elsewhere (but not on the web).

Alex Russel (google): Two contentions points:

<fjh> slightlyoff is alex russel

scribe: gradients of potential specificity is related to the data type itself.

<richt> s/alex russel/alex russell/

<fjh> s/Russel/Russell/

scribe: In input type=file we don't ask for the type, we let the user determine.
... Rather than a specific API, this seems more like markup
... Should this be an API? With Web Intents, there may be a way for service description/discovery that is parallel to other ssystems in the platform.

<Josh_Soref> s/ssystems/systems/

darobin: Interacting with the data-type is useful. Not sure about translating into markup.

AR: Markup provides a way to describe defualt user-interaction in UA's that don't support it.

<richt> agree that this could be reduced to the problem of providing data in Web Intents / Discovery

AR: since markup is not specific by default, it's a good starting point.

Marcos: agree generally.
... We want to get at the data directly and poll it.
... We have a permission model, but often we want to get beyond that to the data and not have the permission model get in the way.

AR: We have an eventing model -- it's tuned for use on the markup/DOM

darobin: One issue with markup is that fallback with input type=location is a text field.
... not a great way of entering data.

Josh_Soref: But not too bad. I'd rather paste into one text field.

AR: Form serialization algo. determins how to serialize the data without causing developers to do extra work.

darobin: If you get arbirary values instead of what you expect, it's not useful to the developer.

AR: Having a fallback doesn't mean that we hang everything off a single value property.

<fjh> s/arbirary/arbitrary/

darobin: Yes, but you end up doing just as much work by the developer.

<Josh_Soref> i|Two contentions points|AR: Alex Russell (Google)|

Jim Steel (sensor platforms): Want to give my vendor perspective.

scribe: Sensors are tuned per the device.

<fjh> Alex notes javascript on the wire is slow and punative

scribe: Developer would like to know what the sensors confidence degree is.

darobin: Speaking to the Intents point...
... Will happen in a joint TF between us and Web Apps.

<Josh_Soref> s|Alex Russel (google): Two|AR: Two|

darobin: Jose provided a great demo earlier.
... before moving on with "should we do this with Intents", I'd like to see an example case.

<Josh_Soref> i|give my vendor perspective|JimS: Jim Steel (sensor platforms)|

darobin: Can you provide such an exmaple?

<fjh> Much thanks to Jose for demo and work on this

<Josh_Soref> s/exmaple/example/

<Josh_Soref> s/Steel/Steele/

<Josh_Soref> s/Steel/Steele/

<scribe> ACTION: darobin to follow up with Alex Russell on getting an example of sensors on Intents. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action03]

<trackbot> Sorry, couldn't find user - darobin

<Josh_Soref> s|Jim Steele (sensor platforms): Want|JimS: Want|

<scribe> ACTION: berjon to follow up with Alex Russell on getting an example of sensors on Intents. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action04]

<trackbot> Created ACTION-464 - Follow up with Alex Russell on getting an example of sensors on Intents. [on Robin Berjon - due 2011-11-10].

jcantera: If web devs don't get the data, they'll turn to other sources.

<fjh> ISSUE: is low level data necessary for all sensor APIs, which ones have use cases and which not

<trackbot> Created ISSUE-122 - Is low level data necessary for all sensor APIs, which ones have use cases and which not ; please complete additional details at http://www.w3.org/2009/dap/track/issues/122/edit .

darobin: Intents does sound like a potential contender

<AnssiK> there's a typo in the Sensor API example, s/session/sensorConnection/ should fix it

Josh_Soref: Orientation was the one I noted that was so specific.

<scribe> ACTION: jcantera to present use cases for the Sensors API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action05]

<trackbot> Created ACTION-465 - Present use cases for the Sensors API [on Jose Manuel Cantera Fonseca - due 2011-11-10].

<Anders> Here is the link to web intents demo that Claes posted to the mailing list http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0009.html

<fjh> ACTION-465: specifically use cases for need for raw lower level data, e.g. orientation

<trackbot> ACTION-465 Present use cases for the Sensors API notes added

Josh_Soref: If there's a requirement to get precision to 10 digits, and you right code that gets to 10 of the 10 digits, but my device only supports 6 digits, then my code might break.

<dom> s/right code/write code/

darobin: sounds like folks that design websites to 1280 width and expecting it to work...

Josh_Soref: I can still use a device as long as it doesn't refuse to work without the same precision as specified.

darobin: There's certainly a "don't be stupid" mentality that should be noted.
... Great job on the demo. This is a process that moves things forward.
... There are lot of folks in the room that work on stuff like a WebOS... Would love their perspective.

<Josh_Soref> s/WebOS/Web OS/

sicking: I like the approach of having a low-level API. This proposal is good. I don't know enough about the other prior art, though it sounds like there's a lot of overlap.
... I see good use cases for proximity sensors.
... Ambient light sensors--not sure. Might want the OS to handle that.

<Josh_Soref> +1

darobin: Might be done with a media query instead.

<fjh> s/prior art/work/

sicking: sounds like a good idea.
... I like the idea of exposing this as an element, but don't know what it would look like.
... proximity is a simple one that should just be exposed. Might just have two values -- proximiate or not.

<Josh_Soref> s/proximiate/proximate/

sicking: current spec is way more than what is likely needed.
... interesting to experiment with this.

<dom> [Android is supposed to give you 0 or 1 for proximity; yet my Nexus reports "9" - go figure]

sicking: The UA might have trouble providing a notification for the use of such sensors.

<fjh> privacy is certainly a concern with raw generic sensor API

dom: One point is that a security model is necessary depending on the type of sensor.
... proximity... may not need security.
... but some others may.
... back to the question of whether a generic API is useful, or if specific APIs are needed.

<Josh_Soref> (light probably does)

sicking: I like the idea of putting this in an extension and seeing what happens.

<dsr_> Are native apps using this kind of sensor data and if so what for? If there are some compelling use cases there we should take a look.

<npdoty> generic sensor api would likely affect fingerprinting in addition to revealing potentially sensitive sensor data

richt: Sensors are kinda like services. How to connect to the sensor, get data from it... Security lies in the process of establishing a connection.

<bryan> the ambient sensors and proximity are unlikely to have any privacy considerations as the information will be so random and constantly changing, that it would have very little value for fingerprinting

darobin: Anyone else have an opinion?

<Josh_Soref> there are things one can do w/ ambient

<npdoty> bryan, I mean that just knowing which combination of sensors are available on the device will enable fingerprinting

<Josh_Soref> ... if there's a light flashing outside, it could be deciphered

<richt> So I wonder if we can reduce the security problem to one of 'connecting' to sensors and reducing the transmission problem to one of transmitting some data: json or otherwise.

<richt> ...which is why the Web Intents / Discovery angle is interesting here.

<npdoty> and native apps (like Color) have used otherwise 'random' ambient sensor values to determine whether one device is near another, which has substantial privacy concerns

<bryan> acceleration and orientation are similar... I see very little privacy concern with these as they will also be largely random across a number of users

dom: There is interest in implementations, so that's positive progress.

<dom> Accelerometer Sensor Sample from Microsoft Windows 8 Metro app

<dom> Proximity Sample from MS Windows 8 Metro

<Josh_Soref> Scribe: Josh_Soref

bryan: wrt privacy

<bryan> the probability that one user has an app that can access another user's sensors without opt-in

bryan: i can't see how you can get something which is so random across users

s/...i/... i/

scribe: would someone trick someone into installing an app?
... we need to focus on static attributes

dom: sensors are privacy risks much beyond fingerprinting
... gps are sensors
... you can payload a computer sitting nex to it
... some sensors like proximity, you have less than others

<Travis_MSFT> Travis_MSFT: Link to information about Windows 8 Sensors access through JavaScript (API): http://msdn.microsoft.com/en-us/library/windows/apps/windows.devices.sensors(v=VS.85).aspx

<Travis_MSFT> scribe: Travis_MSFT

<Marcos> +q Marcos

bryan: Still don't see significant privacy concerns

dom: key point is that depending on the sensor, there's different privacy concerns.

<Zakim> fjh, you wanted to ask about agenda and webintents

fjh: I agree with Dom, but I think this is a bit premature given where we are. Somethings may yet change.
... Thanks Jose, for all your work in the demo.

<Josh_Soref> s/Dom/dom/

<npdoty> I could go off the q and move fingerprinting discussion to email if chairs would prefer

npdoty: working for team on privacy
... Can't address the concern about not caring about privacy :)
... my point on privacy: For a generic API, just "knowing" what is available is a risk
... Plugins and Fonts have this problem, and introducing a new generic api for sensors will have a privacy concerns.

<sicking> q`

<Josh_Soref> s/q`//

<Josh_Soref> Scribe: Josh_Soref

sicking: when we implemented Joystick
... we don't expose Joystick to the web page

<bryan> we have to be able to adapt to the device capabilities by knowing them, unless we are to require only one set of device capabilities on all devices

sicking: until the user uses the Joystick

<darobin> https://wiki.mozilla.org/JoystickAPI

<Travis_MSFT> scribe: Travis_MSFT

bryan: sicking do you think we shouldn't support feature detection?

sicking: didn't say taht.

<Josh_Soref> s/taht/that/

<fjh> example from jonas is that you can know there is joystick but don't now brand and other details

sicking: We're adding joysticks, but are trying to do so without exposing a fingerprinting risk.

dom: two things: detecting the joysticks, and it's characteristics

<Josh_Soref> s/it's/its/

sicking: It does put some limitations on the web developers.
... could be done slightly better. But we should do things that are good.

bryan: I'd like to know whether the device supports front/back camera

sicking: the UA exposes that to the User, but the page doesn't know what the buttons are.
... buttons being the front/back

darobin: wrapping up on sensors discussion?

fjh: Jose did you have a followup action?
... you took an action to get details on use cases for why we need a higher-level api

<Josh_Soref> s/higher/lower/

jcantera: There's a slightly old draft. We have new feedback from implementations, etc., and need to update the draft.
... including info from the mailing list.
... those are the next steps.

<nvbalaji> actions?

darobin: such as doing a plugin for experimentation.
... we also have the feedback from web intents.
... lots of next steps :)

dom: schedule?

<fjh> ACTION: jcantera to update Sensor's API based on feedback, implementation etc [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action06]

<trackbot> Created ACTION-466 - Update Sensor's API based on feedback, implementation etc [on Jose Manuel Cantera Fonseca - due 2011-11-10].

darobin: I don't think we've looked deeply enough at web intents.

richt: If we use Intents, do we have to define the interface?

darobin: yes you still need to know how to get the data.

richt: Intents allow us to make sensors more decentralized. You don't need to define all the formats, etc. up front.

fjh: We wanted implementor feedback...so, what's the timeframe for this?

sicking: I don't have a specific time. Development can take awhile.
... I think proximity and ambient light should be exposed.
... exposed via an API tailored to the experience.

<fjh> ACTION: dom to make proposal for proximity and ambient [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action07]

<trackbot> Created ACTION-467 - make proposal for proximity and ambient [on Dominique Hazaël-Massieux - due 2011-11-10].

<dom> (I think proximity would be better served by a simple "proximity" event)

dsr__: For ambient light, seems like a styling feature. Could be defined by CSS in media queries.

<fjh> ACTION-467" ambient light

<fjh> ACTION-467: ambient light

<trackbot> ACTION-467 make proposal for proximity and ambient notes added

<fjh> s/ACTION-467* ambient light//

Marcos: Controls other actuators in the OS (dim the display, keyboard backlight)

dom: though you could consider expose those as well.

<Josh_Soref> s/ACTION-467" ambient light//

darobin: Thanks again Jose.

<fjh> Again thanks Jose

<fjh> s/...Minutes from 26 October 2011/RESOLUTION: Minutes from 26 October 2011/

jcantera: Referrig to discovery, the list sensors method opens the door to discovery if the implementation decides to.

<dom> s/though you could consider expose those as well/you could consider that keyboard backlight would be controlled by CSS in that case/

jcantera: Regarding extensility, I feel that it is extensible.

<fjh> s/... Minutes from 26 October 2011/RESOLUTION: Minutes from 26 October 2011/

dom: many of these things are still being explored.

Messaging API

darobin: Using SMS, etc., to send messages. It's been significantly redesigned many times over.
... Meh.

<dom> "meh-tality"

darobin: Some folks are starting to implement as it relates to Web OS.
... Interested to know what implementors designs are looking like.

sicking: WebSMS prototype is almost done.
... It's for SMS-only (not generic)

<sicking> https://wiki.mozilla.org/WebAPI/WebSMS

sicking: This is an API that requires additional permissions. We wouldn't be comfortable simply saying "x page wants to send SMS".
... haven't proposed it anywhere yet.

<fjh> sicking notes security model not known yet, hence not deployed

darobin: in other places, security model parallels "mailto:"

<dom> [WebSMS still has SMSManager::send() though]

sicking: Now thinking of using sms: -based links (may needs a spec for that)
... enum messages, delete messages, basic search, functionality
... May never expose this to web pages.

darobin: my view of the security model might be...
... some apps run in browser-context and can get some extra privelges, though sites may not get that priveledge.

<Marcos> +q marcos

sicking: Would be nice to have folks install their own SMS apps.

<dom> [FWIW, WebSMS looks closer to what we moved away from due to security concerns]

sicking: one security model is that the browser has a trust relationship with certain web stores.
... stores may need to be EV certified.
... problem with text message, is there's easy money to be made.
... large incentive which influences the security model.
... may also have an override for users, but behind non-accessible UI to prevent accidental use.

darobin: History: started with a powerful API, but trimmed due to security. Ended up with SMS:

<Josh_Soref> s/SMS:/"sms:"/

<fjh> see http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#threats for premium rate abuse "abuse case"

darobin: Current design allows you to add Blobs to an SMS.

fjh: In our policy use doc. We have documented abuse cases.

<Marcos> -q

<dom> Premium Rate Abuse in Policy Req documents

richt: what's the use case for letting a web app manage my text messages?

<npdoty> there is an SMS uri scheme IETF draft (apologies if this is already well-known to the group) http://tools.ietf.org/html/draft-wilde-sms-uri-20

richt: URL based SMS: has the option of giving the control back to the user.
... not convinced that management of SMS is necessary.
... Opera is not very interested at this stage.

darobin: Often we're asked if we only do Web API or if we do APIs for other contexts.
... usually we say "web apis"

sicking: We're not convinced that this should be a web api either.
... use case is that at least one app will need to manage SMS. Since we're building on Web Platform, we needed it.

<Josh_Soref> [ http://en.wikipedia.org/wiki/Wholesale_Applications_Community - WAC ]

bryan: We have implemented trust models, etc., and have done a lot of work in this space; it's all be unravelled. Now, we could live with sms:

<Josh_Soref> s/be/been/

bryan: now we have devices who's OS is a web platform. If there can be pre-arranged trust relationships, we should go ahead and define what that should look like, or we accept fragmentation in the marketplace.

<Marcos> +q

dom: charter is clear that we focus on web apis.
... an API that can be implemented in a current web browser.

<Marcos> -q

<Josh_Soref> ack

<Josh_Soref> s/ack//

spoussa: in the tyson project, we defined a lot of APIs around messaging.

<Soonho> s/tyson/tizen/

spoussa: hopefully we can come out and publish those soon.

Josh: but W3C will not be interested in that (since they're not Web APIs)

<Cathy> s/tyson/tizen

dom: we're talking about DAP (not W3C in general)

darobin: trying to do Web OS and Web APIs at the same time is problematic. So we stay stricly Web API-based.
... If there's sufficient interest, talk to someone at W3C to start a group...
... It sounds like we're keeping Web Messaging "on the shelf"

richt: I don't think the web messaging (sms) belongs on the ubiquitous Web.

<richt> I see a place for WebSMS but it's not on the ubiquitous web.

sicking: At mozilla, we've worked on web intents, where the first use case is messaging (e.g., sharing)

<dom> very good point that our messaging API would probably be completely overtaken by Web Intents/Activities

sicking: user can choose which message channel they want to use, but to base that on Web Intents.

darobin: makes sense to look at use cases.
... Anything you can submit/send

<dom> ACTION: Robin to look as Mozilla Labs Sharing experimentation re Messaging API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action08]

<trackbot> Created ACTION-468 - Look as Mozilla Labs Sharing experimentation re Messaging API [on Robin Berjon - due 2011-11-10].

<Josh_Soref> http://mozillalabs.com/blog/2011/10/firefox-share-alpha-%E2%80%94-the-next-step-for-fast-sharing-in-firefox/

Suresh: regarding security model problems: have we documented the concerns so that we can try to work with/around them?

dom: we have one example in the policy document.

<fjh> see policy requirements draft on abuse cases

<fjh> http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#premium-rate-abus

richt: another concern is to put the sms technology into the web (we should do something more generic, not tied to the specific technology)

<dsr__> The Mozilla share intent is documented at http://webintents.org/share

<dsr__> s/Mozilla//

nwidell: mailto:++ is this something that we're also dropping, or is it solved by Web Intents.

darobin: It might be solved by Web Intents
... haven't heard lots of feedback desiring this...

<Zakim> dom, you wanted to remind we have an existing api without sms management

dom: if there is convergence on dropping web messaging in favor of Web Intents, are there any objections?

darobin: Any objections to updating the spec to indicate that it's not inprogress.

<Josh_Soref> s/inprogress../in progress?/

jcantera: I object. You are sending the message that it's not usefull work. It's dangerous to say that.

<richt> darobin, this must be done.

jcantera: you are sending that message (no pun)
... I think SMS is a useful approach

dom: if you are saying we should document all good approaches...

darobin: we have lots of drafts out there, it leads to conclusion.

<Josh_Soref> s/conclusion/confusion/

darobin: other people pick up on our drafts. We want to clarify that "this spec" is not something that DAP is pursuing.
... we put a note in the spec. We can finesse the wording. When we stop working on something, we need to be clear that we're not following that path.

<dom> [FWIW, I think the current Messaging API wouldn't actually address most of jcantera's use cases]

darobin: let's find the wording that is acceptable.

<Zakim> bryan, you wanted to ask how does Web Intents allow me to send an MMS?

bryan: Looks like a lot of stuff in our charter could merge together... How will Web Intents subsume this stuff?
... I'd love to have an answer to this.
... I'd suggest that we hold our decision on the messaging spec.

<darobin> ACTION: Robin to make a CfC for shelving Messaging [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action09]

<trackbot> Created ACTION-469 - Make a CfC for shelving Messaging [on Robin Berjon - due 2011-11-10].

[Short Break]

<Josh_Soref> Scribe: Josh_Soref

fjh: we should start again

DAP Architectural Issues

fjh: we've invited members of TAB

noah: Noah Mendelson, TAG Chair

henry: Henry Thomson, U of Edinburg

peterl: Peter Lins, HP





[ fjh presents: http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf ]

[ Slide "Approach" ]

fjh: we talked about using WebIDL and binding to HTTP

[ Slides inputs re:Arch ]


fjh: Calendar could be Calendar on Web instead of on Device
... we want to avoid having two definitions
... we could make WebIDL produce JS bindings
... we decided in Prague that we wanted to explore this
... and then we forgot about it

[ It came up again in Paris ]

[ Slide "Next Steps" ]

fjh: things like Contacts says it could be local or remote in spec
... but i'm not sure it says enough
... should we seriously consider an http-webidl binding
... then there's discovery (new to the WG, after Recharter)


fjh: Security and Privacy are a bit different
... are we ok w/ doing what we're doing - JS w/ WebIDL
... we don't want to rework
... can we get an approach that satisfies other requirements
... I have a separate topic on Privacy, for later
... for now, do we need to do something specific for resources on the web
... if so, how?

[ End of Slides ]

X1: where are you on timeline?

darobin: we're not very advanced
... we have some minimal research
... it was contentious and we found a way of not committing
... if someone comes with something either way, it would sway the balance
... initial feedback was ReSTful
... it initially surfaced that unless you constrained WebIDL
... it quickly becomes JSON RPC
... http based, but not ReST

noah: I wonder if you're overconstraining the answers
... assuming that the right thing is the IDL
... and focus more on wire
... because it tends to lead you to SOAP like
... JS is capable of very fine grained
... i wonder if the right thing is to say "some things are ReST"
... and documented in "WADL"
... and some things are JS
... "course grained streaming operations"
... you could imagine a JS based api to the camera that let you pull bits out if you want to
... whereas with ReST you'll want a streaming thing

i|Edinburg|ashok: Ashok Malhotra, Oracle|


noah: it feels like a Calendar based API
... in ReST, something would stream back
... saying you'll start with JS based
... you'll get something different

fjh: what about URIs
... and what about data minimization

darobin: there's a conflict between minimization and ReST
... but there's a problem involving URIs giving different output

noah: if you're going after someone's calendar through an HTTP link
... you don't want to do 10 GETs
... maybe you create a more complicated HTTP uri

<bryan> Frederick, the links in your slides don't work. Can you put them into IRC?

plinss: if you ignore that now
... you'll design things that will never work with ReST

noah: my prejudice will be
... there are certain tangible benefits of URIs
... and accessing via ReST
... - if you have a Camera on a machine
... and you can access it remotely
... When you name things with URIs that support http
... you can access it transparently
... there are times when our little devices want to act as servers
... if you're a semantic web person
... the very fact that you can name it with URIs is useful
... saying this <uri> is broken
... there are pieces you can access with uri's that you can't with JS

fjh: sicking thoughts?

sicking: if you access with a URI, what's the security model?

darobin: there's important background
... initially this was tied to WebIntroducer
... which is a way of introducing a service to another

<fjh> http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf

darobin: and what you get is an http endpoint
... which is opaque
... the user was asked to provide a relationship
... and you get a version which opaquely describes the thing the user chose
... WebIntroducer faded and is replaced by WebIntents
... this change makes http things less attractive for us

Marcos: you're talking about WebIntents like it's a sure thing

darobin: it indeed isn't
... but the way things are headed, Mozilla Activities don't give you a URI either
... it seems like mozilla's list is moving away from user mediation
... and closer toward web workers
... with things thrown over the wall

noah: in general, identification should be orthogonal to Access Control
... that not everyone should be able to get at my plane reservation
... isn't a reason for it not to be on the web
... don't put credential granters / privacy violations into the url itself
... but do have Access Controls so that the wrong people can't access the content of a URI

<dom> Linking and access control in the WWW Architecture Document

noah: saying we need Access Control isn't a reason not to use URIs

sicking: I see the point of Access Control
... that you can't send a URI to your vendor because they can't access it

noah: putting credentials into a uri (like Google Docs) is controversial
... but even if they're separate
... maybe i identify myself as "noah"
... it doesn't mean i shouldn't be able to have someone send me the uri to their camera
... and i access it with my identity and see their "snow-fall"

fjh: Battery is moving along
... and there's no reason for it to be ReSTful'


scribe: similarly, vibrator doesn't need to be ReSTful

noah: i remember 30 years ago that Printer vendors looked puzzled when asked about Web Servers on them
... and today i can talk to an average printer over HTTP

fjh: so, "it could be handy to ask it over the web?"

noah: i'm saying weigh the costs,
... and consider possible uses/benefits
... and maybe if there's some benefit, maybe it should be done

<richt> I'm in complete agreement with Noah, btw.

fjh: what if we said "ReST is v2?"

Marcos: it has to be based on Use Cases
... noah's example is great
... the gemalto people are running servers on Smart Cards

<richt> well, I say "complete agreement". I think I'm in agreement but I missed some of the conversation.

Marcos: there are really cool things you can do w/ ReST

noah: and i think there are cases where it's a really stupid idea
... like access to the screen buffer or cpu with GET/POST

<bryan> Are device-local resources to be considered equal in terms of value to cloud-based resources? Is there a difference in trust for the user? Do I trust a cloud-based service any more than I trust the device in my hands, or the Web server via which I accessed the app that wants to access the information on the device in my hands?

i|resources|bryan: questions re:Arch on web|

bryan: if i went to a web page, do i trust it less than i trust something in the cloud?

<bryan> If we were to use REST for access to device-local resources, is there any difference to accessing remote resources? If I have a URI to a camera (local or remote), how does the browser ensure the camera owner authorizes the use of that camera?

bryan: that determines whether or not we consider the device to be part of the web

<fjh> Note - issue with REST interface for DAP APIs might be minimization


ht: if you think that a device is implicitly on the web
... - each of these things is a little web server
... changes the balance of power
... in a way that i don't think you want to go to right now
... the benefits that noah was talking about
... arises if the device is addressible
... for the forseeable future, they won't be addressible

<DKA> +.5 to henry

ht: that you want to have access from any server on the web to any device on the web
... given the scale of the task in front of you
... i think you'd be entirely justified to say Device APIs are for the Device
... plinss 's right, if you do this, then it'll be awkward later at best

noah: I asked you to think about it, and you did

dsr__: in many cases, JS makes sense
... sometimes ReSTful apis make sense
... but it involves looking at UCs

fjh: i'm concerned, W3C is talking about going `fast`

plinss: I like bryan 's point about trust
... there are States where if you get pulled over for a Traffic Stop
... the police have the right to plug something into your device
... i'd like the device to be able to not trust that

<ht> s/then it'll/then in a few cases it'll/

plinss: i accept there's a pragmatic approach
... maybe not making the battery available
... think about "were i to access this over http, what would my access pattern be?"
... such that you could design an api to insert to support that
... maybe the local code doesn't change
... you don't have to write that with the mechanism today
... but you're taken care of later by using that bit in a Constructor

<bryan> If my device has an access point it has exposed, e.g. for a service as envisoned by Web and TV IG, or a camera, should a local app be given less permission than a remote app, or are they equal given user permission for them to access the local resource?

bryan: Discovery of devices in the home...

<fjh> peter gave example of abuse case of local data, having law enforcement obtain information from device when that isn't appropriate because it is local

bryan: if a user has given permission, why shouldn't an app be able to access the resource?

sicking: trust issues
... even if we do v1 in JS
... and v2 which is http based
... even if we knew we were going ReSTful

<ht> +1 to bryan -- architecting and installing the necessary security/authentication story for arbitrary devices on the web is not straightforward -- but presumably web-of-things has this in view. . .

sicking: i don't know i'd want web developers to fire 10 http calls just to communicate with Contacts
... sure we could wrap jQuery around that
... but we'd want to make sure one wraps the other
... one more understandable and simple

<Zakim> fjh, you wanted to ask about TAG review

plinss: you could design the ReSTful, and design the JS, and not implement one
... you could get it wrong

noah: you could run into a risk where the two aren't equivalent and if you use both...
... in retrospect, we like controlling printers from browsers
... sometimes remotely
... if you can get 60% done w/ js
... then people will forget the rest
... that's the bigger risk, but i don't know how to quantify
... it seems like for most of this, you're committed to JS
... maybe for some you should survey things and see if some of them where there are UCs for ReST
... and if some seem useful now/real soon

fjh: my sense is we should stick w/ JS apis

<richt> TAG: Opera is looking in to the HTTP approach to local devices. You might want to look at: http://people.opera.com/richt/release/specs/discovery/Overview.html

fjh: UCs that would help us
... maybe the tag could help us
... by reviewing one of our specs
... i think maybe Contacts is the only one
... but i'm so concerned about minimization

noah: is Contacts private to a device?

darobin: when mozilla labs
... did it, it could also expose arbitrary remote contacts

noah: look at Email
... hypothetically in Gmail, there is a uri for each email

<fjh> s/we should stick/that the rough consensus of the Working Group is that we should stick/

<dsr__> [HTTP isn't a good fit when the service needs to send asynchronous messages to the client]

noah: imagine the URI was portable from my device to my phone

<fjh> s/only one/one

Josh_Soref: Gmail doesn't do that, it has a different URI or different device styles

noah: maybe things have a URI, and maybe it can be resolved locally

<dom> dsr__, Server SEnt Events make asynchronous messages fairly easy via HTTP

noah: maybe you're replicating your Picasa/Flickr photos
... i'd like them to have the same URIs on Phone and Flickr
... except when you want to reference the replica
... you may say that integrating address books with too much history
... that it's too hard to wrap

richt: We, Opera, have been working on Device APIs for a long time
... the URL is the killer feature of the web
... and accessing stuff via http
... not just ReST
... accessing data
... we;re interested in that approach


scribe: it's local, but it's on the web as well

fjh: this is a Discovery protocol
... but it doesn't address minimization, or contacts
... it's up to the service/services that provide them
... everything's addressable with http

<bryan> addressable via URI does not equate to only accessible via HTTP

s/fjh: it's up to the/richt: it's up to the/

<npdoty> like X-Archived-At email headers?

s/fjh: everything's/richt: everything's/

fjh: maybe we should move on??


<fjh> ScribeNick: fjh

Josh_Soref: contact merging, integration of local and non-local should be transparent to user
... JavaScript API we have does not prevent that
... ndoty mentioned X-Archived-At email headers, we need that
... need something like UUID but not UUIDs
... merged URLs don't work
... W3 mailing list system is smart about URLs for cross-posted messages, allowing selection
... URL for picture might be picture1
... need really long URLs for local pictures to make unique on the web
... also bad for privacy since this means URL is disclosing information

or a form of fingerprinting

Josh_Soref: bad urls can be a problem

<bryan> I think Josh is questioning universal object addressability via URI

<Josh_Soref> [ fjh's email said: Also linked to DAP agenda at http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_(TPAC) ]

<Josh_Soref> dom: maybe we prefer focusing on js for basic operations

<Josh_Soref> ... i don't see value taking a resolution on this

proposed RESOLUTION: WG consensus to continue Javascript approach to existing APIs

<Josh_Soref> richt: the proposal we have is a JS api

<Josh_Soref> ... it may provide this function, it may swallow the other apis eventually

<Josh_Soref> ... there's no harm in doing both approaches

<Josh_Soref> fjh: i think we need a decision so we don't go around in circles

<Josh_Soref> ht: a double negative solution

<Josh_Soref> ... we decide:

<Josh_Soref> ... we will not hold up a row in this table for lack of a ReSTful api

<Josh_Soref> noah: a proposal

<Josh_Soref> ... imagine we go down the road of doing JS apis

<Josh_Soref> ... not really ReSTful

proposed RESOLUTION: will not stop current work for lack of a a RESTful API for that API

<Josh_Soref> ... but where we need to identify something,

<Josh_Soref> s/a a/a/

<Josh_Soref> ... we try to provide a URI for it

<Josh_Soref> ... it may always be localhost today

<Josh_Soref> ... but down the road, when we want to use a non local thing

proposed RESOLUTION: will not stop work on a current JavaScript API for lack of a a RESTful API for that API,

<Josh_Soref> ... we can change the host

<Josh_Soref> s/a a/a/

<dom> (the actual resolution we could make would be to remove "REST-ful compatiblity" from our APIchecklist but it was already removed in May http://www.w3.org/2009/dap/wiki/ApiCheckList )

<Josh_Soref> ... and then it can be used in ReSTful

<darobin> ISSUE-118?

<trackbot> ISSUE-118 -- How would feature discovery work for REST APIs -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/118

<darobin> proposed RESOLUTION: close ISSUE-118

<richt> Feature Discovery for REST APIs sounds like SOAP :(

<Josh_Soref> Josh_Soref: there's a risk with constant uri's being abbreviated and misunderstood by developers

<Josh_Soref> ... such that in the future when they're not changed, they fall apart

<Josh_Soref> RESOLUTION: close ISSUE-118

<dom> close ISSUE-118

<trackbot> ISSUE-118 How would feature discovery work for REST APIs closed

<Josh_Soref> RESOLUTION: will not stop work on a current JavaScript API for lack of a RESTful API for that API

<darobin> close ACTION-442

<trackbot> ACTION-442 Produce a REST binding example for Contacts (client, server, protocol) closed


<Josh_Soref> fjh: this group has done two things

<Josh_Soref> .... one is minimization

<Josh_Soref> s/..../.../

<Josh_Soref> ... the other is implicit consent

<Josh_Soref> ... there's work in the EU on privacy


<Josh_Soref> fjh: executive summary

<Josh_Soref> ... consent is not just "i said share these 3 contacts is consent"

<Josh_Soref> ... it has to be informed consent

<Josh_Soref> ... you have to know what's going to happen to that information

<Josh_Soref> ... for what purpose

<Josh_Soref> ... how long will it be retained, how will it be used?

<Josh_Soref> ... the other aspect

<Josh_Soref> ... is it isn't within the API scope to define what third parties will do with that information

<Josh_Soref> ... we have a system for privacy

<Josh_Soref> ... it isn't a giblet

<Josh_Soref> ... EU says you don't need to click on ok

<richt> I wouldn't conflate this stuff together.

<Josh_Soref> fjh: concerns:

<Josh_Soref> ... active consent is optional

<richt> I mean API authorization and fjh's description of consent.

<Josh_Soref> ... we're leaving it up to the web page to provide what's needed

<Josh_Soref> ... - i don't know if it would be viable if it isn't

<Josh_Soref> richt: API auth isn't the same as consent

<Josh_Soref> ... it's other stuff on the web site

<Josh_Soref> fjh: we've been telling people we build in privacy by design

<Josh_Soref> ... by having users take actions

<Josh_Soref> ... which is insufficient according to EU opinion

<Josh_Soref> dom: this is a systemic approach

<Josh_Soref> ... but for consent to be informed

<Josh_Soref> ... is not this group's problem

<Josh_Soref> ... it's the problem of the provider

<Josh_Soref> s/provider/site/

<Josh_Soref> ... i don't think that affects how we design the api

<richt> +1 dom.

<Josh_Soref> ... we have consent

<Josh_Soref> ... but i don't know that we need it for EU

<ernesto_jimenez> +1

<Josh_Soref> fjh: do we need consent UI to be mandatory?

<Josh_Soref> dom: it's optional because UI is in a much larger framework than what we as a WG can usefully document

<Josh_Soref> fjh: it's a can of worms, maybe we need to update Best Practices

<Josh_Soref> npdoty: some experience from the GeoLoc case

<Josh_Soref> ... i don't know if everyone was present

<Josh_Soref> ... we agreed it would be good for End Users of GeoLoc to have informed consent

<Josh_Soref> ... there was a large debate whether the protocol should enable informed consent

<Josh_Soref> ... the controversial decision we made

<Josh_Soref> ... was to leave it out

<Josh_Soref> ... but put in a requirement on web sites

<Josh_Soref> ... to use existing html

<Josh_Soref> ... UC Berkeley did a survey, and no one did it

<Josh_Soref> ... you might think about the implications

<dom> Privacy Issues of the W3C Geolocation API

<Josh_Soref> ... there might be ways for the browser to facilitate communication

<Josh_Soref> ... perhaps the browser could force web sites to do things

<scribe> ACTION: fjh to update web application privacy best practices related to active consent [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action10]

<trackbot> Created ACTION-470 - Update web application privacy best practices related to active consent [on Frederick Hirsch - due 2011-11-10].

<Josh_Soref> ernesto_jimenez: the fact that web sites "inform the user"

<Josh_Soref> ... by adding a field to the user

<Josh_Soref> ... doesn't mean they'll fill it in properly

<Josh_Soref> ... providing another field will probably restrict what the UA can do

<Josh_Soref> ... because it will probably have to show that

<Josh_Soref> npdoty: In GeoLoc, putting this in would enable web sites to lie

<Josh_Soref> ... there's no guarantee that it would be useful

<richt> websites will lie :)

<Josh_Soref> ... but it could be a convenient way to provide info to users

<Zakim> dsr, you wanted to note that this may be beyond the API itself, e.g. the browser may be able to provide a button to view the site's privacy policy

<Josh_Soref> ernesto_jimenez: someone will argue that the Browser telling the User what the User said, that the user will trust the Web Site

<Josh_Soref> dsr: in some cases it can be the responsibility of the browser to provide e.g. a link to a privacy policy

<Josh_Soref> ... it might not require changing the api

<bryan> The browser chrome needs to provide a means for users to easily see the types of personal data that the website can access. This is analogous to what is provided by native app managers (though not in the direct context of the app running, as usually the case).

<Josh_Soref> bryan: if the browser had a "what this page can do"

<ernesto_jimenez> s/what the User said/what the User Agent said/

<Josh_Soref> ... just like native app managers

<Josh_Soref> ... users can back away, or uninstall

<Josh_Soref> ... in our studies, "users don't care"

<Josh_Soref> ... providing prompts doesn't enhance the user experience

<dsr> [I worked on something like that with a Firefox extension - Privacy Dashboard http://code.w3.org/privacy-dashboard ]

<ernesto_jimenez> s/will trust the Web Site/will be more likely to trust the Web Site because they trust what they user says/

<Josh_Soref> fjh: we punted on rulesets

<Josh_Soref> ... which enabled users to say what they expected wrt privacy server side

<Josh_Soref> ... i think dsr is right

<dom> Privacy Rulesets Proposal

<Josh_Soref> ... it seems like we could provide access to a Privacy URI

<Josh_Soref> ... it's not the best thing

<Josh_Soref> dom: is that at the api level?

<Josh_Soref> ... or is it just a link for privacy?

<Josh_Soref> fjh: maybe not

<Josh_Soref> ... but is there anything for privacy by design we could push for

<Josh_Soref> ... beyond what is in our scope

<npdoty> our paper on Privacy Issues of the W3C Geolocation API: http://escholarship.org/uc/item/0rp834wf

<Josh_Soref> noah: do you specify at that level?

<Josh_Soref> ... you could have things which don't have e.g. buttons

<Josh_Soref> fjh: we could suggest "provide a means to convey a uri"

s/convey a uri/convey a uri for privacy notice/

<Zakim> Josh_Soref, you wanted to note that browsers are improving this by making Content Alerts

Josh_Soref: users trust browsers more than web pages
... alerts were anchored to browser, looked as if from browser
... now switching so they look like part of the page
... so browsers can show material from page without confusion

<Josh_Soref> noah: the fact that Users actually trust the Browser is interesting

<Josh_Soref> ernesto_jimenez: the concern that we need to do Privacy by Design

<Josh_Soref> ... that the browser must get consent

<Josh_Soref> ... but then the browser should inform the user

<Josh_Soref> fjh: Privacy by Design is Privacy by Default

<Josh_Soref> ernesto_jimenez: but Privacy/Security is for each one of us

<Josh_Soref> ... the UA asks for information

<Josh_Soref> ... and it has to account for that

<Josh_Soref> npdoty: that's an excellent point

<Josh_Soref> ... the work out of this group has been excellent

<Josh_Soref> ... informed consent is an indication of dialog between the site and the user

<Josh_Soref> ... if a UA might want to make a privacy preserving impl

<Josh_Soref> ... they might want to have this extra field

<Josh_Soref> ... defining it in the api or otherwise standardizing this communication protocol

<Josh_Soref> ... that's why i want to discuss it at the api level

<Josh_Soref> ernesto_jimenez: if UA vendors ask for this

<Josh_Soref> ... we could add it

<Josh_Soref> ... but in these cases, trying explain what a page will do with info is tricky

<Josh_Soref> nwidell: we did some testing w/ normal users for getUserMedia()

<Josh_Soref> ... what we found was that people trusted the web site

<Josh_Soref> ... and they didn't understand

<Josh_Soref> ... they trusted the web site

<Josh_Soref> ... because it's a brand they interacted the most

<Josh_Soref> ... your user in the street doesn't understand the bit about UAs

<Josh_Soref> ... no matter how much we try to build sophisticated chrome around this

<Josh_Soref> ... it might not solve the problem, because users might not see these things

<Josh_Soref> [ time check ]

<richt> ernesto_jimenez, websites will lie and if anyone wants to do UI/UX research we're happy to read it :)

<nwidell> We know that web sites will lie, but it is hard to communicate that to users

<Josh_Soref> [ fjh tries to summarize ]

<darobin> http://www.w3.org/2011/04/webrtc/wiki/File:Webrtc_privacy.pdf

<Josh_Soref> i|www.w3|Topic: Security

<Josh_Soref> darobin: I was in the WebRTC WG

<Josh_Soref> ... and it seemed like they didn't know what we'd done in the area

<dom> we have actually documented some of it in http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/ afaik

<Josh_Soref> richt: we've had this principle which has informed our design

<Josh_Soref> ... Opera and Mozilla did hundreds of hours of work and reached the same conclusion/design

s/fjh tries to summarize/Summary - our "implicit consent" mechanism is consistent with "active consent" but requires web applications to provide notice, the WG may consider whether conveying notice should be done by more than relying on a web page to include that information

<Josh_Soref> darobin: it would have been simpler if we had a 2 page document we could point to

<Josh_Soref> ... since you [WebRTC] aren't the last WG who will need to work in this space

<Josh_Soref> ... some of this is in our Wiki in the API checklist

<Josh_Soref> fluffy: Cullin Jennings, Cisco

<npdoty> higher level principles and examples would both be great

<Josh_Soref> fluffy: something like that would help

<Josh_Soref> darobin: (a) documenting it (b) removing confusion that it isn't done

<Josh_Soref> dom: we have a document

<dom> we also have http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/

<Josh_Soref> ... - the privacy document

<npdoty> I would note that the Privacy and Security Interest Groups would be very interested, for example

<Josh_Soref> darobin: but having a note on security principles for api design

<Josh_Soref> ACTION berjon to look into a document for Security Principles for API Design

<trackbot> Created ACTION-471 - Look into a document for Security Principles for API Design [on Robin Berjon - due 2011-11-11].

<Josh_Soref> npdoty: that would be awesome



<Josh_Soref> darobin: Discovery API

<scribe> ACTION: fjh to update policy requirements for security requirements [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action11]

<trackbot> Created ACTION-472 - Update policy requirements for security requirements [on Frederick Hirsch - due 2011-11-11].

<Josh_Soref> [ Adjourned ]

<darobin> ACTION: Robin to coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action12]

<trackbot> Created ACTION-473 - Coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [on Robin Berjon - due 2011-11-11].

<fluffy> s/Cullin/Cullen/

trackbot, start telecon

<trackbot> Meeting: Device APIs Working Group Teleconference

<trackbot> Date: 04 November 2011

<scribe> Chair: Robin_Berjon, Frederick_Hirsch

<karen> [Introductions of attendees]

<karen> Frederick: Please join the irc channel

<karen> Dom: when you start speaking, please restate your name before speaking

<karen> [teleconference bridge may be set up if someone tries to dial in]

<karen> [About 60 people in the room]

<karen> Robin: we will begin with a short presentation on discovery

<scribe> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_(TPAC)

<karen> ...then a few demos

<karen> ...so people can get a feel for how discovery works

<karen> ...then look at potential solutions

<karen> ...look at Web intents

<karen> ...approaches we want to discuss

<karen> First presenter is Giuseppe Pascale, Opera

<karen> Title of presentation: Networked Service Discovery and Messaging

<karen> Giuseppe: Web and TV IG has been looking at use cases for home network discovery

<fluffy> http://people.opera.com/giuseppep/hntf

<dom> Networked Service Discovery and Messaging, Giuseppe Pascale

<karen> ...We started from simple question; looking at what all devices in home have in common

<karen> ...they all run a browser

<karen> ...they are connected to the home network

<karen> ...Look at other facts, numbers

<karen> ...A lot of people surf the internet while watching TV

<richt> 59% of Americans browse the web on different devices while they are watching TV * Nielsen Research http://blog.nielsen.com/nielsenwire/online_mobile/three-screen-report-q409/

<karenm> Giuseppe describes scenarios of ways people can interact with devices

<karenm> Giuseppe: So are we there yet? Can we do this today? Answer is almost

<karenm> ...Each of these use cases require three steps

<karenm> ...Discovery, authorization and third step is communication

<karenm> ...then devices start to communicate

<karenm> ...If we look at three steps

<karenm> ...Download is nothing to be done

<karenm> ...But looking at Discovery, it's not something you can do today in a Web Application

<karenm> ...What we will enable is to allow services to be aware of services and allow them to advertise themselves

<karenm> ...Being able to support this is important

<karenm> ...people could immediately use own devices

<karenm> ...We did not see major gaps with communications

<karenm> ...UPnP is based on SOAP

<karenm> ...so don't have to invent a new messaging protocol

<karenm> ...Use cases where you just want the devices to communicate

<karenm> ...The only real problem using this technology is constraint to same IP

<karenm> ...cannot communicate with normal Web messaging; may want to relax this restriction

<karenm> ...So these were the main conclusions our group made

<karenm> ...So CableLabs and Opera we looked at these use cases

<karenm> ...What we found is that the gaps are small

<karenm> ...We all want application to do the get of services

<karenm> ...Application doesn't need to know; just ask for some kind of service

<karenm> ...Gets a pointer, a URL, and communicate using normal Web stuff

<karenm> ...Only new thing is [this]

<karenm> ...That is what led to this conclusion

<dom> s/[this]/navigator.getNetworkServices/

<karenm> ...Then we created a task force to look into these use cases; and we published a report

<karenm> ...There are more use cases described there; references to existing standards

<karenm> ...We would really like to discuss these use cases and decide which is the right approach

<karenm> ...We are open to discussion

<karenm> ...thank you

<karenm> [Zakim bridge to start]

<karenm> Marcos: It was not clear to me

<karenm> ...a bunch of people like to watch TV while surfing Internet

<karenm> ...Is that the same experience?

<karenm> ...Am I on tablet, laptop?

<karenm> ...where is content coming from

<karenm> ...How does Web content meet ?

<karenm> Giuseppe: TV content is not different from web content

<karenm> ...So far we are experiencing content on one screen; can I distribute to different screens?

<karenm> ...Can we distribute social onto other screens?

<karenm> Marcos: So to render content on both devices

<karenm> Giuseppe: have complementary content on two screens, reuse what is already available

<dom> s/Marcos/Marcos/

<dom> Cullen: I have a question about the security model

<dom> ... Most implementations of UPNP assume the local network is safe

<dom> ... doesn't require credentials on the local network

<dom> ... does this model mean that any random web site can access local network resources?

<dom> Giuseppe: in the opera prposal, this is taken care via the user agent

<dom> ... the UA asks whetehr you want to allow a given web app to access your local services

<dom> ... before that point, no communication is possible

<dom> ... But FWIW, this is already possible today via Android applications

cullen-jennings: what about security,e.g. UpNP makes certain assumptions

<dom> Marcos: the threat model is a bit different there

<dom> ... an adroid application doesn't have as much power as something on the open Web

<francois> s/whetehr/whether/

<dom> @@@: How about the TV? Does the TV get a chance to authorize the mobile device?

<dom> ... like some kind of peering?

<dom> Giuseppe: the examples I showed are based on UPnP

<dom> ... we're reusing that infrastructure

<richt> @dom, my response: There's a decision that needs to be made at connection time. The user needs to decide if they trust the web site to access this X resource. Brokered by the UA.



<karen> Marcos: you don't have a choice

<dom> Jean-Claude: UPnP is one of the protocols that Opera is implementing as an example

<karen> Jean-Claude: we don't want to lock ourselves with UPnP

<dom> ... in the various protocols, there are occasions for security / authentication

<kaz> @@@: @@@

<kaz> giuseppe: as shown in the slides, this allows browser to connect your devices

<kaz> ... using more secure way

<kaz> [ my connection is also very unstable... ]

<dom> ... but that's protocol dependent

<karen> Giuseppe: We are enabling security with two devices

<kaz> JC: there is a communication protocol

<karen> JC: in between request for discovery and answer...

<karen> GP: the application can only ask for a type and get them

<karen> ...there is user agent

<karen> ...everything is hidden; you cannot info about your home network

<karen> Marcos: that is ideal; that isnot being exposed

<karen> GP: define some type of devices

<karen> ...and the suer agent says yeah, you have one

<dom> s/suer/user/

<karen> ...this is device available at this URL

<karen> ...user has authorized it

<Marcos> +q

<karen> ...how this is shown by user agent in way user understands is a big question

<karen> Jonas: sounds like you are getting this to work on existing hardware

<jcdufourd_> JC: Giuseppe's example was only an example, mention of UPnP did not imply we want to use UPnP in the end, just a discovery protocol, and for security, we are just saying that there is a step in between discovery request and response where a security policy is applied

<karen> ...are you looking at different security scenarios?

<karen> GP: enabling something not tied to any protocol if you establish a channel

<karen> ...user agent may say not allow to communicate with any device

<karen> ...this is one approach

<karen> ...if people are concerned they can say now

<karen> s/now/no

<karen> Jonas: where we can enable for security models

<karen> GP: underlying protocol; we recommend two

<karen> ...if there is third or fourth it should be transparent

<karen> ...new service; how to discover it; have a menu

<karen> ...so doesn't have to be discovred in traditional way

<timeless> s/discovred/discovered/

<karen> ? Abstraction of that process

<karen> ...where innovation happens

<karen> ...keep innovation; a high priority

<jcdufourd_> s/?/richt:/

<karen> Robin: BBC wrote a protocol...

<dom> Networked Service Discovery and Messaging proposal from Opera and CableLabs

<karen> Olivier: We looked at a lot of use cases; many have been mentioned

<karen> ...many users in the home

<karen> ...We don't necessarily want the kid's PC to control the TV

<karen> ...we built a prototype that does discovery, pairing, control, reading info

<karen> ...done centralized on set-top box

<dom> [one thing that seems to be protocol specific is the identification of the "type" of services that is to be discovered]

<karen> ...What I hear proposed is interesting...have every device be a first class citizen

<karen> Marcos: about new protocols

<karen> ...would be great if Web and TV could look into that

<karen> ...what is the common model to be used

<karen> ...then could be abstracted if something new is needed

<karen> ...to follow up

<karen> ...Like Web and TV group to answer how much

<karen> ...what these protocols provice

<karen> ...UPnP spec is huge and inaccessible

<karen> ...DLNA is claiming how many billions of devices

<karen> Clarke: ?

<olivier> the Universal Control API (BBC)

<karen> Marcos: have a human accessible list to see what we can do; control volume, etc.

<karen> ...What would be needed if a new protocol is needed?

<karen> GP: Two things

<darobin> ?

<karen> ...this was completion of our group

Summary of Action Items

[NEW] ACTION: berjon to follow up with Alex Russell on getting an example of sensors on Intents. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action04]
[NEW] ACTION: darobin to follow up with Alex Russell on getting an example of sensors on Intents. [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action03]
[NEW] ACTION: dom to make proposal for proximity and ambient [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action07]
[NEW] ACTION: fjh to send cfc for FPWD for vibration [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action02]
[NEW] ACTION: fjh to update policy requirements for security requirements [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action11]
[NEW] ACTION: fjh to update web application privacy best practices related to active consent [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action10]
[NEW] ACTION: jcantera to present use cases for the Sensors API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action05]
[NEW] ACTION: jcantera to update Sensor's API based on feedback, implementation etc [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action06]
[NEW] ACTION: Robin to coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action12]
[NEW] ACTION: Robin to look as Mozilla Labs Sharing experimentation re Messaging API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action08]
[NEW] ACTION: Robin to make a CfC for shelving Messaging [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action09]
[NEW] ACTION: Sakari to draft a proposal for a threshold parameter for Battery events [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/11/04 16:33:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Linuz S. Lee/Linuz_S_Lee/
Succeeded: s/bring/being/
Succeeded: s/: Present+/Present+/
Succeeded: s/+Present Travis_Leithead/Present+ Travis_Leithead/
Succeeded: s/its in the use/it's in the use/
Succeeded: s/so its/so it's/
Succeeded: s/less/fewer/
Succeeded: s/@@@/jcd/
Succeeded: s/the optimizations/adding threshold optimizations/
Succeeded: s/notes that level is appropriate and not more is needed/the design of the API to include a sync 'level' attribute prevents threshold really bringing any significant optimizations to imps/
Succeeded: s/darobin: opens the floor to jokes/[ darobin opens the floor to jokes ]/
Succeeded: s/huwai/huawei/
Succeeded: s/dependening/depending/
Succeeded: s/our devices/some devices/
Succeeded: s/..../.../
FAILED: s/..../.../
FAILED: s/picutre/picture/
FAILED: s/picture"/picture", switching to higher resolution mode for video camera/
FAILED: s/yous tart/you start/
FAILED: s/mwork/work/
FAILED: s/desigfn/design/
FAILED: s/whicih/which/
FAILED: s/note on privacy and consent,/ignore this line/
Succeeded: s/trackbot/Travis_MSFT/
FAILED: s/consenquences/consequences/
FAILED: s/Topic: Sensors//
FAILED: s/... yes./HF: yes./
FAILED: s/The/They/
FAILED: s/Present+Balaji_NV/Present+ Balaji_NV/
FAILED: s/specificiation/specification/
Succeeded: s/HF:/Jose:/g
Succeeded: s/HR:/Jose:/g
FAILED: s/jfh/fjh/
FAILED: s/Point is it's not a generic/I believe Marcos is saying it should be a generic/
FAILED: s/ack nvbalji//
FAILED: s/intrface/interface/
FAILED: s/+!//
FAILED: s/does't/doesn't/
FAILED: s/HR:/Jose:/
FAILED: s/alex russel/alex russell/
FAILED: s/Russel/Russell/
FAILED: s/ssystems/systems/
FAILED: s/arbirary/arbitrary/
FAILED: i|Two contentions points|AR: Alex Russell (Google)
FAILED: s|Alex Russel (google): Two|AR: Two|
FAILED: i|give my vendor perspective|JimS: Jim Steel (sensor platforms)
FAILED: s/exmaple/example/
FAILED: s/Steel/Steele/
FAILED: s/Steel/Steele/
FAILED: s|Jim Steele (sensor platforms): Want|JimS: Want|
Succeeded: s/HR/Jose/G
Succeeded: s/Jose:/jcantera:/G
FAILED: s/right code/write code/
FAILED: s/prior art/work/
FAILED: s/proximiate/proximate/
Succeeded: s/does/does need a security model/
FAILED: s/...i/... i/
FAILED: s/Dom/dom/
FAILED: s/q`//
FAILED: s/taht/that/
FAILED: s/it's/its/
FAILED: s/higher/lower/
FAILED: s/ACTION-467* ambient light//
FAILED: s/ACTION-467" ambient light//
FAILED: s/...Minutes from 26 October 2011/RESOLUTION: Minutes from 26 October 2011/
FAILED: s/though you could consider expose those as well/you could consider that keyboard backlight would be controlled by CSS in that case/
FAILED: s/... Minutes from 26 October 2011/RESOLUTION: Minutes from 26 October 2011/
FAILED: s/SMS:/"sms:"/
FAILED: s/be/been/
FAILED: s/ack//
FAILED: s/tyson/tizen/
FAILED: s/tyson/tizen/
FAILED: s/Mozilla//
FAILED: s/inprogress../in progress?/
FAILED: s/conclusion/confusion/
FAILED: s/Mendelson/Mendelsohn/
FAILED: s/peterl/plinss/
FAILED: s/Lins/Linss/
FAILED: s/Slides/Slide/
FAILED: s/discovery/Discovery/
FAILED: i|Edinburg|ashok: Ashok Malhotra, Oracle
FAILED: s/X1/ashok/
Succeeded: s|ACL|Access Control|G
FAILED: s/'//
FAILED: i|resources|bryan: questions re:Arch on web
FAILED: s/henry:/ht:/
FAILED: s/then it'll/then in a few cases it'll/
FAILED: s/we should stick/that the rough consensus of the Working Group is that we should stick/
FAILED: s/only one/one/
FAILED: s/we;re/we're/
FAILED: s/fjh: it's up to the/richt: it's up to the/
FAILED: s/fjh: everything's/richt: everything's/
FAILED: s/??/?/
FAILED: s/a a/a/
FAILED: s/a a/a/
FAILED: s/..../.../
FAILED: s/provider/site/
FAILED: s/what the User said/what the User Agent said/
FAILED: s/will trust the Web Site/will be more likely to trust the Web Site because they trust what they user says/
FAILED: s/convey a uri/convey a uri for privacy notice/
FAILED: i|www.w3|Topic: Security
FAILED: s/fjh tries to summarize/Summary - our "implicit consent" mechanism is consistent with "active consent" but requires web applications to provide notice, the WG may consider whether conveying notice should be done by more than relying on a web page to include that information/
FAILED: s/Cullin/Cullen/
FAILED: s/[this]/navigator.getNetworkServices/
FAILED: s/Marcus/Marcos/
FAILED: s/whetehr/whether/
FAILED: s/@@@/nvbalaji./
FAILED: s/nvbalaji./nvbalaji/
Succeeded: s/Marcus/Marcos/g
FAILED: s/suer/user/
FAILED: s/now/no/
FAILED: s/discovred/discovered/
FAILED: s/?/richt:/
Found ScribeNick: bryan
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Found Scribe: Travis_MSFT
Inferring ScribeNick: Travis_MSFT
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Found Scribe: Travis_MSFT
Inferring ScribeNick: Travis_MSFT
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Found Scribe: Travis_MSFT
Inferring ScribeNick: Travis_MSFT
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Found ScribeNick: fjh
Scribes: Josh_Soref, Travis_MSFT
ScribeNicks: bryan, Josh_Soref, Travis_MSFT, fjh

WARNING: Replacing list of attendees.
Old list: Josh_Soref Salon_CE tpac +1.941.323.aaaa jlebar + mounir
New list: tpac jlebar

Default Present: tpac, jlebar
Present: tpac jlebar Dominique_Hazael-Massieux Anssi_Kostiainen Frederick_Hirsch Robin_Berjon Laszlo_Gombos Ernesto_Jimenez Travis_Leithead Jose_Cantera Bryan_Sullivan Marco_Marengo Anders_Isberg David_Yushin_Kim(obs) Kihong_Kwon spoussa Cathy_Chan Christophe_Eyrignoux Ingmar_Kliche Soonbo_Han jerome_giraud Soonho_Lee Jongyoul_Park Niklas_Widell Linuz_S_Lee SungOk_You Sakari_Poussa Rich_Tibbett Kepeng_Li Josh_Soref Justin_Lebar Mounir_Lamouri Jean_Claude_Dufourd mahalingam_mani update Adrian_Bateman Ilkka_Oksanen Jari_Alvinen Balaji_NV Jean-Francois_Moy npdoty Cullen_Jennings Philip_Gladstone Jonathan_Jeon Daniel_Appelquist Kangchan_Lee Virginie_Galindo Olivier_Thereaux Matt_Hammond JC_Dufourd Youngsun_Ryu Dave_Raggett Clarke_Stevens Kaz_Ashimura aizu Art_Barstow Richard_Bardini
Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_(TPAC)
Found Date: 03 Nov 2011
Guessing minutes URL: http://www.w3.org/2011/11/03-dap-minutes.html
People with action items: berjon darobin dom fjh jcantera robin sakari

[End of scribe.perl diagnostic output]