07:34:41 <RRSAgent> RRSAgent has joined #dap
07:34:41 <RRSAgent> logging to http://www.w3.org/2010/11/04-dap-irc
07:34:43 <dom> trackbot, start meeting
07:34:43 <trackbot> RRSAgent, make logs world
07:34:44 <Zakim> Zakim has joined #dap
07:34:45 <trackbot> Zakim, this will be DAP
07:34:45 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
07:34:46 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
07:34:47 <trackbot> Date: 04 November 2010
07:34:51 <trackbot> RRSAgent, make logs world
07:34:55 <trackbot> Zakim, this will be DAP
07:34:55 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
07:34:57 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
07:34:59 <trackbot> Date: 04 November 2010
07:35:02 <marengo> Present+ Marco_Marengo
07:35:16 <ingmar> present+ Ingmar_Kliche
07:35:18 <dom> Present+ Dominique_Hazael-Massieu
07:35:21 <dom> s/eu/eux
07:35:33 <dom> Chair: Frederick_Hirsch, Robin_Berjon
07:35:47 <dom> Agenda: http://www.w3.org/2009/dap/wiki/TPAC10Agenda
07:36:03 <marengo> ScribeNick: marengo 
07:36:03 <fjh> Chair: Frederick_Hirsch, Robin_Berjon
07:36:08 <richt> richt has joined #dap
07:36:35 <fjh> Present+ Frederick_Hirsch, Robin_Berjon
07:37:29 <jgiraud> jgiraud has joined #dap
07:37:40 <dom> dom has changed the topic to: Agenda: http://www.w3.org/2009/dap/wiki/TPAC10Agenda
07:37:56 <dom> Meeting: TPAC 2010 F2F Meeting - Day 1
07:37:57 <darobin> darobin has joined #dap
07:38:11 <richt> Present+ Rich_Tibbett
07:38:20 <maoteo> maoteo has joined #dap
07:38:20 <cmarc> cmarc has joined #dap
07:38:21 <Kangchan> Kangchan has joined #dap
07:38:25 <darobin> Present+ Robin
07:38:32 <youenn> youenn has joined #dap
07:38:40 <darobin> Zakim, who's the werewolf?
07:38:40 <Zakim> I don't understand your question, darobin.
07:38:49 <nwidell> nwidell has joined #dap
07:38:51 <cmarc> Present+ Cecile_Marc
07:38:55 <maoteo> Present+ Maria_Oteo
07:40:15 <YounSung> YounSung has joined #dap
07:40:25 <richt> richt has joined #dap
07:40:28 <nwidell> Present+ Niklas_Widell
07:40:45 <marengo> Topic: Welcome, agenda review, scribe selection, logistics, announcements
07:40:57 <YounSung> Present+ YounSung_Chu
07:40:58 <lgombos_w> present+ Laszlo_Gombos
07:41:30 <fjh> scribing - ingmar for 2nd session, laszlo tomorrow morning, 
07:41:59 <Kangchan> Present+ Kangchan_Lee
07:42:01 <Suresh> Suresh has joined #dap
07:42:18 <marengo> fjh: [reviews the agenda]
07:42:20 <Suresh> Present+ Suresh_Chitturi
07:43:14 <Johnson> Johnson has joined #dap
07:44:03 <AnssiK> AnssiK has joined #dap
07:44:16 <AnssiK> Present+ Anssi_Kostiainen
07:44:56 <jgiraud> Present+ Jerome_giraud
07:45:27 <youenn> youenn has joined #dap
07:46:02 <jun> jun has joined #dap
07:46:39 <fjh> add to day 2 agenda  - discussion of device element 
07:46:49 <fjh> remove WAC from day 2 agenda, covered on day 1
07:47:01 <aizu> aizu has joined #dap
07:47:27 <ilkka> Present+ Ilkka_Oksanen
07:47:48 <fjh> possibly discuss additional API such as Tasks
07:48:18 <marengo> Topic: Introductions
07:48:26 <wuj> wuj has joined #dap
07:48:41 <marengo> (round table of introductions)
07:49:38 <hendry> hendry has joined #dap
07:50:02 <fjh> additiional agenda item - f2f planning
07:50:57 <youenn> youenn has joined #dap
07:51:05 <Wuk> Wuk has joined #DAP
07:53:27 <hendry> +Present Kai Hendry
07:53:35 <youenn> +Present youenn fablet
07:53:43 <dom> Present+ Kai Hendry
07:53:48 <dom> Present+ youenn fablet
07:53:53 <anne> anne has joined #dap
07:53:56 <darobin> s/+Present/Present+/g
07:54:05 <anne> Present+ anne
07:54:23 <dom> s/ anne/ Anne_Van_Kesteren
07:54:24 <marengo> Topic: Minutes approval
07:54:26 <fjh> Approve 20 October minutes
07:54:27 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/att-0055/minutes-2010-10-20.html
07:54:34 <marengo> RESOLUTION: minutes from 20 oct are approved
07:54:42 <marengo> Topic: Editorial Updates
07:54:51 <fjh> File APIs published
07:54:59 <fjh> FPWD of Directories & Systems: http://www.w3.org/TR/2010/WD-file-system-api-20101026/
07:54:59 <fjh>  WD of File API: http://www.w3.org/TR/2010/WD-FileAPI-20101026/
07:54:59 <fjh>  WD of Writer: http://www.w3.org/TR/2010/WD-file-writer-api-20101026/
07:55:05 <marengo> darobin: there have been updates to the File APis
07:55:18 <marengo> ... this is a good time to have a look at it
07:55:20 <anne> s/Anne_Van_Kesteren/Anne_van_Kesteren/
07:55:23 <marengo> ... as LC is close
07:56:53 <kensaku> kensaku has joined #dap
07:57:16 <callie> callie has joined #DAP
07:57:49 <AnssiK> http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking
07:58:18 <Claes> Claes has joined #dap
07:58:21 <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.
07:58:49 <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.
07:58:51 <Claes> Present+ Claes_NIlsson
07:58:52 <dom> -> http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2009%2FWD-FileAPI-20091117%2F&doc2=http%3A%2F%2Fwww.w3.org%2FTR%2F2010%2FWD-FileAPI-20101026%2F Diff between the latest version published of FileAPI (Reader)
07:58:54 <marengo> darobin: presents a new WG, Web Events
07:59:01 <fjh> Web Events WG, http://www.w3.org/News/2010#entry-8944
07:59:07 <AnssiK> img.src = createObjectURL(blob);
07:59:57 <richt> yeah, that works AnssiK (but the object will be moved elsewhere)
08:00:02 <dom> http://www.w3.org/2010/webevents/charter/Overview.html
08:00:03 <darobin> http://www.w3.org/2010/webevents/
08:00:11 <richt> ...or it will work when createObjectURL accepts a blob object
08:00:13 <marengo> Topic: Permissions
08:00:31 <marengo> proposed RESOLUTION: Incorporate work from Notifications WG into DAP if acceptable to Notifications WG
08:01:08 <marengo> fjh: permissions work in the Notifications WG, we asked if it is acceptable to move other work there
08:01:13 <AnssiK> richt: sure, the age old debate of not pollution the global namespace (the DAP WG was initially concerned of polluting navigator ;)
08:01:51 <seungjae> seungjae has joined #dap
08:02:22 <marengo> ... some of the people involved there are not in dap, how to avoid controversy?
08:02:42 <Suresh> http://dev.w3.org/2009/dap/api-perms/
08:03:12 <richt> s/richt:/richt,/
08:03:49 <dom> richt: Mozilla rocks
08:04:07 <dom> s/richt: Mozilla rocks//
08:04:29 <anne> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html
08:06:06 <marengo> RESOLUTION: Incorporate the feature permissions draft from Notifications WG into DAP
08:06:22 <Suresh> q+
08:06:42 <dom> ACTION: Robin to invite John Gregg to edit Feature Permissions API document in DAP
08:06:43 <trackbot> Created ACTION-293 - Invite John Gregg to edit Feature Permissions API document in DAP [on Robin Berjon - due 2010-11-11].
08:07:18 <darobin> ack Suresh 
08:07:20 <fjh> q?
08:08:55 <richt> q+
08:08:58 <marengo> ?? 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
08:09:10 <fjh> features requiring opt-in from user, permissions request method calls callback if permission granted, permissions operate via infobar or dialog or other mechanisms
08:09:40 <Johnson> Present+ Johnson_W
08:09:50 <marengo> ... controversy about the usefulness of opt-in bars, as user tends to say yes
08:09:59 <fjh> anne: geolocation bar is viewed as a failure, either click yes, or ignore
08:10:08 <marengo> .. user are likely to be flooded by questions
08:10:49 <marengo> .. global decisions might work better
08:11:03 <Wuk> Present+ Wuk_Kim
08:11:18 <fjh> zakim, who is here?
08:11:18 <Zakim> sorry, fjh, I don't know what conference this is
08:11:19 <Zakim> On IRC I see seungjae, Claes, callie, kensaku, anne, Wuk, youenn, hendry, wuj, aizu, jun, AnssiK, Johnson, Suresh, richt, YounSung, nwidell, Kangchan, cmarc, maoteo, darobin,
08:11:22 <Zakim> ... jgiraud, Zakim, RRSAgent, lgombos_w, fjh, ingmar, marengo, myakura, wmaslowski, lgombos, trackbot, ilkka, dom
08:11:23 <fjh> zakim, this is dap
08:11:29 <Zakim> sorry, fjh, I do not see a conference named 'dap' in progress or scheduled at this time
08:11:34 <shepazu> shepazu has joined #dap
08:11:45 <marengo> darobin: does it make sense to request permissions for mutiple things at once
08:11:51 <wonsuk> wonsuk has joined #dap
08:11:54 <danielcoloma> danielcoloma has joined #dap
08:12:03 <fjh> q?
08:12:06 <fjh> ack richt
08:12:15 <danielcoloma> Present+ Daniel_Coloma
08:12:17 <drogersuk> drogersuk has joined #dap
08:12:29 <marengo> richt: have you considered 'default-allow' policy
08:12:41 <marengo> .. and users can revoke permissions instead of granting
08:13:23 <Suresh> q+
08:13:43 <marengo> fjh: ok to present decisions as part of the workflow, but it must be clear that privacy is taken into account
08:14:08 <dom> [David Rogers informs me that he and other from WAC will join us hopefully soon]
08:14:30 <dom> q?
08:15:30 <fjh> q+ to ask more about UI
08:15:48 <fjh> ack suresh
08:16:01 <dom> q+ to ask about consensus on checkPermissions()
08:16:30 <marengo> Suresh: that seems to be indipendent from our work, how is it related?
08:16:43 <richt> richt: I don't necessarily agree with bringing a generic permissions interface in to DAP.
08:17:28 <marengo> dom: with this API developers can better organize their code
08:17:28 <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.
08:17:42 <marengo> anne: as they know in advance if they can use a certain feature
08:17:50 <richt> ...I prefer intergrating permissions in to the user's workflow. ala Contacts.
08:19:02 <junliao> junliao has joined #dap
08:19:24 <richt> s/user's/users
08:19:49 <Suresh> Suresh has joined #dap
08:20:04 <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 ]
08:20:32 <dom> q?
08:20:35 <dom> ack flh
08:20:38 <dom> ack fjh
08:20:38 <Zakim> fjh, you wanted to ask more about UI
08:20:38 <fjh> ack fjh
08:20:43 <fjh> ack dom
08:20:43 <Zakim> dom, you wanted to ask about consensus on checkPermissions()
08:21:48 <AnssiK> q+
08:22:16 <BoChen> BoChen has joined #dap
08:22:50 <fjh> ack AnssiK
08:22:54 <marengo> richt: doing permissions in dap doesn't mean we need an API for permission
08:23:14 <marengo> .. in a browser, it should be part of the workflow
08:24:19 <marengo> fjh: we don't want to be intrusive, yet we have to consider privacy
08:24:56 <marengo> .. browser extensions could be helpful to test the impact on users
08:27:19 <homata> homata has joined #dap
08:27:23 <fjh> file picker supportive of privacy
08:28:51 <marengo> fjh: with file pickers, does the user understant he's making a privacy decision (does he think about reuse, ...)
08:28:55 <dom> Zakim, ignore richt
08:28:55 <Zakim> I don't understand 'ignore richt', dom
08:29:50 <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 ]
08:29:51 <danielcoloma> is the bridge open?
08:30:09 <dom> Zakim, this will be DAP
08:30:09 <Zakim> I do not see a conference matching that name scheduled within the next hour, dom
08:30:37 <marengo> anne: users don't read dialogs, tend to ignore
08:31:30 <dom> Zakim, this will be DI
08:31:30 <Zakim> ok, dom, I see DI_(TPAC)3:00AM already started
08:32:18 <timeless_xchat> timeless_xchat has joined #dap
08:32:19 <dom> Zakim, call Rhone_1
08:32:19 <Zakim> ok, dom; the call is being made
08:32:21 <Zakim> +Rhone_1
08:32:54 <dom> Zakim, who's on the call?
08:32:54 <Zakim> On the phone I see Susana, Rhone_1
08:33:07 <dom> Zakim, Susana is really Daniel_Coloma
08:33:07 <Zakim> +Daniel_Coloma; got it
08:33:22 <fjh> Present+  Daniel_Coloma
08:38:04 <marengo> lgombos: offers to be editor of the permissions 
08:38:15 <jun> jun has joined #dap
08:38:23 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0058.html 
08:39:23 <marengo> nwidell: permissions for messaging apis. concerned by "open" subscribe permissions: apps can listen to every incoming message
08:39:33 <dom> Present+ Bryan_Sullivan
08:40:04 <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
08:40:37 <marengo> nwidell: security-wise, filters on subscriptions could be enough
08:40:39 <bryan> bryan has joined #dap
08:40:44 <AnssiK> q+
08:41:06 <bryan> Present+ Bryan_Sullivan
08:41:21 <fjh> niklas: messaging does not seem to fit with permissions model
08:41:27 <fjh> ack AnssiK
08:41:29 <danielcoloma> q+
08:42:29 <bryan> q+
08:42:45 <marengo> dom: messaging is a good use case for parametrized permissiong, to avoid allowing apps to send messages to anyone
08:42:58 <fjh> s/permissiong/permissioning
08:43:05 <dom> q?
08:43:38 <dom> Present+ David_Rogers
08:45:07 <fjh> ack danielcoloma
08:46:03 <tlr> tlr has joined #dap
08:46:14 <nwidell> q+
08:46:56 <fjh> daniel: suggest we need parameters for permissions
08:47:08 <drogersuk> drogersuk has joined #dap
08:47:22 <fjh> ack bryan
08:47:24 <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)
08:47:26 <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).
08:47:42 <yongil_jang> yongil_jang has joined #dap
08:48:30 <dom> (sending message to all my contatcs is actually the best malware propagation techniique, it seems to me)
08:49:04 <fjh> q?
08:49:07 <fjh> ack nwidell
08:50:03 <richt> q+
08:50:04 <marengo> nwidell: for receiving, you need to support filters
08:50:06 <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
08:50:24 <wonsuk>  http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.vm-04-Oct.html
08:50:27 <danielcoloma> e.g. I always allow sending messages to a set of destination numbers because I have a flat rate for them, without prompts
08:50:40 <wonsuk> Proposal from Veronique:  http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.vm-04-Oct.html
08:50:42 <dom> danielcoloma, that's likely, but I think we need a very clear model of user interactions between starting to look into parametrizations
08:50:56 <marengo> bryan: permissions (eg for sending) might be session-based
08:51:31 <dom> q?
08:51:35 <fjh> ack richt
08:51:44 <richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0004.html
08:51:46 <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
08:52:02 <dom> not yet I'm afraid
08:52:21 <wonsuk> existing ontology which is working on after made dispositions: http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html
08:52:35 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Nov/0000.html
08:53:11 <wonsuk> diff version between existing one and Veronique's proposal: http://tinyurl.com/3y398st
08:53:22 <dom> wonsuk, I think you're posting your links in the wrong channel
08:58:15 <marengo> fjh: editors of the messaging API should read maria's proposal before the messaging session
08:59:03 <marengo> Suresh: if we agree on the functionality that we're supporting, finding agreement on permissions should be easier
08:59:19 <marengo> fjh: (messaging session is planned for tomorrow)
08:59:39 <nwidell> sending and new message subscription are in scope for v1 for messaging per London F2F discussion
09:00:11 <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
09:02:31 <dom> dom: #1 question is whether messaging API will be available outside of trusted environment
09:03:14 <AnssiK> q+
09:03:35 <fjh> e.g. widgets as trusted environment,  
09:03:46 <fjh> ack AnssiK
09:04:28 <AnssiK> we should make it clear in the spec abstract whether the spec is for "in-browser usage" or "trusted environments"
09:04:43 <dom> ISSUE: Does the messaging API fit outside of contained environments?
09:04:43 <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 .
09:05:01 <Suresh> "widgets" and "open web" - everyone i believe know widgets are indeed trusted
09:05:02 <darobin> ISSUE: Find a better name for "trusted environments"
09:05:02 <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 .
09:07:04 <fjh> model is trusted environment, via widgets or via trusted computing platform or .etc
09:07:13 <nwidell> "curated environment"
09:09:10 <LauraA> LauraA has joined #dap
09:09:43 <jmarting> jmarting has joined #dap
09:10:14 <Suresh> q+
09:10:49 <richt> q+
09:10:55 <marengo> drogersuk: the container could be a browser, what's different is the mediation in accessing the APIs
09:11:09 <dom> ack Suresh
09:11:12 <fjh> q+ to ask about mailto versus javascript 
09:11:14 <bryan> q+
09:11:16 <jmarting> Present+ Jesus_Martin
09:11:21 <andreip> andreip has joined #dap
09:11:26 <fjh> zakim, who is here?
09:11:26 <Zakim> On the phone I see Daniel_Coloma, Rhone_1
09:11:27 <Zakim> On IRC I see andreip, jmarting, LauraA, yongil_jang, drogersuk, tlr, bryan, jun, homata, BoChen, Suresh, junliao, danielcoloma, wonsuk, seungjae, Claes, callie, kensaku, anne, Wuk,
09:11:31 <Zakim> ... youenn, hendry, wuj, aizu, AnssiK, Johnson, richt, YounSung, nwidell, Kangchan, cmarc, maoteo, darobin, jgiraud, Zakim, RRSAgent, lgombos_w, fjh, ingmar, marengo, myakura,
09:11:33 <Zakim> ... wmaslowski, lgombos, trackbot, ilkka, dom
09:12:22 <marengo> dom: if the widget loads an iframe from the web, can the iframe access the "contained enviroment"-only apis?
09:12:40 <shepazu> shepazu has joined #dap
09:12:47 <fjh> ack richt
09:12:51 <dom> q+ dom
09:13:06 <Zakim> +[Vodaphone]
09:13:25 <marengo> richt: againts the distinction between "web" and "curated environment"
09:13:59 <drogersuk> q+
09:14:02 <fjh> ack fjh
09:14:02 <Zakim> fjh, you wanted to ask about mailto versus javascript
09:14:06 <hendry> +1 Web APIs
09:14:09 <nwidell> q+
09:14:09 <dom> q+ to propose that we actually remain fuzzy and say "this API is not expected to be used in general outside of pre-established trust relationships, such as in widgets"
09:14:10 <LauraA> zakim, +[Vodaphone] is LauraA
09:14:11 <Zakim> sorry, LauraA, I do not recognize a party named '+[Vodaphone]'
09:14:20 <tlr> zakim, [Vodafone] is LauraA
09:14:20 <Zakim> sorry, tlr, I do not recognize a party named '[Vodafone]'
09:14:24 <AnssiK> +1 for Web APIs too
09:14:28 <tlr> zakim, [Vodaphone] is LauraA
09:14:28 <Zakim> +LauraA; got it
09:15:23 <marengo> fjh: use case. a website wants to send a mail/sms -> why should it use the messaging API instead of mailto:, smsto:?
09:16:14 <nwidell> we have discussed this one year ago (early version of spec contained text on this)
09:17:00 <fjh> q?
09:17:04 <fjh> ack bryan
09:17:08 <dom> ack bryan
09:17:34 <dom> q-
09:17:39 <marengo> bryan: widgets = packaging model for web applications. the api should be the same. the security model should be the same
09:17:50 <drogersuk> I agree with Bryan - the API and security model should be consistent across environments
09:17:59 <richt> +1 to bryan
09:18:05 <hendry> +1 to bryan
09:19:09 <fjh> q+ to ask about policy
09:19:15 <fjh> ack drogersuk
09:19:19 <fjh> ack nwidell
09:19:34 <timeless_xchat> timeless_xchat has joined #dap
09:19:54 <fjh> ack fjh
09:19:54 <Zakim> fjh, you wanted to ask about policy
09:20:45 <Suresh> q+
09:20:45 <noah> noah has joined #dap
09:21:51 <Zakim> +??P5
09:22:07 <tlr> zakim, I am ??P5
09:22:07 <Zakim> +tlr; got it
09:22:08 <tlr> zakim, mute me
09:22:08 <Zakim> tlr should now be muted
09:23:00 <igarashi> igarashi has joined #dap
09:23:09 <marengo> drogersuk: even in a browser environment, mediation is needed
09:23:11 <bryan> q+
09:23:48 <dom> PROPOSED RESOLUTION: we only work on API functionalities that we know how to offer in the classical browser environment
09:24:32 <richt> +1 to resolution
09:24:39 <bryan> what does "that we know how to offer in the classical browser environment" mean?
09:24:44 <dom> q?
09:24:49 <darobin> +1 to resolution (speaking personally and not for Robineko)
09:25:05 <richt> "that we know how to offer in the classical browser environment" = "that work on the web"
09:25:12 <timeless_mbp> timeless_mbp has joined #dap
09:25:30 <darobin> "classical browser environment" == "that work with the default user-agent policy"
09:25:32 <dom> (richt, probably; but I think we should be explicit to make sure people understand what this means)
09:25:55 <timeless> Present+ timeless
09:26:21 <bryan> can the "default user-agent policy" be vendor-specific?
09:26:24 <dom> Present+ Rigo_Wenning
09:26:31 <fjh> q?
09:26:41 <dom> q+ richt
09:26:58 <fjh> ack Suresh
09:27:07 <timeless> RRSAgent, make minutes
09:27:07 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html timeless
09:28:08 <darobin> *** timecheck ***
09:28:21 <drogersuk> q+
09:29:00 <marengo> Suresh: by focusing on classical web enviroment only we could be very limited in offering new functionalities
09:29:20 <marengo> .. that means only a few people will use it
09:30:23 <marengo> fjh: it would be useful to discuss this with TAG
09:30:37 <drogersuk> We're only limited if no responsibility is taken for mediating the access that API has (controlled by the user)
09:32:05 <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
09:32:45 <richt> hates the word 'mediating'.
09:33:09 <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
09:33:09 <bryan> such as defined in BONDI and to be deployed under WAC.
09:33:21 <fjh> ack bryan
09:33:26 <richt> q-
09:33:28 <fjh> q+ rigo
09:33:43 <drogersuk> @nwidell precisely my point
09:33:51 <fjh> securiy and privacy by design is important to our work
09:34:27 <marengo> (DAP takes a 30m break)
09:34:53 <marengo> (resuming at 11:00)
09:35:19 <Zakim> -tlr
09:35:26 <Zakim> -Daniel_Coloma
09:36:13 <Zakim> -LauraA
09:37:08 <igarashi> igarashi has joined #dap
09:37:19 <igarashi> igarashi has joined #dap
09:38:08 <yongil_jang> yongil_jang has left #dap
09:39:32 <igarashi> igarashi has joined #dap
09:43:36 <parkjy> parkjy has joined #dap
09:47:28 <junliao> junliao has joined #dap
09:49:12 <noah> noah has joined #dap
09:52:43 <fjh> zakim, who is here?
09:52:43 <Zakim> On the phone I see Rhone_1
09:52:44 <Zakim> On IRC I see noah, junliao, parkjy, timeless, shepazu, jmarting, LauraA, drogersuk, tlr, jun, homata, BoChen, Suresh, danielcoloma, wonsuk, seungjae, Claes, kensaku, anne, Wuk,
09:52:49 <Zakim> ... youenn, hendry, wuj, AnssiK, Johnson, richt, YounSung, Kangchan, cmarc, maoteo, darobin, jgiraud, Zakim, RRSAgent, lgombos_w, fjh, ingmar, myakura, wmaslowski, lgombos,
09:52:51 <Zakim> ... trackbot, ilkka, dom
09:54:07 <fjh> rrsagent, generate minutes
09:54:07 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html fjh
09:56:11 <Zakim> +LauraA
09:57:58 <marengo> marengo has joined #dap
10:01:19 <yongil_jang> yongil_jang has joined #dap
10:04:53 <ingmar> scribe: ingmar
10:04:58 <ingmar> scribenick: ingmar
10:05:51 <noah> noah has joined #dap
10:05:52 <bryan> bryan has joined #dap
10:06:22 <noah> Present: Noah Mendelsohn
10:06:57 <aizu> aizu has joined #dap
10:07:01 <ingmar> TOPIC: 7) Security, Privacy and Policy Roadmap Discussion, Extensibility points (includes TAG)
10:07:10 <dom> s/Present:/Present+/
10:07:41 <callie> callie has joined #DAP
10:08:15 <dom> RRSAgent, draft minutes
10:08:15 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html dom
10:08:54 <ingmar> fjh: where we are at the privacy discussion: our group is called "Device API AND Policy", defining JavaScript-APIs to access the device
10:09:20 <ingmar> ... we are discussing different environments, such as widgets and the open web
10:10:00 <ingmar> ... if you have to write a policy, where does it come from when we focus on the web case for a moment
10:10:07 <DKA> DKA has joined #dap
10:10:26 <DKA> present +DKA
10:10:28 <nwidell> nwidell has joined #dap
10:10:45 <ingmar> ... privacy is difficult, some issues need to be handled at the client, such as minimization
10:11:33 <dom> s/present +/present+ /
10:11:44 <wuj> present+Jing Wu
10:12:15 <ingmar> ... also discussed to convei user consent to the server (PPP)
10:12:50 <dom> q?
10:13:08 <ingmar> ... another discussion is about the model, should we focus on the open web?
10:13:23 <dom> [I think we have already started addressing privacy in our work]
10:13:40 <ingmar> ... re privacy, how much impact could we have on the server side
10:13:47 <jorlow> jorlow has joined #dap
10:14:10 <ingmar> ... it is not clear whether privacy will be implemented
10:14:40 <dom> s/privacy will be implemented/the current privacy proposals have buy-in from implementors/
10:15:27 <DKA> q?
10:15:28 <DKA> q+
10:16:00 <drogersuk> q-
10:16:16 <DKA> q-
10:16:48 <andreip> andreip has joined #dap
10:17:02 <ingmar> fjh: re privacy, we walked through all the APIs on whether what is really necessary in terms of simplification and minimization
10:17:19 <DKA> q+ to ask about lessons learned from Geolocation wg (at and post London workshop)
10:17:23 <DKA> q?
10:17:39 <jun> jun has joined #dap
10:17:55 <ingmar> ... in terms of user consent, we try to use the model to get implicit permission by using pickers
10:18:43 <ingmar> ... but it is sometimes difficult to know on whether the user knows about the implications
10:19:06 <ingmar> darobin: <describes address book use case>
10:19:09 <soonho> soonho has joined #dap
10:19:39 <ingmar> ... user can select multiple contacts and define on particular fields
10:19:50 <ingmar> s/define/decide
10:19:54 <bryan> q+
10:21:32 <fjh> http://dev.w3.org/2009/dap/privacy-rulesets/
10:21:49 <ingmar> noah: <describes the role of the TAG>
10:23:23 <ingmar> DKA: question re the priv workshop in London: what learnings have been taken into the DAP work?
10:25:36 <ingmar> fjh: we learned that implementers only implement something if there is a clear value
10:25:51 <richt> q+
10:26:59 <dom> (the privacy rulesets have the set of issues that have been identified)
10:27:14 <dom> s/rulesets/rulesets draft/
10:30:28 <ingmar> noah: should we keep in touch on that on a regular basis, let say every few month?
10:30:32 <Wuk> Wuk has joined #DAP
10:30:49 <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.
10:31:15 <richt> q-
10:31:25 <DKA> q-
10:32:23 <ingmar> dom: re minimization, means that the APIs are designed that you only get back what you requested
10:34:56 <noah> I'm hoping there will be time to get to extensibility later in this session.
10:37:17 <ingmar> rigo: when it comes to sharing addresses of your friends you are in a different role (service provider)
10:37:39 <fjh> q?
10:38:49 <drogersuk> q+
10:39:36 <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
10:39:38 <fjh> ack rigo
10:40:28 <ingmar> rigo: talks about the geopriv proposal, asks about TAGs position
10:40:45 <drogersuk> @hendry - human decision though
10:41:37 <ingmar> DKA: thinks that geopriv is off the table meanwhile
10:42:01 <ingmar> ... we should more talk about the CDT proposal
10:42:08 <drogersuk> Privacy is context specific. We cannot define context
10:42:43 <noah> q+ to explain my interests in extensibility
10:43:07 <Claes>  So we can only design access control but not implement "Privacy by design"?
10:43:19 <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
10:43:19 <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
10:43:20 <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.
10:43:45 <tlr> tlr has joined #dap
10:43:59 <fjh> q?
10:44:08 <fjh> ack bryan
10:44:52 <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.
10:45:18 <richt> ...instead we use the concept of Privacy by Design in the Device APIs with things like data minimization
10:45:19 <ingmar> noah: the TAG is not about UI design, we can not judge this
10:45:20 <drogersuk> device apis do need user protection though
10:45:30 <drogersuk> by policy or other means
10:45:47 <richt> drogers, we use a concept of Privacy by Design.
10:46:36 <richt> ...with the user at the centre of the decision making process.
10:47:03 <ingmar> drogersuk: the TAG can help to incorporate browser vendors, we need a dialog
10:47:40 <ingmar> fjh: we would like to have TAGs input on extensibility
10:48:48 <ingmar> noah: DAP is defining JS-APIs, there are interesting questions about extensibility, especially re privacy
10:48:54 <Suresh> Bryan has a good point about usability and user choice...it seems to be an issue that we often face in the group.
10:49:07 <YounSung> YounSung has joined #dap
10:49:09 <ingmar> ... one way to look at extensibility is adding functions to the API
10:49:14 <arve> arve has joined #dap
10:50:34 <ingmar> ... there is a "must understand" model in defining messages
10:50:41 <ingmar> ... this could be used for APIs
10:51:57 <ingmar> fjh: API versioning is another option
10:51:58 <SGondo> SGondo has joined #dap
10:52:57 <ingmar> annsik: is there some prior art where extensibility has been done right?
10:53:37 <fjh> q?
10:54:09 <ingmar> noah: not aware of something in the security and privacy area
10:54:14 <drogersuk> q-
10:54:45 <fjh> http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/
10:54:53 <Suresh> q+
10:55:12 <fjh> ack noah
10:55:12 <Zakim> noah, you wanted to explain my interests in extensibility
10:55:29 <ingmar> DKA: the minimization topic could be amplified by the TAG
10:55:54 <bryan> q+
10:56:00 <fjh> ack Suresh
10:56:23 <richt> q+
10:56:24 <hendry> AnssiK: HTML is the best example I could think of wrt extensibility
10:56:47 <dom> [as input for guidelines on APIs, we have started noting some patterns in http://www.w3.org/2009/dap/wiki/ApiCheckList ]
10:59:02 <AnssiK> s/annsik/AnssiK/
10:59:48 <Kangchan> Kangchan has joined #dap
11:00:24 <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.
11:00:26 <fjh> ack bryan
11:00:40 <dom> s/Anssik:/Anssik,/
11:01:24 <fjh> ack richt
11:01:27 <noah> q+ to respond to bryan
11:02:00 <ingmar> richt: why are the browser vendors not here? The TAG can certainly help to involve them.
11:02:02 <hidetaka> hidetaka has joined #dap
11:02:54 <ingmar> ... there is a fundamental disagreement in the group between "APIs and Privacy" and "Policy"
11:03:35 <tlr> q+ rigo
11:03:40 <ingmar> richt: we should split the two discussions, possibly considering rechartering
11:04:05 <Claes> +1 for addressing the issue of browser vendors (except Opera) not in this WG
11:05:39 <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.
11:07:53 <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
11:08:23 <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 model
11:09:05 <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
11:09:15 <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
11:09:15 <Suresh> We see to be mixing up everything all the time unless i'm the only confused! 
11:09:49 <dom> drogersuk, the TAG can't do a thing about bringing browser vendors; we as a group need to convince them
11:10:04 <dom> (which includes listening to their concerns)
11:10:37 <junliao> junliao has joined #dap
11:10:38 <drogersuk> Noah said that the TAG would facilitate the dialogue. That's what I mean
11:10:41 <richt> dom, I'm not taking part and have never taken part in the policy discussions in this 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. 
11:11:10 <darobin> we've had the splitting discussion before....
11:11:11 <drogersuk> @richt - you will, you will :-)
11:11:36 <darobin> of course, if all we define is APIs that are websafe, how much policy is left to discuss? </troll>
11:11:54 <dom> 10 glazman points for darobin
11:12:22 <noah> The TAG on why declarative languages are good: http://www.w3.org/2001/tag/doc/leastPower.html
11:12:40 <dom> Zakim, who's on the phone?
11:12:40 <Zakim> On the phone I see Rhone_1, LauraA
11:14:37 <Zakim> -LauraA
11:17:11 <fjh> rrsagent, generate minutes
11:17:11 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html fjh
11:17:28 <wonsuk> wonsuk has left #dap
11:20:10 <SGondo> SGondo has joined #dap
11:22:47 <SGondo> SGondo has joined #dap
11:26:06 <AnssiK> AnssiK has joined #dap
11:57:49 <timeless_mbp> timeless_mbp has joined #dap
12:02:01 <myakura> myakura has joined #dap
12:24:53 <jun> jun has joined #dap
12:31:58 <kensaku> kensaku has joined #dap
12:36:50 <fjh> fjh has joined #dap
12:38:54 <marengo> marengo has joined #dap
12:39:32 <Zakim> -Rhone_1
12:39:33 <Zakim> DI_(TPAC)3:00AM has ended
12:39:35 <Zakim> Attendees were Rhone_1, Daniel_Coloma, LauraA, tlr
12:40:22 <jorlow> jorlow has joined #dap
12:40:53 <andreip> andreip has joined #dap
12:41:18 <myakura> myakura has joined #dap
12:41:37 <andreip> andreip has left #dap
12:41:47 <andreip> andreip has joined #dap
12:43:46 <lgombos_> lgombos_ has joined #dap
12:44:44 <timeless_mbp> timeless_mbp has joined #dap
12:46:54 <wonsuk> wonsuk has joined #dap
12:48:21 <yongil_jang> yongil_jang has joined #dap
12:51:04 <pauld> pauld has joined #dap
12:53:44 <SGondo> SGondo has joined #dap
12:53:46 <AnssiK> AnssiK has joined #dap
12:54:46 <timeless_mbp> timeless_mbp has joined #dap
12:54:48 <Kangchan> Kangchan has joined #dap
12:56:06 <freedom> freedom has joined #dap
12:57:50 <shepazu> shepazu has joined #dap
12:58:23 <drogersuk> drogersuk has joined #dap
12:58:31 <YounSung> YounSung has joined #dap
12:58:37 <timeless> Scribe: timeless 
12:59:54 <soonho> soonho has joined #dap
13:00:32 <freedom> freedom has joined #dap
13:00:54 <dsr> dsr has joined #dap
13:01:04 <dsr> present +dsr
13:01:10 <junliao> junliao has joined #dap
13:01:10 <nwidell> nwidell has joined #dap
13:01:10 <kensaku> kensaku has joined #dap
13:01:11 <aizu> aizu has joined #dap
13:01:12 <francois> francois has joined #dap
13:01:13 <Suresh> Suresh has joined #dap
13:01:14 <bochen> bochen has joined #dap
13:01:32 <junliao> Jun Liao from China Unicom
13:01:41 <fjh> TOPIC: WAC
13:01:41 <Dong-Young_Lee> Dong-Young_Lee has joined #dap
13:01:52 <Dong-Young_Lee> Presnt+ Dong-Young_Lee
13:01:53 <cmarc> cmarc has joined #dap
13:01:53 <fjh> David Rogers introducing WAC update
13:01:55 <dom> Present+ Jun_Liao
13:02:02 <dsr> [dsr = Dave Raggett/W3C Team]
13:02:07 <Dong-Young_Lee> Present+ Dong-Young_Lee
13:02:11 <jmarting> jmarting has joined #dap
13:02:22 <timeless> RRSAgent, make minutes
13:02:22 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html timeless
13:02:24 <anne> anne has joined #dap
13:02:26 <dom> s/ +dsr/+ Dave_Raggett/
13:02:52 <freedom_> freedom_ has joined #dap
13:02:56 <Claes> Claes has joined #dap
13:03:14 <Wuk> Wuk has joined #DAP
13:03:45 <fjh> (slides will be available later)
13:04:52 <fjh> zakim, who is here?
13:04:52 <Zakim> apparently DI_(TPAC)3:00AM has ended, fjh
13:04:53 <Zakim> On IRC I see Wuk, Claes, freedom, anne, jmarting, cmarc, Dong-Young_Lee, bochen, Suresh, francois, aizu, kensaku, nwidell, junliao, dsr, soonho, YounSung, drogersuk, shepazu,
13:04:57 <Zakim> ... Kangchan, timeless, AnssiK, SGondo, pauld, yongil_jang, wonsuk, lgombos_, andreip, jorlow, marengo, fjh, jun, arve, LauraA, danielcoloma, hendry, richt, Zakim, RRSAgent,
13:05:00 <Zakim> ... ingmar, wmaslowski, lgombos, trackbot, ilkka, dom
13:05:04 <noah> noah has joined #dap
13:05:08 <fjh> zakim, this will be DI
13:05:08 <Zakim> fjh, Team_(mediaann)09:00Z is already associated with an irc channel; use 'move DI to here' if you mean to reassociate the channel
13:05:19 <dom> Zakim, this is DI
13:05:19 <Zakim> dom, Team_(mediaann)09:00Z is already associated with an irc channel; use 'move DI to here' if you mean to reassociate the channel
13:05:25 <dom> Zakim, move DI to here
13:05:26 <Zakim> ok, dom; that matches Team_(mediaann)09:00Z
13:05:41 <callie> callie has joined #DAP
13:05:45 <dom> zakim, this is DI_(TPAC)
13:05:45 <Zakim> dom, I see DI_(TPAC)3:00AM in the schedule but not yet started.  Perhaps you mean "this will be DI_(TPAC)".
13:05:50 <dom> zakim, this will be DI_(TPAC)
13:05:50 <Zakim> ok, dom; I see DI_(TPAC)3:00AM scheduled to start 365 minutes ago
13:06:48 <youenn> youenn has joined #dap
13:06:51 <jgiraud> jgiraud has joined #dap
13:07:39 <homata> homata has joined #dap
13:07:48 <bryan> bryan has joined #dap
13:08:07 <bryan> Present+ Bryan_Sullivan;
13:08:13 <Zakim> DI_(TPAC)3:00AM has now started
13:08:17 <dsr> WAC: http://www.wholesaleappcommunity.com/default.aspx
13:08:53 <danielcoloma> can you please open the bridge?
13:08:58 <bochen> Present+ Bo_Chen
13:09:13 <tlr> tlr has joined #dap
13:09:20 <maoteo> maoteo has joined #dap
13:09:27 <dom> Zakim, call Rhone_1
13:09:27 <Zakim> ok, dom; the call is being made
13:09:27 <fjh> zakim, call rhone_1
13:09:29 <Zakim> ok, fjh; the call is being made
13:09:56 <maoteo> Present+ Maria_Oteo
13:10:15 <danielcoloma> Present+ Daniel_Coloma
13:10:25 <hidetaka> hidetaka has joined #dap
13:11:05 <timeless_mbp> timeless_mbp has joined #dap
13:12:29 <danielcoloma> Public spec URL: http://public.wholesaleappcommunity.com/redmine
13:13:46 <Kangchan> -> http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/   WAC Waikiki Developer Release Specification
13:14:16 <timeless> bryan: app launcher has been reduced in the current release to URI schemes ...
13:14:24 <timeless> ... and a specification of how to launch the browser
13:14:33 <timeless> ... which from the widget perspective is not always clear in everyone's mind
13:14:48 <timeless> ... the ability to launch an arbitrary application has been reserved for a future release
13:14:52 <nwidell> Present+ Niklas_Widell
13:15:03 <freedom> Present+ Koan-Sin_Tan
13:15:15 <darobin> darobin has joined #dap
13:15:27 <Claes> Present+ Claes_NIlsson
13:15:37 <timeless> darobin: are you suggesting we provide such an api later (as opposed to sooner)?
13:15:37 <jiyong_park> jiyong_park has joined #dap
13:16:07 <timeless> bryan: the app launcher proposal has additional use cases which are not satisfied by simple URI schemes
13:16:09 <darobin> s/are you suggesting we provide such an api later (as opposed to sooner)?/from a WAC perspective, do you think we should follow a similar approach to AppLauncher in DAP?/
13:16:32 <timeless> DR: ... one other area...
13:16:47 <timeless> ... we have our default policy, which explains how we think certain prompting should be allowed/not allowed
13:17:01 <Johnson> Johnson has joined #dap
13:17:02 <timeless> ... we'll upload our example policy to our web site
13:17:16 <timeless> ... it can be tweaked...
13:17:22 <aizu> Present+ Hiroyuki_Aizu
13:17:25 <timeless> ... we'll have a standard default policy that people can take
13:17:32 <timeless> ... and we'll have a child aware parental policy
13:17:42 <timeless> ... which will lock down Geolocation and maybe camera
13:17:44 <Johnson> Present+ Johnson_W
13:17:48 <timeless> ... it's fairly new
13:17:57 <timeless> ... something for parents to use to somehow protect their children
13:18:06 <timeless> ... any questions?
13:18:14 <wuj> wuj has joined #dap
13:18:15 <timeless> fjh: you mentioned two things that were changed?
13:18:19 <timeless> ... application launcher and?
13:18:23 <timeless> DR: gallery
13:18:34 <timeless> ... it was deemed to be a subset of file api, so it was folded into that
13:18:41 <seungjae> seungjae has joined #dap
13:18:50 <timeless> ... The file system api is a subset of the real file system, it's basically virtual mounts 
13:19:09 <timeless> danielcoloma: Part of these roots include Video, Images and Sounds
13:19:16 <timeless> ... those covered the use cases for Gallery
13:19:28 <timeless> Suresh: you use terms like untrusted
13:19:32 <timeless> ... which we discussed earlier
13:19:49 <timeless> ... what is the characterization, how do you use them in WAC?
13:20:10 <timeless> DR: as in mobile devices, there is a provision to map onto Digital Signatures as in Widgets
13:20:51 <timeless> ... The publisher ID is verifiable ("class 2")
13:21:15 <timeless> ... getting a WAC seal of approval enables more api access
13:21:25 <timeless> Suresh: can you relate this with the discussions from earlier?
13:21:32 <timeless> ... does open web fall into one of these categories?
13:21:43 <timeless> DR: the example i wanted to highlight is the Browser vs. Widget model
13:21:47 <timeless> ... if we do use Geolocation
13:22:01 <timeless> ... the mozilla mobile application, Fennec
13:22:25 <timeless> ... when a site prompts and is confirmed 5 times, the affirmation becomes permanent
13:22:33 <timeless> ... and it isn't prompted for again
13:22:46 <timeless> ... There isn't much difference between that model and ...
13:23:00 <timeless> ... You still need to get the user to make some kind of decision.
13:23:13 <dsr> [I note that WAC specs cover accelerometer, which has also been discussed in W3C geloc lists]
13:23:15 <timeless> ... And there might just be terminology differences
13:23:26 <timeless> ... Wakiki ?
13:23:53 <timeless> ... When we started doing BONDI. We envisioned that Charities or AV vendors might want to implement Policies and trust
13:24:09 <timeless> ... The reason we provided a default policy, was that we felt some implementers wouldn't know what to start with
13:24:28 <timeless> ... Unlike a firewall where things break surprisingly
13:24:38 <timeless> ... Our APIs return a response indicating policy rejection
13:24:51 <timeless> ... Our target is Barcelona (Mobile World Congress)
13:25:15 <timeless> ... We recognize that developers are the heart of this. Without listening to developers, there will be no applications in the app stores
13:25:25 <timeless> ... So it's necessary to help seed things
13:25:44 <timeless> ... People may sneer at SDKs, but the majority of people can't write applications with just Notepad++
13:25:53 <timeless> ... We want to make writing applications as easy as possible
13:26:00 <timeless> ... We want to work very closely with W3C
13:26:15 <timeless> ... We've already made a clear statement that we endorse W3C specifications
13:26:20 <timeless> ... We'd like to have regular meetings
13:26:27 <timeless> [ DR is reading a slide ]
13:26:43 <timeless> [ Slide 17 ]
13:27:12 <timeless> DR: Questions?
13:27:36 <timeless> Claes: When it comes to the type of application you intend to provide with WAC
13:27:44 <timeless> ... are you intend to do some differentiation because ...
13:27:56 <dsr> q+ to ask about relation between WAC accelerometer spec and Geoloc device orientation event spec
13:27:57 <timeless> ... one argument for WAC is that you can make applications that are platform independent
13:28:11 <timeless> ... but you still have to compete with [Apple] AppStore and 
13:28:17 <timeless> ... Android Market
13:28:26 <timeless> DR: so you're asking "what's the killer app for WAC?"
13:28:31 <timeless> ... but that's not your question
13:28:36 <timeless> ... The value is the long term
13:28:53 <timeless> ... People who are using iPhones are a tiny proportion of all mobile users in the world
13:29:05 <timeless> ... We have a vendor in the Philippines 
13:29:14 <timeless> ... They were using SMS for applications
13:29:23 <fjh> ack dsr
13:29:23 <Zakim> dsr, you wanted to ask about relation between WAC accelerometer spec and Geoloc device orientation event spec
13:29:29 <timeless> ... So it's kind of like moving from DOS to Windows
13:29:38 <SGondo> SGondo has joined #dap
13:29:38 <timeless> ... This stack makes it very easy to go to HTML5
13:29:51 <timeless> ... The native application space could be very easily embraced in WAC
13:29:59 <timeless> ... We're open to them, and it's under study
13:30:14 <timeless> dsr: The relationship between WAC and W3C specs..?
13:30:30 <timeless> ... I saw Accelerometer which is under study in Geolocation
13:30:43 <timeless> DR: danielcoloma did you want to talk about Accelerometer in W3C
13:30:50 <hendry> http://dev.w3.org/geo/api/spec-source-orientation.html
13:31:01 <timeless> danielcoloma: We don't believe the W3C draft is stable enough
13:31:12 <timeless> fjh: so you're saying you will use it when it's stable?
13:31:21 <timeless> danielcoloma: The target is MWC2011
13:31:32 <timeless> ... which is before the W3C spec would be ready
13:31:41 <timeless> [ so they needed their own in the interim ]
13:31:51 <dsr> Geloc DeviceOrientation spec http://dev.w3.org/geo/api/spec-source-orientation.html
13:31:52 <timeless> Topic: Continuation of Permissions Discussion
13:32:18 <hendry> versus http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/deviceapis/accelerometer.html
13:32:57 <timeless> q?
13:33:36 <timeless> Suresh: if you take the presentation from WAC
13:33:43 <timeless> ... and put in the mix of discussions in this group
13:33:48 <timeless> ... there's a lot of overlap
13:34:03 <timeless> ... I think we need to start with some sort of architecture. what falls in what.
13:34:09 <timeless> ... which parts can be separated out
13:34:14 <timeless> ... Security has various things, signing
13:34:19 <Claes> q+
13:34:26 <timeless> ... Versus getting permission to do some thing
13:34:27 <darobin> q?
13:34:47 <igarashi> igarashi has joined #dap
13:34:51 <fjh> suresh asks for clear architecture picture, and clear requirements
13:35:11 <timeless> Suresh: on the one hand, we're asked to bake Security and Privacy into the API
13:35:21 <timeless> ... In WAC, they have some kind of default policy
13:35:26 <timeless> ... you prompt the user, or you don't prompt
13:35:43 <timeless> ... In our case, we have an example with Geolocation where the suggestion is prompt the user
13:35:57 <timeless> ... What are we trying to achieve in putting security into the APIs?
13:36:09 <timeless> darobin: The goal is to not create security/privacy issues
13:36:14 <timeless> ... when running in the Same Origin model
13:36:25 <timeless> ... What it implies is integrating with a user understandable workflow
13:36:35 <timeless> ... You click on something, and get a contact picker
13:36:44 <timeless> ... People aren't fooled when they click on a file upload button
13:36:54 <timeless> ... They understand that they're giving file info to the web site
13:37:13 <timeless> ... Similarly, with Geolocation, whenever there's a security boundary, you make it asynchronous
13:37:24 <timeless> ... It might talk to a permission server, or call someone up
13:37:25 <bryan> q+
13:37:42 <timeless> ... If we go to a model, where the only API specs we release work with a model
13:37:48 <timeless> s/model/approach/
13:38:07 <timeless> ... preferably where there's a model that doesn't result in 7 infobars
13:38:40 <timeless> ... For new features, it means we might mean we need to delay things
13:38:51 <timeless> ... until we know how to expose it in a safe manner
13:39:20 <timeless> Suresh: you mentioned a workflow the user could understand
13:39:35 <timeless> ... the user has to pick what it wants
13:39:48 <timeless> darobin: we define an interface such that you can build a UI that we think is correct
13:40:02 <timeless> ... If you want to build a different model, or you want to say screw the security model
13:40:09 <timeless> ... I want to return all the contacts
13:40:12 <timeless> ... that's fine.
13:40:20 <timeless> ... Taking the contacts example
13:40:30 <timeless> ... If you want to allow for selecting an item, that's ok.
13:40:45 <timeless> ... But if you want to provide a way to allow a widget to allow access to all contacts, that's ok.
13:40:53 <Claes> DAP has createt this draft that is defining 3 basic use cases: http://dev.w3.org/2009/dap/policy-reqs/#normative-references
13:40:56 <timeless> Suresh: someone could use our contacts API to do both of those
13:41:00 <timeless> darobin: that's our point
13:41:12 <timeless> ... it works in Browser or a more powerful Widget
13:41:24 <timeless> ... The exact same code would work in both places
13:41:30 <timeless> Suresh: taking this model, you could do it safely
13:41:35 <timeless> ... Save and Delete are not safe
13:41:56 <timeless> [ darobin described how to select one, or select * - for selecting contacts ]
13:42:06 <timeless> Suresh: you could have checkboxes to do save/delete
13:42:09 <timeless> darobin: it's possible.
13:42:24 <timeless> ... the issue with Delete is the problem of how to define a metaphor
13:42:35 <timeless> ... because there's no matching metaphor in the browser interface for deleting something
13:42:42 <timeless> Suresh: the browser could throw up a dialog
13:42:57 <timeless> darobin: the browser does for deleting cookies, but that isn't from the web page
13:43:09 <timeless> ... we can find this, those things are harder to do
13:43:23 <timeless> ... you could prioritize Reading, and 6 months later make a Writing API
13:43:32 <timeless> Suresh: no matter how you solve permissions / user prompts
13:43:48 <timeless> ... you need those apis to do the reading/writing
13:44:12 <timeless> ... there's an api no matter which ui paradigm you take
13:44:25 <timeless> q?
13:44:31 <dom> q+ richt
13:44:37 <timeless> ack Claes 
13:44:50 <timeless> Claes: we have been working on a document
13:44:59 <timeless> ... Device API access control use cases
13:45:08 <timeless> ... that states 3 basic use cases for Access Control
13:45:15 <timeless> ... we made some conclusions when we made that document
13:45:20 <timeless> ... i'm not sure if we're going to discuss that
13:45:31 <timeless> darobin: the idea is to finish it
13:45:37 <timeless> Claes: i think it's quite simple
13:45:45 <timeless> ... all apis must be usable in an untrusted environment
13:45:53 <timeless> ... and in addition, if i have a trusted authority
13:46:05 <timeless> ... we should provide a way for it to work without as much user interaction
13:46:20 <timeless> darobin: In a non chair view,
13:46:25 <timeless> q?
13:46:32 <fjh> ack bryan
13:46:49 <timeless> bryan: that we need to find a model that works makes perfect sense
13:46:59 <timeless> ... managing file systems...
13:47:06 <timeless> ... I think people understand those things
13:47:20 <timeless> ... The important things is that when a user allows for things to occur
13:47:26 <timeless> ... is an important decision
13:47:35 <timeless> ... When the user says "yeah, i trust you"
13:47:42 <timeless> ... the point is that it's persistent
13:47:49 <timeless> ... that could happen before they launch the widget
13:47:52 <timeless> ... or application
13:48:02 <timeless> ... but the user doesn't have to make the decisions in real time
13:48:07 <timeless> ... because that could break the application
13:48:19 <timeless> darobin: I'll go one step furhter
13:48:22 <Kai> Kai has joined #dap
13:48:24 <timeless> s/furhter/further/
13:48:33 <timeless> ... we need to be even more flexible than that
13:48:44 <timeless> ... We need to enable smarter implementations
13:48:52 <timeless> .... we might have a trust delegation
13:49:01 <timeless> ... or prompt
13:49:13 <richt> q-
13:49:27 <timeless> ... The ideal model would be flexible enough to handle different implementations
13:49:29 <fjh> API orthogonal to security and privacy model
13:49:33 <fjh> ack richt
13:49:39 <timeless> richt: there's basically different levels for paradigms
13:49:46 <timeless> ... but there are a lot of apis available out there
13:49:50 <timeless> ... taking the file system apis
13:49:54 <timeless> ... [in webapps]
13:50:00 <timeless> ... you could have a service level contact book
13:50:00 <fjh> s/API/darobin: API/
13:50:03 <hidetaka_> hidetaka_ has joined #dap
13:50:08 <timeless> ... you could use IndexDB
13:50:16 <timeless> ... you could synchronize with the contacts book
13:50:21 <timeless> ... when it comes to the API design
13:50:27 <timeless> ... I think it makes sense to look at use
13:50:31 <timeless> ... instead of management
13:50:41 <timeless> ... The idea is to look out how people will use the API is what's important
13:50:45 <timeless> ... in contacts it's getting
13:50:48 <timeless> ... in calendar it's saving
13:51:14 <timeless> Suresh: I think the usage, we get into usability
13:51:22 <timeless> ... are we the experts to solve that
13:51:27 <timeless> richt: it's an ongoing dicussion
13:51:35 <timeless> ... there are different levels to address that
13:51:43 <timeless> q?
13:52:42 <timeless> [ scribe lost dom's statements ]
13:52:46 <dom> dom: this is introductory discusson on whether we want to work on APIs that require a different security model than the browser model
13:52:57 <timeless> darobin: as dom stated: do we ever want to release a specification of an api
13:53:13 <timeless> ... for which we don't know how to create a safe implementation in the browser
13:53:32 <timeless> Suresh: I think we need to create something safe. And it has to be useful
13:53:44 <timeless> ... In both environments, you could have different default states
13:53:54 <timeless> ... I get a feeling that we're being more concerned than we should be
13:54:02 <timeless> ... In the process, we're having a very minimal api
13:54:12 <timeless> darobin: I don't think we're going with minimal api
13:54:18 <timeless> ... we're shipping what we're confident we can ship
13:54:30 <timeless> ... When we ship X, we're saying we know how to implement X
13:54:44 <timeless> ... And we can do Y later, when we know how to do it
13:54:52 <timeless> ... It's about not delaying releasing X
13:54:59 <timeless> ... while we figure out Y
13:55:24 <timeless> Suresh: We talk about environment where widget environment is more trusted
13:55:36 <timeless> darobin: I don't think we want our documents to reflect a distinction
13:55:48 <timeless> ... we should make apis that work in both environments
13:55:54 <timeless> ... [ Widgets and Open Web ]
13:55:58 <drogersuk> q+
13:56:01 <darobin> q?
13:56:05 <timeless> ... We can make things that work in both environments
13:56:28 <timeless> Suresh: People are used to interacting with device
13:56:40 <darobin> q+ to talk about not two different environments but rather a large number including a default one
13:56:43 <timeless> ... in that environment, we could expose more functionality
13:56:55 <timeless> ... But in browser, we might expose less functionality
13:57:19 <timeless> ... We seem to be limiting our UI toward what might be on the Web
13:57:31 <timeless> darobin: the kind of architecture under discussion allows us to do both
13:57:34 <timeless> ... it's just more work
13:57:46 <timeless> ... because we need to find ways to expose these things that are safe in the default environment
13:58:17 <dom> q+ to mention the browser security model might become an important feature
13:58:19 <timeless> darobin: If we need to make everything work in both worlds with the same functionality, it is harder to do safely
13:58:29 <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
13:58:30 <timeless> ... It might delay things, but I think it's the more powerful path
13:59:04 <timeless> Suresh: a lot of where we're getting stuck is the UI paradigm
13:59:17 <timeless> richt: I don't believe we can separate the layers
13:59:25 <darobin> ack drogersuk 
13:59:28 <jorlow> jorlow has joined #dap
13:59:39 <jorlow_> jorlow_ has joined #dap
13:59:53 <timeless> drogersuk: we have a consensus
13:59:57 <timeless> ... that we need common APIs
14:00:05 <timeless> ... and we understand that these APIs are sensitive
14:00:12 <fjh> is your point, drogersuk, that policy framework is an implementation decision and aspect?
14:00:20 <timeless> ... the key question lies around, us saying that if you use this api, you have to use security
14:00:31 <timeless> ... In our environment, in the widget world, we say you use policy
14:00:48 <dom> fjh, I like your characterization of david's point
14:00:55 <timeless> ... In the browser that could be some other kind of security
14:01:02 <timeless> ... the point is that there is security for this kind of API
14:01:22 <timeless> drogersuk: (answering fjh) yes
14:01:36 <timeless> darobin: it's an obligation, but how you do it is an implementation choice
14:01:41 <timeless> ... but before we design an api
14:01:52 <timeless> ... we need to make sure it's possible to make it secure in the default web environment
14:02:06 <timeless> q?
14:02:08 <darobin> ack me
14:02:08 <Zakim> darobin, you wanted to talk about not two different environments but rather a large number including a default one
14:02:10 <darobin> ack dom 
14:02:12 <Zakim> dom, you wanted to mention the browser security model might become an important feature
14:02:24 <timeless> dom: building in security is costly
14:02:28 <timeless> ... but it's a feature
14:02:38 <timeless> ... there was a story recently about Facebook
14:02:45 <timeless> ... where it got phone numbers
14:02:49 <timeless> ... without asking the user
14:03:07 <timeless> ... I agree that we're making it more difficult to have access to features
14:03:13 <timeless> ... which seem natural in a controlled environment
14:03:21 <timeless> ... but I think we need to look at more than the cost
14:03:29 <timeless> ... to make sure we understand the benefit to the user
14:03:46 <timeless> Suresh: I'm afraid of us taking 2-3 years to come out with something that won't be useful
14:04:09 <nwidell> q+
14:04:31 <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
14:04:37 <timeless> RRSAgent, make minutes
14:04:37 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html timeless
14:04:46 <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
14:04:48 <darobin> ack nwidell 
14:04:53 <dom> PROPOSED RESOLUTION: we should focus on API features that can be implemented safely in the default browser policy model
14:05:29 <timeless> nwidell: You could have an API which has a messy UI implementation
14:05:32 <drogersuk> agree with fjh's proposal
14:05:32 <fjh> q?
14:05:39 <timeless> ... if it's useful, people will try to work to resolve the UI situation over time
14:05:57 <timeless> dom: but what you're describing ought to happen before standardization, not after
14:06:08 <timeless> ... I think the risk is that you if you try to standardize something like that
14:06:14 <timeless> ... it won't have a long duration
14:06:59 <timeless> ... I'm not sure that trying to push something early
14:07:07 <timeless> nwidell: it was to avoid having two APIs
14:08:20 <richt> dom, I agree with everything you say...at the least, +1 to your proposal :)
14:08:43 <timeless> dom: if someone wants to propose an api featuer
14:08:47 <timeless> s/featuer/feature/
14:08:59 <timeless> ... they need to explain how they expect it to work in a browser environment
14:09:06 <timeless> Suresh: can that be with policy?
14:09:08 <timeless> darobin: no
14:09:26 <timeless> Suresh: I'm not sure what you mean browser, do you mean desktop?
14:09:29 <timeless> darobin: no, it could be mobile
14:09:40 <timeless> Suresh: I'm coming from a device vendor
14:09:42 <rigo> rigo has joined #dap
14:09:47 <timeless> ... we have a focus on controlling the environment
14:09:53 <rigo> q+
14:09:54 <timeless> darobin: Suresh, if you don't think it's safe
14:10:00 <timeless> ... desktop won't think it's safe either
14:10:08 <fjh> ack rigo
14:10:16 <timeless> rigo: for this policy environment
14:10:37 <timeless> ... one of the ideas is to make it easily consumable
14:10:43 <timeless> ... the problem is making an api consumable
14:10:48 <timeless> ... the problem with an api control point
14:10:54 <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
14:10:58 <timeless> ... is that you don't have enough information coming through the api
14:11:04 <timeless> ... to enable informed consent
14:11:10 <fjh> q+ to note we left out privacy from resolution
14:11:18 <timeless> ... because you don't have enough information to warn the user if it's safe or dangerous
14:11:27 <timeless> ... the suggestion is that we somewhat express the semantics
14:11:33 <timeless> ... that give you the possibility to convey more information
14:11:39 <timeless> ... from the one requesting the information
14:11:46 <timeless> ... to the one giving the information
14:12:01 <timeless> ... so that we enable the app to provide assertions
14:12:12 <timeless> ... so the UA can provide a meaningful question
14:12:24 <timeless> ... so the user can make an informed decision
14:12:32 <timeless> ... There was a proposal at the October (?) session
14:12:38 <timeless> ... with a JSON mechanism
14:12:47 <timeless> ... which would provide a richer exchange
14:12:49 <timeless> q+ 
14:12:53 <timeless> ack fjh 
14:12:53 <Zakim> fjh, you wanted to note we left out privacy from resolution
14:12:55 <drogersuk> q+
14:13:04 <timeless> fjh: i don't disagree with that
14:13:11 <timeless> ... I think the resolution was scoped narrowly
14:13:30 <timeless> ... I think we need @@ ... @@ in the browser
14:13:36 <timeless> .... I think the privacy issue still stands
14:13:49 <timeless> ... but I think that's a different issue
14:13:54 <timeless> ... than a policy framework
14:14:02 <timeless> ... which might not provide what we want
14:14:04 <timeless> q?
14:14:07 <fjh> q?
14:14:11 <timeless> ack me
14:14:11 <dsr> I note that "safely" doesn't clearly distinguish between security and privacy!
14:14:12 <fjh> ack timeless
14:14:24 <timeless> I just heard something which reminds me
14:14:28 <timeless> ... of something from a while ago
14:14:53 <drogersuk> "sicherheit" - safety and security
14:14:58 <dsr> why is it valuable to conflate security and privacy?
14:15:21 <rigo> let P3P sleep in peace :)
14:15:24 <timeless> fjh: the group understand the scribe's concern
14:15:25 <bryan> q+
14:15:35 <timeless> ack drogersuk 
14:15:41 <timeless> drogersuk: on Privacy and Security
14:15:47 <timeless> ... they are separate but intertwined
14:16:01 <timeless> ... I did propose what rigo proposed to BONDI
14:16:05 <timeless> ... for example Location
14:16:09 <timeless> ... If you look at android
14:16:23 <timeless> ... you find the number of applications that ask for location
14:16:25 <timeless> ... is quite high
14:16:31 <rigo> so timeless, let's have an argument in the break. I can even explain you how P3P enforcement worked
14:16:39 <timeless> ... and malicious applications will ask for the highest precision
14:16:52 <timeless> darobin: how you implement it, and how you support trust
14:17:12 <timeless> drogersuk: What I'm saing is that in other environments, it isn't working
14:17:23 <timeless> darobin: I'm disagreeing with going in a direction away from a resolution
14:17:29 <freedom> s/ask for location/ask for fine-grain location information/
14:17:38 <timeless> <dom> PROPOSED RESOLUTION: we should focus on API features that can be implemented safely in the default browser policy model
14:17:40 <timeless> q?
14:17:48 <fjh> ack bryan
14:18:13 <drogersuk> @timeless - correction: fine grained location permissions request
14:18:47 <drogersuk> q+
14:18:54 <timeless> bryan: is that like Geolocation?
14:19:05 <timeless> darobin: yes, but we're aware it's suboptimial
14:19:12 <timeless> bryan: is everything Same Origin
14:19:29 <timeless> <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
14:20:18 <timeless> fjh: our real decision is to not require building a policy framework into the browser
14:20:29 <wuj> wuj has joined #dap
14:20:43 <timeless> drogersuk: my concern with dom's proposal
14:20:50 <timeless> ... is that it seems to constrain the number of APIs
14:21:03 <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
14:21:03 <timeless> darobin: the important part from dom's proposal is that we have to prioritize
14:21:13 <timeless> ... APIs, based on what's important
14:21:18 <darobin> PROPOSED RESOLUTION: We prioritise API functionality for which we have security solutions
14:21:25 <timeless> bryan: fjh's proposal about not mandating the mechanism
14:21:30 <timeless> ... add that to dom's....
14:22:14 <timeless> fjh: i don't like the first one because for browsers it can't be policy framework
14:22:34 <timeless> darobin: as i described earlier for contacts
14:22:41 <timeless> ... if you're in the browser, you might get a find contacts
14:22:46 <fjh> s/first one/second one
14:23:00 <timeless> ... but in a Widget you might get everything automatically from search:*
14:23:03 <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
14:23:04 <fjh> s/be policy/necessarily be a policy
14:23:18 <timeless> darobin: i can live with that
14:23:30 <timeless> fjh: any objections to drogersuk 's proposal?
14:23:37 <timeless> darobin: you actually read stuff before agreeing?!
14:23:52 <bblfish> bblfish has joined #dap
14:24:03 <bblfish> hi
14:24:08 <timeless> nwidell: haven't we resolved this before?
14:24:20 <dom> s/hi//
14:24:27 <bblfish> s/hi//
14:24:44 <drogersuk> I still think we should continue working on security alongside the APIs
14:25:03 <timeless> Dong-Young_Lee: what's the problem of mandating a policy framework?
14:25:11 <timeless> fjh: the policy framework is something specific
14:25:20 <timeless> ... which raises questions of who writes the framework
14:25:26 <timeless> ... and how does that work on the web
14:25:44 <timeless> darobin: and there's the bit of no one wants to write or maintain it for the web
14:25:57 <drogersuk> q+
14:26:05 <timeless> Dong-Young_Lee: so we delay our work, until some mechanism until a mechanism other than the policy model?
14:26:10 <darobin> ack drogersuk 
14:26:14 <timeless> drogersuk: we have a duty to work on ...
14:26:31 <timeless> ... something so we can support multiple security models
14:26:37 <timeless> ... one for mobile
14:26:49 <timeless> ... e.g. Google came to the table with PowerBox
14:27:00 <timeless> ... More to do with implementation than specification
14:27:09 <timeless> dom: any objections to the proposed resolution?
14:27:26 <timeless> lgombos: so if this is very sensitive in a default browser environment
14:27:35 <timeless> ... do we have to call that out in the specification
14:27:43 <timeless> ... do we make it optional for browsers?
14:27:48 <timeless> darobin: if there's something that's sensitive and dangerous
14:27:55 <timeless> ... and we don't have a solution for it in browsers?
14:28:05 <timeless> ... then we don't spec it until we have a solution
14:28:15 <timeless> drogersuk: there's also a group that tlr is working on
14:28:29 <timeless> <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
14:28:59 <drogersuk> . The group will continue to work on security.
14:29:11 <timeless> darobin: yes, with that
14:29:32 <timeless> 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.
14:30:15 <dom> RRSAgent, draft minutes
14:30:15 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html dom
14:30:18 <timeless> <darobin> PROPOSED RESOLUTION: We prioritise API functionality for which we have security solutions
14:30:48 <timeless> RESOLUTION: We prioritise API functionality for which we have security solutions
14:30:57 <timeless> [ break ]
14:31:12 <timeless> [ return @ 4pm ]
14:35:41 <andreip> andreip has joined #dap
14:39:50 <jorlow> jorlow has joined #dap
14:43:26 <tlr> tlr has joined #dap
14:44:25 <tlr> tlr has joined #dap
14:47:47 <nwidell> nwidell has joined #dap
15:00:27 <freedom> freedom has joined #dap
15:01:58 <marengo> marengo has joined #dap
15:03:02 <bblfish> bblfish has joined #dap
15:04:37 <homata> homata has joined #dap
15:05:35 <jmarting> jmarting has joined #dap
15:06:04 <youenn> youenn has joined #dap
15:06:41 <aizu> aizu has joined #dap
15:06:49 <hidetaka> hidetaka has joined #dap
15:08:43 <dsr> scribe: dsr
15:08:57 <dsr> we resume after a coffee break
15:09:26 <dsr> Robin: suggest we keep going with the agenda. [link?]
15:09:31 <richt> Here's the proposal to simplify the Sys Info API: http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html
15:09:37 <adam> adam has joined #dap
15:10:21 <dsr> The draft is kind of big. At the same time the Android browser has a different way to describe the network connection type.
15:10:30 <fjh> Topic: SysInfo
15:10:32 <fjh> http://www.w3.org/mid/23BEF3D8-2957-4D6F-99EE-61EF1479C97B@berjon.com
15:10:32 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0059.html (Illka)
15:10:32 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html (Rich)
15:10:44 <hendry> +1 to alignment wirh browser :)
15:11:06 <dsr> 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)
15:11:20 <francois> francois has joined #dap
15:11:44 <marengo> marengo has joined #dap
15:12:18 <fjh> zakim, who is here?
15:12:18 <Zakim> On the phone I see no one
15:12:19 <Zakim> On IRC I see marengo, francois, adam, hidetaka, aizu, youenn, jmarting, homata, bblfish, freedom, tlr, jorlow, andreip, wuj, rigo, Kai, igarashi, Johnson, darobin, timeless,
15:12:24 <Zakim> ... maoteo, bryan, jgiraud, Wuk, Claes, anne, cmarc, bochen, Suresh, kensaku, junliao, dsr, soonho, YounSung, shepazu, Kangchan, AnssiK, wonsuk, lgombos_, fjh, jun, LauraA, hendry,
15:12:26 <Zakim> ... richt, Zakim, RRSAgent, ingmar, wmaslowski, lgombos, trackbot, ilkka, dom
15:12:46 <dsr> Rich talks us through his proposal for a simplication (email to DAP WG list)
15:12:47 <dom> (I didn't get a chance to reply to Rich's message on the list, but I mostly +1 his proposal)
15:13:11 <dsr> on 29 Oct (SysInfo API vs Generic Sensors API)
15:13:45 <kkim> kkim has joined #dap
15:13:47 <dsr> This is from the Android browser
15:13:56 <bryan> q+
15:14:24 <AnssiK> q+ to ask about event handlers, and if they're needed
15:14:42 <dom> robin notes a mistake in the proposed WebIDL where type is shown as a method rather than an attribute
15:14:50 <dsr> [uri? for his email]
15:15:10 <dom> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html
15:15:28 <nwidell> nwidell has joined #dap
15:15:52 <dsr> Bryan: this moves us to an object oriented approach as opposed to a vocabulary oriented approach which could create problems for future extensibility.
15:16:50 <dsr> Robin: to clarify we would keep the SysInfo mechanism for extensibility but introduce the simpler interface in parallel.
15:17:57 <adam> could you infer you were on a corporate network?
15:18:11 <dsr> Bryan: you could infer that someone is at home from the details of their network connection info, this is a privacy concern.
15:18:29 <dsr> Robin: the information available is limited e.g. on 3G or WiFi
15:20:10 <dsr> Suresh recaps background leading up to where we are now. We should take this decision in the context of all the SysInfo params.
15:20:51 <dsr> Dom: the fact that the simple approach already has some traction should be taken into account, but it is only one of several proposals.
15:20:57 <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?
15:21:17 <fjh> q?
15:21:26 <fjh> ack bryan
15:21:43 <fjh> ack AnssiK
15:21:43 <Zakim> AnssiK, you wanted to ask about event handlers, and if they're needed
15:21:47 <dsr> May be we should add event handlers to avoid the need for polling?
15:21:56 <fjh> q+ fjh to confirm alternative
15:22:30 <manyoung> manyoung has joined #dap
15:22:30 <fjh> ack fjh
15:22:30 <Zakim> fjh, you wanted to confirm alternative
15:23:19 <AnssiK> implement EventTarget, add connectionchange event type
15:23:19 <dsr> Is the proposal to remove some information from SysInfo where it is available from the Android interface?
15:24:04 <dom> q+ hendry
15:24:32 <dom> ack hendry
15:24:37 <dsr> Suresh: some properties can be synchronous, but others could necessitate polling or asynchronous, let's keep some synchronous properties where practical.
15:24:56 <Dong-Young> Dong-Young has joined #dap
15:25:07 <freedom> q+
15:25:33 <dsr> Rich: what do we want to do next?
15:26:22 <dsr> 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?
15:26:22 <timeless> q+ to ask about vpn's
15:26:46 <dsr> Google is in this WG and signed up to its IPR policy.
15:27:55 <hendry> hendry: type just caches last seen connection type; Android browser fires online when the type changes
15:27:57 <timeless> ack me
15:27:57 <Zakim> timeless, you wanted to ask about vpn's
15:28:11 <dsr> Robin: numerical constants are bad for developers, and named methods/properties are preferable.
15:28:54 <dsr> Josh: worried about information leakage e.g. website learning about my VPN.
15:29:39 <fjh> rrsagent, generate minutes
15:29:39 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html fjh
15:29:58 <dsr> Rich: this is why we need a spec to clarify that that can't occur.
15:30:40 <bryan> q+
15:30:46 <dsr> Robin: if you are on 2G you might want to avoid using web fonts for performance reasons.
15:30:46 <fjh> Present+ Dong-Young_Lee
15:30:55 <fjh> s/Presnt+ Dong-Young_Lee//
15:31:20 <manyoung> Present+Manyoung_Cho
15:31:31 <dsr> Josh: download rate is critical for my user experience, not the details of the network connection.
15:31:40 <fjh> s/David Rogers introducing WAC update/David Rogers introducing WAC update, WAC 1.0 is here: http://www.wholesaleappcommunity.com/\//
15:32:43 <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)/
15:32:50 <fjh> rrsagent, generate minutes
15:32:50 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html fjh
15:32:57 <ilkka> q+
15:32:58 <dsr> Josh: giving people an API that encourages sloppy practices, when developers could use code to adapt to the network speed directly.
15:34:12 <dsr> Dom: this might be difficult in practice.
15:34:17 <lgombos_> .. it seems tha the android implementation has an eventing mechanism - The online event is fired when the networkType changes.
15:34:21 <timeless> s/tha/that/
15:34:48 <bryan> q?
15:35:38 <freedom> q-
15:35:45 <SGondo> SGondo has joined #dap
15:35:55 <Kai> Kai has joined #dap
15:36:07 <dom> [I recommend not bundling the new proposals together]
15:36:13 <dsr> Robin summarizes.
15:36:15 <dom> ack bryan
15:36:59 <dsr> Bryan: we already have this use case, so it doesn't argue strongly for the Android interface.
15:37:46 <dsr> Josh: the browser doesn't have control over which network connection packets flow (apart from Symbian).
15:37:49 <dom> Bryan: also, our proposal can deal with several connections; this one doesn't
15:39:29 <dsr> Bryan repeats concern over privacy.
15:40:11 <timeless> q+ to note that IP addresses generally disclose network topology (Cable, DSL, T1, Cellular, WiFi hotspot)
15:40:14 <dsr> Bryan: we have a security solution for our existing API, but not for this new proposal.
15:41:00 <bblfish> bblfish has joined #dap
15:41:02 <dsr> Rich proposes to draft a spec based upon the Android solution.
15:41:06 <bryan> q+
15:41:38 <dsr> Robin: if we have a detailed proposal then we will be in a stronger position to review its security.
15:42:07 <dsr> Henry: I would rather have network speed rather than its specific type.
15:42:55 <dsr> Josh: it is important to test the performance in the kinds of data the app needs, e.g. latency/jitter on video
15:42:58 <dom> ack timeless
15:42:58 <Zakim> timeless, you wanted to note that IP addresses generally disclose network topology (Cable, DSL, T1, Cellular, WiFi hotspot)
15:43:00 <dom> ack illka
15:43:04 <dom> ack ilkka
15:43:26 <dom> q+ timeless
15:43:31 <dsr> Ilka: network characteristics can change dramatically over time.
15:43:44 <timeless> q?
15:44:05 <ilkka> s/Ilka:/Ilkka:/
15:44:15 <Suresh> +
15:44:18 <Suresh> q+
15:44:28 <dom> ACTION: Rich to create an editors draft for new proposed network connection API
15:44:28 <trackbot> Sorry, couldn't find user - Rich
15:44:33 <dom> ACTION: Richard to create an editors draft for new proposed network connection API
15:44:33 <trackbot> Created ACTION-294 - Create an editors draft for new proposed network connection API [on Richard Tibbett - due 2010-11-11].
15:44:33 <timeless> ack bryan 
15:44:38 <timeless> ack me
15:45:29 <dsr> Josh: IP addresses generally disclose network info, e.g. which type you are using.
15:46:12 <dsr> Bryan: disagree (details lost)
15:46:23 <dom> ack suresh
15:46:50 <dsr> Suresh: would like to see this approach applied broadly.
15:46:59 <dsr> Dom: safe and useful.
15:47:23 <dsr> Topic: Contacts API
15:47:23 <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.
15:47:49 <fjh> q?
15:48:09 <dsr> Henry: I could spend 2 minutes describing link with WebId
15:48:16 <dsr> Robin: go ahead
15:49:01 <dsr> [ see e.g. http://esw.w3.org/WebID ]
15:49:06 <bryan> q+
15:50:17 <dsr> Rich: HTML5 gives us keygen mechanism which could be useful.
15:50:40 <dsr> Dom: this is an API not a format.
15:51:04 <tlr> tlr has joined #dap
15:51:07 <dsr> Henry: ah thanks for the clarification.
15:51:26 <dsr> Henry will communicate offline with Rich.
15:51:57 <dsr> Rich: work on the contacts API has been a fun ride ;)
15:52:11 <manyoung> manyoung has left #dap
15:52:32 <dsr> Sorting is hard. Similar discussion in Web Apps WG earlier this week.
15:52:57 <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?
15:52:59 <bryan> q-
15:53:18 <dsr> Robin: leave it to JavaScript. (Unicode string sorting)
15:53:24 <timeless> +1
15:53:50 <dsr> Rich: Appendix B.1. 
15:54:29 <dsr> this example has been there for a long time
15:54:35 <dom> -> http://dev.w3.org/2009/dap/contacts/ Contacts API editors draft
15:54:55 <dsr> B.2 is a way to invoke API synchronously.
15:55:25 <dsr> works similar to window.open
15:55:37 <dom> [I'm thinking the button binding should probably be the only way to access the contacts API]
15:55:59 <dsr> untrusted code results in pop-up blocker kicking into effect.
15:56:03 <AnssiK> q+
15:56:29 <dsr> trusted if as a result of a user action, e.g. button press
15:56:43 <dom> [my main concern is that with the button text being able to say anything, this can be used for social engineering]
15:56:48 <lgombos_> q+
15:56:52 <dom> q+
15:57:04 <bryan> q+
15:57:38 <AnssiK> body.addEventListener('click', doEvil, false);
15:57:41 <darobin> q?
15:57:47 <darobin> ack dom
15:57:51 <dom> <input type=contact> would avoid that
15:57:55 <dsr> Dom: prefer the requirement for direct user action, but concerned about social engineering where users are "tricked" into doing something
15:58:20 <darobin> <input type=contact> degrades to <input type=text>, which is an issue
15:58:21 <bblfish> bryan: private key are kept in keychain in browser
15:58:51 <dsr> Rich: web developers circumvent official controls for a variety of reasons
15:59:02 <richt> http://valums.com/ajax-upload/
15:59:56 <drogersuk> drogersuk has joined #dap
16:00:00 <dsr> Clicking on an image acting as a button results in the file selection dialogue appearing
16:00:10 <SGondo> SGondo has joined #dap
16:00:37 <tlr> tlr has joined #dap
16:00:49 <dsr> Robin: advantage of non-user initiated version is that it results in (missed)
16:01:22 <dom> s/(missed)/it can re more easily re-used in the "trusted environment"/
16:01:27 <timeless> http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events
16:02:14 <dsr> s/can re/can be/
16:03:15 <dsr> Rich: we need to describe the connection to DOM3 trusted events
16:03:31 <darobin> ack AnssiK 
16:03:36 <dsr> Robin: any objections to making it normative
16:03:51 <Kai> Kai has joined #dap
16:04:01 <nwidell> q+
16:04:28 <dsr> Ilkka: concerned about developer's tricking users
16:04:45 <fjh> s/Ilkka/Anssi
16:05:42 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html tlr
16:05:47 <dsr> Some discussion about event bubbling and trust model
16:06:23 <manyoung> manyoung has joined #dap
16:06:30 <lgombos_> ack lgombos_
16:06:43 <dsr> Josh talks through the details of click jacking...
16:07:31 <darobin> q?
16:07:33 <timeless> you can probably game the user to double click and hit enter
16:07:35 <darobin> ack nwidell 
16:08:02 <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
16:08:13 <dsr> nwidell: in this case does the fact that the events are trusted matter that much?
16:08:52 <timeless> richt: editorial, can you use green instead of red for {}s ? :)
16:09:20 <dsr> Rich: this is how file upload works today
16:09:36 <noah> noah has joined #dap
16:09:51 <lgombos_> q+
16:11:03 <dsr> Rich projects a click jacking example where the submit button has opacity zero.
16:11:13 <darobin> q?
16:11:26 <Suresh> q+
16:11:26 <darobin> ack bryan 
16:11:36 <richt> q+ !!! :)
16:11:42 <richt> q- !!!
16:11:45 <richt> q+
16:12:16 <dsr> 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?
16:12:42 <richt> you should probably have access for the life of the script.
16:12:49 <dsr> is this access to the data or to the object?
16:12:54 <dsr> Dom: to the data
16:12:55 <richt> but right now you get a snapshot of the data
16:13:28 <dom> q?
16:13:35 <fjh> bryan: suggests creating a test case for this case to make sure it is the case
16:13:41 <darobin> RESOLUTION: Contacts data is a snapshot, not a live mirror of the contacts DB info
16:13:50 <darobin> ack lgombos
16:14:31 <dsr> lgombos: does this interface open the contact info directly?
16:14:38 <timeless> q+
16:15:20 <dsr> Robin: non-normatively we say a notification bar is shown first to alert the user to the action.
16:15:25 <darobin> Zakim, close the queue
16:15:25 <Zakim> ok, darobin, the speaker queue is closed
16:16:15 <dsr> some discussion on filtering of contacts via filter param in API
16:17:41 <dsr> usability considerations and comparison with current implementations of geoloc.
16:18:41 <dsr> Dom: the API does influence the UI
16:18:42 <fjh> q+ to ask about privacy without any ui requirement?
16:18:46 <francois> francois has joined #dap
16:18:56 <richt> q-
16:19:02 <dsr> Robin: we're not UI experts and want to give the designers freedom to do a good job
16:19:32 <Kai> Kai has joined #dap
16:19:39 <freedom> freedom has joined #dap
16:19:47 <dsr> Robin: we don't assume that privacy and security are done through the UI. There could be other approaches [ delegation models? ]
16:19:49 <lgombos_> ack lgombos_
16:21:01 <fjh> concern that privacy will get lost in the gap between various optionalities
16:21:25 <dsr> David: the app doesn't need to know the personal info, but we don't (now) have the technology to deal with this.
16:21:36 <fjh> however Dom argues that privacy is a competitive advantage of implementations
16:21:40 <dsr> Rich: data minimization ...
16:22:15 <timeless> ack Suresh 
16:22:57 <dsr> Suresh: on your examples you state "sharing" but do so in a way that could be misleading.
16:23:50 <dsr> some more details which I can deal with offline.
16:24:39 <dsr> Robin: we will have a broader discussion tomorrow.
16:24:55 <darobin> http://www.w3.org/2009/dap/wiki/TPAC10Agenda#10.29_Metaphors_for_write-back_and_deletion
16:24:59 <darobin> ack Suresh 
16:25:05 <timeless> ack me
16:25:08 <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).
16:25:11 <jorlow> jorlow has joined #dap
16:26:01 <Suresh> The leading section under the Contact interface still omits OMA CAB, which is inconsistent with our earlier discussion....
16:26:10 <dsr> [ DSR wonders about requirements for signed contacts ]
16:27:04 <darobin> timless suggest requiring the ability to return dummy contacts
16:27:04 <timeless> s/timless/timeless/
16:27:24 <darobin> dom pushes back that that's UI innovation best left to implementers
16:27:33 <darobin> q?
16:28:01 <dsr> David: the facebook issue, I will deny you access to this site UNLESS....
16:28:20 <dsr> Rich: we can't do much about that in technical specs
16:28:36 <manyoung> manyoung has left #dap
16:29:55 <drogersuk> ACTION: David Rogers to outline social engineering threat, API entry hurdles to websites
16:29:55 <trackbot> Created ACTION-295 - Rogers to outline social engineering threat, API entry hurdles to websites [on David Rogers - due 2010-11-11].
16:30:03 <dsr> Robin provides a summary of the proposed next steps
16:30:29 <manyoung> manyoung has joined #dap
16:30:52 <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 a heartbeat
16:31:04 <darobin> Robin: the hope is that it's the last heartbeat before LC
16:31:06 <dom> s/heartbeat/WD/
16:31:25 <timeless> s/heartbeat/WD/
16:31:44 <timeless> RRSAgent, make minutes
16:31:44 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html timeless
16:32:40 <dsr> Suresh: is having two models an issue?
16:32:51 <dsr> Robin: yes, more work for implementors
16:33:10 <richt> But the two models use the same component (ie
16:33:19 <richt> (i.e. contact picker)
16:33:24 <dsr> Dom: we could leave this to CR and see what is implemented.
16:33:35 <dom> (and call it feature as risk if needed)
16:33:41 <darobin> ... because it's clearly implementation feedback
16:33:48 <dsr> s/as/at/
16:33:48 <richt> agreed.
16:33:57 <timeless> s/it's clearly/it clearly requires/
16:34:10 <nwidell> nwidell has joined #dap
16:34:24 <darobin> PROPOSED RESOLUTION: Accept changes, document dual infobar+trusted events as feature at risk, and publish a heartbeat WD
16:34:42 <darobin> RESOLUTION: Accept changes, document dual infobar+trusted events as feature at risk, and publish a heartbeat WD
16:34:44 <dsr> Accepted as written
16:36:04 <dsr> ... the room is hot and stuffy and it is 5:35pm, what can we usefully do  now ...
16:36:58 <dsr> Topic: Galery (stored media interactions)
16:38:16 <dsr> Dom talks through use case with a lot of files in the gallery
16:38:34 <bryan> +1 to the value of gallery as a metadata search engine for media files
16:39:23 <dsr> We probably need more discussion on use cases before deciding on the technical details.
16:40:08 <dsr> Suresh: having just the metadata might restrict the UI
16:40:36 <dsr> [ thumbnails for audio, video and photos? ]
16:41:06 <AnssiK> the UI on the left is already a gallery: http://dev.w3.org/2009/dap/camera/capture-api-file-picker-concept.png
16:41:16 <dsr> Nokia contribution covered file picker use case.
16:41:21 <darobin> Zakim, open the queue
16:41:21 <Zakim> ok, darobin, the speaker queue is open
16:41:39 <dsr> Bryan: very high priority for us
16:41:54 <richt> the functionality is high priority, not the API, right?
16:41:55 <dom> ACTION: Dom to send use cases for gallery API
16:41:55 <trackbot> Created ACTION-296 - Send use cases for gallery API [on Dominique Hazaël-Massieux - due 2010-11-11].
16:42:28 <darobin> RRSAgent, draft minutes
16:42:28 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html darobin
16:42:49 <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?)
16:43:03 <callie> callie has joined #dap
16:43:06 <darobin> Topic: TimezonedDate
16:43:18 <darobin> http://dev.w3.org/2009/dap/calendar/TimezonedDate.html
16:43:48 <dsr> Rich: I wrote it and haven't touched it since then, needs refinement
16:44:36 <dsr> Rich wants to provide a new proposal.
16:44:39 <Suresh> q+
16:45:15 <dsr> floating time, fixed time, timezones changing all over the place. Better to apply  timezone and format preferences to UTC values
16:46:05 <dsr> [ do all devices really know daylight savings transitions in all countries? ]
16:46:43 <timeless> dsr: no.
16:48:42 <dsr> Dom cites example of flights where timezones change definition during trip
16:48:53 <adam> adam has joined #dap
16:49:44 <dsr> Robin: example of call starting in boston timezone and ending when I need to collect my daughter from daycare in my local timezone
16:50:40 <dom> (I suggest TZDate instead of TimezonedDate FWIW)
16:51:34 <dsr> Robin: I need a to UTC date method to simplify my code.
16:51:36 <timeless> dom +1
16:52:27 <dsr> yes, reduces camel casing errors
16:52:43 <bblfish> bblfish has joined #dap
16:53:30 <dsr> Rich edits the TZDate object definition on the fly
16:53:38 <timeless> richt: Constructor(Date, timezoneID)
16:53:56 <dsr> Suresh: why not inherit from ECMAScript Date object?
16:54:18 <dsr> Josh: when that object changes you get screwed
16:54:27 <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 !?
16:54:56 <richt> Constructor(year, month, day, hours, minutes, seconds, timezoneID)
16:55:01 <richt> ..works much better...
16:55:08 <timeless> richt: serialize to number first and then add timezoneid
16:56:38 <dsr> DSR suggests noting the importance of having accurate and current DST info
16:58:19 <dsr> Platform developers need to be good, web developers don't want to get burned
16:59:06 <dom> ISSUE-81?
16:59:06 <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
16:59:06 <trackbot> http://www.w3.org/2009/dap/track/issues/81
16:59:43 <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
16:59:44 <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
17:00:02 <timeless> <Josh> when that object changes you get screwed
17:00:07 <dom> ISSUE-81: since extending a host object is a bad idea in case the original object evolves (and would aslo implies stringification nightmares)
17:00:07 <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
17:00:33 <timeless> "that object", being the API of that Host/Host language object
17:02:32 <wonsuk> wonsuk has left #dap
17:03:02 <dsr> Suresh and Rich discuss Date object and timezone, could timezone be added as attribute to the Date object?
17:03:20 <dsr> Rich: Date serializes to local time leading to problems.
17:03:25 <timeless> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toJSON Date().toJSON is a "new" property, I believe from ECMAScript5
17:05:10 <SGondo> SGondo has joined #dap
17:05:29 <dom> ACTION: Robin to draft up TZDate
17:05:29 <trackbot> Created ACTION-297 - Draft up TZDate [on Robin Berjon - due 2010-11-11].
17:05:44 <dsr> Robin asks for volunteers to take over TZDate spec, but ends up doing so himself
17:06:37 <fjh> rrsagent, generate minutes
17:06:37 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/04-dap-minutes.html fjh
17:06:55 <kkim> kkim has left #dap
17:08:47 <manyoung> manyoung has left #dap
17:08:57 <SGondo> SGondo has joined #dap
17:13:49 <adam> adam has left #dap
17:37:45 <AnssiK> AnssiK has joined #dap
17:40:21 <drogersuk> drogersuk has joined #dap
17:55:07 <fjh> fjh has joined #dap
17:58:07 <homata> homata has joined #dap
18:01:17 <kensaku> kensaku has joined #dap
18:48:01 <AnssiK> AnssiK has joined #dap
19:32:17 <timeless_mbp> timeless_mbp has joined #dap
20:43:14 <richt> richt has joined #dap
21:02:35 <bblfish> bblfish has joined #dap
21:50:44 <AnssiK> AnssiK has joined #dap
22:29:26 <bblfish> bblfish has joined #dap
22:37:55 <bblfish1> bblfish1 has joined #dap
22:55:31 <Zakim> DI_(TPAC)3:00AM has ended
22:55:33 <Zakim> Attendees were 
22:58:48 <Kai> Kai has joined #dap
22:59:06 <Kai> Kai has left #dap
23:12:44 <fjh> fjh has joined #dap
23:59:49 <hidetaka> hidetaka has joined #dap