DAP F2F Day 2 -- 21 Mar 2012

<bryan> ping

<scribe> Scribe: Josh_Soref

Media Capture

<darobin> http://dev.w3.org/2011/webrtc/editor/getusermedia.html

<darobin> http://www.w3.org/TR/capture-scenarios/

<darobin> http://www.w3.org/TR/html-media-capture/

<fjh> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html

<fjh> we will start with taking a look at MediaStream Capture Scenarios

<fjh> then getusermedia, then html media capture

[ Bryan projects the MediaStream Capture Scenarios ]

Darobin: Scenario 1 is photo upload

Bryan: I reviewed this document, and it's pretty good
... If we focus on the specific capabilities described in this document

<SungOk_You> I'm in the bridge, but I can't hear anything.

Bryan: I think we can go forward pretty quickly

<SungOk_You> Deepanshu, Could you open the bridge?

Fjh: this document is for the joint WebRTC. + DAP Task Force
... The "Media Capture TF"
... WebRTC is working on streaming
... This document was initially created to focus on DAP scenarios

Bryan: The design section (#5)
... We'll need to make some decisions
... Some of the items cover dependencies to HTML5

Darobin: Using the issues in the document to drive discussion seems to be the way to go

Bryan: there are levels of access that are granted
... Initially you can't see anything

Richt: there's a proposal from Voxeo
... For capabilities
... Which is going to make fingerprinting too easy

<Wonsuk> Capabilities API proposal: http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0041.html

<fjh> fjh: there appears to be a concern of fingerprinting related to the capability document being discussed in the task force

<fjh> fjh: this is a concern

Darobin: we have serious concerns about the capabilities document and its implications on privacy

<bryan_sullivan> Device selection and capabilities discovery/setting are privacy-sensitive functions - as long as the user is in control of the initial access permission, I think those concerns are mitigated.

<fjh> fjh: what is the source of requirements for the capabilities API and document

<fjh> darobin: capabilities API should not be exposed to untrusted sources

Darobin: so the WebRTC starting point is where DAP was two years ago?

Josh_Soref: yes

Richt: it's best to start from nothing and expose as little as possible, slowly adding

<fjh> discussing 5.1.2 Issues related to privacy

Bryan: it's better to have the UA ask the user if it wants to expose cameras
... And once you do, then you can provide some information

<fjh> issue: capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk

<trackbot> Created ISSUE-125 - Capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk ; please complete additional details at http://www.w3.org/2009/dap/track/issues/125/edit .

Bryan: If we recommend that there's a step by step process

Richt: I think that's a given
... We have a build that has this, it's in Opera Mobile 12
... And in a labs desktop build
... The UI problem is understood by all browser vendors
... It's a hard problem

<richt> fyi: http://dev.opera.com/articles/view/getusermedia-access-camera-privacy-ui/

Bryan: I read the API and scenarios document at the same time
... And thought about how we discussed pickers

Fjh: let's look at the conference call scenario

[ fjh reads section 2.5 ]

Fjh: it's talking about automatically selecting video based on who's speaking

Josh_Soref: this is quite doable, Zakim can already tell us who's making noise
... Selecting the video is a logical extension

Fjh: she (scribe) does what Josh does, pausing / rewinding
... It would be interesting to analyze this from a privacy perspective
... This document attempts to outline the capabilities needed to implement this

<bryan_sullivan> Most of this is app-specific and has no impact on the API AFAICT.

Fjh: There's a whole bunch of stuff in this use case

Bryan: obviously when she receives the streams, she could save / record / etc.

Fjh: Harold sent an email to the list explaining that Streaming isn't so simple
... The capabilities document is not this document, but it isn't publicised outside the TF

[ Preview ]

Bryan: I just reviewed the documents
... I haven't sent comments yet

<fjh> Thanks to the task force and Travis for a great job with the scenarios document

<fjh> the DAP WG should review and comment on the issues, preferably on the task force mailing list

[ Pre-Processing ]

Richt: I have a demo
... This issue quick demo
... Nothing normative

[ getUserMedia ]

Richt: all browsers are experimenting with UIs

<bryan_sullivan> I have some comments I will send to the list. Overall I think the document is a useful overview of the capabilities/issues and if we focus on key capabilities the API can be very useful, without being initially too complex.

Richt: Mozilla demonstrated their UI, and it was very similar to our's

<fjh> "hair check" - show still from camera in ok dialog, so you can decide on permission including this information in the decision

<Wonsuk> Webcam Toy demo: http://neave.com/webcam/html5/

Richt: Although they included a "hair check" - a preview to see if your hair is out if place

<bryan_sullivan> e.g. re Pre-processing (monitoring of the input signal for various purposes, e.g. audio end-pointing, volume leveling/AGC, face/gesture recognition) - this is key to many of the use cases and usability of apps. Initially it should include boolean options (capture auto-start/pause and AGC).

Richt: The first visit to the page requests permission
... And we're making permissions persistent
... Per domain

<bryan_sullivan> input level events (e.g. threshold passing) or some realtime-updated attribute (input signal level) are very useful as well but perhaps advanced capabilities that can be deferred.

Richt: We're looking into domains that have user generated content

[ demo of live post-processing ]

Darobin: capturing a video from canvas will give you camera quality from 5 years ago
... You want to use canvas as a view-finder
... And capture from the underlying stream
... We need something similar for audio
... There are two APIs proposals

<fjh> shows capture of video frame and post--processing on canvas, also ability to capture as photo

<fjh> richt: face recognition demo - recognize specific face and add mustache automatically

<dsr> I was thinking about platform support to find faces and extract video for them for use in conferencing apps.

<gbillock> * 9-something

<fjh> bryan and rich note that simple api appropriate, as javascript and current standards can be used for this work, hardware should evolve to enable faster javascript processing for face recognition, robin notes certain opencl hardware should enable better performance as well

Darobin: The first visit to the page requests permission
... And we're making permissions persistent
... capturing a video from canvas will give you camera quality from 5 years ago
... You want to use canvas as a view-finder
... And capture from the underlying stream
... We need something similar for audio
... There are two apiece proposals

Dsr: for the conferencing case

<bryan_sullivan> Apps may need to know and set the image capture options, so the section on Capture method selection is important (e.g. determining if the camera/device can capture RAW format for HDR postprocessing, or only JPEG), and to set the options via MediaStreamOptions)

