See also: IRC log
<dom> trackbot, start meeting
<trackbot> Date: 04 November 2010
<trackbot> Date: 04 November 2010
<marengo> ScribeNick: marengo
<scribe> Scribe: Marco_Marengo
<fjh> Chair: Frederick_Hirsch, Robin_Berjon
<fjh> scribing - ingmar for 2nd session, laszlo tomorrow morning,
fjh: [reviews the agenda]
<fjh> add to day 2 agenda - discussion of device element
<fjh> remove WAC from day 2 agenda, covered on day 1
<fjh> possibly discuss additional API such as Tasks
(round table of introductions)
<fjh> additional agenda item - f2f planning
<fjh> Approve 20 October minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/att-0055/minutes-2010-10-20.html
RESOLUTION: minutes from 20 oct are approved
<fjh> File APIs published
<fjh> FPWD of Directories & Systems: http://www.w3.org/TR/2010/WD-file-system-api-20101026/
<fjh> WD of File API: http://www.w3.org/TR/2010/WD-FileAPI-20101026/
<fjh> WD of Writer: http://www.w3.org/TR/2010/WD-file-writer-api-20101026/
darobin: there have been updates to the File APis
... this is a good time to have a look at it
... as LC is close
<AnssiK> http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking
<anne> To get URLs out of Blob/Stream we will keep methods that give you a URL as a string but we are going to try to move them from Window so the global object is polluted less.
<anne> In addition to that IDL attributes that accept a DOMString which is a URL might get changed into accepting a DOMURL or some such so you can assign Blob/Stream directly to them.
<dom> Diff between the latest version published of FileAPI (Reader)
darobin: presents a new WG, Web Events
<fjh> Web Events WG, http://www.w3.org/News/2010#entry-8944
<AnssiK> img.src = createObjectURL(blob);
<richt> yeah, that works AnssiK (but the object will be moved elsewhere)
<dom> http://www.w3.org/2010/webevents/charter/Overview.html
<darobin> http://www.w3.org/2010/webevents/
<richt> ...or it will work when createObjectURL accepts a blob object
proposed RESOLUTION: Incorporate work from Notifications WG into DAP if acceptable to Notifications WG
fjh: permissions work in the Notifications WG, we asked if it is acceptable to move other work there
<AnssiK> richt, sure, the age old debate of not pollution the global namespace (the DAP WG was initially concerned of polluting navigator ;)
fjh: some of the people involved there are not in dap, how to avoid controversy?
<Suresh> http://dev.w3.org/2009/dap/api-perms/
<anne> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html
RESOLUTION: Incorporate the feature permissions draft from Notifications WG into DAP
<dom> ACTION: Robin to invite John Gregg to edit Feature Permissions API document in DAP [recorded in http://www.w3.org/2010/11/04-dap-minutes.html#action01]
<trackbot> Created ACTION-293 - Invite John Gregg to edit Feature Permissions API document in DAP [on Robin Berjon - due 2010-11-11].
?? need for some kind of user opt-in from the ua, the user interacts with the bar, user can check which things are allowed or not
<fjh> features requiring opt-in from user, permissions request method calls callback if permission granted, permissions operate via infobar or dialog or other mechanisms
scribe: controversy about the usefulness of opt-in bars, as user tends to say yes
<fjh> anne: geolocation bar is viewed as a failure, either click yes, or ignore
scribe: user are likely to be flooded by questions
... global decisions might work better
darobin: does it make sense to request permissions for mutiple things at once
richt: have you considered 'default-allow' policy
... and users can revoke permissions instead of granting
fjh: ok to present decisions as part of the workflow, but it must be clear that privacy is taken into account
<dom> [David Rogers informs me that he and other from WAC will join us hopefully soon]
Suresh: that seems to be indipendent from our work, how is it related?
<richt> richt: I don't necessarily agree with bringing a generic permissions interface in to DAP.
dom: with this API developers can better organize their code
<richt> ...when we start overloading a few permission strings it gets either a.) messy or b.) annoying and user's just click 'allow' all the time. Hence we have failed.
anne: as they know in advance if they can use a certain feature
<richt> ...I prefer intergrating permissions in to the users workflow. ala Contacts.
<AnssiK> [ Permissions in the context of Moz Open Web App platform: "Use of the capabilities field of the manifest for integration with browser-based permission APIs, including camera, microphone, geolocation, storage, file access, and cross-domain network access": https://apps.mozillalabs.com/web_or_native.html ]
<Zakim> fjh, you wanted to ask more about UI
<Zakim> dom, you wanted to ask about consensus on checkPermissions()
richt: doing permissions in dap doesn't mean we need an API for permission
... in a browser, it should be part of the workflow
fjh: we don't want to be intrusive, yet we have to consider privacy
... browser extensions could be helpful to test the impact on users
<fjh> file picker supportive of privacy
fjh: with file pickers, does the user understant he's making a privacy decision (does he think about reuse, ...)
<AnssiK> [ re <input type=file> (also <device>) integration and impls https://bugzilla.mozilla.org/show_bug.cgi?id=451674 and https://bugs.webkit.org/show_bug.cgi?id=43572 ]
<danielcoloma> is the bridge open?
anne: users don't read dialogs, tend to ignore
lgombos: offers to be editor of the permissions
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0058.html
nwidell: permissions for messaging apis. concerned by "open" subscribe permissions: apps can listen to every incoming message
<darobin> Summary of Permissions API decision: we publish it with warnings that there is no consensus around requestPermission, we ask johng if he wants to edit, lgombos is volunteer as editor from this WG
nwidell: security-wise, filters on subscriptions could be enough
<fjh> niklas: messaging does not seem to fit with permissions model
dom: messaging is a good use case for parametrized permissioning, to avoid allowing apps to send messages to anyone
<fjh> daniel: suggest we need parameters for permissions
<AnssiK> I was wondering if we already tried "MessagingManager implements EventTarget" type of an approach at one point and how that works with permissions -- and it appears that was already discussed (I will look for pointers)
<bryan> Permissions for messaging should include easy-to-understand concepts such as "Allow this app to send messages to any of my contacts, but no one else" (prevent malware propagation while making it easy for the user to provide a global permission).
<dom> (sending message to all my contatcs is actually the best malware propagation techniique, it seems to me)
nwidell: for receiving, you need to support filters
<danielcoloma> my point is that if we want to make the most of a trusted environment, it should be possible to use parameters in permissions
<wonsuk> http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.vm-04-Oct.html
<danielcoloma> e.g. I always allow sending messages to a set of destination numbers because I have a flat rate for them, without prompts
<wonsuk> Proposal from Veronique: http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.vm-04-Oct.html
<dom> danielcoloma, that's likely, but I think we need a very clear model of user interactions between starting to look into parametrizations
bryan: permissions (eg for sending) might be session-based
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0004.html
<danielcoloma> dom, have you had a look at the e-mail from Maria: http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0000.html
<dom> not yet I'm afraid
<wonsuk> existing ontology which is working on after made dispositions: http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0000.html
<wonsuk> diff version between existing one and Veronique's proposal: http://tinyurl.com/3y398st
<dom> wonsuk, I think you're posting your links in the wrong channel
fjh: editors of the messaging API should read maria's proposal before the messaging session
Suresh: if we agree on the functionality that we're supporting, finding agreement on permissions should be easier
fjh: (messaging session is planned for tomorrow)
<nwidell> sending and new message subscription are in scope for v1 for messaging per London F2F discussion
<fjh> please review Maria's proposal related to messaging before tomorrow's messaging discussion, http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0000.html
<dom> dom: #1 question is whether messaging API will be available outside of trusted environment
<fjh> e.g. widgets as trusted environment,
<AnssiK> we should make it clear in the spec abstract whether the spec is for "in-browser usage" or "trusted environments"
<dom> ISSUE: Does the messaging API fit outside of contained environments?
<trackbot> Created ISSUE-103 - Does the messaging API fit outside of contained environments? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/103/edit .
<Suresh> "widgets" and "open web" - everyone i believe know widgets are indeed trusted
<darobin> ISSUE: Find a better name for "trusted environments"
<trackbot> Created ISSUE-104 - Find a better name for "trusted environments" ; please complete additional details at http://www.w3.org/2009/dap/track/issues/104/edit .
<fjh> model is trusted environment, via widgets or via trusted computing platform or .etc
<nwidell> "curated environment"
drogersuk: the container could be a browser, what's different is the mediation in accessing the APIs
dom: if the widget loads an iframe from the web, can the iframe access the "contained enviroment"-only apis?
richt: againts the distinction between "web" and "curated environment"
<Zakim> fjh, you wanted to ask about mailto versus javascript
<hendry> +1 Web APIs
<AnssiK> +1 for Web APIs too
fjh: use case. a website wants to send a mail/sms -> why should it use the messaging API instead of mailto:, smsto:?
<nwidell> we have discussed this one year ago (early version of spec contained text on this)
bryan: widgets = packaging model for web applications. the api should be the same. the security model should be the same
<drogersuk> I agree with Bryan - the API and security model should be consistent across environments
<richt> +1 to bryan
<hendry> +1 to bryan
<Zakim> fjh, you wanted to ask about policy
drogersuk: even in a browser environment, mediation is needed
<dom> PROPOSED RESOLUTION: we only work on API functionalities that we know how to offer in the classical browser environment
<richt> +1 to resolution
<bryan> what does "that we know how to offer in the classical browser environment" mean?
<darobin> +1 to resolution (speaking personally and not for Robineko)
<richt> "that we know how to offer in the classical browser environment" = "that work on the web"
<darobin> "classical browser environment" == "that work with the default user-agent policy"
<dom> (richt, probably; but I think we should be explicit to make sure people understand what this means)
<bryan> can the "default user-agent policy" be vendor-specific?
<darobin> *** timecheck ***
Suresh: by focusing on classical web enviroment only we could be very limited in offering new functionalities
... that means only a few people will use it
fjh: it would be useful to discuss this with TAG
<drogersuk> We're only limited if no responsibility is taken for mediating the access that API has (controlled by the user)
<nwidell> I could see myself having more trust in "well known" web pages than some widget, no matter how well reviewed (by some mediator) that widget would be
<richt> hates the word 'mediating'.
<bryan> We should make a goal of security/privacy "by design" in APIs, place where possible and effective, choice in the user's hands, and accommodate choices that include delegation of security/privacy controls to a trusted third party, e.g. the browser vendor, employer, service provider, etc. This is essential for the flexibility to address key use cases such as protection of children. The method of delegation may include policy-based permissions frameworks
<bryan> such as defined in BONDI and to be deployed under WAC.
<drogersuk> @nwidell precisely my point
<fjh> securiy and privacy by design is important to our work
(DAP takes a 30m break)
(resuming at 11:00)
<ingmar> scribe: ingmar
<scribe> scribenick: ingmar
fjh: where we are at the privacy discussion: our group is called "Device API AND Policy", defining JavaScript-APIs to access the device
... we are discussing different environments, such as widgets and the open web
... if you have to write a policy, where does it come from when we focus on the web case for a moment
... privacy is difficult, some issues need to be handled at the client, such as minimization
... also discussed to convei user consent to the server (PPP)
... another discussion is about the model, should we focus on the open web?
<dom> [I think we have already started addressing privacy in our work]
fjh: re privacy, how much impact could we have on the server side
... it is not clear whether the current privacy proposals have buy-in from implementors
... re privacy, we walked through all the APIs on whether what is really necessary in terms of simplification and minimization
... in terms of user consent, we try to use the model to get implicit permission by using pickers
... but it is sometimes difficult to know on whether the user knows about the implications
darobin: <describes address book use case>
... user can select multiple contacts and decide on particular fields
<fjh> http://dev.w3.org/2009/dap/privacy-rulesets/
noah: <describes the role of the TAG>
DKA: question re the priv workshop in London: what learnings have been taken into the DAP work?
fjh: we learned that implementers only implement something if there is a clear value
<dom> (the privacy rulesets draft have the set of issues that have been identified)
noah: should we keep in touch on that on a regular basis, let say every few month?
<richt> I believe there is a clear divide in the group on 'Device APIs and Privacy' and 'Policy' on the other. I would like to decouple these initiatives within W3C.
dom: re minimization, means that the APIs are designed that you only get back what you requested
<noah> I'm hoping there will be time to get to extensibility later in this session.
rigo: when it comes to sharing addresses of your friends you are in a different role (service provider)
<hendry> rigo made an interesting point where when you give access to your friend's contact, you aren't neccessarily getting the consent of your friend to do that, so access control is not enough
rigo: talks about the geopriv proposal, asks about TAGs position
<drogersuk> @hendry - human decision though
DKA: thinks that geopriv is off the table meanwhile
... we should more talk about the CDT proposal
<drogersuk> Privacy is context specific. We cannot define context
<Claes> So we can only design access control but not implement "Privacy by design"?
<bryan> A balance of usability and user choice need to be considered in establishing permissions for applications. Giving the user the ability to choose (or responsibility to use) fine-grained control does not necessarily result in good choices, as the user can be overwhelmed with the need to choose (and thus say OK whatever), or miss/misinterpret the permissions that they are actually giving. Putting the design responsibility for this into the browser
<bryan> vendor's hands and thus limiting our APIs to what they can figure out how to design from a UI perspective, has resulted in the splitting of the APIs into "read" vs "write" or "send" vs "receive" specs with different development timelines, largely because the browser vendors have responded that they don't have an existing paradigm of representing certain operations, e.g. updating a contact. The policy-based approach is an attempt to resolve those
<bryan> limitations, and enable the user to choose a trusted delegate which can establish a more seamless/unobtrusive and ultimately reliable set of permissions to expose to applications. Much of DAP's discussion on these has represented these as two opposite poles of this topic, but I think that is an unnecessary and unhelpful simplification of the DAP "policy" design options.
<richt> policy needs device apis but device apis don't need policy. Therefore decoupling it would make a lot of sense and help us bring the (other) browser vendors in to the group.
<richt> ...instead we use the concept of Privacy by Design in the Device APIs with things like data minimization
noah: the TAG is not about UI design, we can not judge this
<drogersuk> device apis do need user protection though
<drogersuk> by policy or other means
<richt> drogers, we use a concept of Privacy by Design.
<richt> ...with the user at the centre of the decision making process.
drogersuk: the TAG can help to incorporate browser vendors, we need a dialog
fjh: we would like to have TAGs input on extensibility
noah: DAP is defining JS-APIs, there are interesting questions about extensibility, especially re privacy
<Suresh> Bryan has a good point about usability and user choice...it seems to be an issue that we often face in the group.
noah: one way to look at extensibility is adding functions to the API
... there is a "must understand" model in defining messages
... this could be used for APIs
fjh: API versioning is another option
Anssik, is there some prior art where extensibility has been done right?
noah: not aware of something in the security and privacy area
<fjh> http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/
<Zakim> noah, you wanted to explain my interests in extensibility
DKA: the minimization topic could be amplified by the TAG
<hendry> AnssiK: HTML is the best example I could think of wrt extensibility
<dom> [as input for guidelines on APIs, we have started noting some patterns in http://www.w3.org/2009/dap/wiki/ApiCheckList ]
<bryan> The TAG should help clarify from the Web architecture perspective that resources include features of the host device (not just some networked service that has a location indentifiable via URIs), and that resources can be accessed via multiple interface paradigms, e.g. REST/HTTP, Javascript objects, or HTML tags.
richt: why are the browser vendors not here? The TAG can certainly help to involve them.
... there is a fundamental disagreement in the group between "APIs and Privacy" and "Policy"
... we should split the two discussions, possibly considering rechartering
<Claes> +1 for addressing the issue of browser vendors (except Opera) not in this WG
<richt> we have to address this issue. I don't want DAP to be a talking shop and I think it's fair to suggest that Opera cannot (and will not) carry the industry without participation and support from other vendors.
<dom> richt, fwiw, I've wondered about your proposal before; I guess I would be willing to push that discussion once we have some insurance splitting would have an actual effort on browser vendors
<Suresh> I would really like to get back to the morning discussion and maybe define a API architecure to exactly understand how APIs fit between policy, privacy, user interaction/consent, the differences between web/widget approach
<dom> +1 Suresh; I don't know if we should try to squeeze that into a pre-lunch discussion or put it in the schedule for this pm
<drogersuk> I would like the TAG to bring the other browser vendors to the table. I disagree with breaking the group into different areas. They are closely linked - sensitive real-world APIs and security / privacy. This is the first time we are touching real, physical things
<Suresh> We see to be mixing up everything all the time unless i'm the only confused!
<dom> drogersuk, the TAG can't do a thing about bringing browser vendors; we as a group need to convince them
<dom> (which includes listening to their concerns)
<drogersuk> Noah said that the TAG would facilitate the dialogue. That's what I mean
<richt> dom, I'm not taking part and have never taken part in the policy discussions in ts group. Other vendors simply don't show up to show their position. That needs to change and the splitting discussion could go a long way to address that.
<darobin> we've had the splitting discussion before....
<drogersuk> @richt - you will, you will :-)
<darobin> of course, if all we define is darobin: APIs that are websafe, how much policy is left to discuss? </troll>
<dom> 10 glazman points for darobin
<noah> The TAG on why declarative languages are good: http://www.w3.org/2001/tag/doc/leastPower.html
<timeless> Scribe: timeless
<junliao> Jun Liao from Cna Unicom
<Dong-Young_Lee> Presnt+ Dong-Young_Lee
<fjh> David Rogers introducing WAC update, WAC 1.0 is here: http://www.wholesaleappcommunity.com/
<dsr> [dsr = Dave Raggett/W3C Team]
<fjh> WAC Waikiki (public draft) is here (feedback is actively encouraged): <a href="http://public.wholesaleappcommunity.com
<dsr> WAC: http://www.wholesaleappcommunity.com/default.aspx
<danielcoloma> Public spec URL: http://public.wholesaleappcommunity.com/redmine
<Kangchan> WAC Waikiki Developer Release Specification
bryan: app launcher has been reduced in the current release to URI schemes ...
... and a specification of how to launch the browser
... which from the widget perspective is not always clear in everyone's mind
... the ability to launch an arbitrary application has been reserved for a future release
darobin: from a WAC perspective, do you think we should follow a similar approach to AppLauncher in DAP?
bryan: the app launcher proposal has additional use cases which are not satisfied by simple URI schemes
DR: ... one other area...
... we have our default policy, which explains how we think certain prompting should be allowed/not allowed
... we'll upload our example policy to our web site
... it can be tweaked...
... we'll have a standard default policy that people can take
... and we'll have a child aware parental policy
... which will lock down Geolocation and maybe camera
... it's fairly new
... something for parents to use to somehow protect their children
... any questions?
fjh: you mentioned two things that were changed?
... application launcher and?
DR: gallery
... it was deemed to be a subset of file api, so it was folded into that
... The file system api is a subset of the real file system, it's basically virtual mounts
danielcoloma: Part of these roots include Video, Images and Sounds
... those covered the use cases for Gallery
Suresh: you use terms like untrusted
... which we discussed earlier
... what is the characterization, how do you use them in WAC?
DR: as in mobile devices, there is a provision to map onto Digital Signatures as in Widgets
... The publisher ID is verifiable ("class 2")
... getting a WAC seal of approval enables more api access
Suresh: can you relate this with the discussions from earlier?
... does open web fall into one of these categories?
DR: the example i wanted to highlight is the Browser vs. Widget model
... if we do use Geolocation
... the mozilla mobile application, Fennec
... when a site prompts and is confirmed 5 times, the affirmation becomes permanent
... and it isn't prompted for again
... There isn't much difference between that model and ...
... You still need to get the user to make some kind of decision.
<dsr> [I note that WAC specs cover accelerometer, which has also been discussed in W3C geloc lists]
DR: And there might just be terminology differences
... Wakiki ?
... When we started doing BONDI. We envisioned that Charities or AV vendors might want to implement Policies and trust
... The reason we provided a default policy, was that we felt some implementers wouldn't know what to start with
... Unlike a firewall where things break surprisingly
... Our APIs return a response indicating policy rejection
... Our target is Barcelona (Mobile World Congress)
... We recognize that developers are the heart of this. Without listening to developers, there will be no applications in the app stores
... So it's necessary to help seed things
... People may sneer at SDKs, but the majority of people can't write applications with just Notepad++
... We want to make writing applications as easy as possible
... We want to work very closely with W3C
... We've already made a clear statement that we endorse W3C specifications
... We'd like to have regular meetings
[ DR is reading a slide ]
[ Slide 17 ]
DR: Questions?
Claes: When it comes to the type of application you intend to provide with WAC
... are you intend to do some differentiation because ...
... one argument for WAC is that you can make applications that are platform independent
... but you still have to compete with [Apple] AppStore and
... Android Market
DR: so you're asking "what's the killer app for WAC?"
... but that's not your question
... The value is the long term
... People who are using iPhones are a tiny proportion of all mobile users in the world
... We have a vendor in the Philippines
... They were using SMS for applications
<Zakim> dsr, you wanted to ask about relation between WAC accelerometer spec and Geoloc device orientation event spec
DR: So it's kind of like moving from DOS to Windows
... This stack makes it very easy to go to HTML5
... The native application space could be very easily embraced in WAC
... We're open to them, and it's under study
dsr: The relationship between WAC and W3C specs..?
... I saw Accelerometer which is under study in Geolocation
DR: danielcoloma did you want to talk about Accelerometer in W3C
<hendry> http://dev.w3.org/geo/api/spec-source-orientation.html
danielcoloma: We don't believe the W3C draft is stable enough
fjh: so you're saying you will use it when it's stable?
danielcoloma: The target is MWC2011
... which is before the W3C spec would be ready
[ so they needed their own in the interim ]
<dsr> Geloc DeviceOrientation spec http://dev.w3.org/geo/api/spec-source-orientation.html
<hendry> versus http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/deviceapis/accelerometer.html
Suresh: if you take the presentation from WAC
... and put in the mix of discussions in this group
... there's a lot of overlap
... I think we need to start with some sort of architecture. what falls in what.
... which parts can be separated out
... Security has various things, signing
... Versus getting permission to do some thing
<fjh> suresh asks for clear architecture picture, and clear requirements
Suresh: on the one hand, we're asked to bake Security and Privacy into the API
... In WAC, they have some kind of default policy
... you prompt the user, or you don't prompt
... In our case, we have an example with Geolocation where the suggestion is prompt the user
... What are we trying to achieve in putting security into the APIs?
darobin: The goal is to not create security/privacy issues
... when running in the Same Origin model
... What it implies is integrating with a user understandable workflow
... You click on something, and get a contact picker
... People aren't fooled when they click on a file upload button
... They understand that they're giving file info to the web site
... Similarly, with Geolocation, whenever there's a security boundary, you make it asynchronous
... It might talk to a permission server, or call someone up
... If we go to a model, where the only API specs we release work with a model
... preferably where there's a model that doesn't result in 7 infobars
... For new features, it means we might mean we need to delay things
... until we know how to expose it in a safe manner
Suresh: you mentioned a workflow the user could understand
... the user has to pick what it wants
darobin: we define an interface such that you can build a UI that we think is correct
... If you want to build a different model, or you want to say screw the security model
... I want to return all the contacts
... that's fine.
... Taking the contacts example
... If you want to allow for selecting an item, that's ok.
... But if you want to provide a way to allow a widget to allow access to all contacts, that's ok.
<Claes> DAP has createt this draft that is defining 3 basic use cases: http://dev.w3.org/2009/dap/policy-reqs/#normative-references
Suresh: someone could use our contacts API to do both of those
darobin: that's our point
... it works in Browser or a more powerful Widget
... The exact same code would work in both places
Suresh: taking this model, you could do it safely
... Save and Delete are not safe
[ darobin described how to select one, or select * - for selecting contacts ]
Suresh: you could have checkboxes to do save/delete
darobin: it's possible.
... the issue with Delete is the problem of how to define a metaphor
... because there's no matching metaphor in the browser interface for deleting something
Suresh: the browser could throw up a dialog
darobin: the browser does for deleting cookies, but that isn't from the web page
... we can find this, those things are harder to do
... you could prioritize Reading, and 6 months later make a Writing API
Suresh: no matter how you solve permissions / user prompts
... you need those apis to do the reading/writing
... there's an api no matter which ui paradigm you take
Claes: we have been working on a document
... Device API access control use cases
... that states 3 basic use cases for Access Control
... we made some conclusions when we made that document
... i'm not sure if we're going to discuss that
darobin: the idea is to finish it
Claes: i think it's quite simple
... all apis must be usable in an untrusted environment
... and in addition, if i have a trusted authority
... we should provide a way for it to work without as much user interaction
darobin: In a non chair view,
bryan: that we need to find a model that works makes perfect sense
... managing file systems...
... I think people understand those things
... The important things is that when a user allows for things to occur
... is an important decision
... When the user says "yeah, i trust you"
... the point is that it's persistent
... that could happen before they launch the widget
... or application
... but the user doesn't have to make the decisions in real time
... because that could break the application
darobin: I'll go one step further
... we need to be even more flexible than that
... We need to enable smarter implementations
... we might have a trust delegation
... or prompt
... The ideal model would be flexible enough to handle different implementations
<fjh> API orthogonal to security and privacy model
richt: there's basically different levels for paradigms
... but there are a lot of apis available out there
... taking the file system apis
... [in webapps]
... you could have a service level contact book
... you could use IndexDB
... you could synchronize with the contacts book
... when it comes to the API design
... I think it makes sense to look at use
... instead of management
... The idea is to look out how people will use the API is what's important
... in contacts it's getting
... in calendar it's saving
Suresh: I think the usage, we get into usability
... are we the experts to solve that
richt: it's an ongoing dicussion
... there are different levels to address that
[ scribe lost dom's statements ]
<dom> dom: this is introductory discusson on whether we want to work on APIs that require a different security model than the browser model
darobin: as dom stated: do we ever want to release a specification of an api
... for which we don't know how to create a safe implementation in the browser
Suresh: I think we need to create something safe. And it has to be useful
... In both environments, you could have different default states
... I get a feeling that we're being more concerned than we should be
... In the process, we're having a very minimal api
darobin: I don't think we're going with minimal api
... we're shipping what we're confident we can ship
... When we ship X, we're saying we know how to implement X
... And we can do Y later, when we know how to do it
... It's about not delaying releasing X
... while we figure out Y
Suresh: We talk about environment where widget environment is more trusted
darobin: I don't think we want our documents to reflect a distinction
... we should make apis that work in both environments
... [ Widgets and Open Web ]
... We can make things that work in both environments
Suresh: People are used to interacting with device
... in that environment, we could expose more functionality
... But in browser, we might expose less functionality
... We seem to be limiting our UI toward what might be on the Web
darobin: the kind of architecture under discussion allows us to do both
... it's just more work
... because we need to find ways to expose these things that are safe in the default environment
... If we need to make everything work in both worlds with the same functionality, it is harder to do safely
<drogersuk> We need to bridge to the browser with common APIs but acknowledge that the APIs need security to be used. That, in our environment (mobile, widgets) is a policy framework. It could still work with something else that does this in the browser
darobin: It might delay things, but I think it's the more powerful path
Suresh: a lot of where we're getting stuck is the UI paradigm
richt: I don't believe we can separate the layers
drogersuk: we have a consensus
... that we need common APIs
... and we understand that these APIs are sensitive
<fjh> is your point, drogersuk, that policy framework is an implementation decision and aspect?
drogersuk: the key question lies around, us saying that if you use this api, you have to use security
... In our environment, in the widget world, we say you use policy
<dom> fjh, I like your characterization of david's point
drogersuk: In the browser that could be some other kind of security
... the point is that there is security for this kind of API
... (answering fjh) yes
darobin: it's an obligation, but how you do it is an implementation choice
... but before we design an api
... we need to make sure it's possible to make it secure in the default web environment
<Zakim> darobin, you wanted to talk about not two different environments but rather a large number including a default one
<Zakim> dom, you wanted to mention the browser security model might become an important feature
dom: building in security is costly
... but it's a feature
... there was a story recently about Facebook
... where it got phone numbers
... without asking the user
... I agree that we're making it more difficult to have access to features
... which seem natural in a controlled environment
... but I think we need to look at more than the cost
... to make sure we understand the benefit to the user
Suresh: I'm afraid of us taking 2-3 years to come out with something that won't be useful
<drogersuk> from before: We need to bridge to the browser with common APIs but acknowledge that the APIs need security to be used. That, in our environment (mobile, widgets) is a policy framework. It could still work with something else that does this in the browser
<fjh> proposed RESOLUTION: the sense of the WG is to require security without mandating the mechanism apart from requiring safe use in a browser context
<dom> PROPOSED RESOLUTION: we should focus on API features that can be implemented safely in the default browser policy model
nwidell: You could have an API which has a messy UI implementation
<drogersuk> agree with fjh's proposal
nwidell: if it's useful, people will try to work to resolve the UI situation over time
dom: but what you're describing ought to happen before standardization, not after
... I think the risk is that you if you try to standardize something like that
... it won't have a long duration
... I'm not sure that trying to push something early
nwidell: it was to avoid having two APIs
<richt> dom, I agree with everything you say...at the least, +1 to your proposal :)
dom: if someone wants to propose an api feature
... they need to explain how they expect it to work in a browser environment
Suresh: can that be with policy?
darobin: no
Suresh: I'm not sure what you mean browser, do you mean desktop?
darobin: no, it could be mobile
Suresh: I'm coming from a device vendor
... we have a focus on controlling the environment
darobin: Suresh, if you don't think it's safe
... desktop won't think it's safe either
rigo: for this policy environment
... one of the ideas is to make it easily consumable
... the problem is making an api consumable
... the problem with an api control point
<darobin> darobin: if you see something unsafe in a mobile browser, it's almost certainly unsafe in a desktop environment too — there is no strong distinction
rigo: is that you don't have enough information coming through the api
... to enable informed consent
... because you don't have enough information to warn the user if it's safe or dangerous
... the suggestion is that we somewhat express the semantics
... that give you the possibility to convey more information
... from the one requesting the information
... to the one giving the information
... so that we enable the app to provide assertions
... so the UA can provide a meaningful question
... so the user can make an informed decision
... There was a proposal at the October (?) session
... with a JSON mechanism
... which would provide a richer exchange
<Zakim> fjh, you wanted to note we left out privacy from resolution
fjh: i don't disagree with that
... I think the resolution was scoped narrowly
... I think we need @@ ... @@ in the browser
... I think the privacy issue still stands
... but I think that's a different issue
... than a policy framework
... which might not provide what we want
<dsr> I note that "safely" doesn't clearly distinguish between security and privacy!
I just heard something which reminds me
scribe: of something from a while ago
<drogersuk> "sicherheit" - safety and security
<dsr> why is it valuable to conflate security and privacy?
<rigo> let P3P sleep in peace :)
fjh: the group understand the scribe's concern
drogersuk: on Privacy and Security
... they are separate but intertwined
... I did propose what rigo proposed to BONDI
... for example Location
... If you look at android
... you find the number of applications that ask for fine-grain location information
... is quite high
<rigo> so timeless, let's have an argument in the break. I can even explain you how P3P enforcement worked
drogersuk: and malicious applications will ask for the highest precision
darobin: how you implement it, and how you support trust
drogersuk: What I'm saing is that in other environments, it isn't working
darobin: I'm disagreeing with going in a direction away from a resolution
<dom> PROPOSED RESOLUTION: we should focus on API features that can be implemented safely in the default browser policy model
<drogersuk> @timeless - correction: fine grained location permissions request
bryan: is that like Geolocation?
darobin: yes, but we're aware it's suboptimial
bryan: is everything Same Origin
<fjh> PROPOSED RESOLUTION: the sense of the WG is to require security without mandating the mechanism apart from requiring safe use in a browser context
fjh: our real decision is to not require building a policy framework into the browser
drogersuk: my concern with dom's proposal
... is that it seems to constrain the number of APIs
<darobin> PROPOSED RESOLUTION: The WG will deliver APIs that do not mandate a specific security model but function safely in all contexts, especially the default browser security context
darobin: the important part from dom's proposal is that we have to prioritize
... APIs, based on what's important
<darobin> PROPOSED RESOLUTION: We prioritise API functionality for which we have security solutions
bryan: fjh's proposal about not mandating the mechanism
... add that to dom's....
fjh: i don't like the second one because for browsers it can't necessarily be a policy framework
darobin: as i described earlier for contacts
... if you're in the browser, you might get a find contacts
... but in a Widget you might get everything automatically from search:*
<drogersuk> PROPOSED RESOLUTION: The WG will deliver APIs that do not mandate a specific security model but ensure the safety and security of the user in all contexts, especially the default browser security context
darobin: i can live with that
fjh: any objections to drogersuk 's proposal?
darobin: you actually read stuff before agreeing?!
<bblfish> hi
nwidell: haven't we resolved this before?
<drogersuk> I still think we should continue working on security alongside the APIs
Dong-Young_Lee: what's the problem of mandating a policy framework?
fjh: the policy framework is something specific
... which raises questions of who writes the framework
... and how does that work on the web
darobin: and there's the bit of no one wants to write or maintain it for the web
Dong-Young_Lee: so we delay our work, until some mechanism until a mechanism other than the policy model?
drogersuk: we have a duty to work on ...
... something so we can support multiple security models
... one for mobile
... e.g. Google came to the table with PowerBox
... More to do with implementation than specification
dom: any objections to the proposed resolution?
lgombos: so if this is very sensitive in a default browser environment
... do we have to call that out in the specification
... do we make it optional for browsers?
darobin: if there's something that's sensitive and dangerous
... and we don't have a solution for it in browsers?
... then we don't spec it until we have a solution
drogersuk: there's also a group that tlr is working on
<drogersuk> PROPOSED RESOLUTION: The WG will deliver APIs that do not mandate a specific security model but ensure the safety and security of the user in all contexts, especially the default browser security context
<drogersuk> . The group will continue to work on security.
darobin: yes, with that
RESOLUTION: The WG will deliver APIs that do not mandate a specific security model but ensure the safety and security of the user in all contexts, especially the default browser security context. The group will continue to work on security.
<darobin> PROPOSED RESOLUTION: We prioritise API functionality for which we have security solutions
RESOLUTION: We prioritise API functionality for which we have security solutions
[ break ]
[ return @ 4pm ]
<dsr> scribe: dsr
we resume after a coffee break
Robin: suggest we keep going with the agenda. [link?]
<richt> Here's the proposal to simplify the Sys Info API: http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html
The draft is kind of big. At the same time the Android browser has a different way to describe the network connection type.
<fjh> http://www.w3.org/mid/23BEF3D8-2957-4D6F-99EE-61EF1479C97B@berjon.com
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0059.html (Illka)
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html (Rich)
<hendry> +1 to alignment with browser :)
This presents us with a choice, we could align with what is happening in the browser or continue with the current proposal in the draft (see above)
Rich talks us through his proposal for a simplication (email to DAP WG list)
<dom> (I didn't get a chance to reply to Rich's message on the list, but I mostly +1 his proposal)
on 29 Oct (SysInfo API vs Generic Sensors API)
This is from the Android browser
<dom> robin notes a mistake in the proposed WebIDL where type is shown as a method rather than an attribute
[uri? for his email]
<dom> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html
Bryan: this moves us to an object oriented approach as opposed to a vocabulary oriented approach which could create problems for future extensibility.
Robin: to clarify we would keep the SysInfo mechanism for extensibility but introduce the simpler interface in parallel.
<adam> could you infer you were on a corporate network?
Bryan: you could infer that someone is at home from the details of their network connection info, this is a privacy concern.
Robin: the information available is limited e.g. on 3G or WiFi
Suresh recaps background leading up to where we are now. We should take this decision in the context of all the SysInfo params.
Dom: the fact that the simple approach already has some traction should be taken into account, but it is only one of several proposals.
<fjh> Is it correct to say that all information provided in the proposal from Rich will still be provided using the current SysInfo API draft?
<Zakim> AnssiK, you wanted to ask about event handlers, and if they're needed
May be we should add event handlers to avoid the need for polling?
<Zakim> fjh, you wanted to confirm alternative
<AnssiK> implement EventTarget, add connectionchange event type
Is the proposal to remove some information from SysInfo where it is available from the Android interface?
Suresh: some properties can be synchronous, but others could necessitate polling or asynchronous, let's keep some synchronous properties where practical.
Rich: what do we want to do next?
Bryan: this is currently only supported by Android and not other browsers. Do we want to do this, and don't we need to get Google's consent?
Google is in this WG and signed up to its IPR policy.
<hendry> hendry: type just caches last seen connection type; Android browser fires online when the type changes
<Zakim> timeless, you wanted to ask about vpn's
Robin: numerical constants are bad for developers, and named methods/properties are preferable.
Josh: worried about information leakage e.g. website learning about my VPN.
Rich: this is why we need a spec to clarify that that can't occur.
Robin: if you are on 2G you might want to avoid using web fonts for performance reasons.
Josh: download rate is critical for my user experience, not the details of the network connection.
<fjh> s/(slides will be available later)/WAC Waikiki (public draft) is here (feedback is actively encouraged): http://public.wholesaleappcommunity.com/\/ (slides will be available later)/
Josh: giving people an API that encourages sloppy practices, when developers could use code to adapt to the network speed directly.
Dom: this might be difficult in practice.
<lgombos_> .. it seems that the android implementation has an eventing mechanism - The online event is fired when the networkType changes.
<dom> [I recommend not bundling the new proposals together]
Robin summarizes.
Bryan: we already have this use case, so it doesn't argue strongly for the Android interface.
Josh: the browser doesn't have control over which network connection packets flow (apart from Symbian).
<dom> Bryan: also, our proposal can deal with several connections; this one doesn't
Bryan repeats concern over privacy.
Bryan: we have a security solution for our existing API, but not for this new proposal.
Rich proposes to draft a spec based upon the Android solution.
Robin: if we have a detailed proposal then we will be in a stronger position to review its security.
Henry: I would rather have network speed rather than its specific type.
Josh: it is important to test the performance in the kinds of data the app needs, e.g. latency/jitter on video
<Zakim> timeless, you wanted to note that IP addresses generally disclose network topology (Cable, DSL, T1, Cellular, WiFi hotspot)
Ilkka: network characteristics can change dramatically over time.
<dom> ACTION: Richard to create an editors draft for new proposed network connection API [recorded in http://www.w3.org/2010/11/04-dap-minutes.html#action02]
<trackbot> Created ACTION-294 - Create an editors draft for new proposed network connection API [on Richard Tibbett - due 2010-11-11].
Josh: IP addresses generally disclose network info, e.g. which type you are using.
Bryan: disagree (details lost)
Suresh: would like to see this approach applied broadly.
Dom: safe and useful.
<bryan> IP addresses provided by mobile networks cannot be mapped to a particular location - they are public IP addresses assigned to the data center that the mobile device is connected to, and which may be hundreds of miles away. This is how mobile networks are architected.
Henry: I could spend 2 minutes describing link with WebId
Robin: go ahead
[ see e.g. http://esw.w3.org/WebID ]
Rich: HTML5 gives us keygen mechanism which could be useful.
Dom: this is an API not a format.
Henry: ah thanks for the clarification.
Henry will communicate offline with Rich.
Rich: work on the contacts API has been a fun ride ;)
Sorting is hard. Similar discussion in Web Apps WG earlier this week.
<bryan> Question I was going to ask (on the queue) for Henry: how are the private keys protected for WebID? Are there any specific requirements for where these keys are kept and how protected?
Robin: leave it to JavaScript. (Unicode string sorting)
<timeless> +1
Rich: Appendix B.1.
this example has been there for a long time
<dom> Contacts API editors draft
B.2 is a way to invoke API synchronously.
works similar to window.open
<dom> [I'm thinking the button binding should probably be the only way to access the contacts API]
untrusted code results in pop-up blocker kicking into effect.
trusted if as a result of a user action, e.g. button press
<dom> [my main concern is that with the button text being able to say anything, this can be used for social engineering]
<AnssiK> body.addEventListener('click', doEvil, false);
<dom> <input type=contact> would avoid that
Dom: prefer the requirement for direct user action, but concerned about social engineering where users are "tricked" into doing something
<darobin> <input type=contact> degrades to <input type=text>, which is an issue
<bblfish> bryan: private key are kept in keychain in browser
Rich: web developers circumvent official controls for a variety of reasons
<richt> http://valums.com/ajax-upload/
Clicking on an image acting as a button results in the file selection dialogue appearing
Robin: advantage of non-user initiated version is that it results in it can be more easily re-used in the "trusted environment"
<timeless> http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events
Rich: we need to describe the connection to DOM3 trusted events
Robin: any objections to making it normative
Anssi: concerned about developer's tricking users
Some discussion about event bubbling and trust model
Josh talks through the details of click jacking...
<timeless> you can probably game the user to double click and hit enter
<timeless> but if you add a lag between filling in contacts (etc.) and if you default to cancel instead of submit in the dialog, you're probably ok
nwidell: in this case does the fact that the events are trusted matter that much?
<timeless> richt: editorial, can you use green instead of red for {}s ? :)
Rich: this is how file upload works today
Rich projects a click jacking example where the submit button has opacity zero.
Bryan: question - once I've picked a contact, does that mean I have perpetual access to that contact, or at least for the rest of the browser session?
<richt> you should probably have access for the life of the script.
is this access to the data or to the object?
Dom: to the data
<richt> but right now you get a snapshot of the data
<fjh> bryan: suggests creating a test case for this case to make sure it is the case
<darobin> RESOLUTION: Contacts data is a snapshot, not a live mirror of the contacts DB info
lgombos: does this interface open the contact info directly?
Robin: non-normatively we say a notification bar is shown first to alert the user to the action.
some discussion on filtering of contacts via filter param in API
usability considerations and comparison with current implementations of geoloc.
Dom: the API does influence the UI
Robin: we're not UI experts and want to give the designers freedom to do a good job
... we don't assume that privacy and security are done through the UI. There could be other approaches [ delegation models? ]
<fjh> concern that privacy will get lost in the gap between various optionalities
David: the app doesn't need to know the personal info, but we don't (now) have the technology to deal with this.
<fjh> however Dom argues that privacy is a competitive advantage of implementations
Rich: data minimization ...
Suresh: on your examples you state "sharing" but do so in a way that could be misleading.
some more details which I can deal with offline.
Robin: we will have a broader discussion tomorrow.
<darobin> http://www.w3.org/2009/dap/wiki/TPAC10Agenda#10.29_Metaphors_for_write-back_and_deletion
<timeless> Provide a way for the user to provide an adhoc or dummy card for privacy reasons (to avoid being refused admittance by sites which require the API to return data).
<Suresh> The leading section under the Contact interface still omits OMA CAB, which is inconsistent with our earlier discussion....
[ DSR wonders about requirements for signed contacts ]
<darobin> timeless: suggest requiring the ability to return dummy contacts
<darobin> dom pushes back that that's UI innovation best left to implementers
David: the facebook issue, I will deny you access to this site UNLESS....
Rich: we can't do much about that in technical specs
<drogersuk> ACTION: David Rogers to outline social engineering threat, API entry hurdles to websites [recorded in http://www.w3.org/2010/11/04-dap-minutes.html#action03]
<trackbot> Created ACTION-295 - Rogers to outline social engineering threat, API entry hurdles to websites [on David Rogers - due 2010-11-11].
Robin provides a summary of the proposed next steps
<darobin> PROPOSED RESOLUTION: Document the infobar+trusted click dual model as an issue (with the idea that we might retain only one if it's better) and publish an updated WD
<darobin> Robin: the hope is that it's the last heartbeat before LC
Suresh: is having two models an issue?
Robin: yes, more work for implementors
<richt> But the two models use the same component (ie
<richt> (i.e. contact picker)
Dom: we could leave this to CR and see what is implemented.
<dom> (and call it feature at risk if needed)
<darobin> ... because it clearly requires implementation feedback
<richt> agreed.
<darobin> PROPOSED RESOLUTION: Accept changes, document dual infobar+trusted events as feature at risk, and publish a heartbeat WD
RESOLUTION: Accept changes, document dual infobar+trusted events as feature at risk, and publish a heartbeat WD
Accepted as written
scribe: the room is hot and stuffy and it is 5:35pm, what can we usefully do now ...
Dom talks through use case with a lot of files in the gallery
<bryan> +1 to the value of gallery as a metadata search engine for media files
We probably need more discussion on use cases before deciding on the technical details.
Suresh: having just the metadata might restrict the UI
[ thumbnails for audio, video and photos? ]
<AnssiK> the UI on the left is already a gallery: http://dev.w3.org/2009/dap/camera/capture-api-file-picker-concept.png
Nokia contribution covered file picker use case.
Bryan: very high priority for us
<richt> the functionality is high priority, not the API, right?
<dom> ACTION: Dom to send use cases for gallery API [recorded in http://www.w3.org/2010/11/04-dap-minutes.html#action04]
<trackbot> Created ACTION-296 - Send use cases for gallery API [on Dominique Hazaël-Massieux - due 2010-11-11].
<richt> so if the functionality is available elsewhere then we don't need a Gallery API (e.g. if we can use File API + File System API + a richer File Picker (with gallery capability) then we're good right?)
<darobin> http://dev.w3.org/2009/dap/calendar/TimezonedDate.html
Rich: I wrote it and haven't touched it since then, needs refinement
Rich wants to provide a new proposal.
floating time, fixed time, timezones changing all over the place. Better to apply timezone and format preferences to UTC values
[ do all devices really know daylight savings transitions in all countries? ]
<timeless> dsr: no.
Dom cites example of flights where timezones change definition during trip
Robin: example of call starting in boston timezone and ending when I need to collect my daughter from daycare in my local timezone
<dom> (I suggest TZDate instead of TimezonedDate FWIW)
Robin: I need a to UTC date method to simplify my code.
<timeless> dom +1
yes, reduces camel casing errors
Rich edits the TZDate object definition on the fly
<timeless> richt: Constructor(Date, timezoneID)
Suresh: why not inherit from ECMAScript Date object?
Josh: when that object changes you get screwed
<richt> timeless, depends how you interpret the Date object if e.g. it has a -04:00 offset and a timezoneId of 'Asia/Ulaanbataar' what is the time !?
<richt> Constructor(year, month, day, hours, minutes, seconds, timezoneID)
<richt> ..works much better...
<timeless> richt: serialize to number first and then add timezoneid
DSR suggests noting the importance of having accurate and current DST info
Platform developers need to be good, web developers don't want to get burned
<dom> 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? -- pending review
<trackbot> http://www.w3.org/2009/dap/track/issues/81
<dom> ISSUE-81: http://dev.w3.org/2009/dap/calendar/TimezonedDate.html proposal that will need to be reworked to avoid extending a host object
<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? notes added
<timeless> <Josh> when that object changes you get screwed
<dom> ISSUE-81: since extending a host object is a bad idea in case the original object evolves (and would aslo implies stringification nightmares)
<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? notes added
<timeless> "that object", being the API of that Host/Host language object
Suresh and Rich discuss Date object and timezone, could timezone be added as attribute to the Date object?
Rich: Date serializes to local time leading to problems.
<timeless> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toJSON Date().toJSON is a "new" property, I believe from ECMAScript5
<dom> ACTION: Robin to draft up TZDate [recorded in http://www.w3.org/2010/11/04-dap-minutes.html#action05]
<trackbot> Created ACTION-297 - Draft up TZDate [on Robin Berjon - due 2010-11-11].
Robin asks for volunteers to take over TZDate spec, but ends up doing so himself
