See also: IRC log
<trackbot> Date: 03 November 2011
<dom> Chair: Frederick_Hirsch, Robin_Berjon
<scribe> Scribe: bryan, Josh_Soref, Travis_MSFT, karen, dom, olivier
[ fjh introduces the DAP wiki working mode, etc. ]
<fjh> http://www.w3.org/2009/dap/wiki/ApiCheckList
shunan: shunan fan, Huawei terminal company
spoussa: Sakari Poussa, Intel
RESOLUTION: Minutes from 26 October 2011 are approved, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0076/minutes-2011-10-26.html
AnssiK: Battery API intro
... expect that folks have looked at the draft, it's pretty stable and nearing last call stage
jcantera: main concern is no way to specify event rate
<AnssiK> http://www.w3.org/mid/4EB03375.3070702@lamouri.fr
AnssiK: Jonas Sicking (Mozilla) wants to leave that up to the implementation
darobin: seems fine
jcantera: What does that mean to the app, does it need to filter the events?
AnssiK: The app can measure the delta
<jcantera> My concern is the event rate at which receive battery events
AnssiK: Firing events too often don't help as they may not be true changes
... Developers will need to handle various firing speeds
bryan: Don't we have the ability to threshold?
AnssiK: no
<Cathy> http://dev.w3.org/2009/dap/system-info/battery-status.html
bryan: Dropping threshold events is an issue
AnssiK: This was based upon implementer feedback (Mozilla)
dom: The original spec was 1% change events... if we have platforms that don't send events consistently that won't be helpful to developers
... http://lists.w3.org/Archives/Public/public-device-status/
Travis_MSFT: Firing events too often could be counter-productive to saving battery...
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
lgombos: What about the use case on scaling back work when the battery is getting low?
AnssiK: It's in the use cases in the spec
lgombos: We need to consider both browser implementer concerns and web page author concerns
jcantera: The monitoring of the battery will impact the battery, if it depends upon handling continual events
AnssiK: 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
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.
AnssiK: The spec is designed to use defaults for charging time
spoussa: It's 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
AnssiK: One concern raised about the semantic events being dropped
... If the web code gets too many events as a result
... Our consensus 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:
... 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
darobin: With 1% thresholds (implementation approach) we are talking 80 events
dom: Note that optional threshold parameter would have value and low cost, avoid issues that developer might not recognize
... 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)
AnssiK: 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
mounir: If we have native extension listening to battery events, the platform is also optimizing the rate of events
[ Conversation to confirm we're switching from Battery to Vibration to help jlebar ]
[ Conclusion: Vibration @10:45am Pacific ]
spoussa: Additional comment to adding the level... there are backends that are already optimizable
AnssiK: The platform should already optimize it without webapp help
fjh: Sounds like this is a potentially useful optimization
Josh_Soref: The system can determine when to send events based upon whether the apps need them - when do they care
darobin: Wakeup is important
Josh_Soref: Preventing the need to wake up just to handle the events, needs a different approach
dom: An optional threshold setting would allow the host 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
richt: The design of the API to include a sync 'level' attribute prevents threshold really bringing any significant optimizations to imps
AnssiK: We still have the sync interface which allows the app to get fewer events
... the app can poll the sync interface
ernesto_jimenez: We 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
jcdufourd: Could use the constructor approach to prevent the sync API from being used when not needed
... 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
... 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].
[ darobin opens the floor to jokes ]
darobin: jlebar, welcome back, thanks for joining us
... 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
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, which 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 implementation 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 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 JavaScript loop of the vibrate behavior as many times as I like (rather than specifying an optional repeat parameter)
... 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
... JavaScript 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> Android'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: On 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
Josh_Soref: At Nokia we had to look at haptics and we had to worry about buffers
... 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) ?)
... 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 Vibration 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?
[ none ]
<fjh> ACTION: fjh to send cfc for FPWD for vibration [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action02]
<trackbot> Created ACTION-460 - Send cfc for FPWD for vibration [on Frederick Hirsch - due 2011-11-10].
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
... like supporting multiple targets
darobin: Thanks jlebar for joining us
<jlebar> Bye, everyone. I'll send mail to the list soon.
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 programmatic 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 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 (Microsoft), 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 from 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
... 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 my phone
... and perform a search
... when I click here [point on screen],
... 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
... 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 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 picture", switching to higher resolution mode for video camera.
... 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 you start recording from the camera, you merge audio+video
... and having to split that up requires a lot more work.
... Three more things:
... 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 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 design 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
... I'm suggesting to consider more, and 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 question and one comment.
... 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
... which might disclose your geolocation
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
<Josh_Soref> ACTION: Travis to submit UCs [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action03]
<trackbot> Created ACTION-461 - Submit UCs [on Travis Leithead - due 2011-11-10].
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
<Josh_Soref> ACTION: richt to submit UCs [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action04]
<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 File API.
... 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?
Travis_MSFT: I share richt 's view that we should reuse things from the platform
<fjh> thanks to Travis_MSFT for comments and work on this
darobin: I think we can make progress!
... you didn't talk about html Media Capture
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 choice
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 parameters
darobin: we won't be working on HTML MC before We get UI feedback
<Zakim> dom, you wanted to talk about next steps w.r.t. WebRTC TF
dom: We talked about getUserMedia()
... We're interested in a Joint TF
... that has logistic consequences
... a new TF to join, a new mailing list
... WebRTC hasn't agree to it yet
... darobin and I were at WebRTC where it was discussed, but not approved
<Josh_Soref> ACTION: darobin to draft a joint TF proposal with WebRTC [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action05]
<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?
<Josh_Soref> ACTION: berjon to draft a joint TF proposal with WebRTC [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action06]
<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 ]
[Round of introductions]
<dom> Sensors API editors draft
jcantera: I will be presenting the Sensors API.
... current draft is 2 months old.
... we've been creating a prototype to demonstrate the feasibility 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?
jcantera: 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.
... 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
jcantera: They also use a web browser component.
... From the web view, a JavaScript->Java conversion takes place, then a Java->C++ to get to the sensors themselves.
... Sensor metadata is partially implemented.
... [presenting the demo]
<fjh> logical sensors provide a view on other real sensors, e.g. linearAcceleration ignores gravity
<dom> [Sensor.name and Sensor.vendor create fingerprint issues]
jcantera: units appear to be different even among different Android devices.
... not sure if they are using different units.
[ applause! ]
jcantera: any requests or anything else you'd like to see?
richt: This appears to look like the System Information API?
dom: There is some overlap, though it's not exactly the same. I share some of your concerns.
... 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 its 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 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 flexible enough to be extensible.
<Zakim> Josh_Soref, you wanted to ask what will you do with the data on average?
fjh: I believe Marcos is saying it should be a generic API that can handle future sensors.
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
... 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, Geolocation has a precision. Noted, that precision might not be to the inch. Geolocation specification has a generic location.
<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.
nvbalaji: 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 interface that can handle many things; I also think Marcos was suggesting this.
<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_Soref'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.,
<dom> a big +1 on not duplicating deviceorientation
<Josh_Soref> +1
<dom> and another +1 re: exposing vendor
Marcos: 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 doesn't invalidate the API
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 disenfranchised.
... 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).
AlexR: Alex Russell (Google)
... Two contentions points:
... gradients of potential specificity is related to the data type itself.
... 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 systems in the platform.
darobin: Interacting with the data-type is useful. Not sure about translating into markup.
AlexR: Markup provides a way to describe default 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
AlexR: 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.
AlexR: 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.
AlexR: Form serialization algorithm determines how to serialize the data without causing developers to do extra work.
darobin: If you get arbitrary values instead of what you expect, it's not useful to the developer.
AlexR: Having a fallback doesn't mean that we hang everything off a single value property.
darobin: Yes, but you end up doing just as much work by the developer.
JimS: Jim Steele (sensor platforms)
... Want to give my vendor perspective.
... Sensors are tuned per the device.
<fjh> AlexR notes JavaScript on the wire is slow and punitive
JimS: 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.
... jcantera, provided a great demo earlier.
... before moving on with "should we do this with Intents", I'd like to see an example case.
... Can you provide such an example?
<fjh> Much thanks to jcantera, for demo and work on this
<Travis_MSFT> 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#action07]
<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 developers 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.
<Travis_MSFT> ACTION: jcantera to present use cases for the Sensors API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action08]
<trackbot> Created ACTION-465 - Present use cases for the Sensors API [on jcantera, 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 write code that gets to 10 of the 10 digits, but my device only supports 6 digits, then my code might break.
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 lots of folks in the room that work on stuff like a Web OS... Would love their perspective.
sicking: I like the approach of having a low-level API. This proposal is good. I don't know enough about the other work, 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.
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 -- proximate or not.
... 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 need a security model)
... there are things one can do w/ ambient
... if there's a light flashing outside, it could be deciphered
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 kind of 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
npdoty: bryan, I mean that just knowing which combination of sensors is available on the device will enable fingerprinting
darobin: Anyone else have an opinion?
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.
... 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
bryan: w.r.t. 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
... 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 next to it
... some sensors like proximity, you have less than others
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
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. Some things may yet change.
... Thanks jcantera, for all your work in the demo.
<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: 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
bryan: sicking do you think we shouldn't support feature detection?
sicking: didn't say that.
<fjh> example from sicking 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 its characteristics
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: jcantera, did you have a follow-up action?
... you took an action to get details on use cases for why we need a lower-level API
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.
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#action09]
<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 implementer 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#action10]
<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
<trackbot> ACTION-467 make proposal for proximity and ambient notes added
Marcos: Controls other actuators in the OS (dim the display, keyboard backlight)
dom: you could consider that keyboard backlight would be controlled by CSS in that case.
darobin: Thanks again jcantera.
<fjh> Again thanks jcantera
jcantera: Referring to discovery, the list sensors method opens the door to discovery if the implementation decides to.
... Regarding extensibility, I feel that it is extensible.
dom: many of these things are still being explored.
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 implementers 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 privileges, though sites may not get that privilege.
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:"
<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.
<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 been unraveled. Now, we could live with sms:
... 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.
dom: charter is clear that we focus on Web APIs.
... an API that can be implemented in a current web browser.
spoussa: in the Tizen project, we defined a lot of APIs around messaging.
... hopefully we can come out and publish those soon.
Josh_Soref: but W3C will not be interested in that (since they're not Web APIs)
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 strictly 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#action11]
<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 Share Intent is documented at http://webintents.org/share
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 in progress?
jcantera: I object. You are sending the message that it's not useful 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 confusion.
... 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#action12]
<trackbot> Created ACTION-469 - Make a CfC for shelving Messaging [on Robin Berjon - due 2011-11-10].
[Short Break]
fjh: we should start again
fjh: we've invited members of TAG
noah: Noah Mendelsohn, TAG Chair
ashok: Ashok Malhotra, Oracle
ht: Henry Thomson, U of Edinburg
plinss: Peter Linss, 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
[ Slide 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 JavaScript 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)
... Security and Privacy are a bit different
... are we ok w/ doing what we're doing - JavaScript 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 ]
ashok: 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
... JavaScript 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 JavaScript
... "course grained streaming operations"
... you could imagine a JavaScript based API to the camera that let you pull bits out if you want to
... whereas with ReST you'll want a streaming thing
... it feels like a Calendar based API
... in ReST, something would stream back
... saying you'll start with JavaScript 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
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 URIs that you can't with JavaScript
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
... 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: questions re:Arch on web
<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?
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 addressable
... for the foreseeable future, they won't be addressable
<DKA> +.5 to ht
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 in a few cases it'll be awkward later at best
noah: I asked you to think about it, and you did
dsr: in many cases, JavaScript 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
... 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 envisioned 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 JavaScript
... 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 JavaScript, 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/ JavaScript
... 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 JavaScript
... 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 that the rough consensus of the Working Group is that we should stick w/ JavaScript 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 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
<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
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
... 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
richt: 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
<npdoty> like X-Archived-At email headers?
fjh: maybe we should move on?
Josh_Soref: contact merging, integration of local and non-local should be transparent to user
... JavaScript API we have does not prevent that
... npdoty 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_Soref is questioning universal object addressability via URI
[ 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) ]
dom: maybe we prefer focusing on JavaScript for basic operations
... I don't see value taking a resolution on this
<fjh> proposed RESOLUTION: WG consensus to continue JavaScript approach to existing APIs
richt: the proposal we have is a JavaScript api
... it may provide this function, it may swallow the other APIs eventually
... there's no harm in doing both approaches
fjh: I think we need a decision so we don't go around in circles
ht: a double negative solution
... we decide:
... we will not hold up a row in this table for lack of a ReSTful api
noah: a proposal
... imagine we go down the road of doing JavaScript APIs
... not really ReSTful
<fjh> proposed RESOLUTION: will not stop current work for lack of a RESTful API for that API
noah: but where we need to identify something,
... we try to provide a URI for it
... it may always be localhost today
... but down the road, when we want to use a non local thing
<fjh> proposed RESOLUTION: will not stop work on a current JavaScript API for lack of a RESTful API for that API,
noah: we can change the host
<dom> (the actual resolution we could make would be to remove "REST-ful compatibility" from our APIchecklist but it was already removed in May http://www.w3.org/2009/dap/wiki/ApiCheckList )
noah: 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: there's a risk with constant URIs being abbreviated and misunderstood by developers
... such that in the future when they're not changed, they fall apart
RESOLUTION: close ISSUE-118
<dom> close ISSUE-118
<trackbot> ISSUE-118 How would feature discovery work for REST APIs closed
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
fjh: this group has done two things
... . one is minimization
... the other is implicit consent
... there's work in the EU on privacy
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0091.html
fjh: executive summary
... consent is not just "I said share these 3 contacts is consent"
... it has to be informed consent
... you have to know what's going to happen to that information
... for what purpose
... how long will it be retained, how will it be used?
... the other aspect
... is it isn't within the API scope to define what third parties will do with that information
... we have a system for privacy
... it isn't a giblet
... EU says you don't need to click on ok
<richt> I wouldn't conflate this stuff together.
fjh: concerns:
... active consent is optional
<richt> I mean API authorization and fjh's description of consent.
fjh: we're leaving it up to the web page to provide what's needed
... - I don't know if it would be viable if it isn't
richt: API auth isn't the same as consent
... it's other stuff on the web site
fjh: we've been telling people we build in privacy by design
... by having users take actions
... which is insufficient according to EU opinion
dom: this is a systemic approach
... but for consent to be informed
... is not this group's problem
... it's the problem of the site
... I don't think that affects how we design the API
<richt> +1 dom.
dom: we have consent
... but I don't know that we need it for EU
<ernesto_jimenez> +1
fjh: do we need consent UI to be mandatory?
dom: it's optional because UI is in a much larger framework than what we as a WG can usefully document
fjh: it's a can of worms, maybe we need to update Best Practices
npdoty: some experience from the GeoLocation case
... I don't know if everyone was present
... we agreed it would be good for End Users of GeoLocation to have informed consent
... there was a large debate whether the protocol should enable informed consent
... the controversial decision we made
... was to leave it out
... but put in a requirement on web sites
... to use existing html
... UC Berkeley did a survey, and no one did it
... you might think about the implications
<dom> Privacy Issues of the W3C Geolocation API
npdoty: there might be ways for the browser to facilitate communication
... perhaps the browser could force web sites to do things
<fjh> 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#action13]
<trackbot> Created ACTION-470 - Update web application privacy best practices related to active consent [on Frederick Hirsch - due 2011-11-10].
ernesto_jimenez: the fact that web sites "inform the user"
... by adding a field to the user
... doesn't mean they'll fill it in properly
... providing another field will probably restrict what the UA can do
... because it will probably have to show that
npdoty: In GeoLocation, putting this in would enable web sites to lie
... there's no guarantee that it would be useful
<richt> websites will lie :)
npdoty: 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
ernesto_jimenez: someone will argue that the Browser telling the User what the User Agent said, that the user will be more likely to trust the Web Site because they trust what they user says
dsr: in some cases it can be the responsibility of the browser to provide e.g. a link to a privacy policy
... 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).
bryan: if the browser had a "what this page can do"
... just like native app managers
... users can back away, or uninstall
... in our studies, "users don't care"
... 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 ]
fjh: we punted on rulesets
... which enabled users to say what they expected w.r.t. privacy server side
... I think dsr is right
<dom> Privacy Rulesets Proposal
fjh: it seems like we could provide access to a Privacy URI
... it's not the best thing
dom: is that at the API level?
... or is it just a link for privacy?
fjh: maybe not
... but is there anything for privacy by design we could push for
... beyond what is in our scope
<npdoty> our paper on Privacy Issues of the W3C Geolocation API: http://escholarship.org/uc/item/0rp834wf
noah: do you specify at that level?
... you could have things which don't have e.g. buttons
fjh: we could suggest "provide a means to 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
noah: the fact that Users actually trust the Browser is interesting
ernesto_jimenez: the concern that we need to do Privacy by Design
... that the browser must get consent
... but then the browser should inform the user
fjh: Privacy by Design is Privacy by Default
ernesto_jimenez: but Privacy/Security is for each one of us
... the UA asks for information
... and it has to account for that
npdoty: that's an excellent point
... the work out of this group has been excellent
... informed consent is an indication of dialog between the site and the user
... if a UA might want to make a privacy preserving implementation
... they might want to have this extra field
... defining it in the API or otherwise standardizing this communication protocol
... that's why I want to discuss it at the API level
ernesto_jimenez: if UA vendors ask for this
... we could add it
... but in these cases, trying explain what a page will do with info is tricky
nwidell: we did some testing w/ normal users for getUserMedia()
... what we found was that people trusted the web site
... and they didn't understand
... they trusted the web site
... because it's a brand they interacted the most
... your user in the street doesn't understand the bit about UAs
... no matter how much we try to build sophisticated chrome around this
... it might not solve the problem, because users might not see these things
[ 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
[ 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 ]
<darobin> http://www.w3.org/2011/04/webrtc/wiki/File:Webrtc_privacy.pdf
darobin: I was in the WebRTC WG
... 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
richt: we've had this principle which has informed our design
... Opera and Mozilla did hundreds of hours of work and reached the same conclusion/design
darobin: it would have been simpler if we had a 2 page document we could point to
... since you [WebRTC] aren't the last WG who will need to work in this space
... some of this is in our Wiki in the API checklist
fluffy: Cullen Jennings, Cisco
<npdoty> higher level principles and examples would both be great
fluffy: something like that would help
darobin: (a) documenting it (b) removing confusion that it isn't done
dom: ... we also have http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/
... - the privacy document
<npdoty> I would note that the Privacy and Security Interest Groups would be very interested, for example
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 [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action14]
<trackbot> Created ACTION-471 - Look into a document for Security Principles for API Design [on Robin Berjon - due 2011-11-11].
npdoty: that would be awesome
darobin: Discovery API
<fjh> ACTION: fjh to update policy requirements for security requirements [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action15]
<trackbot> Created ACTION-472 - Update policy requirements for security requirements [on Frederick Hirsch - due 2011-11-11].
[ 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#action16]
<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].
<fjh> trackbot, start telecon
<trackbot> Meeting: Device APIs Working Group Teleconference
<trackbot> Date: 04 November 2011
<fjh> Chair: Robin_Berjon, Frederick_Hirsch
[Introductions of attendees]
fjh: Please join the IRC channel
dom: when you start speaking, please restate your name before speaking
[teleconference bridge may be set up if someone tries to dial in]
[About 60 people in the room]
darobin: we will begin with a short presentation on discovery
<fjh> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_(TPAC)
darobin: then a few demos
... so people can get a feel for how discovery works
... then look at potential solutions
... look at Web Intents
... approaches we want to discuss
Presented by Giuseppe Pascale, Opera
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
Giuseppe: We started from simple question; looking at what all devices in home have in common
... they all run a browser
... they are connected to the home network
... Look at other facts, numbers
... 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/
Giuseppe describes scenarios of ways people can interact with devices
Giuseppe: So are we there yet? Can we do this today? Answer is almost
... Each of these use cases require three steps
... Discovery, authorization and third step is communication
... then devices start to communicate
... If we look at three steps
... Download is nothing to be done
... But looking at Discovery, it's not something you can do today in a Web Application
... What we will enable is to allow services to be aware of services and allow them to advertise themselves
... Being able to support this is important
... people could immediately use own devices
... We did not see major gaps with communications
... UPnP is based on SOAP
... so don't have to invent a new messaging protocol
... Use cases where you just want the devices to communicate
... The only real problem using this technology is constraint to same IP
... cannot communicate with normal Web messaging; may want to relax this restriction
... So these were the main conclusions our group made
... So CableLabs and Opera we looked at these use cases
... What we found is that the gaps are small
... We all want application to do the get of services
... Application doesn't need to know; just ask for some kind of service
... Gets a pointer, a URL, and communicate using normal Web stuff
... Only new thing is navigator.getNetworkServices
... That is what led to this conclusion
... Then we created a task force to look into these use cases; and we published a report
... There are more use cases described there; references to existing standards
... We would really like to discuss these use cases and decide which is the right approach
... We are open to discussion
... thank you
[Zakim bridge to start]
Marcos: It was not clear to me
... a bunch of people like to watch TV while surfing Internet
... Is that the same experience?
... Am I on tablet, laptop?
... where is content coming from
... How does Web content meet ?
Giuseppe: TV content is not different from web content
... So far we are experiencing content on one screen; can I distribute to different screens?
... Can we distribute social onto other screens?
Marcos: So to render content on both devices
Giuseppe: have complementary content on two screens, reuse what is already available
fluffy: I have a question about the security model
... Most implementations of UPNP assume the local network is safe
... doesn't require credentials on the local network
... does this model mean that any random web site can access local network resources?
Giuseppe: in the Opera proposal, this is taken care via the user agent
... the UA asks whether you want to allow a given web app to access your local services
... before that point, no communication is possible
... But FWIW, this is already possible today via Android applications
fluffy: what about security, e.g. UPnP makes certain assumptions
Marcos: the threat model is a bit different there
... an Android application doesn't have as much power as something on the open Web
nvbalaji: How about the TV? Does the TV get a chance to authorize the mobile device?
... like some kind of peering?
Giuseppe: the examples I showed are based on UPnP
... 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.
Marcos: you don't have a choice
Jean-Claude: UPnP is one of the protocols that Opera is implementing as an example
... we don't want to lock ourselves with UPnP
... in the various protocols, there are occasions for security / authentication
@@@: @@@
Giuseppe: as shown in the slides, this allows browser to connect your devices
... using more secure way
... but that's protocol dependent
... We are enabling security with two devices
Jean-Claude: there is a communication protocol
... in between request for discovery and answer...
Giuseppe: the application can only ask for a type and get them
... there is user agent
... everything is hidden; you cannot info about your home network
Marcos: that is ideal; that isn't being exposed
Giuseppe: define some type of devices
... and the user agent says yeah, you have one
... this is device available at this URL
... user has authorized it
... how this is shown by user agent in way user understands is a big question
sicking: sounds like you are getting this to work on existing hardware
<jcdufourd> Jean-Claude: 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
sicking: are you looking at different security scenarios?
Giuseppe: enabling something not tied to any protocol if you establish a channel
... user agent may say not allow to communicate with any device
... this is one approach
... if people are concerned they can say no
sicking: where we can enable for security models
Giuseppe: underlying protocol; we recommend two
... if there is third or fourth it should be transparent
... new service; how to discover it; have a menu
... so doesn't have to be discovered in traditional way
richt: Abstraction of that process
... where innovation happens
... keep innovation; a high priority
darobin: BBC wrote a protocol...
<dom> Networked Service Discovery and Messaging proposal from Opera and CableLabs
olivier: We looked at a lot of use cases; many have been mentioned
... many users in the home
... We don't necessarily want the kid's PC to control the TV
... we built a prototype that does discovery, pairing, control, reading info
... 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]
olivier: What I hear proposed is interesting...have every device be a first class citizen
Marcos: about new protocols
... would be great if Web and TV could look into that
... what is the common model to be used
... then could be abstracted if something new is needed
... to follow up
... Like Web and TV group to answer how much
... what these protocols provide
... UPnP spec is huge and inaccessible
... DLNA is claiming how many billions of devices
Clarke: DLNA references UPnP.
<olivier> the Universal Control API (BBC)
Marcos: have a human accessible list to see what we can do; control volume, etc.
... What would be needed if a new protocol is needed?
Giuseppe: Two things
... this was completion of our group
... per the charter
... This group will have to answer
Marcos: So we will have to work together to answer it
... discover something, but now I cannot do anything with it
Giuseppe: we also discussed high vs. low level
... do you want to abstract in high level
Marcos: don't want to go there; too early
darobin: queue is closed
Marcos, bryan, and darobin
Marcos: we have to look at the licenses around these technologies and the implications
darobin: I think they are pretty bad
Marcos: we don't know
<bryan> If I understand one goal expressed, it would be to facilitate both existing and new devices through an API abstraction which is tied to neither. That seems like a good goal for the initial API. Is that considered a high-level or low-level API?
darobin: UPnP is RAND-Z; DLNA
Giuseppe: spec does not mention any
bryan: if I understand one goal
<Zakim> darobin, you wanted to talk about use case diversity
bryan: it would be to facilitate new devices that are tied to neither
... a good goal
darobin: a comment on presentation and discussion
... what I find notable
... this is a generic discovery API
... have you guys looked at...
... other things that people like me who don't have a TV would be interested in
... I could not watch two screens at once since I don't have a TV
richt: Good point
... look at services; what is local
... is this something we are going to do
darobin: if only controlling TVs
Giuseppe: if you watch content
... vs. not have a TV
... could watch content on your PC
darobin: Why would I have it on ten devices? I have a PC
... just saying it's important to look at other devices
... If I can access an extended network
... something about no assumption; and is it possible
Clarke: today it is possible
darobin: hands around the room
<dsr> There are many more devices of interest than TVs, cars, remote sensors, home healthcare, home security, heating and lighting, it is very open ended.
BobLund: this is not limited to multiple screens
... can access multiple devices
... UPnP can talk to your thermometer
Jan: prototype surrounding discovery
... allows you to discover content, formats
... see what is most compatible with your device
... example of not TV based
... there is other potential regarding that
... in homes
Jean-Claude: the use case we brought was multiscreen
... TV was one example that spoke to most people
... one important thing was to have use cases where things move around dynamically after start of various switches
sicking: a non-device we would like to talk to
... people's home routers
... that scares me if Web pages can open up a dialogue on users browsers
Giuseppe: user agent...
sicking: If all I need is...
Jean-Francois: We were talking about TV screens
... seems to bother you
... you can imagine listening to a podcast, go to car
... and transfers to car; continuous journey
... over different locations and devices
darobin: second screen
... let's go to demos
<richt> Any native application on any device can already pwn your router if it wants to.
Clarke: this discovery protocol...is a single API
... assumption is device discovered in some fashion, connected electronically
... way you communicate is up to user agent
<dom> richt, true, but native apps needs to be installed in the first place; you can't fall upon them just by clicking a random obscure link
Clarke: could speak an IP based protocol, USB, Bluetooth
... have to write some code to do that discovery
... that is only question
... no assumption
... turns out I work for company interested in TV; why my assumptions are based on that
[Clarke Stevens to demo]
<bryan> re the point about risk of routers with UPNP interfaces being taken over by a single browser ACTION: it's not possible in most routers to take control via a simple button from a browser on the network - most routers have some sort of admin login enforced, but I agree that it would be bad if that security was diminished in any way by this
Clarke: I have UPnP servers; mini DLNA
... demonstrates two protocols
... I am currently using two
... bringing up a regular web page
... the way I implemented it
... and how Opera has done in browser code itself is user agent is a Java applet
... web page is typical; HTML, CSS, JavaScript
... two things in applet; get network services
... three parameters
... type of service to find
... showing UPnP service
... passes URN that identified that service
<dom> CableLabs Discovery API Implementation as a Java applet (Member-only archive)
Clarke: other is MTDAP [?]
... everything else is on the network; only discovering those types of services
... also implemented in the applet
... XHR that does cross-origin stuff
... to security question, this authorizes browser to get the applet
... I've got a Java consol here to see what is happening
... now applet has started
... start UPnP Discovery and it starts discovery process to find devices
<richt> FYI, we will make 'Start UPnP Discovery' and 'Start mDNS Discovery' as a background process in the UA...like we do with Opera Unite with zero performance interruption.
Clarke: Once it's discovered, this asks to find two devices
... on the network
... a check box here
... So far the web page knows nothing about devices; all in the user agent
... If I don't check it still doesn't know
... have to check and say ok
... Now it knows about those devices
... communication is nothing new
... using XHR, Web Sockets
... whatever protocol you are using
... Calls are identical
... Looking for adapt server, calling different code within Java applet
... call it again and it recognizes that something has been discovered
... showing three services here
... just to show communications
... let me browse down tree
... generating SOAP
... come back again
... pop up same services it found before; uncheck one
... now communication with that service is disabled
... web page could store that
... no communication allowed between that
... that's it
[applause]
<Clarke> Here is the URL where you can get the CableLabs demo: http://lists.w3.org/Archives/Member/w3c-archive/2011Oct/0400.html
Giuseppe: quick comment
... communication part can be used with off the shelf products already
darobin: that's a security problem
Giuseppe: widget is allowed to communicate
Marcos: I still think that you guys are doing
... approaching in a weird way
darobin: the architecture?
dsr: Dave Raggett, W3C
<bryan> I wonder how the owner of the devices that are discoverable can be a part in this process. Is it assumed that any access controls are included here, except on the discovering user's case?
dsr: I'm going to show you another way of discovery
... Webinos is discovering apps across devices
... BMW is one of the participants
... this is an Android phone
... top part of display shows incoming requests
... advertises the IP address
... running UPnP and local web server
... bottom is screen preview
... I'll show you API is a second
... it's discovered the phone
... this is where Zeroconf/UPnP take different approaches
... and the naming may matter to users
darobin: this could be solved
... elsewhere
dsr: hopefully the users will give better names to their devices as they see them
... jumping backwards
... I developed a plugin that exposes EVERYTHING
... it's a nightmare
[ dsr demos a thing listing everything ]
dsr: SSDP is common and Zeroconf
... exposing everything makes fingerprinting trivial
[ dsr shows a dialog ]
dsr: this dialog shows what's available
... and it shows who's showing the dialog
<bryan> that brings up the essence of my note above: is it assumed that the users of all the accessible devices are responsible for the access to their devices?
dsr: I don't know that it's enough for informed consent
[ dsr: darobin look at the picture ]
dsr: you've discovered a ReSTful service for an unrestful picture
[ picture of darobin squirming ]
dsr: user's and end user's perspective are critical
bryan: do we assume that things out in cloud is out of scope?
dsr: I think AC is out of scope
... a lot of people out here are advertising themselves
... and they might not be totally aware that they're doing that
... but it's a separate issue
Clarke: I'll post a url on IRC for our app
darobin: thanks all for the demos
... it's nice for something concrete
... I'd like to get into the arch issues that several people have been talking about
... one of the things I've heard a lot of concern about
... is that you can list services
<bryan> link to dsr's demo?
<richt> FYI, some mockups of the UA UI for security/authorization:
<richt> http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_1.png
<richt> http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_2.png
darobin: yes it's user mediated
... but is that something you want to tell an app if you can avoid it?
... say you want to print something
... either "list me all the printers", I "show you the list of printers"
<fjh> does minimization apply to discovery
darobin: then you print something
... alternatively, you could say "I want to print something"
Jean-Claude: avoid "user mediated" to say "mediated"
darobin: we have a rule that you have to drink if you say "policy"
... is it more useful/more secure to get a list of services to the application
... or to have the app say "I want to do X to Y" and never let it know what it's talking to
Giuseppe: there could be cases when you need to talk to it
darobin: so you get a Worker
Giuseppe: some systems never want to be exposed
darobin: yeah, that's what I'm aiming at
bryan: that brings up the Roles of the Users in this Equation
... user has to make a decision about whether it's good for things to see stuff
... there's also a decision about knowing if things should be seen of remote devices
... there's an assumption of single owner on a home network
... that falls apart in the coffee shop
... we need to think about roles of users involved in making things accessible
Marcos: your example of the printer was a good one
... when you go to print from a web page
... you just press apple-p/cmd-p
... you get an Intent to Print
... I never need to expose the API of the printer to the web page
... I'm able to print
... I think that's a good model
... if this functionality is explored, I'd like to see that explored
... I'd like to see where it breaks down
<bryan> We need to think about the roles of the users accessing devices (the user may want to limit their browser to access only certain devices, whether or not they own/trust the devices), and the role of the owner of those other devices. These roles are very different in the home vs. a public space.
Clarke: I think that breaks down at the first step
... because the point is to let the web page have that interface
... if you have a TV or something
Marcos: give me a more concrete use case
... say I have Facebook and I want to have something on the screen
... or I go to Facebook, and I want to play radio somewhere
... let's cover the 90% UCs
dsr: there are many different UCs for accessing services
... the number of services, some will be defined by us, some by others
Giuseppe: we were thinking about looking at Web Intents
darobin: I heard something interesting
... I heard simple use cases and I heard Intents
... it could be very much interesting to see code
... about how simple UCs
... that Marcos was talking about
... could be done with Intents
... this is a debate that happens for a lot of APIs
... do you do low level or high level
<bryan> +1 to quick production of code examples that illustrate how discovery and Intents help here.
darobin: low better for innovation, high better for security
... there's no set rule
... it would be useful for moving forward
... to see a simple high level Intents api
... and a discovery api
Clarke: my url has 3 examples + source code
Giuseppe: how do we move forward?
... it would be useful to have the discussion in the sample place/group
<Zakim> dsr, you wanted to mention connection to social networks as a means for describing sharing preferences
dsr: we spoke about AC a while back
... it involved stuff in your own home
... there's stuff for social networks
... and what do you share with your friends
... how do users think about their services and control how they're used
fjh: we have different proposals about Discovery
... one from Opera
... one from Webinos
... should we talk about other fundamental differences in approaches
<bryan> +1 to dsr's comment - Intents as I understand it is about use cases outside the home - in the cloud
fjh: I'm not sure I understand what Arch issues are significant that we might not have been discussed
... dsr mentioned Naming
... another was timing for Discovery
<dom> (I don't think Intents are particularly limited to cloud-based services)
fjh: impact on Battery
... not sure what from Webinos that we're missing/forgetting
... we should identify Issues
darobin: given Time Constraints
<bryan> underscores the need to understand what Intents and Discovery *are* really about
darobin: Capture as Issues in Tracker
fjh: get a handle on key bits
Giuseppe: we did some in the Comparison doc
darobin: I'd like to close the queue
[ the queue was closed ]
<dsr> I will post my example as shown
sicking: you said most of what I was going to say
<richt> FYI, use cases are being collected on the W3C DAP Wiki at: http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases
sicking: the problem with low level APIs, is they're great, but the security model depends heavily on the api
<Clarke> The Opera/CableLabs proposed specification has already been posted to DAP. You can answer a lot of architecture questions by referring to the specification.
sicking: if anyone could take a picture with just that incomprehensible dialog
... would be scary
<fjh> ISSUE: Low level discovery API security and privacy issues
<trackbot> Created ISSUE-123 - Low level discovery API security and privacy issues ; please complete additional details at http://www.w3.org/2009/dap/track/issues/123/edit .
sicking: I might want to allow something in Mozilla, but with a different security model
dsr: we could argue about high/low level
... the security/usability bit needs to be discussed at length
adrianba: Adrian Bateman, Microsoft
... 1. in many platforms, e.g. Windows
... we have APIs in the platform that do Discovery with different protocols
... this proposal abstracts protocols is a good thing
... requiring certain protocols in the API spec, which this does, we think is a bad thing
... 2. the level of details exposed
... is too detailed
... we tell you "which of these TVs do you want to talk to"
... not "which services do you want to talk to"
... 3. we don't generally make individual protocols available
... requiring pages to be able to speak individual protocols seem like a problem
Giuseppe: exposing an AV service
... the UA has all the info
... it won't show AV service
... the info isn't shown to the page, but to the user
adrianba: we don't know what you're looking for
... the API asks me to ask for services
... I don't know what you really want
... I don't know how to aggregate it
Clarke: you could make that specific to your application
... we're implementing everything in JS
... to make the API very generic
... you could offer only "show on screen"
... you could show "do you want to connect to your TV?"
... I think that's an implementation detail
jcdufourd: one thing not in the two proposals
... discovery is started by JS API call
... one choice is to have discovery as a background process in the UA
... and not started by the call
richt: that's not what our proposal is
jcdufourd: the demos showed that
dsr: it's not the case
richt: in Opera Unite, we do background discovery
... it has 0 penalty
... on performance
... we like it
darobin: where do we move this forward?
... is it the consensus of Web IG that it happen in the same place as Web Intents
Giuseppe: we haven't discussed this in the IG
darobin: we had a joint session w/ WebApps on Monday
... the agreement w/ WebApps is a joint TF on Intents w/ DAP
<ArtB> Here are the minutes from WebApps' minutes re Web Intents: http://www.w3.org/2011/10/31-WebApps-minutes.html#item06
darobin: that's scheduled for the next session
... there would be a separate mailing list where Intents would be discussed/developed
... I don't know to what degree discovery could be done there
... I'm sort of happy with whatever makes people happy
... it would be useful for you guys to come to the next session
... better for you to represent yourself, than have me proxy you
... after the break, 10 mins on NetInfo and then Intents
ArtB: talking about technical details or just work split?
darobin: getting approval from the group
... it could be 30s
... it could take 2 hours and a half
... back at 10:50a
... tentatively Intents at 11am sharp
<ArtB> Title: DAPI WG f2f Meeting
<ArtB> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_%28TPAC%29
<ArtB> Meeting: DAPI WG f2f Meeting
<dom> The Network Information API editors draft
darobin: information exposed about user's network situation is not sufficient
... might be on the WiFi network but that WiFi could be using 3g (via tethering)
... some people have expressed interest in talking about this
... Mozilla, Microsoft
sicking: first thing is checking whether you have connectivity at all
... you probably want to know whether you are connected, and know whether you are on Edge (very slow)
... some concerns about finger printing too
adrianba: Web platform sensitive to network in two ways
... JavaScript API to learn whether you are on a metered network
... we think it is difficult because it's usually another part of the platform making that kind of decision
... e.g. we may want the video element to make a decision based on available bandwidth
... may need apps to coordinate based on the network available
<Zakim> Josh_Soref, you wanted to talk about how apps might want to make a decision and will make the wrong one based on the answer they get to the unrelated question they ask
Josh_Soref: apps might want to make a decision and will make the wrong one based on the answer they get to the unrelated question they ask
... if you have multiple network paths, the app might make a bad decision
... XHR can be used to know whether you have network connectivity
... try!
... the only way to know whether you have connectivity and sufficient bandwidth is to try
... if you try and make a decision based on some theoretical network topology you are likely to make the wrong decision
adrianba: +1
fluffy: one thing you can't find by measuring is what you will be billed
<Zakim> Josh_Soref, you wanted to respond that no one has that info
adrianba: question is how much is the UA's responsibility, how much is the app's
Josh_Soref: [missed]
bryan: there are network APIs in development
Josh_Soref: Nothing knows costs, Nokia+RIM experience shows that a SIM in a given country doesn't have any relation to cost
dom: the GSMA is working on this as part of their work on network APIs (e.g. OneAPI)
lgombos: Just the act of trying costs money
[ Birds chirping in background ]
lgombos: it is possible that the network knows those characteristics, but the browser does not know them yet
[ The chirps turn out to maybe be squeaky wheels on a cart ]
darobin: anyone interested in working on a proposal around this
[ Marcos investigates carts ]
sicking: I might be interested
adrianba: expresses interest too
Josh_Soref: me too
<dom> ACTION: Adrian to make a proposal for Network Information API [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action17]
<trackbot> Created ACTION-474 - Make a proposal for Network Information API [on Adrian Bateman - due 2011-11-11].
<Josh_Soref> ACTION: soref to propose a new Network Info [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action18]
<trackbot> Created ACTION-475 - Propose a new Network Info [on Josh Soref - due 2011-11-11].
<Josh_Soref> ACTION: berjon to ACTION: sicking to propose a new Network Info [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action19]
<trackbot> Created ACTION-476 - ACTION: sicking to propose a new Network Info [on Robin Berjon - due 2011-11-11].
darobin: the idea is to get agreement on the joint work
... objection to working with WebApps on Web Intents?
[ darobin references unorganizations from Wednesday ]
richt: clarify what it exactly means?
... where does the editing get done?
darobin: the document lives in /TR
... and it lives in /hg for which we're happy to use mercurial. If the editors prefer to use CVS, they should be dragged away and shot
... IPR-wise, the document would be covered by the union of the two groups
... no details yet on the operational side
ArtB: no change to DAP charter, but would require a change to the WebApps charter
darobin: might be technically covered by DAP first
[ might be => is ]
richt: is this the model for Device APIs going forward
darobin: whenever it makes sense to use something, we'll use it
sicking: can I request to have a separate mailing-list
darobin: that's operational. Hold that thought
bryan: no objection. We need to understand what we consider device api, what we consider network API etc
dom: the answer is 42, I'm afraid
bryan: people still have questions about "what is a device API"
dom: answering the question won't change the shape of the work
... I don't think we can usefully define what is a device API and what's not
... the only useful answer is what is currently a deliverable in what group charter
adrianba: joint deliverables should be avoided in general
... there are times when some people can't participate in some WGs
... when such situations arise, a joint Deliverable is probably the least worst solution
Josh_Soref: rather than, say, creating yet another group
jcdufourd: problem is we don't exactly know what Web Intents are
dom: Does anyone want to introduce?
Marcos: go to http://webintents.org
[ Josh_Soref takes a run at introducing Web Intents]
Josh_Soref: the general idea is - a page wants to do something, e.g. share
... the UA will get a list of things that could do sharing
... if the user chooses to share, the UA would open a new window and send the data that the user wants to share
... you can share, call, print... many different possible verbs
Marcos: list of default Intents - Discover, Share, Edit, View, Pick, Subscribe, Save
darobin: fairly similar to HTTP verbs
... example of sending e-mail from a page in Android
<Anders> WebIntents, try the demo posted by Claes Nilsson http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0009.html
jcdufourd: this looks like a web service directory or broker
darobin: it is, but we don't have that
jcdufourd: but do we need a standard for it
Marcos: we need services to register themselves with the broker
jcdufourd: you could implement that today, offer the service
[ Josh_Soref demonstrates how Intents "tosses" the data ]
<dom> Josh_Soref: not without knowing the service provider beforehand
Josh_Soref: not directly talking to the service
jcdufourd: but why do we need a standard
darobin: we've already decided to have a standard, it's in the charter
nvbalaji: the browser is becoming a broker, so web pages can register themselves
... can any site register itself?
Josh_Soref: that's one way. Someone could maintain a list
dom: there are many ways to register
... in band, out of band
ArtB: [tongue in cheek] I conclude you are not going to do it and WebApps will do it
Josh_Soref: important point is that if we don't do it, WebApps will
dsr: when it comes to joint deliverable, important to agree on scope
... can we reach an agreement on set of use cases
darobin: would have liked this discussion to happen on the list
dsr: relationship between this and generic registration and discovery. Need to clarify
darobin: yes
<Zakim> dsr, you wanted to ask if this is essentially service registration. an invocation?
JanL: question on the security aspect
bryan: Is part of the reason for DAP's interest that we expect device-local resources to use Web Intents to register themselves as potential providers?
darobin: yes
nvbalaji: would we expect DAP APIs to be required to use WebIntents
darobin: having reached the end of queue, asking again - any objection to joint work
RESOLUTION: DAP will do joint work with WebApps on web intents
darobin: opening operational topics
sicking: a few people would rather not subscribe to the DAP (or WebApps) ML
... but would have a lot to contribute
<dom> +1
sicking: request a separate mailing-list
darobin: Any objection to calling it Intents?
sicking: don't know
<nvbalaji> Does it mean that interest web intent implies Device APIs must be defined in terms of intents?
<dom> (public-noname@w3.org ?)
sicking: think it's a terrible name but trying to stay away from naming discussions
[show of hands for strong support]
RESOLUTION: there will be a separate mailing-list for web-intents joint work
[ The show of hands is quite strong ]
darobin: should the task force have telcons? think it should be the TF's decision
... ditto for mercurial, etc
... anyone would like to step in as chair for the TF?
... any other operational concerns?
dom: question of when WebApps gets rechartered with it
... and when we start
darobin: I assume ASAP
<richt> +1
Igarashi: wonder if the scope would include discovery of services and resources in the home network
... as we discussed in previous session
<richt> +1 and I'd _like_ to solve local device discovery with Web Intents.
<richt> ...but I'm entirely unconvinced.
mav: Mark Vickers, Comcast
... too soon to say that the two efforts should result in the same API, but there are clear similarities
<dom> +1 on mav
mav: hoping they at least be consistently addressed, early on
... strong similarities with the use cases mentioned in home networking discussion earlier, sharing photo, etc
darobin: first discussion on Web Intents could take scenarios and see how they map
<dom> +1 to robin
darobin: see if Intents match, complement Discovery
mav: could result in chartering issues for WebApps if the two need to be merged
richt: I'd _like_ to solve local device discovery with Web Intents. We tried but ran in to numerous issues and absolutely needed to remove some of the abstraction from that model. Would like to re-evaluate those use cases in the Web Intents discussion.
<olivier> ACTION: Robin to draft TF charter for Intents [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action20]
<trackbot> Created ACTION-477 - Draft TF charter for Intents [on Robin Berjon - due 2011-11-11].
<olivier> ACTION: Robin to wirk with ArtB, agree on mailing-list name (public-Intents?) [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action21]
<trackbot> Created ACTION-478 - Work with ArtB, agree on mailing-list name (public-Intents?) [on Robin Berjon - due 2011-11-11].
dom: any feedback on using Web Intents as potential replacement for messaging API
fjh: do you want to draft a proposal?
http://f1.mozillamessaging.com/
darobin: people working on F1 best for that?
nvbalaji: is the browser responsible for the UI for local messaging?
sicking: not necessarily
dom: the browser can hand off UI to the native app
darobin: Intent can be anything
... same for printing
... you can do cloud printing
... you could do printing to a local device
... if you're doing it locally, you have to support local printing
... that's already the case if the browser already supports this
... if it doesn't, it can send the Intents elsewhere
nvbalaji: if someone wants to expose local services, it has to be through the browser
dom: one way to expose them is to use a local native app
... you need to have something to send the data to the native app
... but the browser doesn't have to do the UI
... or underlying protocol
darobin: one thing not discussed
... I'd expect UAs to allow for Extensions to expose Intent services
... so you might not need to modify the browser itself to expose local services
... you would probably use its extensibility platform to do that
... at least, if that's what I'd do as a browser vendor
dom: other feedback?
<bryan> Is the concept for using Web Intents for messaging that all interaction with a messaging client would use XHR / REST to a local or remote device resource (depending upon which provider was selected by the user)? Or for a "local provider" would the browser be able to optimize the interaction by calling a native service API directly (e.g. a messaging API)? Would we expect that the user experience in both cases is equal, and the Web developer tasks to
<bryan> use these implementations equivalent?
bryan: understanding concept of using Intents to replace Messaging API
<darobin> http://mozillalabs.com/messaging/2010/11/10/f1/ -> Mozilla Labs: F1
dom: up to the browser
... will there really be no difference in Perf/Security?
<dsr> In principle, the browser could also load intent "drivers" for remote services over WiFi and Bluetooth, or even USB and NFC.
<darobin> http://f1.mozillamessaging.com/ -> official Mozilla F1 site, for Sharing/Messaging
bryan: say I want to create a draft message
... how would that work?
... is that sent to the cloud/device?
... I understand how that works in JS
richt: my understanding of Intents
... you choose an intent, get a service
... the UA broker opens a tabbed window displaying the service's page
... this concept of communicating over HTTP w/ UPnP
... is not in the protocol
dom: I think the browser could have a UPnP implementation for that
richt: the browser has to speak that language
dom: if you require this, you lose the ability to bring more
Josh_Soref: of course an extension could add them
dom: Intents is a Framework for adding solutions
... but we'd still need an API for that UC
... for drafting, for sending
... at the end of the day, it's up to the User to select the UE
... turning the Messaging API into the Intent based approach
... still requires deciding how to do it in that Framework
... how do I discover and attach?
darobin: the idea is not "We Have Intents, We're Done"
<dsr> [I am looking into ways to treat service/Intent drivers dynamically as a market for services, and look forward to providing demos]
darobin: each Intent still needs to define how a given API works
dom: we have WSDL for that >:)
[ darobin threatens to throw a full bottle @dom, we only tossed empty bottles earlier ]
darobin: it's reasonably easy to define that api
bryan: we still need a messaging API spec
... is it possible to be done in JS?
dom: you could have a wrapper that could do that
bryan: developed outside of W3 from that?
nvbalaji: Messaging/Intents
... for local messages
... will the browser actually do that?
... will a plugin have to do that?
... will the browser do that?
dom: I think browsers will have to do that
... just as they respond to mailto:
nvbalaji: is that mandatory in the spec?
<bryan> To me, the result of the discussion is that we still need a messaging API spec, even if we use Web Intents to facilitate discovery, attachment, security.
dom: it's as normative as having a separate JS api
... browsers would have to implement it if it were separate
... same as if browsers bridge to local for Intents for Messaging
nvbalaji: is it mandated that browsers do this?
Josh_Soref: there is this thing called window.print in DOM0
... and have a lot of devices with no ability to print
<bryan> An open question is whether Web Intents prevents the exposure of APIs using JavaScript, or the W3C's ability/opportunity to develop JavaScript-based APIs.
Josh_Soref: or send e-mail
... some browsers don't have such capabilities out of the box
... but could be extended
... as a framework, this says "you can ask for X"
... implementation quality will determine whether the user can print/message
[time check]
sicking: re: bryan 's concern about messaging over Intents
... we just need to ensure we can handle the UCs
... it's unanswered, but we can ensure it will be supported
... there will need a defined API on top of Intents
bryan: maybe that URI is abstracted by the browser
dom: there will not be URIs for services
... communication is via postMessage
... you get something back
... is how you get things back
... no visible HTTP interactions
... in the background there may be, but you don't experience them
<nvbalaji> It looks to me "messaging API with Web Intent" means dropping the messaging spec entirely :-)
darobin: lunch until 1pm
[ Adjourned ]
[ We're about ready to start ]
<fjh> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
lgombos: Laszlo Gombos, Nokia
... originally in Web Notifications
... later on it was discussed that it would be useful outside of the scope of that API
... so it came to DAP
... and Web Notifications has a dependency on this Spec
... it's somewhat controversial
... we're interested in getting the issues on the table
... there's a WebKit implementation
sicking: is it shipping?
lgombos: yes
... I think it's in Chrome
... Nokia shipped it as well
<darobin> http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html -> Playground for Feature Permissions
lgombos: I think it's vendor prefixed
fjh: I think darobin did an experiment a while ago of using a registry for features
... we talked about using a registry, reusing infrastructure
darobin: there's a registry for XPointer
... I registered the DAP-XPointer scheme
... the same infrastructure could be used
... the infrastructure is there
lgombos: atm, what we know is Web Notification
... if that's the only feature for this api
... then maybe it doesn't make sense to have this spec
darobin: if it's the only case, then this approach, is the wrong way
fjh: one could ask if there's a need to have a means for permissions that's interoperable
sicking: to derail the discussion
... or I'll yield to implementers
lgombos: for Nokia, we're interested in Web Notification, and we have a dependency
sicking: here's the take from Mozilla/people talking about it
... most people at Mozilla (there are disagreements at Mozilla)
... my understanding that the goal of this spec
<dom> Permissions For Web Applications, Robert O'Callahan
sicking: is to allow the page to bundle a bunch of requests together
... to reduce the number of requests the user sees
... that's an antigoal for us
... we don't want to let people group together a lot of requests (camera, location, ...)
... there's research that says people don't read dialogs
... but there is research that says people do read the button
... having a very big button will cause users to not read the button
lgombos: I think the functionality you describe would be a natural fit
... a the moment you only can request one thing at a time
... is that when we display UI for something
sicking: another thing that's a goal for us
... at the site when something is going to use it
... for instance, when you install an App on Android
... you get asked for permissions for lots of things
... but you have no way of making a determination
... of why does e.g. a Game need access to Contacts
... maybe the Game wants to play w/ contacts
... and maybe you could add a description to the request
... but when you want to install, you're so excited
... you really want to play
... and sharing the game with others
... is something the user can make a decision on later
fjh: the idea was to ask for permission up front
... to avoid user involvement
sicking: that's an antigoal for us
... we don't want an app to say "I want to play the game, but I don't want to give access to contacts"
... it's better application design
... the way to encourage that is through more user choice
... in general, we're worried about applications asking for a bunch of things up front
... and if you don't say yes for everything, they'll say "you don't get to play"
... we can't prevent it completely, but the more we do to prevent it, the better
bryan: this API is about an app asking for permission
<bryan> We need to provide a way for users to know about what features are used by an app, and to select permission level for each. Most users would never be expected to use such controls, but the exposure of them is likely to be a mandated (e.g. regulatory) requirement. These permissions do not need to involve prompts, but do need to be representable in some UI that is provided by a trusted entity (e.g. the Web user agent).
lgombos: also query permission
<bryan> The reasons why an app wants to use an API, and how it intends to use/share data that it obtains from it, are things which we defined a way to express using W3C POWDER, and can be associated with the app through the HTML link element.
lgombos: on their mailing list
... something like .allowed / .enabled /
<AnssiK> Feature Permissions Playground demo on how to handle multiple permissions up-front: http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html
<dom> navigator.geolocation.enabled feature request
<dsr> [Note that WebAppSec WG are working on content security policies (CSP) where the browser is instructed to *remove* permissions. In the current session we are talking about *adding* permissions, so we should probably coordinate with WebAppSec]
AnssiK: at one F2F, I was asked to write a demo for this
... so you can say sensor implements permissions
... you can play with it
... and see if it feels right
... most of the time it doesn't feel right
... sometimes, it might be ok
<dom> [CSP removes permissions on cross-site operations, AFAIK, not on API usage directly]
AnssiK: if the UA asks up front "can I save 10mb of data"
darobin: am I hearing this might not be a model for all permissions
... but it might be useful for a subset of things?
AnssiK: yes, it's not a silver bullet
... in this group, we don't have many APIs that might work
... especially sensitive-user-detail-exposing APIs it'd be out of scope
... maybe Storage+Notifications
... but I don't like Notification Bars
... they don't feel right to me
... but it's the best we have
lgombos: the Notification UC is valuable
... perhaps your Gmail tab
... in your Gmail case, you want to be notified in your native environment
... that's where the action happens
... you're trying to get attention of the user
... perhaps it's only the notification API
... the challenge with Storage, it's a good example
<bryan> Link to the workshop where we presented the POWDER approach to app intent disclosures: http://www.w3.org/2011/track-privacy/ and our paper http://www.w3.org/2011/track-privacy/papers/ATT.pdf
lgombos: by the time you ask, maybe we have 10 mb
... but maybe someone else starts using it?
richt: I think it makes a lot more sense to access something
... and get permission at time of use
<richt> http://developers.facebook.com/docs/reference/oldjavascript/FB.Connect.showPermissionDialog/
richt: I want to point to Facebook
... specifically, Facebook Connect
Marcos: how many times have you read it?
... do you remember any of the things you've been given?
richt: I want to point out the precedent
darobin: Android does that as well
Josh_Soref: Sun's Java did that years ago -- they stopped!
sicking: there's interesting research
... it doesn't all say that it's terrible
... the research says what parts work and what doesn't work
... out of Berkeley
<Zakim> adrianba, you wanted to talk about testing
adrianba: I agree w/ a lot of what sicking said
... I want to pass on feedback we've heard
... a lot of developers don't want the explosion in the test matrix
... of testing their apps in different combinations of permissions
<Zakim> dsr, you wanted to relate this to the privacy and informed consent issue
<dom> Android Permissions Demystified , from UC Berkeley
dsr: when it comes to asking permissions of users
... I understand about usability research
... and respect that
<dom> Adrienne Porter Felt home page (one of the co-authors of said paper)
dsr: there's a more general issue of how web sites inform the users about what they do
... beyond the current point
... there's the issue of informed consent
sicking: a way for a site to indicate what features in say a manifest
... we have the open web apps proposal
... maybe submitted to W3C
darobin: I don't think so
bryan: I don't either
sicking: the idea is it's a manifest format
... for installation process for a web app
<dsr> Dave: very much respect the usability research on asking users for permissions, and we also need to factor in the need for informed consent - this is hard, but we have to address this.
sicking: when it's installed, doesn't give you much permissions
... we've talked about giving some permissions, but nothing actually sensitive
<dom> "we find that about one-third of [940 Android applications] are overprivileged. We investigate
<dom> the causes of overprivilege and find evidence that developers
<dom> are trying to follow least privilege but sometimes fail due to insufficient API documentation." -- http://www.cs.berkeley.edu/~afelt/Android_permissions.pdf
<dom> Widget Access Request Policy
<darobin> https://apps.mozillalabs.com/ -> Open Web Applications
sicking: we've talked about putting into that manifest a list of things that this app requests
... we've talked about putting in about whether it comes from a trusted source
... e.g. Amazon
... and letting Amazon say I trust this app to do these things
... so a page can express high privilege things
Josh_Soref: support Mozilla perspective, asking permissions upfront a disaster
... reminds me of Java approach
... Android installing app, or PlayBook, also doesn't work.
... BlackBerry says upfront but can continue without granting permissions
<dsr> [A further consideration is whether users are in a position to make an informed decision about trusting a site, sometimes people will prefer to delegate that to others they feel are in a position to provide effective advice. We need to consider the potential role of trust delegation.]
Josh_Soref: being able to use the app without granting permissions upfront is valuable
... do not want Java model of "try and die"
<dom> Nokia process to sign applications
Josh_Soref: goal is to always let app go on, maybe a picture won't be shown and there be a blank space, but better to continue
<dom> navigator.geolocation.enabled feature request
Josh_Soref: use of a non-blocking field is valuable, can see and/or change value, see context
... IRCCloud I use, it has notices
... give permission to enable pop up by system from inline notice
... give permission through action so no need for permissions
<dom> [a blog post of mine arguing for <input type="location"> back in 2008 http://www.w3.org/blog/MWITeam/2008/01/29/making_html_location_aware ]
Josh_Soref: lying also asks as an alternative to permissions
<bryan> Just because we have not found an effective UI for user informed consent, is no reason to either abandon effort to obtain informed consent (ignore the UI), or severely limit the Web in terms of the types of contextual data etc that can be used by apps. We have to solve the UI problem, and provide at least some user control, however ineffectual current models for that UI are or seem to be.
<bryan> On the point Josh_Soref made re exceptions, I disagree because exceptions (of a "not supported" or "security violation" type) allow the app developer to take fallback approaches in the catch handler. Taking the notice example, it would be important for an app to know that a notice was not given because the user decided to turn off notices, as that would give the app the ability to use another approach.
[ bryan makes a case for giving the app choice about fallback ]
fjh: to adrianba
... on testing permissions
adrianba: if my app asks for webcam, location, storage
... you're going to need to test the fallbacks anyway, right?
... there are 8 different combinations of yes/no for each combination
fjh: but at some point you're going to need to test if you don't get the camera
dom: if you have camera-storage-location yes/no
... then you have only two cases to test
fjh: so a batch is "simpler"
darobin: a lot of this hinges on how people write the code
... if you ask up front, the application takes a different path early, maybe a totally different app
... if you test in the flow, the logic of the individual case can be tested
adrianba: I started by saying that I agree with what sicking said
... but I was sharing feedback I was given
fjh: I don't see how we get express agreement
... you can't say action = consent
Josh_Soref: to expand on the location thing, I've had a lot of time think it through
... one could imagine that <input type=location> would be visualized via a map
... the browser could offer various level of granularity
... and update the map as you pick a place
... the browser could then offer to make the update to the map automatically
... the user then reacts based on the value she perceives
fjh: if that map provider sells my info, then consent needs to take into account notice about that, at the time of consent
... what to do when user has denied permission
sicking: several things
... we can do as Josh_Soref suggested, provide false data
... in general, we do things async
... so throwing isn't a risk
... we can never provide an answer
... which has the use of sites graying out until you answer
... it's a technical discussion on individual specs
... I do hear that,
... on adrianba 's concern on test matrix size
... but I'd like to allow UAs to be able to try
... if the alternatives are "allow all/none"
... or pick and choose
... I think the User would rather pick/choose
... on consent, it's not something we've talked about
<bryan> Re the comment on async APIs and exceptions, async APIs can include an error callback so even if exceptions are not returned, errors (e.g. security) can be provided to the app.
sicking: if we take the string from the page and show it in chrome UI
... users might think we're enforcing what the page claims
... at that point, we're risking the user only consenting to that
... if we formulate it so that the user understands what we claim to be doing
<dom> [FYI, Mozilla currently doesn't request permissions to show notifications IIRC https://developer.mozilla.org/en/DOM/Displaying_notifications ]
sicking: then that's better that the site is breaking the site's promise
<Zakim> richt, you wanted to talk about how we can enable trust decisions to be triggered within a web page. (RE: pop-out web notifications)
richt: I like Josh_Soref 's idea of escalating permissions
... you get the functionality, and you get something better
<bryan> Informing the user that data is intended to be used locally or sent to a server is specifically the intent of what we proposed with POWDER. The notice represents a contract with the user that can be tested.
richt: and we looked into that for getUserMedia()
... we allowed the video element to display data
... but we tainted the canvas
... and you had buttons to allow full access later
... you got a Head/Hair check
... the problem is ClickJacking
... but based on what Josh_Soref was saying
... the most intuitive cases
... being able to make trusted escalation permissions
... from in web pages
... we took a concept from DOM
... we wanted to tie a click event to a user's click
... if that event is synthesized, it won't work
... but for a trusted click, it works
fjh: you're not talking about trust between parties
richt: this is about escalating permissions from within a web page
... that's impossible w/ Click Jacking
... but we looked into it earlier on
... I just wondered whether we could solve some of those problems
fjh: is there an example?
richt: you have click events on specific objects
... if the user actually clicks it
Josh_Soref: use the file dialog
<dom> API Invocation via DOM Events in Contacts API
richt: the file dialog is the result of clicking on the UA styled element
... it's inserted into the Page
... and the User clicks on it
... then we can show that the user wanted to do this
... that would be really cool
... this is Escalation
... we could have popups in the page
... for popups, you may not need anything
... just mentioned that we have looked at it
<Zakim> dsr, you wanted to note that mechanisms to prevent clickjacking are being considered in WebAppSec that might help
richt: it's cool, but difficult
dsr: WebAppSec is looking at how to limit click jacking
... like limiting areas within the screen
<dom> [https://mail.mozilla.org/pipermail/WebAppSec/2010-August/000003.html talks about protection from clickjacking from third parties]
fjh: so, about this spec
... what are we going to do?
sicking: if it's just going to be used by notifications
... then I'd ask if it makes sense
dom: there's the aspect of asking about querying permissions
... I think that's less controversial
sicking: I think there's some controversy about that
... I don't know enough about it
... one place we do put up a prompt is for AppCache
... I know it's a model that isn't really working well
... and developers have been asking for things to make it easier to work with that prompt
... like "will that prompt show up if I try"
... another is "please forget that I had permission"
... I don't know if it makes sense in a generic API
dom: that could be defined out of bounds
<rigo> I think you should just record decisions/permissions and let the lawyers figure out what it means in their respective context/region
sicking: I don't know if it's better for the APIs to be together or spread across for querying/forgetting
Josh_Soref: Querying came up in GeoLocation this week (see dom's pointer) and I think it's an indication of a bad design
sicking: you can easily limit the API so that it only puts up a prompt during a click action
... we talked about only allowing file picker during a click
... we want ways of communicating to a page what will happen when an action is taken
... we can't design APIs perfectly to avoid certain dialogs
darobin: on queries
... datapoints relating to querying
... in the jQuery breakout on Wednesday
... one thing that surfaced very strongly
... is a desire to do feature detection
rigo: to define consent is difficult, as it's contextual e.g. by locality
... you can record the evidence that is later looked at to determine if there was consent
... so you could reduce to the technical decision where to record and how to save it for later
richt: we looked at where and how to record, so you could look back at what the API was doing, and for the %.001 of people who would do that, it would be useful
... and provide more transparency
fjh: what do we do next...? Dom had some good suggestions, and we need to do something now that we have talked about it
... anything we can do?
lgombos: one option is to continue to discuss, or to make a decision now re whether the generic API is something to pursue
dom: my take is Web Notifications gives an example, but is not a completely reusable way to do this. Rather propose including this in the design of the UI for each API.
fjh: is that there is another way to do notifications the way out of this?
sicking: have not figured out the way to do this for desktop yet
fjh: sounds like we are not ready to make a decision
sicking: mobile is likely different, as the whole screen is the page
dom: you get notifications in the bar at the top etc
bryan: we will end up with a continually shifting set of approaches if we drop this now
Josh_Soref: UIs are evolving, faster now, and having something specified may not be the answer - letting the UIs evolve may lead to a better solution
darobin: there is a difference between not addressing this API and not addressing security issues
<darobin> http://dl.dropbox.com/u/444684/notifications.html -> a demo of notifications that works in current Chrome and Firefox Mobile
dom: we've heard that querying permissions may be less controversial, but asking for permissions is something that browsers may not be ready to adopt
lgombos: we need more feedback from content providers
<fjh> dom notes adoption of requesting permissions in a bundle not clear
<fjh> we need more implementer feedback here
darobin: could we take this to the JQuery dev group etc and get their feedback, would that be useful
sicking: we are in research on this, the current thinking can be shared, but we don't know the UI that will result
<fjh> if this is a research topic is it premature for standardization?
fjh: we are looking for additional feedback
dom: robin's suggestion is good enough for that
<darobin> ACTION: Robin to take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action22]
lgombos: propose to provide the feedback from the discussion we just had to the notifications group
<trackbot> Created ACTION-479 - Take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account [on Robin Berjon - due 2011-11-11].
<fjh> ACTION: laszlo to provide summary and request feedback from notification wg on feature permissions [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action23]
<trackbot> Created ACTION-480 - Provide summary and request feedback from notification wg on feature permissions [on Laszlo Gombos - due 2011-11-11].
dom: anyone interested in pursuing querying permissions?
<fjh> fluffy notes we should not confuse lying with errors, need to lie clearly
fluffy: there should be a discussion about the "lying" response or other such things, as they have cons
... or pros
lgombos: as editor happy to make changes as needed
dom: we are not ready to make changes
... need some look into how this has been done on other platforms
fjh: will look into that
<dom> ACTION: fjh to work with laszlo on looking at options for querying permissions across APIs, providing fake data, etc [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action24]
<trackbot> Created ACTION-481 - Work with laszlo on looking at options for querying permissions across APIs, providing fake data, etc [on Frederick Hirsch - due 2011-11-11].
<dom> Contacts API Editors draft
Josh_Soref: displays current contacts draft
... moved into DAP mercurial project
<darobin> https://wiki.mozilla.org/WebAPI/ContactsAPI -> Mozilla's Contacts work
<Josh_Soref> http://bitbucket.org/Josh_Soref/dap has my repo
Josh_Soref: showing version being edited
... looking at diffs
[ Can we wrap the diff on the screen? ]
<nvbalaji> Contacts is an excellent candidate for Intents
Josh_Soref: may have questions on the starting point for the edits
... attribute ContactName was removed, changing complicated objects into flat strings
<henri> Do we care (at all) about contacts? In the "cloud" era, there will be many online services that do this and anyone can write a web app that connects to them already. Just curious.
fluffy: Web RTC was assuming the ability to lookup a phone number, email address, IM address and then display the user's name. If you drop the fields does that make it easier to do phishing attacks?
Josh_Soref: the need to use all the dots to link the names of things in the object tree is wasteful
darobin: it's better for interop with VCard 4 to have a flatter set of attributes
fluffy: removing the type?
... how will you do IM schemes?
Josh_Soref: embedding a URI scheme into it etc have not been fully though out
bryan: you are taking away the ability to know family, business, groups, etc...? not a good idea
Josh_Soref: the freeform type doesn't help where the content is represented differently in different locales
+1 to richt
dom: you are dropping a feature vs. fixing it per bryan's comments
[ Josh_Soref displays Mozilla contacts API docs ]
https://wiki.mozilla.org/WebAPI/ContactsAPI
fluffy: the suggestion for the problem is to create an enumerated list rather than dropping the field
fjh: we had extensive discussions about POCO etc, some are just cleanup other to features and not sure about the rationale
Josh_Soref: one approach is to drop it and take Mozilla's proposal
darobin: we build on POCO and in VCard 4 the data model has moved toward flatter structures which map better to this
dom: a proposal to change some of the design decisions need to be made so we can address each
nvbalaji: wondering why the API approach when Web Intents is being considered now
Josh_Soref: came late to this
darobin: as currently specified it is mostly about what does a contact look like, so most of the API would not change even with Web Intents
<dom> [I think we should probably highlight that point as an ISSUE in the document]
dom: suggest to add note re this may change with Web Intents
<Josh_Soref> ACTION: soref Contacts find() may be replaced with Intents [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action25]
<trackbot> Created ACTION-482 - Contacts find() may be replaced with Intents [on Josh Soref - due 2011-11-11].
<Zakim> fjh, you wanted to ask about interop
<Josh_Soref> ACTION: soref to send proposal to list for how Contacts will move forward [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action26]
<trackbot> Created ACTION-483 - Send proposal to list for how Contacts will move forward [on Josh Soref - due 2011-11-11].
fjh: assume an action to send a proposal to the list so we can find it - any additional key points?
Josh_Soref: some examples will go away
... address fields etc will flatten. things on the web will allow parsing the fields
bryan: I'd like to see a proposal
... individual fields are important
... not sure I trust ability to parse text fields reliably
... just wow. We need to review the things one by one
spoussa: about find, have a question. what is the spec status, should we address this now...
<darobin> [so quickly, off the top of my head, getting a contact from Intents would look like: navigator.startActivity(new Intent("pick", "text/vcard"))]
<fjh> we need to remember minimization in any change we make
<fluffy> Might be interesting to people …. vCard 4 spec is at http://tools.ietf.org/html/rfc6350 and XML representation of vCards are defined in http://tools.ietf.org/html/rfc6351
<darobin> [where "pick" is a generic action that would work for pick people, or dates, or files, or whatever can be shown as a list from which something is selected]
spoussa: based upon find, it defines the set you want, and the search filter is applied to that
<darobin> [and where "text/vcard" is a string that I made up that states the kind of stuff that one wants to pick]
Josh_Soref: user's can do anything with the number of fields that are in the spec
... have a proposal that might be sent...
spoussa: PhoneGap's implementation of this has gotten complaints of being broken
Josh_Soref: when you are searching, you want to find something that looks like something else. The user can fix the find filter when something unexpected is displayed.
... would like re different types of sections, display the whole card and allow to select the section that is to be returned.
... mostly the need to specify search fields goes away
dom: the current API gives the fields the app is interested in, and the user can choose
spoussa: the summary is something needs to be done for the find
[ Break until 3:35pm ]
<Josh_Soref> ACTION: spoussa to ask Phonegap users to send feedback on find() [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action27]
<trackbot> Created ACTION-485 - Ask Phonegap users to send feedback on find() [on Sakari Poussa - due 2011-11-11].
Josh_Soref: I will send some UI comments/ideas to the list when I have something I can share
dom: TPAC next year, Lyon, FR, dates announced?
<dom> next TPAC will be Oct29-Nov 2
<dom> in Lyon, France
fjh: we have a lot of European members
... March would be ...
<darobin> http://www.w3.org/mid/4E67BCFD.8070804@w3.org -> TPAC 2012 announcement
darobin: dates last year...
dom: Last year was Mar 15
fjh: where are we doing this?
... who could host?
dom: we tend to have between 30 and 40 participants at F2F
fjh: Seoul was 15
darobin: at lot of people canceled because of Fukushima
fluffy: IETF is Mar 25-30 in Paris
fjh: Not the week after (Easter and stuff)
jcdufourd: We could handle 40 easily unless it's during exams
darobin: we generally have one @ TPAC, and two intermediate
... since we're meeting in US now, and will meet in France
... it would be good to have one of these meetings in Asia
... I don't know if any of our Asian members would be interested in hosting
[ LG could host in Seoul ]
[ Huawei could host in China ]
[ probably in Shenzhen ]
[ Opera, possibly Oslo ]
darobin: preferably not March
dom: Next F2F roughly in March, seem reasonable?
... not the last week in March / avoid IETF meeting
fjh: June/July ?
<Josh_Soref> ACTION: dom to do a WBS for the next F2F for mid March [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action28]
<trackbot> Created ACTION-484 - Do a WBS for the next F2F for mid March [on Dominique Hazaël-Massieux - due 2011-11-11].
dom: to host a F2F, we need:
... seats, tables,
... no NDAs
... WiFi
... Breaks
darobin: there's a strict rule: we can't hold a meeting if we're required to sign a Strict NDA at a meeting
dom: There's a Web Testing IG
... and Browser Testing and Tools Working Group
<fjh> http://www.w3.org/2011/08/browser-testing-charter.html
<fjh> Testing interest group
<fjh> http://www.w3.org/2011/05/testing-ig-charter.html
AnssiK: I think the Mozilla Web API will arrange for testing for Battery
dom: there's a question about how to test battery for Hardware
AnssiK: they're looking at Qemu for Android
dom: Hardware testing is out of scope, right?
AnssiK: yes
<dom> ACTION: Dom to build test cases for battery [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action29]
<trackbot> Created ACTION-486 - Build test cases for battery [on Dominique Hazaël-Massieux - due 2011-11-11].
lgombos: testing, the problem is similar to GeoLocation
dom: I think what they've done is integrate positions into the tests
<AnssiK> testing hardware interaction on Mozilla dev-webapi: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/dae263e27197f9a0#
dom: like "tell the position provider to say you're @X moving to Y"
... Testing IG is building a Generic Framework that most of WGs are expected to use
darobin: there's a harness and a bunch of other things
<darobin> http://www.w3.org/2009/dap/track/issues/open -> DAP Issues
ISSUE-81?
<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no TZ information; using strings is less than ideal; do we have to create a Web Dates specification? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/81
ISSUE-81?
<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no TZ information; using strings is less than ideal; do we have to create a Web Dates specification? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/81
ISSUE-87?
<trackbot> ISSUE-87 -- Degree of ruleset transmission with API calls, how often, which -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/87
darobin: 81 is still pending
Josh_Soref: do we want to stop doing rulesets?
fjh: I'll leave it open
ISSUE-89?
<trackbot> ISSUE-89 -- Clarify how rulesets interact with pre-existing relationships -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/89
fjh: let's close them, we can reopen them if we change our minds
close ISSUE-87
<trackbot> ISSUE-87 Degree of ruleset transmission with API calls, how often, which closed
close ISSUE-88
<trackbot> ISSUE-88 User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc closed
ISSUE-87: group isn't pursuing this at this time
<trackbot> ISSUE-87 Degree of ruleset transmission with API calls, how often, which notes added
close ISSUE-87
<trackbot> ISSUE-87 Degree of ruleset transmission with API calls, how often, which closed
ISSUE-88: group isn't pursuing this at this time
<trackbot> ISSUE-88 User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc notes added
close ISSUE-88
<trackbot> ISSUE-88 User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc closed
ISSUE-89: group isn't pursuing this at this time
<trackbot> ISSUE-89 Clarify how rulesets interact with pre-existing relationships notes added
close ISSUE-89
<trackbot> ISSUE-89 Clarify how rulesets interact with pre-existing relationships closed
ISSUE-89: group isn't pursuing this at this time
<trackbot> ISSUE-89 Clarify how rulesets interact with pre-existing relationships notes added
ISSUE-95: group isn't pursuing this at this time
<trackbot> ISSUE-95 Different regulatory environments and relationship to privacy and rulesets notes added
close ISSUE-95
<trackbot> ISSUE-95 Different regulatory environments and relationship to privacy and rulesets closed
ISSUE-105?
<trackbot> ISSUE-105 -- Should the capture hint in HTML Media Capture be specified through a MIME parameter? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/105
ISSUE-105: waiting for implementers
<trackbot> ISSUE-105 Should the capture hint in HTML Media Capture be specified through a MIME parameter? notes added
ISSUE-109?
<trackbot> ISSUE-109 -- We need solid use cases for Feat Perms if it's going to fly -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/109
ISSUE-113: we resolved this by changing the design
<trackbot> ISSUE-113 AddEventListener in Battery Status has side effects notes added
ISSUE-114: we resolved this by changing the design
<trackbot> ISSUE-114 Battery spec should note relative ordering of battery low versus battery critical in terms of criticality notes added
ISSUE-115: we resolved this by changing the design
<trackbot> ISSUE-115 Do you get the batterylow event when you're charging and cross that boundary? notes added
close ISSUE-113
<trackbot> ISSUE-113 AddEventListener in Battery Status has side effects closed
close ISSUE-114
<trackbot> ISSUE-114 Battery spec should note relative ordering of battery low versus battery critical in terms of criticality closed
close ISSUE-115
<trackbot> ISSUE-115 Do you get the batterylow event when you're charging and cross that boundary? closed
darobin: the other issues are still relevant
ACTION-315?
<trackbot> ACTION-315 -- Dominique Hazaël-Massieux to look into pop-up windows in Permissions draft -- due 2011-05-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/315
<dom> [context of permissions for pop-up is http://lists.w3.org/Archives/Public/public-device-apis/2010Dec/att-0039/minutes-2010-12-15.html#item03 ]
close ACTION-340
<trackbot> ACTION-340 Look at how we're doing privacy by design closed
close ACTION-359
<trackbot> ACTION-359 Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo closed
Josh_Soref: oops, ACTION-360 has an ACTION-444 for me to follow up
<darobin> ACTION: Robin to issue a CfC to shelve SysInfo [recorded in http://www.w3.org/2011/11/03-dap-minutes.html#action30]
<trackbot> Created ACTION-487 - Issue a CfC to shelve SysInfo [on Robin Berjon - due 2011-11-11].
ACTION-364: characterization of the open web
close ACTION-364
<trackbot> ACTION-364 Get the COW started notes added
<trackbot> ACTION-364 Get the COW started closed
close ACTION-368
<trackbot> ACTION-368 Collect and summarize current use cases for Gallery API and includes a draft doc closed
close ACTION-370
<trackbot> ACTION-370 Dive more deeply into Web Intents/Web Activities in view of integration closed
ACTION-374: group isn't pursuing this at this time
<trackbot> ACTION-374 Complete Privacy Rulesets with binding considerations notes added
close ACTION-374
<trackbot> ACTION-374 Complete Privacy Rulesets with binding considerations closed
close ACTION-413
<trackbot> ACTION-413 Contact Claudio Caldato from MS and discuss media capture closed
ACTION-413: Travis has an action to come back with UCs
<trackbot> ACTION-413 Contact Claudio Caldato from MS and discuss media capture notes added
AnssiK: can we close http://www.w3.org/2009/dap/track/actions/414 given that Microsoft is now looking at Media Capture?
close ACTION-414
<trackbot> ACTION-414 Write up an overview of the media capture landscape, with ideas of how to move forward closed
ACTION-414: AnssiK is happy to close since MS has interest
<trackbot> ACTION-414 Write up an overview of the media capture landscape, with ideas of how to move forward notes added
close ACTION-423
<trackbot> ACTION-423 Draft the use cases and requirements section for Battery closed
ACTION-423: we have UCs
<trackbot> ACTION-423 Draft the use cases and requirements section for Battery notes added
ACTION-424: might want to apply to Intents UCs
<trackbot> ACTION-424 Draft the use cases and requirements for Messaging, perhaps even take over Messaging editing notes added
ACTION-425: We expect input from adrianba, sicking, Josh_Soref
<trackbot> ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section notes added
close ACTION-426
<trackbot> ACTION-426 Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical closed
ACTION-425: see ACTION-475 ACTION-476 ACTION-474
<trackbot> ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section notes added
ACTION-426: drafted, but change dthe design
<trackbot> ACTION-426 Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical notes added
close ACTION-428
<trackbot> ACTION-428 Make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side closed
ACTION-428: Neither group was interested in alignment
<trackbot> ACTION-428 Make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side notes added
close ACTION-431
<trackbot> ACTION-431 Review Messaging for publication closed
ACTION-431: that was done
<trackbot> ACTION-431 Review Messaging for publication notes added
close ACTION-433
<trackbot> ACTION-433 Reply to Anne about his Permissions questions closed
ACTION-433: lgombos: I spoke to anne and there's a new action from today
<trackbot> ACTION-433 Reply to Anne about his Permissions questions notes added
close ACTION-434
<trackbot> ACTION-434 Investigate if DAP could use the XPointer registration code for feature registration closed
close ACTION-450
<trackbot> ACTION-450 Get his CVS working; or migrate specs he might patch to Mercurial closed
close ACTION-452
<trackbot> ACTION-452 Work with Josh on a proposal for Contacts names closed
ACTION-450: Contacts was migrated to Mercurial
<trackbot> ACTION-450 Get his CVS working; or migrate specs he might patch to Mercurial notes added
close ACTION-455
<trackbot> ACTION-455 Reply to ArtB about Web Intents closed
ACTION-452: this was done
<trackbot> ACTION-452 Work with Josh on a proposal for Contacts names notes added
close ACTION-460
<trackbot> ACTION-460 Send cfc for FPWD for vibration closed
close ACTION-456
<trackbot> ACTION-456 Write to the list to explain UA mediation in selecting sensors closed
ACTION-456: this can probably be resolved by Intents, but I can explain this to the list
<trackbot> ACTION-456 Write to the list to explain UA mediation in selecting sensors notes added
darobin: do your action items
fjh: no meeting next week
darobin: we already cancel the week after a F2F
[ heads up, clocks are changing in the US this Sunday early morning, in case you're still here then ]
darobin: please spend some time looking at Intents
... thanks to the editors and people who provide feedback
... and to scribes
[ Applause ]
darobin: Please pay attention to the announcements about the creation of new mailing lists
... because things will be moving to them shortly
... thanks for coming
... see you on the phone
... see you in March in person
[ Applause ]