Dsr: Facial recognition?
... Can you do that?

Richt: we have a demo of putting a mustache on people

Darobin: Mozilla had a demo, they cheated by looking at shirt color
... would you have been helped by Simd or OpenCL?

[ Scribe was disconnected ]

<bryan_sullivan> The options described in "Format detection" are important to reach consensus on, to support that capability-awareness for apps.

WoPhone OS

[ Jing_Wu presents WoPhone OS - China Unicom ]

Jing_Wu: questions?

Richt: how do you run your Web applications?
... Are web applications trusted?
... Do you install with trust?

Jing_Wu: I think we're going with the installed model

<darobin> http://www.w3.org/community/coremob/

Darobin: The Core Mobile Platform CG is looking into which APIs should be supported first

<fjh> fjh: thanks for presentation on WoPhone; questions regarding status of DAP specs should be discussed as part of the DAP F2F agenda, so that should help

<fjh> fjh: if you have any remaining questions please ask tomorrow during the F2F

Darobin: We have data on the most commonly installed applications for most platforms
... We're going to define a level 0 and a level 1
... thanks

<darobin> RB: in the CoreMob CG we will have level 0 which gives us a large majority of the most popular applications, and level 1 which gives us all of them

<darobin> ... you are all encouraged to join

WebIntents Demonstration

[ Class presenting ]

<darobin> c/Claes/Claes/

<darobin> s!c/Class/Claes/!!

Claes: the client page sends postMessage commands
... And the service uses UPnP to talk to the light

<Daniel-Samsung> question: ack messages from the light ? answer is yes

Richt: is the message from the client a well known format?

Claes: it's speaking JSON and the service converts that to UPnP
... Abstracting away the UPnP
... So you could speak to some non-UPnP thing

Richt: Could I use this to talk to my TV?

Claes: yes

Cathy: can you do UPnP eventing?

Claes: yes

Bryan: so do you have some native code?

Claes: yes

Bryan: can you do it in pure javascript?

Claes: no

Richt: it looks like this needs standardization
... And integration with the Intents specification
... We need a way to reach an address

<darobin> http://people.opera.com/richt/release/specs/discovery/Overview.html -> Opera's Discovery Proposal

Richt: And then you could speak to it directly

Bryan: could you do this with an internal web server?

Claes: of course, but we consider this more efficient

Dsr: a generic mechanism allows access to Bluetooth, Zigbee, UPnP /ZeroConf

Richt: why not allow low level access?

Dsr: do you want access to packet sniffing?

Richt: of course not

Josh_Soref: we decided yesterday that there would be a WebIntents compendium for UPnP
... We could have similar for Bluetooth and others

Dsr: which forum for follow up?

Richt: WebIntents

Unknown

Won_Suk: tomorrow we'll talk about Tizen web API

HTML Media Capture

Fjh: can we talk about html media capture?

<Deepanshu> hints??

Darobin: Mozilla has implemented their own thing

<fjh> dsr noted earlier that restricted API for multicast might be useful APIs

<fjh> s/medi /media /

Darobin: We noted that whomever implements first gets to pick names

<darobin> ACTION: Robin to kill Media Capture API [recorded in http://www.w3.org/2012/03/21-dap-minutes.html#action01]

<trackbot> Created ACTION-517 - Kill Media Capture API [on Robin Berjon - due 2012-03-28].

Device orientation feedback to Geolocation.w3.org WG

[ Bryan presents dzung tran's email ]

<bryan> Re Sensor API feedback to GeoLoc (http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0097.html)

<bryan> We need ability to integrate events from sensors to prevent event overload and processing overhead of doing this in Javascript.

<bryan> Some simple type of controls would be IMO essential for an effective sensor API.

Fjh: part of this thread was impact on battery life and whether sensor is on it
... But this seems implementation dependent

Bryan: for the part we give to the geolocation WG
... What's missing

<Zakim> Josh_Soref, you wanted to ask about QoI

Bryan: If an implementer is firing events into the application, isn't that more expensive than filtering earlier

<fjh> josh_soref: yes, want browers to filter earlier, but more work, simpler to pass what is from OS

<fjh> josh_soref: react to feeback as approach is often taken

<fjh> josh_soref: app asks for something, implemented, then discover getting too much information then ask for simpler API

<fjh> ... analogy to drown then ask for less, so point is to start with less in API, not more

<fjh> ... don't micromanage a firehose

Richt: the android system lets you manage flow by application class
... Is sensors a wolf in sheep's clothing?

Darobin: and are we losing sense of security

<richt> The Sensors API is simply a rebranding of Systems Information API without addressing the problems of that approach.

Fjh: there was a request for generic API

<richt> i.e. losing focus on use cases for the individual sensors.

<fjh> that enabled extension to new as yet unidentified sensors

Fjh: So you have an api for when you don't know how it will be used

<fjh> does understanding threat model depends on specifics or can it be generic to sensors

Darobin: we should have a collection box for when people ask for a generic

Bryan: on the one hand, postMessage is generic
... But we don't like sensors as generic

Darobin: there's a difference between geolocation and temperature

Claes: discovering sensors using technology Intents, model makes sense to me

Bryan: you'll have middle ware on the device
... Which will be used
... If we don't facilitate sensor access
... I'm good with not rehashing old ground

<fjh> josh_soref: look how we simplified network info, likely to need to simplify sensors as well

<fjh> bryan: agree, need prototyping

<fjh> richt: need to see implementations

Richt: Josh_Soref is right, we need to shred apis and rebuild to address use cases instead of apis requests
... We accept documents to CVS
... It's really hard to get rid of them

Darobin: the point Josh_Soref made about network information
... Is that we aren't reviewing things
... When we do, the output is better, but doesn't look like the initial input

<darobin> ACTION: Frederick to send a CfC about changing the design of Sensors [recorded in http://www.w3.org/2012/03/21-dap-minutes.html#action02]

<trackbot> Created ACTION-518 - Send a CfC about changing the design of Sensors [on Frederick Hirsch - due 2012-03-28].

Fjh: we need a CfC to obtain agreement to discontinue work on current Sensor API spec as-is, review different cases, refactoring use of webintents etc

Richt: should something based on discovery be suggested?

Claes: yes, maybe based on Intents

Bryan: once you get it, how do you talk to

<richt> you treat a generic sensor as a service.

<dsr> Josh: my hope is that we deal with this via intents.

<bryan_sullivan> I can agree in principle that to progress work on sensors that if the only way is to work on individual specs, we should do that at least.

<fjh> we do not want WG members to devote resources on work that might no progress or be implemented as is

<dsr> Josh: for example a get temperature intent, and each individual sensor ends up with its own intent.

<bryan_sullivan> I would recommend though that if we have consensus on the usefulness of discovering what sensors are accessible (e.g. via Web Intents), then that work should also proceed. Accessing the specific sensors then could be individual spec work.

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html - example B

<dsr> Bryan: for each sensor, how would you implement it as a service, as a XHR, or what?

<richt> ^-- Josh's example for exposing temperature sensor via Intents.

<dsr> scribenick: dsr

dsr: it depends, you could use XHR, websockets, or whatever is appropriate.

Josh talks through an email with thermometer as an example of a web intent.

This is an email from 21 Nov 2011.

<darobin> close ACTION-517

<trackbot> ACTION-517 Kill Media Capture API closed

This can be realized with a real sensor, or with a service exposed by a website.

<darobin> close ACTION-297

<trackbot> ACTION-297 Draft up TZDate closed

Oliver: using web intents could result in exposing users to choices which aren't really important to them.

Bryan: if we can use a consistent model for web intents for sensors, that would be fine.

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/author.html

Josh: I sent off 5 parts via email to introduce the concepts involved in web intents.

<darobin> close ACTION-397

<trackbot> ACTION-397 Coordinate with HTML WG chairs about Capture, include the HCG closed

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html

<darobin> close ACTION-425

<trackbot> ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section closed

<darobin> close ACTION-479

<trackbot> ACTION-479 Take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account closed

<darobin> close ACTION-492

<trackbot> ACTION-492 Prod DavidA and Shane about feedback on Activities/Intents closed

Some suggestions for likely common intents, e.g. save, send, print, share, call, chat. Some of these are similar.

<darobin> close ACTION-509

<trackbot> ACTION-509 Prepare gUM scenarios for publication closed

I can end up printing to a file, where the result is like a share.

Josh talks about the sensor examples, e.g. get temperature, get orientation.

We will need multiple deliverables, including a best practices note.

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0012.html

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html

web apps shouldn't know how/where the data was obtained.

We need a way for persistent user defined names.

Josh uses the term "hub" for assemblies of devices/services, e.g. a thermometer which knows where it is.

Users should be able to change the provider of a service without the application becoming aware of the change.

richt: RPC doesn't lend itself to hot swapping.

josh: consider example of a keyboard, the app only needs the key stroke stream.

swapping keyboards between keystrokes shouldn't effect the app.

the user agent may register services as it finds them in the background, but apps only become aware when requesting a particular intent.

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0039.html

<richt> http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0038.html

Bryan: user invoked discovery example: I am in a hotel and walk up to a device.
... I may not have permission to use local discovery protocols directly, but instead could have access to a proxy discovery service.

Josh: user agents may record devices it sees advertisements broadcast over the networks it is connected to.

Josh attempts to open the Mac printing dialog to see if it shows any discovered printers visible via bonjour (zeroconf)

<fjh> ACTION-518: http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0136.html

<trackbot> ACTION-518 Send a CfC about changing the design of Sensors notes added

<fjh> ACTION-518 closed

<trackbot> ACTION-518 Send a CfC about changing the design of Sensors closed

Josh: inspectors would be useful for developers working with intents.

richt: I love the idea of transparency, and think logging is really nice!

Josh: unaffiliated reputation providers would be valuable for services involving confidential data.

print dialogs are a example of a design pattern that we should aim for with web intents.

especially with the means to print to PDF as an alternative to printing to actual media.

Greg: there are some sensors that don't fit the request/response pattern. Proximity is an example.

Robin: yes, proximity provides an event stream.

Oliver: still concerned with location example, where there are multiple location providers.

Josh talks about filters that indicate the location precision.

Greg: there are application specific prompts for location.

When people install a particular location provider, they can learn about the precision etc. at that time.

Oliver: that won't work for automatically registered providers.

Josh: I much prefer providers to offer a UI describing their service, e.g. a map with a circle indicating the precision for a location provider.

greg: showing a map can be helpful when the location is actually wrong!

<darobin> ScribeNick: richt

Web Intents - Part 2

james: Scalable extras for future use cases.
... may relate to Versioning.

<darobin> http://www.w3.org/wiki/WebIntents/ContactsAPI

gregb: Like the idea of object literals that can be overloaded.

james: if you have separate extras in the future then you will have a different name.
... For the API itself when we need to make a change we add a version number to it.

darobin: we don't. we just add methods and properties.

james: let's look at permissions.

Josh_Soref: the fact that I trust foo.com for certain tasks it may not apply for others.
... fine to remember things I come across as I browse but I still want the choice when I actually need something.

james: Sounds like an addition to the registration API for 'Learn more...' about this service.

Josh_Soref: Yes. Would also be good if it also records when and where I discovered the service initially.

james: not opposed to 'Learn more'. It would be optional. It does add another attribute for registration but seems reasonable.
... "How do we give persistent permissions for the same action type on one page." (from sticky board in room)

Josh_Soref: Assuming I'm on a website that is operating a weather station. requires monitor temperature and get location.
... I want to be able to go to the site and have these things just work together so I can get to the information quicker.

james: two things. the first is remembering the preferences. the second is not requiring a user initiated action.

Josh_Soref: Looking for a way to make the whole process automated somehow.
... an easier case, we'd like to use intents to provide geolocation.

james: with geolocation there are obviously privacy concerns but in general I like the idea.
... are we thinking this requires changing to the API?

gregb: might require a change to the semantics of the user gesture we have right now.
... Letting intents trigger without a user gesture is something we don't know how to do yet.
... Maybe if you get a verification page that could work instead of something up front but we would need to think about it more.

james: we should take an action to define an error that says "This was not user initiated".
... "how much UX is required for service registration?" (from sticky board in room)
... josh, you suggest "none".

Josh_Soref: right

<qiang> qiang will have joined #dap

Josh_Soref: I have some ideas on this. The more you use something then these should appear in the services list with others hidden behind.
... so there are some heuristics to use here for service listing: when, where I discovered it, how often I've used it, when I last used it.

<dsr> how popular a service is, whether my friends use it etc.

<darobin> I've listed the Use Cases at http://www.w3.org/wiki/WebIntents/ExtraUseCases

<darobin> now we need people to fill them out :)

record action for james to specify the no info bar recommendation idea.

can't directly assign an action to james as he's not in the tracker system

james: "Should the user be able to restrict web intents to a list of well-known action types" (from sticky board in room)
... It's up to the user to choose what they're doing. We will have strings for the top actions. Might just confuse the user to give them an understanding of what the actions are.
... may also have some localization issues.

Josh_Soref: On localization, it may problematic if we get verbs registered in e.g. Chinese.

james: that's fine. that would probably be useful in a localized context.
... ...for localized actions.

gregb: we have been suggesting the action strings be URLs.
... so it's just URL.

james: Someitmes this might make sense for non-English communities or actions that relate to a specific locale.

darobin: Generally we need a best practise not to mint new actions where existing actions already exist.

<darobin> "A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources." (from http://www.w3.org/TR/webarch/#URI-scheme)

james: right, darobin. that makes sense.

OliverD: This may not be an issue but the risk might be for a service to register hundreds of actions.

james: it could be an issue. a page registers for every intent action imaginable. we need to manage those cases.
... e.g. through social recommendations, feedback, reviews.
... off on a tangent. how far can we spread knowledge of sites. It's really about reputation.
... we might be heading towards needing this reputation to be queryable.
... back to the question at hand: "Should the user be able to restrict web intents to a list of well-known action types?"
... maybe it's not about the action but the services themselves?

bryan_sullivan: I may want to turn off a whole action.
... there should be a way to disable certain types of actions you don't want to usee. maybe I want to disable 'share'.

james: Isn't that a blacklist?

bryan_sullivan: I want to disable a certian action. The opposite might be true. Disable all and enable some.

Josh_Soref: So if there's an annoying client I want to block them without them knowing about it.

james: I'm not opposed to adding intent identifiers to elements.
... but this is getting a little complicated.
... we could compromise that this only works on clickable things. onclick.

fjh: what's the objective here?

james: if the user can disable a certain action and nothing happens then the page is going to know it.

fjh: why can't we have a default action. let's take 'pay'. could I choose something that doesn't actually do anything i.e. a deadend stub?
... that is the default action that then doesn't actually do anything meaningful (in these items for tomorrow case 'pay' for something).

james: we can't say anything on white/black-listing unless we have a solution for this question.

Josh_Soref: If a site wants to do something and the user doesn't want to do it then the site is being annoying.
... but there may be parts of the page that are useful.

<fjh> choice not to visit site or to leave, choice not to pick

james: we have a picker so you have another layer of choice. If you don't want to pay you don't choose a service and click a button. The choice remains with the user to actually trigger the default action.
... so the answer to the question is "no, because the user still has choice to trigger the service to fulfill the action".

^-- FYI: the question was "Should the user be able to restrict web intents to a list of well-known action types?"

s/to trigger the service/to trigger any service/

james: let's take a look at 'Privacy' issues.
... "Informed consent usable for Privacy" (from sticky note on board)

fjh: Essentially the user needs to know what they're doing and why. So we need to be careful that there is enough information about what's going on so users get it.

s/about what's going on so users get it./about what's going on when invoking an intent/service so users understand it./

gregb: not trivial to get a user gesture e.g. pop-unders.

fjh: we should put a note in the spec around user gesture requirements.

Josh_Soref: Even though we want fast-paths to action completion we don't want to make it trivial if I'm browsing a web site for the first time.

james: the UI won't necessarily be in the location where you initially tapped to invoke the picker.

Josh_Soref: I don't think that is sufficient but I'll comment more later.

<fjh> s/around user gesture requirements/around user gesture requirements and providing necessary context for decisions and permissions/

james: "How will web intents work with Private Browsing - Registration phase"
... simple answer. no intents registration in private browsing mode.

Josh_Soref: I'd propose that we register in the context of the private browsing session but that's lost when leaving the private browsing session.

james: ok. works for me.

darobin: same principle for e.g. cookies

james: second part: "How will web intents work with Private Browsing - Invocation phase"
... actions are still available.

darobin: we could leak information via these action invocations.
... we could add a note to the spec "The user agent should ... in private mode."

<darobin> s/The user agent should ... in private mode/Implementers should take issues relating to private browsing into consideration when invoking intents so as to avoid identifying information leaking./

james: next up "How should explicit intents work with private browsing"

darobin: same as normal.

james: "Should the UA warn when the intent action is rare"

Josh_Soref: A UA should consider doing that.

gregb: If you haven't seen it before you get a 'speed bump'.

bryan_sullivan: we could be hampering extensibility if we keep putting in road blocks.

james: I agree.

fjh: I say we keep it simple rather than introduce obstacles.

james: "What can we hide from providers". What is too much to give to providers?

Josh_Soref: In my outline I suggested that there should be some transparency/inspectors of data travelling to/from service providers.

james: giving a pseudo-sandbox to providers?

Josh_Soref: potentially.
... For example I don't want a site to know which provider I'm using.
... and vice versa.

darobin: we can limit the information transmitted e.g. no referer header.

gregb: the referer for instantiating a service should be the intent action.

<fjh> +1 to no sharing referer header to provider, to avoid information leakage, a privacy concern

darobin: agree

james: agree

Josh_Soref: agree

<fjh> +1 to sharing intent action as referer

Josh_Soref: all above agreeing with gregb's proposal.
... can we ensure people can't introduce line feeds in to an action?

gregb: good point. it must be properly escaped.

james: we'll make a note to explicitly address this point.
... "Inline disposition". General discussion. Should we do it?

fjh: generally yes.

Josh_Soref: Who requests the inline disposition - sites?

james: yes
... given form factor considerations you may not have inline dispositions. e.g. mobile phones.

<fjh> s/generally yes./inline disposition has a reason for being specd, it offers a provider the means to offer a usable page/

james: so you can request it but shouldn't be concerned if you don't get it. It's a preference only - a hint for the UA.
... the default is 'window' disposition.
... that's "I want a new context".
... we're more flexible on inline disposition

Josh_Soref: Is the intents dialog modal?

james: tab modal. z-indexed on top. you can still interact with the tab content.

gregb: when we think about mandating inline, when service providers are going to support intents, they're going to se inline disposition most of the time. The user experience will be consistent when a user e.g. visits their bank site.

Josh_Soref: If certain providers do and others don't then we get different experiences.

Claes: We see use cases for inline disposition from our experimentation with web intents to date.
... It is easy to spoof but still would hope for more options - inline in picker, hidden(?). using ssl for all services.

s/using ssl for all services./using ssl for all services may be necessary./

scribe: we should do a security review and assess this last point.

<Zakim> darobin, you wanted to ask about inlined using iframe or something like that?

darobin: wonder if we can assign things directly to an iframe.

Josh_Soref: still potential for click-jacking against any embedded content.

gregb: any anti-clickjacking mechanism could not be applied to that page.

james: how do you close an embedded service?

Josh_Soref: not easily.

james: concern would be on the security aspects of course.

<darobin> [I wonder if we could have always-on-top iframes to help with clickjacking issues]

james: not sure if we should even leave allowing inline disposition up to implementors.

Josh_Soref: we may want a MUST NOT in the spec around these points.

s/a MUST NOT/a MUST NOT statement/

Josh_Soref: Instead of offering embedded we're kind of offering hidden instead.

james: we started with this in the spec.
... we decided against it due to UX issues. We can't preclude it since we have use cases for this mode.
... so we took it out for a.) UX issues b.) the assumption you should be able to display *something* to the user.

s/ use cases for this mode./ use cases for hidden mode./

s/so we took it out/we took it out/

Action for Claes to add a proposal for hidden disposition.

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

Action Claes to add a proposal for hidden disposition.

<trackbot> Created ACTION-519 - Add a proposal for hidden disposition. [on Claes Nilsson - due 2012-03-28].

james: "Will clients want UA provided UI for intents?"
... my feeling on this is no.
... seems a bit much.

Josh_Soref: Let's push this in to the future work category.

james: right.
... probably belongs in HTML5.
... "Saving pipelines". We talked about this yesterday.

Josh_Soref: asuming 'share' and 'save' have the same action url.

s/asuming/assuming/

james: "Accessibility".
... A lot of work happening on this topic in other groups at W3C.
... it's a work in progress.

fjh: let's take a 15 minutes break.

<break>

<bryan> scribenick: bryan

fjh: 1st question - why would something be hidden, don't we want the user to be in control? 2nd question: why would apps lie about the purpose of an intent?

james: issue - how can the verb space be managed for interoperability
... the lying issue was about pages misbehaving, we should not have to worry about that

fjh: on hiding the actions, this limits the user choice

james: if there is no need to display a UI, we don;t have to force the page to provide a UI

josh: the picker is always displayed

fjh: ok, understand

james: issue - what can we learn from previous groups

fjh: will take an action to look at WS* to see what might be relevant

james: issue - android intent holes to avoid
... will take an action to talk to Google to see what might need to be considered

s/Google/Android team/

<fjh> ACTION: fjh to look at WS* to see what might be relevant [recorded in http://www.w3.org/2012/03/21-dap-minutes.html#action03]

<trackbot> Created ACTION-520 - Look at WS* to see what might be relevant [on Frederick Hirsch - due 2012-03-28].

james: issue - what is the interaction with other groups?

darobin: it means what does a group do when they want to create a Web Intents based API?
... outside W3C we don't need to worry
... we will write specs, try to do it right, and people will cut & paste

james: where will verbs be defined for UPnP?

darobin: Claes has an AI to coordinate with UPnP forum on the mapping of intents to UPnP

<darobin> ACTION Claes to coordinate with UPnP forum about extensions required for Intents

<trackbot> Created ACTION-521 - Coordinate with UPnP forum about extensions required for Intents [on Claes Nilsson - due 2012-03-28].

james: issue - use cases for persistent permission, e.g. an app comes registered with another app

darobin: this fallbacks for intents

josh: is it possible to have more than one suggestion?

james: would we say its up to the UA to determine how much to display?
... issue - HTML5 impact
... this is the intent tag
... issue - how much UX/UI should be MUST?
... we decided nothing
... issue - what is the relationship between client and service pages?
... seems to be already answered in the discussion
... issue - how to educate users?
... we decided it was pointless
... issue - MITM attack
... maybe AI is for someone to attempt MITM to demo the risk

josh: should be pretty easy

darobin: same as phishing

josh: why phishing vs MITM?
... the FB URL for sharing is HTTP - in a coffeehouse the DNS may be local

james: we could add a best practice on use of HTTPS
... what are spam/phishing risks?

darobin: nothing too much different from the rest of the web

josh: assuming the provider trusts the user's data, do users know what they are +1'ing?
... its a form of spam, for users to be unaware and have to be told what they are sharing

james: this could allow savvy users to point out bad pages
... someone had an AI for logging?
... issue - is there a case for relaxing same-origin?

josh: my case is that while I authorized sharing, I did not auth other things

james: this is the same as the web permissions problem
... issues - auditing - Yes
... issue - service wants to be invoked by certain clients

gregb: this comes up for regulatory cases e.g. banks
... something the server can implement
... could be used for figerprinting
... don't want that

josh: we don't want enable servers to whitelist clients

<dsr> s/figerprinting/fingerprinting/

james: we could say it should be a SHOULD for some cases

[ applause ]

Battery & Vibration

<AnssiK> http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html

<AnssiK> http://www.w3.org/2009/dap/wiki/ImplementationStatus

anssik: latest is LC ended 20DEC2011 - working toward CR. Implementations exist for webkit and mozilla
... webkit landed a week ago, in FF 10 2 months ago. 2 major projects, also phonegap
... all the open issues and comments have been closed

fjh: acks

anssik: will organize a call with director to move it forward

<AnssiK> http://www.w3.org/2009/dap/wiki/FutureWork

anssik: some new features have been proposed - these need to be in the future work wiki

fjh: incl the email traffic this week

anssik: yes, those should be in the future work wiki

fjh: so all that commented should update the wiki

anssik: seems no more to discuss at the moment

<fjh> https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-battery-status-20111129/doc/

anssik: congratulate yourselves

[ applause ]

<fjh> disposition of comments is completed in LC-Tracker

Vibration API

UNKNOWN_SPEAKER: smallest API ever

<fjh> disposition of LC comments -> https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-vibration-20120202/doc/

UNKNOWN_SPEAKER: LC ended 1MAR2012. Spec is also going to CR. Implemented in webkit and mozilla. Webkit a month ago, and mozilla in FF11 one week ago
... so this is a done deal, very tightly scoped. as with battery, prefer future work to be documented on the wiki page
... one issue has come up, in vibration we dont have a privacy section, IMO we have baked this into the API

<AnssiK> "If the device does not provide a vibration mechanism, or it is disabled, the user agent must silently ignore any invocations of the vibrate() method."

<fjh> http://www.w3.org/TR/2012/WD-vibration-20120202/

<AnssiK> "For example, an implementation might abort the algorithm because the user has set a preference indicating that pages at a given origin should never be able to vibrate the device, or an implementation might cap the total amount of time a page may cause the device to vibrate and reject requests in excess of this limit."

<AnssiK> "An implementation may abort the algorithm at this point."

UNKNOWN_SPEAKER: other one important

<Zakim> darobin, you wanted to bring up testing

UNKNOWN_SPEAKER: on purpose we are trying not to spec UI. Im wondering if this guidance is needed for implementers to do the right thing?

darobin: a privacy section is not required, if we are satisfied we dont need a section

anssik: the notes should be enough. impementers will come up with innovative UIs. No privacy/security threat except battery consumption. Users will likely just navigate away.
... that was my only issue.

<AnssiK> http://dev.w3.org/2009/dap/vibration/Overview.html

darobin: we don't have any tests for battery right now?

<darobin> ACTION: Robin to write tests for Battery [recorded in http://www.w3.org/2012/03/21-dap-minutes.html#action04]

<trackbot> Created ACTION-522 - Write tests for Battery [on Robin Berjon - due 2012-03-28].

anssik: no, webkit contributors have been asked for tests, there may be something specific for webkit
... its on my todo list for battery
... have to have tests for CR
... and two interoperable implementations
... defer to chairs to handle CR transition
... will take an action for both specs

<fjh> ACTION: anssik to work on test cases for battery and vibration [recorded in http://www.w3.org/2012/03/21-dap-minutes.html#action05]

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

<fjh> ACTION: anssi to work on test cases for battery and vibration [recorded in http://www.w3.org/2012/03/21-dap-minutes.html#action06]

<trackbot> Created ACTION-523 - Work on test cases for battery and vibration [on Anssi Kostiainen - due 2012-03-28].

darobin: have some time to work on the test suites

anssik: could use this time to talk about AOB

<fjh> s/AOB/other topics related to vibration/

richt: dont see use cases - wondering why to expose vibration

bryan: games

<darobin> (and sex toys)

anssik: it's intentional, use case was for gaming

richt: re note in the spec about indefinite vibration - what is a decent amount of time for a vibration to end?
... 2nd thing is nothing about navigating away - this should cancel the pattern

anssik: in FF about:config, the default max is 10 sec

<AnssiK> in FF about:config, see dom.vibrator.max_vibrate_ms

<fjh> why isn't this decision of app?

anssik: may be more or less per the impl
... steps 5 and 7 tell what to do
... an exception is thrown
... not a decision of the app, better to have the UI control it - and configurable
... similar to storage limits

<fjh> got it, misunderstood what Richt was saying

darobin: when will opera implement it?

<Zakim> darobin, you wanted to ask when Opera will implement

richt: unsure

<darobin> \o/

darobin: thanks to anssik for joining and doing all the work

<fjh> +1 thanking Anssi

anssik: re AOB, discussions on HTML Media Capture - can I help. we are stuck with the extra media attributes, right? Did we agree on a way forward?

darobin: we are waiting on the 1st implementer, to see how the hint is shaped

anssik: no agreement yet on the hint?

darobin: not yet
... on the media capture TF people think the declarative way is still useful
... isnt chrome implementing?
... does Chrome have documentation?

<AnssiK> http://code.google.com/chrome/mobile/docs/overview.html

gregb: no idea

<Deepanshu> Is someone implementing HTML Media Capture?

anssik: need to know the details of the implementation

AI to gregb to find out whats up with Chrome

<darobin> s/AI/ACTION/

<AnssiK> s/extra media attributes/capture/

<gbillock> Is there a URL I can go to to test the media capture?

system level APIs

<darobin> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0046.html

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0046.html

darobin: history lesson on DAP charter re system level APIs, unsafe, requiring permissions... did not get support in the broader web community, so we switched to browser only

<fjh> email request re system level apis -> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0047.html

darobin: in meantime we have things being developed, but other people are using web for the entire system. where and how to standardize the APIs comes up regularly
... e.g. APIs for Tizen and B2G
... we could do this in DAP or a new group e.g. SLAPI

<Zakim> fjh, you wanted to talk about agenda

josh: 1st question geoloc, vibration, battery. not system level APIs?

darobin: no, they work in the browser security model

josh: file writer, file system ?

darobin: they are getting close. using a picker approach is OK, but some apps need more system level access.

dom: well geoloc could be said to be borderline; its security model is a bit awkward for browsers IMO

darobin: we are seeing limits to the ability to expose system level APIs without a permissions model

richt: we have seen more progress since rechartering. had to work hard to set expectations. would not be good to upset that balance. recommend system level be in a new group (or not here)
... trusted/installed approach leads to poor designs
... would not mix that up with the browser approach

<Zakim> fjh, you wanted to suggest we review Sakari's email

bryan: btw, APIs are at https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.help.web.api%2Findex.html

<gbillock> WRT my action item, I'm asking about http://dev.w3.org/2009/dap/camera/ ?

fjh: sakari's email describes issues leading to WAC/Tizen needing to develop non-standard APIs
... wondering if there is a need being missed

<richt> gbillock: I think the action was to ask about implementation of http://www.w3.org/TR/html-media-capture/

wonsuk: Tizen has bluetooth and NFC. some more APIs, but not sure they require standards

<fjh> what do we need beyond what we have in DAP, what is the issue here in concrete terms

<richt> gbillock: this is why: http://davidbcalhoun.com/2011/android-3-0-honeycomb-is-first-to-implement-the-device-api

<fjh> s/terms/terms?

wonsuk: B2G has more items e.g. call and control for wifi, browser APIs etc
... Tizen has a few items, but B2G more

fjh: maybe we have 90% of what is needed, and what is needed could work in a web way, and we could consider the reqs and may not need to spin off a new group

<Deepanshu> B2G wants some API, why don't they define themself?

<richt> gbillock. hmm that's the same link with a different name. didn't realize we published in two different normative locations.

fjh: maybe stack, unclear about bluetooth... details are needed on what is not being met

<richt> ... actually, one is the editor's draft and the other is the latest working draft.

fjh: we didnt decide yet what is the right way
... tomorrow we will introduce the tizen APIs and need to investigate the B2G project APIs

<fjh> I suggest that we need to understand (1) what cannot be done with DAP APIs currently being developed, and (2) whether a web approach might not work for what is needed - then we can understand what might be needed to be done at a system level, implies a charter for decision

fjh: AFAIK system level APIs like call and wifi, browser USB ...

<darobin> Mozilla's (partial) list for B2G: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/5649fb1085144d13/34fe9feea3887140

josh: DAP had browser vendors but they ran away. DAP got them back. We're hearing from a browser vendor or two thinking about doing what they ran away from.
... not sure how practical it will be - will it be portable? e.g. USB device paths

darobin: may issues, but they can be worked out
... e.g. no portability with the browser APIs

josh: hoping intents will solve some problems
... can we ask that new ideas be considered here first?

darobin: no, such constraints wont work
... it can say there needs to be coordination
... there is an incentive for surfacing APIs to the browser, but some things cant be

<fjh> my point is that we should see if how much of this can be used with our browser approach, then see the gaps, then see if a charter is needed

<fjh> also suggest that writing the charter is not the work of this group

josh: assuming DAP manages to get out a REC that supersedes other work... what happens?

richt: worried about intergroup conflicts

<fjh> it all depends on the real requirements as to what is needed

richt: would a reduced scope lead to conflict - there might be significant overlaps

deepanshu: do we need system level APIs in the first place

bryan: we don't have them

darobin: we don't have portable APIs

deepanshu: are we talking about installed natively running APIs?

josh: yes, as in B2G they only have JS

deepanshu: why does B2G need W3C to do this?

darobin: because they are a project not an DO

s/DO/SDO/

scribe: some of the parts can't be done in a genuine web context

<fjh> B2G = Boot to Gecko https://wiki.mozilla.org/B2G

<fjh> bryan: took a lot of stuff out of DAP since we could not get it to work in the browser

<fjh> bryan: had features we needed, could have some in the web with limited scope, but need them back on the table somewhere, market motivation

<fjh> bryan: need standardization to avoid fragment

<AnssiK> now that we're talking about system level APIs such as those spec'd by Tizen, B2G, and friends you may also want to consider Windows Runtime JS APIs: http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx

<AnssiK> Msft is a member of the DAP WG, so they should be able to chime in and contribute if they see value in standardizing system level APIs

anssik: heads up MS is doing something similar in Windows 8 - if that work goes somewhere, we should get feedback from them
... adding one more player

darobin: hearing some level of interest, some consensus not to do it in DAP - next step may be to draft a charter

dsr: a charter develops by the W3C team with key stakeholders
... for this group, do we want to plan recharter for future work?

darobin: it would make sense to do both

josh: we should also talk about crypto
... re chartering, AC input is also sought

dsr: e.g. if key stakeholders would not join, we may need to change the scope

action robin to prepare charter for system level APIs

<trackbot> Created ACTION-524 - Prepare charter for system level APIs [on Robin Berjon - due 2012-03-28].

darobin: extensions should be considered in this scope
... e.g. FF extensions have access via XPCOM to the whole system at least what is exposed to the user
... in laptop OS e.g. Chrome OS the extensions are how the app talks to the system

what parts of crypto are not in the crypto WG

josh: crypto WG will define a simple API - a good thing, e.g. validate/create a signature
... some groups want to HDMI type things for a secure channel to TVs

<fjh> Agenda plan for Thur am (1) feature permissions (2) Tizen review , after lunch (3) NFC

darobin: this is related to the HTML encrypted media proposal

<fjh> remaining to discuss apart from this - interop/testing (talked some today), calendar, network information api

josh: there is an ask to send content to secure elements

bryan: e.g. UICC

josh: some asks to get content over HTTP with a signature and used on a page
... and pull into an HTTPS page without breaking the secure lock UI

bryan: a signature will not protect the content

josh: the signature is attached and the content can be trusted

darobin: if there is anything to add to DAP charter re this, please propose on the list

josh: assuming no more WGs will be created to address things like this
... concerned about too many WGs

richt: what about network services discovery
... suggest to put on the agenda

<fjh> http://www.w3.org/2009/dap/wiki/F2F_Agenda_20-22_March_2012,_Shenzhen,_China

recess

<fjh> I have updated the agenda for tomorrow

- DRAFT -

DAP F2F Day 2

21 Mar 2012

Attendees

Contents

Media Capture

WoPhone OS

WebIntents Demonstration

Unknown

HTML Media Capture

Device orientation feedback to Geolocation.w3.org WG

Web Intents - Part 2

Battery & Vibration

Vibration API

system level APIs

what parts of crypto are not in the crypto WG

Summary of Action Items

Scribe.perl diagnostic output