16:26:22 <RRSAgent> RRSAgent has joined #dap
16:26:22 <RRSAgent> logging to http://www.w3.org/2009/11/02-dap-irc
16:26:24 <trackbot> RRSAgent, make logs world
16:26:24 <Zakim> Zakim has joined #dap
16:26:26 <trackbot> Zakim, this will be DAP
16:26:26 <Zakim> ok, trackbot; I see UW_DAP(TPAC)11:30AM scheduled to start in 4 minutes
16:26:27 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
16:26:27 <trackbot> Date: 02 November 2009
16:26:36 <dom> zakim, call salon_5
16:26:36 <Zakim> I am sorry, dom; I do not know a number for salon_5
16:33:26 <dom> zakim, call salon_5
16:33:26 <Zakim> I am sorry, dom; I do not know a number for salon_5
16:33:34 <darobin> darobin has joined #dap
16:33:41 <dom> Present+ Dominique_Hazael-Massieux
16:33:48 <fhirsch> fhirsch has joined #dap
16:33:52 <dom> s/Teleconference/F2F Day 1/
16:34:01 <dom> zakim, call salon_5
16:34:01 <Zakim> I am sorry, dom; I do not know a number for salon_5
16:34:13 <dom> zakim, call Salon_5
16:34:13 <Zakim> I am sorry, dom; I do not know a number for Salon_5
16:34:37 <Bryan> Bryan has joined #dap
16:35:09 <Laura_Arribas> Laura_Arribas has joined #dap
16:35:51 <Laura_Arribas> Present+ Laura_Arribas
16:38:05 <dom> Scribe: Bryan
16:38:07 <tlr> tlr has joined #dap
16:38:11 <marengo> marengo has joined #dap
16:38:43 <Hixie> Hixie has joined #dap
16:38:56 <schittur2> schittur2 has joined #dap
16:38:57 <Hixie> Present+ Ian_Hickson
16:39:03 <dom> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0003.html
16:39:09 <dom> dom has changed the topic to: DAP WG F2F, Agenda http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0003.html
16:39:21 <dom> Chair: Frederick, Robin
16:39:34 <tlr> Present+ Thomas_Roessler
16:39:39 <DanielColoma> DanielColoma has joined #dap
16:40:05 <JereK> JereK has joined #dap
16:40:38 <DanielColoma> Present+ DanielColoma
16:40:42 <Kangchan> Kangchan has joined #dap
16:41:14 <marengo> Present+ Marco_Marengo
16:41:51 <JonathanJ> JonathanJ has joined #dap
16:42:16 <Claes> Claes has joined #dap
16:42:49 <Claes> Present+ Claes_Nilsson
16:42:57 <dom> RRSAgent, draft minutes
16:42:57 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
16:43:02 <Kangchan> Present+ Kangchan
16:43:07 <marcin> marcin has joined #dap
16:43:34 <Suresh> Suresh has joined #dap
16:43:43 <richt> richt has joined #dap
16:43:55 <richt> Present+ Richard_Tibbett
16:44:16 <marcin> Present+ Marcin_Hanclik
16:44:35 <tlr> zakim, call Salon_5
16:44:35 <Zakim> I am sorry, tlr; I do not know a number for Salon_5
16:44:43 <drogersuk> drogersuk has joined #dap
16:45:51 <maxf> maxf has joined #dap
16:46:34 <AnssiK> AnssiK has joined #dap
16:46:38 <JonathanJ> Present+ JonathanJ
16:46:54 <AnssiK> Present+ Anssi_Kostiainen
16:47:01 <slewontin> slewontin has joined #dap
16:47:27 <maxf> maxf has joined #dap
16:47:41 <claudio> claudio has joined #dap
16:49:34 <marcin2> marcin2 has joined #dap
16:50:02 <daniel> daniel has joined #dap
16:51:45 <darobin> Present+ Robin_Berjon
16:52:05 <wonsuk> wonsuk has joined #dap
16:52:11 <marcin2> Present+ Marcin_Hanclik
16:52:11 <nwidell> nwidell has joined #dap
16:52:25 <slewontin> Present+ Steve Lewontin
16:52:28 <wonsuk> Present+ Wonsuk_Lee
16:52:53 <drogersuk> Present+ David_Rogers
16:52:55 <nwidell> Present+ Niklas_Widell
16:53:30 <drogersuk> BONDI 1.1 Candidate Release today: http://bondi.omtp.org
16:53:45 <DanielColoma> Present+ DanielColoma
16:53:46 <Bryan> drogersuk: announcementof  BONDI 1.1 candidate release is pending
16:54:06 <fhirsch> david notes seeking feedback on this public candidate release
16:54:17 <Bryan> topic: minutes approval
16:54:28 <mmani> mmani has joined #dap
16:54:32 <fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0240/minutes-2009-10-28.html
16:54:41 <darobin> (direct link to BONDI 1.1 CR: http://bondi.omtp.org/Documents/CR1.1/BONDI%20Candidate%20Release%201.1.zip)
16:55:00 <Bryan> Resolution: minutes of 28t Oct are approved
16:55:16 <Bryan> topic: update to contacts API
16:55:30 <fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0261.html
16:55:40 <schittur2> schittur2 has joined #dap
16:55:41 <drogersuk> http://bondi.omtp.org/1.1/CR/
16:55:55 <Bryan> richt: been working on baseline, last update is on multiple address book report, error handling, etc. expect interesting stuff this week
16:57:25 <Bryan> fhirsch: mark actions as pending when work has been done, to assist tracking
16:58:09 <Bryan> fhirsch: any need to discuss File API or notifications in advance of joint meeting?
16:58:31 <Bryan> darobin: not sure we have a lot to discuss yet in advance
16:59:10 <Bryan> fhirsch: suggest to talk about policy requirements: sent out a draft for discussion 
17:00:13 <tlr> topic: Policy Requirements
17:00:20 <darobin> live updated agenda, together with scribe slots: http://www.w3.org/2009/dap/wiki/F2F_Agenda_2-3_November_2009%2C_TPAC/
17:00:25 <SureshChitturi> SureshChitturi has joined #dap
17:00:25 <Bryan> new topic: policy requirements draft
17:00:39 <Bryan> topic: policy requirements draft
17:00:43 <dom> -> -> http://dev.w3.org/2009/dap/policy-reqs/ Device API Policy Requirements draft
17:00:49 <dom> s/->//
17:01:36 <Bryan> fhirsch: current draft displayed, with input from BONDI etc
17:02:00 <Bryan> fhirsch: need a general discussion about features, capabilities etc
17:02:46 <Bryan> fhirsch: one issue, we need to address javascript dependency but are there any other language independency requirements?
17:03:16 <Bryan> darobin: must support ecmascript and other languages as nice to have
17:03:58 <Bryan> drogersuk: rationale on language independence is the policy language is not directly connected to the implementation, e.g. as javascript API's
17:05:12 <Bryan> marcin: 2 comments, 1 is all of BONDI policy language independent as an XML document, 2 is all interfaces are expressed in webidl, which is intended to be implementation independent
17:06:02 <Bryan> fhirsch: so it seems language independence is given if you look at the policy elements themselves, but is there a language dependency on the strings, e.g. features
17:06:09 <drogersuk> @JereK - yes that's right
17:06:16 <Bryan> marcin: no the strings should be language independent
17:06:51 <AnssiK> my minor nit was that normative statements should use ECMAScript over JavaScript for consistency
17:07:14 <Benoit> Benoit has joined #dap
17:07:15 <noahm> noahm has joined #dap
17:07:20 <fhirsch> fhirsch has changed the topic to: DAP F2F agenda http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0003.html
17:07:29 <noahm> present+ Noah Mendelsohn
17:07:40 <claudio> claudio has joined #dap
17:07:46 <Marcos> Marcos has joined #dap
17:08:19 <darobin> http://www.w3.org/mid/59db1b5a0911020854o3f14f88bsb7339ce88a3b98ca@mail.gmail.com
17:08:30 <Bryan> laura: new email from paddy received on comments to policy requirements
17:08:31 <darobin> ^-- link to Paddy's email
17:08:54 <dom> s/http:/-> http:/
17:09:10 <Laura_Arribas> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0004.html
17:09:10 <dom> s/gmail.com/gmail.com Paddy’s comments on policy requirements
17:09:18 <dom> RRSAgent, draft minutes
17:09:18 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
17:09:24 <mmani> mmani has joined #dap
17:09:43 <Laura_Arribas> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0243.html
17:09:54 <dom> s/http:/-> http:/
17:10:16 <dom> s/243.html/243.html Laura’s comments on policy requirements/
17:10:20 <nwidell> nwidell has joined #dap
17:10:29 <dom> RRSAgent, draft minutes
17:10:29 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
17:10:49 <Bryan> fhirsch: discuss first the feature requirement, as a set of capabilities provided by the API, as a policy resource aspect
17:11:11 <tlr> zakim, call salon_5
17:11:14 <Zakim> ok, tlr; the call is being made
17:11:15 <Zakim> UW_DAP(TPAC)11:30AM has now started
17:11:15 <Zakim> +Salon_5
17:11:45 <ingmar> ingmar has joined #dap
17:12:06 <ingmar> Present+  Ingmar_Kliche
17:12:25 <Bryan> fhirsch: understanding is that mechanism is defined in terms of features, access controls are defined re features, and capabilities are things concerned about but related to features first. the API is related to features and capabilities
17:12:41 <Bryan> drogersuk: believe that is correct
17:13:57 <Bryan> slewontin: see  two models, abtract capability model related to operations e.g. send - with that model specs need non-normative description of semantics, with baseline description of normative capabilities 
17:14:44 <Bryan> slewontin: 2nd option is the API's define the semantics, in that model the API;s define the capabilities, and we don't need a generic capability approach
17:14:53 <Bryan> slewontin: the 2nd is the feature model
17:15:16 <Bryan> slewontin: the policy model itself does not have to define the semantics and can work in either case
17:15:50 <Bryan> slewontin: if we adopt the abstract model, we need to give guidance on what to use to comply with the semantics
17:16:25 <Bryan> slewontin: a feature based model is easier to specify - we don't have to worry about extensions or give overt guidance
17:16:49 <fhirsch> q+
17:16:50 <Bryan> drogersuk: agree, need to keep abstraction level low
17:17:55 <Bryan> Nick: features to be capability-centric, and provide a way of insulating the API from the underlying implementation
17:18:10 <fhirsch> Present+ Ashok
17:18:44 <Bryan> slewontin: question is when new features are added within an API, e.g. to add geolocation tag, the policy implications are easier to address in a feature model
17:20:15 <Bryan> slewontin: feature-based approach also simplify the access to data where the data type implies semantics, e.g. media access vs direct file access
17:20:49 <Bryan> fhirsch: don't we still have to define the semantics for the feature name?
17:21:47 <Bryan> marcin: device capabilities vs feature model is still being debated in BONDI
17:22:20 <Bryan> Suresh: when a widget is defined, so you declare the feature or capabilities?
17:22:35 <Bryan> Marcin: we declare the feature only
17:22:55 <fhirsch> stephen notes that capability can be treated as only string - e.g name + parameter
17:23:34 <Bryan> marcin: there are three parameters in enforcement, the feature, context, and parameters. some decisions thus are not possible until runtime
17:24:10 <Bryan> fhirsch: so how is interoperability of capabilities semantics ensured?
17:25:42 <Bryan> marcin: the mapping is often 1-to-1, there is also an n-to-m mapping but there  is not an enforcement point to mandate that mapping
17:26:16 <Bryan> bryan: isn't the mapping defined in the webidl specification?
17:27:25 <Bryan> marcin: when we allow extensions there may be unclear mappings
17:27:48 <Bryan> bryan: but properly specified API's should define the capabilities if done correctly
17:28:37 <richt> q+
17:28:41 <Bryan> marcin: there is the possibility of inconsistency if a vendor does not make the mapping clear
17:29:02 <tlr> zakim, who is on the phone?
17:29:02 <Zakim> On the phone I see Salon_5
17:29:07 <tlr> zakim, drop salon_5
17:29:07 <Zakim> Salon_5 is being disconnected
17:29:08 <Zakim> UW_DAP(TPAC)11:30AM has ended
17:29:08 <Zakim> Attendees were Salon_5
17:30:12 <Bryan> slewontin: if we open up the spec to say this needs to apply to any API outside our set, we have dependency to clarify how the mapping is ensured in those extensions
17:30:50 <Bryan> fhirsch: so for our chartered API's we can define the policy elements normatively and informatively for API's outside our set
17:31:36 <lgombos> lgombos has joined #dap
17:32:10 <Bryan> fhirsch: the abstract approach seems more involved
17:32:37 <MikeSmith> MikeSmith has joined #dap
17:33:08 <Bryan> Nick: 3 reasons for the way that BONDI approache this: 1 is extensibililty, 2 is versioning, 3 is way of expressing in a simple rule a risk that may be orthogonal over 12 API
17:33:18 <fhirsch> exensible apis, enable api versioning, 
17:34:09 <Bryan> Nick: an example of 3 is that file API and gallery, the io.file capability can address a risk over the two
17:34:48 <Bryan> Nick: we need to define the semantics clearly
17:35:05 <Bryan> drogersuk: is extensibility in scope here?
17:36:20 <Bryan> dom: extensibility is not in scope - also the orthogonal risks should be manageable through the policy framework
17:37:27 <plh-webapps> plh-webapps has joined #dap
17:37:37 <dom> s/also/but/
17:38:08 <Bryan> marcin: we should focus on those capabilities that are expressed in the charter, the device capabilities as definition of what we plan to do, and the API's as  how - the implications on versioning are important to consider in this
17:39:23 <Bryan> fhirsch: so we should be able to concretely define the semantics of the chartered capabilities  - but for versioning, don't we have plan (by resolution) to not address versioning
17:39:36 <Bryan> dom: we are not trying to create API's with versioning information
17:39:48 <Bryan> fhirsch: what are the implications for policy versioning?
17:39:55 <lgombos> Present+ Laszlo_Gombos
17:40:02 <tlr> q?
17:40:20 <tlr> q+ richt
17:40:47 <daniel> daniel has joined #dap
17:40:48 <paddy> paddy has joined #dap
17:41:03 <Bryan> marcin: we solved that in BONDI we want to keep compatibility, but if there are changes that break compatibility we change the API IRI
17:41:11 <dom> q?
17:41:23 <fhirsch> suggestion -define capabilities and their semantics for the specific cases listed in the charter, define associated features concretely
17:41:26 <fhirsch> ack richt
17:41:39 <paddy> Present+ Paddy_Byers
17:41:58 <tlr> zakim, who is on the phone?
17:41:58 <Zakim> apparently UW_DAP(TPAC)11:30AM has ended, tlr
17:41:59 <Zakim> On IRC I see paddy, daniel, plh-webapps, MikeSmith, lgombos, ingmar, nwidell, Marcos, claudio, noahm, SureshChitturi, wonsuk, marcin2, maxf, slewontin, AnssiK, drogersuk, richt,
17:42:00 <Bryan> marcin: example is file API, IRI is filesystem. We will add seek capability, and if that is security related, we may have a related device capability e.g. file.seek, and thus the feature IRI will need to change
17:42:03 <Zakim> ... Claes, JonathanJ, Kangchan, JereK, DanielColoma, Hixie, marengo, tlr, Laura_Arribas, Bryan, fhirsch, darobin, Zakim, RRSAgent, DanC, arve, MoZ, ilkka, arg, trackbot, dom
17:42:35 <paddy> No, I'm not on the phone
17:42:57 <fhirsch> richard notes separate spec versioning from detailed versioning of content
17:43:23 <Bryan> richt: the BONDI n-to-m model is very good, the problem is when bad user agents don't comply to what the user and policy expects 
17:43:39 <Bryan> richt: if the implementation is incorrect, where does the blame lie?
17:43:40 <paddy> I can only pay full attention later today
17:43:46 <Bryan> dom: with the runtime vendor
17:44:14 <Bryan> drogersuk: are you asking if the runtime should be verified to ensure compliance?
17:44:26 <paddy> ok, thanks
17:44:34 <Bryan> richt: the vendors need to ensure compliance
17:46:23 <Bryan> bryan: web runtime application installation/update controls should address the compliance issue 
17:47:26 <Bryan> drogersuk: the policy is itself also an issue if malformed 
17:47:56 <Bryan> fhirsch: enter an issue in the chat, but non-conforming implementations or data are a secondary issue at this point
17:48:36 <tlr> zakim, call salon_5
17:48:36 <Zakim> ok, tlr; the call is being made
17:48:37 <Zakim> UW_DAP(TPAC)11:30AM has now started
17:48:37 <Zakim> +Salon_5
17:48:38 <tlr> zakim, code?
17:48:38 <Zakim> the conference code is 3279 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr
17:49:01 <tlr> zakim, call salon_5
17:49:01 <Zakim> ok, tlr; the call is being made
17:49:02 <Zakim> +Salon_5.a
17:49:04 <schittur2> schittur2 has joined #dap
17:49:10 <tlr> zakim, drop salon_5
17:49:10 <Zakim> Salon_5 is being disconnected
17:49:12 <tlr> zakim, drop salon_5.a
17:49:12 <Zakim> -Salon_5
17:49:12 <Zakim> Salon_5.a is being disconnected
17:49:13 <Zakim> UW_DAP(TPAC)11:30AM has ended
17:49:13 <Zakim> Attendees were Salon_5, Salon_5.a
17:49:17 <tlr> zakim, call salon_5
17:49:17 <Zakim> ok, tlr; the call is being made
17:49:18 <drogersuk> ISSUE: How to handle malformed policies, policy validity and intentional abuse of policy? How is policy deadlock handled? e.g. Only dial +39 numbers + Never dial +39 numbers
17:49:18 <trackbot> Created ISSUE-35 - How to handle malformed policies, policy validity and intentional abuse of policy? How is policy deadlock handled? e.g. Only dial +39 numbers + Never dial +39 numbers ; please complete additional details at http://www.w3.org/2009/dap/track/issues/35/edit .
17:49:18 <Zakim> UW_DAP(TPAC)11:30AM has now started
17:49:19 <Zakim> +Salon_5
17:49:21 <Bryan> fhirsch: we need some resoutions, e.g. "we will have features", and how general we will be with capabilities etc
17:49:24 <Zakim> + +1.781.534.aaaa
17:49:58 <Bryan> fhirsch: we all seem to be in agreement on the features, and will formalize that later - not sure how to address capabililties 
17:50:03 <tlr> zakim, aaaa is maybe arve
17:50:03 <Zakim> I don't understand 'aaaa is maybe arve', tlr
17:50:05 <dom> dom: note that our policy framework shouldn't be limited to the scope of our own charter — it needs to work for APIs defined in other W3C groups (e.g. Geolocation, WebApps)
17:50:25 <Bryan> slewontin: think need to define capability semantics is unavoiable
17:50:30 <paddy> I would support defining device capabilities for those specific capabilities listed in the charter
17:50:48 <paddy> but at the same time set out the framework by which additional capabilities get defined
17:50:50 <Bryan> slewontin: policy processing model should be orthogonal to this discussion
17:51:10 <fhirsch> believe we have agreement to have "features" and standardize that, also will need to define capabilities for APIs of this WG and some related W3C work
17:51:13 <Bryan> Suresh: it depends upon how the policy document is to be defined
17:51:33 <fhirsch> also will need some semantics discussion of cababilities
17:51:39 <Bryan> slewontin: would propose a requirement that the policy expression and processing model be orthogonal
17:52:01 <Bryan> fhirsch: e.g. a URI or string that allows loose coupling
17:53:01 <arve> arve has joined #dap
17:53:12 <Bryan> dom: we have said we plan to let the user make decisions which is a UI-related objective, and feature dependent, but will the processing model etc affect those presentation requirements?
17:53:31 <fhirsch> general agreement to treat feature/capabilities separeate from general policy model
17:53:40 <fhirsch> with linkage of URIs/strings etc
17:53:44 <fhirsch> ?
17:54:12 <Bryan> dom: take a widget accessing the camera, don't we need ability to express requirements on when/how the user is informed?
17:54:49 <Bryan> slewontin: if we do need to present something, it needs to be presented in a useful way and semantically meaningful to the user
17:55:01 <Zakim> +arve
17:55:15 <tlr> zakim, mute arve
17:55:15 <Zakim> arve should now be muted
17:55:36 <tlr> ack arve
17:55:45 <darobin> arve?
17:55:50 <tlr> zakim, call thomas-mobile
17:55:50 <Zakim> ok, tlr; the call is being made
17:55:52 <Zakim> +Thomas
17:56:08 <darobin> Oslo this is Santa Clara please come in
17:56:18 <Zakim> -Thomas
17:56:37 <tlr> zakim, who is making noise?
17:56:49 <Zakim> tlr, listening for 11 seconds I heard sound from the following: arve (87%)
17:57:07 <arve> Zakim, mute me
17:57:07 <Zakim> arve should now be muted
17:57:18 <tlr> zakim, call thomas-mobile
17:57:18 <Zakim> ok, tlr; the call is being made
17:57:20 <Zakim> +Thomas
17:57:52 <nallott> nallott has joined #DAP
17:58:16 <Bryan> bryan: prompts should influence the processing model
17:58:19 <Zakim> -Thomas
18:00:12 <Bryan> slewontin: we can have an API that  implies user consent in the way is provided
18:00:14 <fhirsch> user consent can be implicit in API definition, e.g. if API requires camera user to press camera button, essentially giving consent
18:00:52 <plh-css> plh-css has joined #dap
18:00:54 <Bryan> fhirsch: it was an important point that we want to ensure user consent but avoid prompts where possible
18:01:22 <AnssiK> q+
18:01:31 <Bryan> slewontin: it is possible to have implicit consent because the applicaiton was signed
18:01:43 <fhirsch> ack anssiK
18:01:59 <fhirsch> anssiK asks about domain based trust
18:02:09 <Bryan> AnssiK: is a  domain based model included ?
18:02:38 <fhirsch> see http://www.w3.org/2008/security-ws/papers/SecurityPolicyNokia.pdf
18:02:45 <Bryan> slewontin: yes, in the access policy model and trust policy model should include domain based approach
18:03:38 <mmani> mmani has joined #dap
18:03:42 <darobin> q+ tlr
18:03:59 <dom> q+ suresh
18:04:01 <fhirsch> ack tlr
18:04:12 <Bryan> bryan: in BONDI we have flexibilty to use multiple models
18:04:12 <tlr> tlr has joined #dap
18:05:12 <fhirsch> q+
18:05:17 <Bryan> thomas: as we talk about getting high assurance about identity of web applications, we need to mind the HTML model which is limited to the domain model
18:05:33 <dom> ack fh
18:05:36 <Bryan> thomas: thus we need to be clear on where we are limited to the model provided by HTML5
18:06:08 <Bryan> fhirsch: if the origin is HTTPS, doesn't that provide equivalence to HTML5?
18:06:13 <dom> q+ slewontin
18:06:16 <dom> ack su
18:06:18 <fhirsch> ack suresh
18:06:31 <Bryan> thomas: the information in the certificate is not addressed in HTML5
18:06:33 <Benoit> Benoit has joined #dap
18:07:07 <Bryan> suresh: how to the feature and access element play into this discussion?
18:07:09 <Bryan> q+
18:07:30 <richt> q+
18:07:54 <mani> mani has joined #dap
18:07:56 <Bryan> fhirsch: access is expected to be a short-term solution to an immediate problem, to keep it limited in scope
18:08:05 <tlr> q?
18:08:08 <slewontin> q+
18:08:08 <Bryan> darobin: also not to constrain DAP
18:08:29 <AnssiK> here's a thesis related to the domain-based trust model I talked about http://lib.tkk.fi/Dipl/2009/urn100073.pdf
18:08:30 <fhirsch> ack slewontin
18:09:26 <Bryan> slewontin: want to address the issue brought up, in a certain way we said we will just have to live with the HTML5 sandboxing model - for widgets this is OK, but for browser-based webapps this is a serious issue
18:09:33 <fhirsch> stephen notes that contstraints of html5 and javascript sandboxing too limiting
18:10:08 <Bryan> slewontin: it is an issue we are going to have to address separately from the policy model
18:10:54 <Bryan> slewontin: we may not implement domain-based access since the javascript same-domain based security needs to be rethought from the ground up
18:11:38 <Bryan> drogersuk: it depends upon the use case, and the assurance that you can trust the DNS system
18:11:59 <fhirsch> issue: how far can we go with domain based trust model given constraints of HTML5 security model 
18:11:59 <trackbot> Created ISSUE-36 - How far can we go with domain based trust model given constraints of HTML5 security model  ; please complete additional details at http://www.w3.org/2009/dap/track/issues/36/edit .
18:12:24 <fhirsch> q?
18:12:54 <Bryan> drogersuk: what we need is guidance to warn people of the risks of domain-based models
18:13:48 <Bryan> slewontin:  the limitations of the user-agent need to be taken into account
18:13:55 <slewontin> q+
18:14:07 <fhirsch> ack bryan
18:14:18 <fhirsch> bryan notes roaming can impact trust model
18:14:23 <tlr> q+ to suggest that we keep our layers straight
18:14:32 <fhirsch> q+ anssi
18:15:34 <fhirsch> bryan notes we need framework that goes browser
18:15:37 <fhirsch> ack richt
18:15:40 <Bryan> q-
18:16:20 <fhirsch> richard notes variants of session, one shot etc for domain based trust
18:16:41 <fhirsch> ansii notes trust applicatoin versus application instance
18:16:56 <dom> TTL's of policy decisions
18:17:06 <drogersuk> q+
18:17:18 <Bryan> bryan: we need to address network roaming, e.g. 3G-WiFi, and trust in the DNS system as a requirement - if we need additional feature support e.g. reliance upon certificate data and HTML5 does not provide that, DAP should be able to create new requirements ala what BONDI supports for this
18:18:03 <Claes> q+
18:18:20 <fhirsch> ack slewontin
18:19:07 <Bryan> slewontin: the issue with sandboxing was discussed last year, we can find the discussion details to refresh the group
18:19:11 <fhirsch> ack tlr
18:19:11 <Zakim> tlr, you wanted to suggest that we keep our layers straight
18:19:15 <fhirsch> ack anssi
18:19:18 <richt> note to JereK: the concept was that different trust models may denote more or less opt-in requirements for users. One-shot as an option for domain-based opt-in due to the inherent security concerns...
18:19:50 <fhirsch> tlr clarifies we cannot trust network because of layerin
18:19:55 <Bryan> thomas: re different networks and assurance, we need to think of the web as an end-to-end environment in which the network layer is not trusted
18:19:58 <fhirsch> s/layerin/layering
18:20:25 <dom> q?
18:20:33 <Bryan> thomas: we are focusing on the level of properties exposed through HTTP
18:20:34 <Bryan> q+
18:20:34 <fhirsch> ack drogersuk
18:20:51 <tlr> proposed requirement: we only use information that's visible on the HTTP level, not security properties of lower level network protocols
18:22:15 <nwidell> nwidell has joined #dap
18:22:21 <dom> zakim, close the queue
18:22:21 <Zakim> ok, dom, the speaker queue is closed
18:22:28 <Bryan> drogersuk: in the real world, there is an assumption of trust in the service provider and is an additional source of information to use in policies  - 
18:22:55 <fhirsch> ack claes
18:23:12 <Bryan> drogersuk: 2nd point is re abuse cases, it doesn't matter if we trust a site and have recorded a user consent through, since a spoofing attack is possible
18:23:35 <fhirsch> issue: domain spoofing
18:23:35 <trackbot> Created ISSUE-37 - Domain spoofing ; please complete additional details at http://www.w3.org/2009/dap/track/issues/37/edit .
18:24:17 <ingmar> ingmar has joined #dap
18:25:29 <Bryan> action: claes should issue recommendation on the granularity of the security system
18:25:29 <trackbot> Created ACTION-38 - Should issue recommendation on the granularity of the security system [on Claes Nilsson - due 2009-11-09].
18:26:30 <fhirsch> tlr notes can rely on http and ssl
18:26:35 <Bryan> bryan: we need to rely upon what HTTP relies upon also
18:27:19 <Bryan> thomas: we should also rely upon SSL as a dependency, but perhaps not DNS
18:27:47 <tlr> s/as a dependency/as a source of information/
18:27:58 <tlr> s/but perhaps not DNS/but DNSSEC, e.g., isn't directly linked to what we interact with/
18:29:39 <Zakim> - +1.781.534.aaaa
18:29:48 <Bryan> fhirsch: we have at least 6 different areas we should get concrete proposals on: access control, trust model, capabilities,  features, API security considerations, security threats & privacy risks
18:30:51 <dom>  zakim, pick a victim?
18:30:51 <Zakim> I don't understand your question, dom.
18:30:54 <dom>  zakim, pick a victim
18:30:54 <Zakim> Not knowing who is chairing or who scribed recently, I propose arve (muted)
18:30:57 <dom>  zakim, pick a victim
18:30:57 <Zakim> Not knowing who is chairing or who scribed recently, I propose arve (muted)
18:33:11 <Zakim> -arve
19:00:53 <Benoit> Benoit has joined #dap
19:02:28 <tlr_> tlr_ has joined #dap
19:03:24 <richt>  Scribe: richt
19:03:25 <darobin> darobin has joined #dap
19:03:46 <richt> Scribe_Nick: richt
19:05:38 <Zakim> +arve
19:06:08 <paddy> paddy has joined #dap
19:06:40 <johnnyg> johnnyg has joined #dap
19:06:45 <weinig> weinig has joined #dap
19:06:59 <richt> ScribeNick: richt
19:07:09 <ifette> ifette has joined #dap
19:07:12 <chaals> chaals has joined #dap
19:07:16 <ArtB> ArtB has joined #dap
19:07:20 <chaals> Present+ Chaals (Webapps)
19:07:23 <shiki> shiki has joined #dap
19:07:23 <adrianba> adrianba has joined #dap
19:07:35 <richt> topic:  File API
19:07:42 <jorlow> jorlow has joined #dap
19:07:48 <richt> work started in 2006. merged work to webapps.
19:07:50 <JonathanJ> JonathanJ has joined #dap
19:07:56 <ArtB> Present+ ArtB
19:08:03 <richt> darobin: DAP defining file system API
19:08:07 <JonathanJ> Present+JonathanJ
19:08:13 <Travis> Travis has joined #dap
19:08:19 <richt> darobin: this meeting is to get everyone up to date with File API progress
19:08:24 <richt> darobin: and how we can coordinate
19:08:31 <weinig> Present+ SamW (WebApps)
19:08:32 <sicking> sicking has joined #dap
19:08:33 <ifette> present+ ifette (DAP, webapps)
19:08:44 <Claes> Claes has joined #dap
19:08:57 <sicking> present+ sicking (webapps, mozilla)
19:09:04 <Vladimir> Vladimir has joined #dap
19:09:04 <darobin> Scribe: Richard
19:09:08 <pererik> pererik has joined #dap
19:09:08 <darobin> ScribeNick: richt 
19:09:32 <ArtB> RRSAgent, make minutes
19:09:32 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html ArtB
19:09:37 <Zakim> -Salon_5
19:10:03 <jorlow> jorlow has joined #dap
19:10:10 <dom> zakim, call Salon_5
19:10:10 <Zakim> ok, dom; the call is being made
19:10:12 <Zakim> +Salon_5
19:10:18 <anne> anne has joined #dap
19:10:25 <darobin> File API: http://dev.w3.org/2006/webapi/FileAPI/
19:10:27 <richt> Arun: any features device API wants to introduce should layer elegantly with File API
19:10:38 <shepazu> shepazu has joined #dap
19:10:58 <richt> Arun: synchronous access to the file although this was a non-starter for specs.
19:11:14 <darobin> File System API requirements: http://www.w3.org/TR/dap-api-reqs/#file-system
19:11:16 <richt> Arun: second incarnation was asynchronous with callback functions.
19:11:32 <jorlow_> jorlow_ has joined #dap
19:11:40 <richt> Arun: however, rather than callbacks we went with an Event model. This is the 3rd incarnation of File API
19:12:37 <dom> ->
19:12:48 <dom> -> http://dev.w3.org/2006/webapi/FileAPI/ FileAPI Editor’s Draft
19:12:48 <richt> Arun: discusses the individual components of the File API spec.
19:13:11 <darobin> the Blob API: http://1416andcounting.files.wordpress.com/2009/03/theblobremakebox.jpg
19:14:01 <arve> Is having someone pose the question OK?
19:14:05 <richt> Arun: use of URNs to identify a file
19:14:24 <anne> arve, you could type it in and see if somebody picks up on it
19:14:46 <richt> Arun: File API allows you to receive progress events as file is being read
19:15:16 <daniel> daniel has joined #dap
19:15:19 <nwidell> nwidell has joined #dap
19:15:34 <richt> Arun: one of the drawbacks of call based model was that it did not elegantly account for progress events
19:15:47 <richt> Arun: hence the 3rd incarnation based on the Event model
19:17:24 <darobin> q?
19:18:15 <richt> Arun: In discussions it was also useful to preview files. In 2nd incarnation we had a scheme. in 3rd incarnation we have URNs
19:18:36 <richt> Arun: URNs have a lifetime of the document
19:18:43 <claudio> claudio has joined #dap
19:18:58 <dom> ack B
19:18:58 <darobin> ack Bryan 
19:19:02 <richt> Arun: not general concensus about how to identify files (in editor's comments in spec)
19:19:09 <richt> Bryan: how do we address writing to a file?
19:19:18 <schittur2> schittur2 has joined #dap
19:19:26 <Magnus> Magnus has joined #dap
19:19:30 <richt> Arun: there are no write methods. This is subject to security considerations and needs to be discussed further
19:19:52 <richt> Arun: There is a security error placeholder in the File API spec
19:19:59 <fhirsch> arun notes security considerations more limited for read than write
19:20:05 <richt> Arun: but not clear how this is used currently
19:20:10 <Bryan> q-
19:20:12 <Bryan> q+
19:20:19 <dom> zakim, reopen the queue
19:20:19 <Zakim> ok, dom, the speaker queue is open
19:20:28 <Bryan> q+
19:20:59 <shepazu> sandbox++
19:21:06 <sicking> q+
19:21:17 <ifette> me
19:21:38 <ifette> Maciej
19:21:41 <ifette> is talking
19:21:59 <DanielColoma> DanielColoma has joined #dap
19:22:08 <DanielColoma> Present+ DanielColoma
19:22:13 <richt> mjs: if you have a single API. read access to any file a user can access. that has serious security risks to ensure that other files aren't exposed
19:22:24 <richt> mjs: so files in a webapp should be treated in a seperate way
19:22:38 <soonho> soonho has joined #dap
19:22:58 <tlr__> tlr__ has joined #dap
19:22:59 <richt> ian: if the user passes in a file reference and let the app upload is a user writing to that more dangerous?
19:23:02 <Marcos> Marcos has joined #dap
19:23:25 <dom> -> http://www.w3.org/TR/dap-api-reqs/#file-system DAP Requirements for filesystems API
19:23:30 <richt> mjs: the write handle should be different to the read handle for the file dialog
19:23:34 <cgi-irc> cgi-irc has joined #dap
19:23:48 <darobin> q?
19:23:52 <darobin> ack Bryan 
19:23:53 <dom> ack Br
19:24:10 <richt> Bryan: how do we access local files in particular locations and discover particular locations?
19:24:23 <richt> Bryan: how are those locations represented in URN?
19:24:57 <richt> Bryan: what are the available mount points that I can access?
19:25:00 <tlr> tlr has joined #dap
19:25:04 <richt> Arun: file API has not worked on this issue
19:25:37 <shepazu> q+
19:25:42 <darobin> q+ to talk about Blobs, defining writing
19:25:45 <richt> Arun: with the existing file picker. you can poke in to the system. no hook but file picker mitigates this
19:25:47 <dom> q+ anne
19:26:05 <marcin2> q+
19:26:12 <richt> Bryan: writing to a file and determining read locations: the use cases are different between DAP and File API?
19:26:19 <fhirsch> q?
19:26:44 <Bryan> q-
19:26:48 <richt> Arun: has some concerns on the requirements in BONDI and DAP File System APIs
19:26:58 <anne> q-
19:27:26 <darobin> ack sicking 
19:27:38 <richt> drogersuk: issues have been addressed in BONDI 1.1
19:27:40 <arun> arun has joined #dap
19:27:46 <MikeSmith> q?
19:28:10 <drogersuk> correction - BONDI 1.01
19:28:35 <richt> speaker?
19:29:06 <Benoit> Benoit has joined #dap
19:29:17 <richt> sicking: anything that allows read or write access beyond what we have already is going to be extremely hard.
19:29:47 <darobin> http://www.w3.org/TR/dap-api-reqs/#file-system
19:29:51 <fhirsch> q+
19:30:02 <noahm> noahm has joined #dap
19:30:25 <dom> -> http://bondi.omtp.org/1.1/cr/apis/filesystem.html BONDI Filesystem API
19:30:27 <anne> youwant http://dev.w3.org/2009/dap/file-system/
19:30:43 <richt> sicking: keep security and the API orthogonal
19:30:45 <anne> (remove cvsweb if you want the actual files and not the CVS crap)
19:30:54 <drogersuk> BONDI 1.01 version here: http://bondi.omtp.org/1.01/apis/filesystem.html (current approved)
19:30:58 <Benoit> Benoit has joined #dap
19:30:58 <richt> hixe: not sure if this can be orthogonal
19:31:06 <richt> s/hixe/hixie
19:31:29 <richt> Arun: there is clearly a wish list for write capability. There are some good use cases that we should discuss
19:31:32 <fhirsch> q?
19:32:04 <richt> Arun: if version 1 of File API has any observations from DAP WG this is useful input. Would like to progress to TR
19:32:18 <JariA> JariA has joined #dap
19:32:35 <richt> darogersuk: would be good to have leadership from the chairs on how to resolve the differences
19:32:52 <richt> s/darogersuk/drogersuk
19:32:59 <Bryan> q+
19:33:08 <dom> q?
19:33:45 <richt> Arun: lots of discussions around what the security hangs off. lots of considerations based on what we choose
19:34:01 <richt> Arun: File API hangs off the global object
19:34:10 <richt> Arun: There could be a file writer object?
19:34:37 <richt> drogersuk: We have to make these decisions quickly to avoid fragmenting and going in different directions between groups
19:35:05 <chaals> q+ to say Opera implements
19:35:33 <shepazu> (WebApps File API: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/FileAPI/Overview.html?rev=1.9 )
19:35:51 <richt> drogersuk: the implementors of BONDI are browsers and widget user agents
19:36:06 <richt> drogersuk: many company initiatives in progress 
19:36:35 <dom> ack cha
19:36:35 <Zakim> chaals, you wanted to say Opera implements
19:36:56 <richt> chaals: we implement this in the browser. we have it running in widgets. based on significant security considerations. runs in opera unite
19:37:11 <richt> chaals: doesn't see fundamental disconnect between widgets and web apps
19:37:23 <richt> chaals: it makes sense to be the same system and same API in these environments
19:37:31 <chaals> q-
19:37:41 <mjs> mjs has joined #dap
19:38:07 <richt> marcin2: thinks concepts introduced in BONDI are relevant to web apps. lots of reuse may be possible.
19:38:16 <chaals> s/implement this/implement a full filesystem api/
19:38:29 <richt> marcin2: would like to rename File API to File Upload API
19:38:43 <dom> FileReader API rather than FileUpload, at the very most
19:38:59 <richt> marcin2: in BONDI/DAP we want to manipulate the file system. Different with a URN abstraction?
19:39:06 <chaals> [agree with DOM that this is now a fileReader API]
19:39:10 <richt> s/different/difficult
19:39:33 <fhirsch> Chair: Robin Berjon, Frederick Hirsch
19:39:34 <dom> s/DOM/Dom/
19:39:42 <fhirsch> q?
19:39:53 <drogersuk> q+
19:40:01 <richt> Arun: 'upload' may be interpreted differently. File API may work with some form of 'upload' but this a file read spec not file upload spec
19:40:08 <mjs> q+
19:40:14 <richt> Arun: it is lacking write metaphors. any way to write to a file
19:40:18 <anne> Web File API vs System File API?
19:40:29 <dom> ack shep
19:40:34 <weinig> q+
19:40:49 <richt> shepazu: when we talk about evolution do we mean this version or next?
19:41:10 <richt> Arun: we should ship an evolution soon. agree on it, ship it then create version 2 addressing other issues
19:41:14 <Kai> Kai has joined #dap
19:41:26 <richt> shepazu: a File API that doesn't let me write is not useful
19:41:35 <richt> sicking: its useful but there are other use cases
19:41:57 <richt> Arun: what we have in version 1 is the current level. there are use cases for writing.
19:42:00 <dom> s/is not useful/is not as useful to me/
19:42:30 <dom> q?
19:42:33 <dom> ack dar
19:42:33 <Zakim> darobin, you wanted to talk about Blobs, defining writing
19:42:33 <darobin> ack
19:42:47 <marcin2> q-
19:42:59 <arun> I am willing to look at use cases, generate requirements, and edit draft of write capabilities.
19:42:59 <richt> darobin: 2 things. 1.) clarify status of blob interface - is it generic for handling binary data
19:43:21 <richt> sicking: yes and no. it is synchronous. may have need for byte array. Intent is for it to be generic
19:43:22 <ingmar> ingmar has joined #dap
19:43:35 <richt> darobin: hasn't seen discussion on linking bytearray and blob
19:43:37 <richt> sicking: agree
19:43:49 <richt> darobin: it's a question that needs to be addressed
19:43:57 <dom> q?
19:44:05 <ArtB> q+ to get clarification on when DAP plans to publish the FPWD of their File System API
19:44:42 <soonho> soonho has left #dap
19:44:46 <slewontin> q+
19:44:53 <soonho> soonho has joined #dap
19:44:58 <richt> mjs: this would be a good topic for friday's meeting
19:45:26 <tlr> when is the joint meeting?
19:45:34 <tlr> ECMA TC39 / HTML5 / webApps
19:45:49 <mjs> tlr, it's Friday morning
19:46:10 <weinig> q-
19:46:58 <dom> ack fhir
19:47:24 <richt> fhirsch: CRUD of file system in Device API charter
19:48:14 <richt> fhirsch: do we need to think about ACLs or other forms and levels of permissions
19:49:26 <richt> chaals: File API plans to coordinate with DAP group. We want something that layers smoothly between the two.
19:49:45 <arun> q+
19:49:54 <richt> chaals: do we want to add ACLs. not something we have considered yet. It gets complicated and not something to ship right now.
19:49:54 <arun> q+ to discuss use cases 
19:50:06 <richt> chaals: may be something for the future.
19:50:55 <richt> fhirsch: not just the chairs working. the WG should assist on this topic
19:51:12 <nwidell> nwidell has joined #dap
19:51:36 <richt> drogersuk: chairs should liase - own the master doc and have some discussions in WGs and publicly
19:51:43 <dom> [I don't think it needs to be owned by the Chairs; I don't see why it would, in any case]
19:51:57 <drogersuk> q-
19:51:59 <arun> q?
19:52:14 <darobin> ack arun 
19:52:14 <Zakim> arun, you wanted to discuss use cases
19:52:36 <Hixie> darobin: can you repeat the actual item for which you want volunteers? it didn't get minuted
19:52:43 <Hixie> s/darobin:/darobin,/
19:53:05 <darobin> RB: looking for volunteers to look at how the layering of File API, Writer, FS browsing can be layered
19:53:17 <richt> The action on the table is: someone to ask questions via mailing lists on how these two initiatives can layer together. Collate use cases - what are the exact write API use cases for the web?
19:54:30 <JariA> JariA has joined #dap
19:54:35 <richt> ACTION: chaals to Collate use cases - what are the exact write API use cases for the web. Hoe the two initiatives can layer.
19:54:35 <trackbot> Sorry, couldn't find user - chaals
19:54:43 <darobin> ACTION: chaals to shepperd the discussion on File API, Reader, Writer, FS Browser layers; collecting use cases
19:54:43 <trackbot> Sorry, couldn't find user - chaals
19:55:13 <darobin> Volunteers to help: Arun, Hixie
19:55:20 <dom> ACTION: Robin to check that Chaals shepperds the discussion on file API, Reader, Writer, FS Browser layers; collecting use cases
19:55:21 <trackbot> Created ACTION-39 - Check that Chaals shepperds the discussion on file API, Reader, Writer, FS Browser layers; collecting use cases [on Robin Berjon - due 2009-11-09].
19:55:21 <darobin> ack
19:55:28 <darobin> q?
19:55:31 <darobin> ack Bryan 
19:56:15 <fhirsch> chaals noted that policy for File API can be someone simple as first cut, not addressing ACLs but file system access itself
19:56:18 <richt> Bryan: looking at File API, DAP charter, BONDI: the file system API in DAP charter is focused on providing native resource access similar to any other (non-web) device API
19:56:28 <fhirsch> he notes later effort could be more detailed
19:56:34 <tlr> tlr has changed the topic to: Mute your mobile phones | DAP F2F agenda http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0003.html
19:57:07 <ifette> q+
19:57:07 <kaz> kaz has joined #dap
19:57:11 <richt> Bryan: File System API and File API have different use cases? Valid in their own domains?
19:57:13 <darobin> q?
19:57:14 <Travis> Travis has joined #dap
19:57:16 <dom> [but clearly a FileSystem API should be able to re use the File Interface defined in FileUpload/Reader/ ...]
19:57:30 <ifette> q+ to say that we need simplicity, but we don't want two totally separate APIs depending on where i want to store a file
19:57:33 <richt> shepazu: we want the UX to be consistent across usage
19:58:13 <Bryan> Bryan: The DAP FileSystem API is focused clearly in the DAP charter and as already implemented in products based upon BONDI, as a "device API" specifically on the functionality expected of an applications accessing the device filesystem directly. The Webapps FileAPI is clearly focused on the role of a web API using web semantics, and is different in objective than device API's, e.g. accessing a device native client functionality such as a messaging client.
19:59:10 <chaals> [I pretty much diametrically disagree with you Bryan...]
19:59:22 <richt> Eric Irving: generating a set of use cases for a web file system. readable/writable files/directories. There will be a lot of overlapping use cases between File API and DAP WG
19:59:26 <shepazu> [I don't want to have a situation where some spec is developed for writing files, but it's not implemented by desktop browsers, just on mobiles]
19:59:32 <richt> Eric Irving: see requirements in DAP but not use cases
19:59:51 <richt> darobin: use same use cases. requirements extracted from inputs from other groups
19:59:51 <fhirsch> issue: use cases and threat model for security requirements
19:59:51 <trackbot> Created ISSUE-38 - Use cases and threat model for security requirements ; please complete additional details at http://www.w3.org/2009/dap/track/issues/38/edit .
20:00:01 <fhirsch> issue: use cases for API requirements where needed
20:00:01 <trackbot> Created ISSUE-39 - Use cases for API requirements where needed ; please complete additional details at http://www.w3.org/2009/dap/track/issues/39/edit .
20:00:10 <richt> darobin: if for some APIs we don't need use cases then we'll skip otherwise they will be added
20:00:43 <NEWTON_VAGNER_DIN> NEWTON_VAGNER_DIN has joined #dap
20:00:45 <darobin> q?
20:00:46 <richt> darobin: quickly listed requirements. if there is any doubts we will go to use cases
20:00:50 <dom> ack mjs
20:01:33 <richt> mjs: thinks there is a fundamental disconnect between widgets and web pages
20:01:37 <ifette> +1 othermaciej
20:01:41 <richt> mjs: installing widgets involves a user trust decision
20:01:57 <richt> mjs: following a link does not denote a trust decision.
20:02:08 <chaals> *cou*phishing
20:02:23 <weinig> q+
20:02:48 <richt> mjs: this has an impact on web api design. In File API, file is chosen by the user, when they initiate the process.
20:02:51 <chaals> q+ to note that we have *browsers* that ask if we want to follow a link, specifically for trust reasons.
20:03:06 <kaz> kaz has left #dap
20:03:08 <richt> mjs: throwing up permissions dialogs is not acceptable in the web domain. makes a difference to the API design
20:03:48 <richt> mjs: important when designing the API - is it only for widgets with explicit trust decisions or the web where we don't have and don't want to create those trust decisions
20:04:13 <Bryan> q+
20:04:22 <richt> mjs: perhaps the widget trust decisions are a superset of web decisions
20:04:50 <chaals> ["the public web" isn't "the web"]
20:05:14 <ifette> q?
20:05:19 <chaals> q?
20:05:54 <shepazu> [I wonder if Maciej is saying that Web pages shouldn't be able to say they want to write to a file?]
20:05:58 <richt> hixie: the best api for a file system on a device may not be a perfect superset of a web based file system api
20:06:06 <richt> hixie: they have different security architectures.
20:06:19 <marcin2> q+
20:06:20 <richt> mjs: they may end up not as supersets if there are different security constraints
20:06:41 <chaals> nikunj meht
20:06:42 <sicking> Nikunj from Oracle
20:06:44 <chaals> mehta
20:07:38 <richt> Nikunj: a web application could write to its own sandboxed area. Read and write may not be a disjoint set as opposed to widgets
20:07:39 <dom> [I think the use cases will also help identifying what features we need in priority for a write/filesystems API]
20:08:03 <chaals> [Dom, agree]
20:08:26 <shepazu> [which mailing list(s) should this coordination happen?]
20:08:31 <michaeln> michaeln has joined #dap
20:08:49 <richt> let's get through the queue....
20:08:52 <dom> zakim, close the queue
20:08:52 <Zakim> ok, dom, the speaker queue is closed
20:08:53 <drogersuk> q+
20:08:55 <darobin> ack ArtB 
20:08:55 <Zakim> ArtB, you wanted to get clarification on when DAP plans to publish the FPWD of their File System API
20:09:15 <richt> ArtB: we will go round in circles until we have solid use cases
20:09:17 <shepazu> s/happen/happen on
20:09:23 <richt> ArtB: when will File API be available for FPWD
20:09:29 <richt> Arun: believe we could go out now
20:09:31 <mjs> shepazu, what I'm saying is, it's ok to let the user choose a file to let a Web app write to it in an active way (like a "Save As" dialog) but it would not be ok for a Web App to choose a place in the filesystem to write to and throw up an OK/Cancel dialog to the user
20:09:50 <JonathanJ> JonathanJ has joined #dap
20:10:02 <mjs> shepazu, (at least, that's my judgment of the balance between usability and security for the browsable Web)
20:10:15 <richt> darobin: DAP rule for FPWD: is it reasonable feature complete for patent exclusion process. We don't have a timeline for our release.
20:10:28 <richt> darobin: we will have a better idea when we've had the layering discussion with File API
20:10:29 <shepazu> [ mjs : okay, yes, that seems totally sensible... thanks for the clarification]
20:10:42 <dom> q?
20:10:45 <dom> ack sle
20:10:46 <darobin> ack slewontin 
20:10:52 <richt> darobin: FPWD *could* be in Dec/Jan but no commitment to that
20:11:15 <michaeln> sorry for talking out of q order... didn't realize there was such a thing
20:11:30 <richt> slewontin: discussed earlier that it's sensible to distiguish between implicit and explicit permissions declaration in APIs
20:11:31 <shepazu> [mjs: in fact, maybe it should be explicitly handled by the browser's file save handler]
20:11:38 <richt> slewontin: makes sense as a good place to start
20:11:43 <darobin> q+ drogersuk 
20:12:16 <richt> slewontin: However, File API has no security considerations in it. Would be helpful to take security aspects and create a Security Considerations section in File API
20:12:17 <dom> zakim, reopen the queue
20:12:17 <Zakim> ok, dom, the speaker queue is open
20:12:21 <dom> q+ drogersuk
20:12:22 <shepazu> [... as opposed to allowing "cool" custom file dialogs]
20:12:24 <dom> zakim, close the queue
20:12:24 <Zakim> ok, dom, the speaker queue is closed
20:12:39 <Claes> Claes has joined #dap
20:12:45 <Zakim> + +1.781.534.aabb
20:12:51 <mjs> shepazu, right, the file save dialog would have to be trusted UI provided by the browser
20:12:54 <darobin> ack ifette 
20:12:54 <Zakim> ifette, you wanted to say that we need simplicity, but we don't want two totally separate APIs depending on where i want to store a file
20:12:58 <arun> ACTION: Arun to write up security considerations section of existing File API spec. in preparation for FPWD
20:12:59 <trackbot> Created ACTION-40 - Write up security considerations section of existing File API spec. in preparation for FPWD [on Arun Ranganathan - due 2009-11-09].
20:14:09 <Qiuling> Qiuling has joined #dap
20:14:14 <richt> Ian: e.g. would like to delegate trust to a page/domain such as facebook. May require different APIs. If they have to be different we should have good reasons why.
20:14:54 <dom> -> http://www.w3.org/2008/webapps/wiki/Coordination WebApp’s WG coordination wiki
20:15:03 <richt> sicking: you can trust a page to read file system. would be hard to delegate trust.
20:15:05 <dom> q?
20:15:05 <chaals> q?
20:15:25 <Hixie> Hixie has joined #dap
20:15:26 <darobin> ACTION: ifette to start drafting a unitarian file API
20:15:26 <trackbot> Created ACTION-41 - Start drafting a unitarian file API [on Ian Fette - due 2009-11-09].
20:15:32 <darobin> q?
20:15:34 <dom> ack weinig
20:17:16 <shepazu> [I think maybe it would be good for the webapp to be able to provide a filename and default file extension/mimetype, then based on user prefs, the browser may pop up its native file dialog (a black box to the webapp), then passes back an opaque abstract hook that the webapp to write to (within some filesize limits)]
20:18:01 <dom> [browsers already have "downloaders" UIs]
20:18:20 <dom> q?
20:18:24 <darobin> q?
20:18:27 <darobin> ack chaals 
20:18:27 <Zakim> chaals, you wanted to note that we have *browsers* that ask if we want to follow a link, specifically for trust reasons.
20:19:33 <richt> chaals: there is an industry intiative around safe browsing. e.g. this site is safe/ this site is not sage
20:19:37 <richt> s/sage/safe
20:20:00 <sicking> q+ to disagree with chaals, that is all
20:20:15 <weinig> [I think that any specification that defines how one can write to a File object, needs to be dependent on another spec which allows for File objects to be saved to the file system]
20:20:57 <mjs> weinig, I assume you mean a mechanism for the user to choose a file to write to
20:21:09 <weinig> mjs: I do
20:21:26 <dom> s/mjs:/mjs,/
20:21:30 <howard218> howard218 has joined #dap
20:21:35 <darobin> q?
20:21:51 <richt> sicking: we have warnings that things are unsafe....not any safe guarantee
20:21:53 <mjs> and yeah, I agree, the File API for reading can free-ride on <input type="file">, but there's nothing predefined for writing
20:22:22 <arun> q+
20:22:27 <richt> hixie: we do have opt-in to trust in widgets. i.e. do you trust this site?
20:23:07 <arun> q?
20:23:14 <arun> q+
20:23:25 <darobin> ack drogersuk 
20:23:31 <dom> zakim, reopen the queue
20:23:31 <Zakim> ok, dom, the speaker queue is open
20:23:33 <shepazu> mjs: yes, users would "get" that they can select a save location with a file dialog, but we should also allow the API to be used outside that model as well
20:23:44 <richt> drogersuk: disagrees. If I've sideloaded a widget. no idea where it's from therefore no implicit trust
20:24:00 <richt> drogersuk: widgets not fundamentally different to web sites
20:24:13 <chaals> [this isn't a case of one side is trusted and one is not - there are levels of (dis)trust, which are different, but in amount of distrust not fundamentally based on a difference of nature]
20:24:27 <richt> drogersuk: contents of a widget are effectively a web site.
20:24:29 <shepazu> [agree... we need more than a CYA for "trust decisions"]
20:24:43 <richt> hixie: web security model doesn't work in this case. it's an uninformed decision for the user
20:25:05 <richt> tlr: difference is when that decision is made.
20:25:07 <mjs> q?
20:26:32 <richt> drogersuk: for consistency we should only have 1 API.
20:26:45 <JereK> [might be useful to distinguish a 'simple file reader API for just browsers' from a 'more elaborate file system API that allows a widget to provide file open / save dialogs and read / write files as in a desktop app' - the latter has more extensive security implications]
20:27:01 <Hixie> q+
20:27:06 <mjs> q+ rob
20:27:18 <darobin> Zakim, close the queue
20:27:18 <Zakim> ok, darobin, the speaker queue is closed
20:27:25 <richt> Arun: web has an API in at least 2 browsers: geolocation. raises user facing message
20:27:41 <richt> Arun: suggested before that these messages may want to be implemented async / non-blocing
20:27:50 <richt> s/non-blocing/non-blocking
20:28:04 <chaals> [I wonder how Hixie imagines the UI for selecting a filesystem, as compared to that for selecting a particular file to read. That might be a bigger issue than it seems in resolving this deadlock (since as far as I can say we are saying a lot of the same things, which lead us along the same lines to the opposite conclusions :( ) ]
20:28:28 <mjs> chaals, there should be no UI for selecting a filesystem
20:28:28 <richt> Arun: other APIs on the web should be async / non-blocking. Even then, it's very hard for users to make informed desicions on the messages presented
20:28:34 <JereK> [the extent of the security implications depends on the origin of the (web)app]
20:28:50 <darobin> q?
20:29:11 <richt> slewontin: APIs don't say anything about Policies. API and Policies are orthogonal
20:29:16 <pererik> pererik has joined #dap
20:29:18 <chaals> [mjs why not?]
20:29:56 <richt> darobin: would like to get people to discuss on the mailing list(s)
20:30:32 <darobin> ack Hixie 
20:30:37 <mjs> chaals, a user can make a reasonably informed decision to open/upload a file or save to a file, but realistically a user can't make an informed decision to give a webapp the run of a whole section of the filesystem - and the potential consequences are really terrible
20:30:56 <richt> hixie: until there is a UI for providing informed trust decisions, not interested in a policy model.
20:31:04 <Hixie> IH: until we have a UI for the security policy layer that results in users making informed trust decisions, i do no think we use that on the web
20:31:15 <dom> q?
20:31:17 <Hixie> do not think we can use that, even
20:31:34 <dom> ack Br
20:32:12 <tlr> hixie's earlier note: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0133.html
20:32:22 <Zakim> - +1.781.534.aabb
20:32:31 <richt> Bryan: agree consistent user experience. policy author can choose level of permissions required. Avoid user needing to make explicit decisions
20:32:36 <dom> zakim, time speaker 1 minute
20:32:36 <Zakim> I don't understand 'time speaker 1 minute', dom
20:32:58 <dom> zakim, time speakers at 1 minute
20:32:58 <Zakim> I don't understand 'time speakers at 1 minute', dom
20:33:03 <richt> Bryan: we have an equivalent capability in BONDI. would like discussion on where that is weak.
20:33:08 <dom> zakim, time speakers at 1 minutes
20:33:08 <Zakim> ok, dom
20:33:13 <dom> ack marcin
20:33:33 <fhirsch> I think Hixie's earlier message is a different discussion, it was argument against blocking dialogs. Isn't the question now about enabling policy in general and why isn't that possible with approaches suggested in that email?
20:33:52 <Bryan> bryan: I agree there should be a consistent user experience, and one that does not depend upon explicit opt-in on every filesystem access, e.g. by selecting a file through a file selector (even though this appears to be implicit). The policy framework should enable equivalent security of filesystem access via native methods, in both browser and widget contexts. As currently supported in BONDI, the policy author can choose the level of permissions based upon sensi
20:33:52 <Bryan> tivity of filesystem access in the different contexts. This can prevent the user from needing to make adhoc security decisions as the evidence supporting trust is specific and reliable in both browser and widget contexts, and is expressable in the policy.
20:34:12 <richt> marcin2: in a layered model. we can have some APIs not covered by any security policy. File System API could be secured by security policy
20:34:27 <dom> q?
20:34:31 <darobin> ack rob
20:34:31 <dom> ack rob
20:34:47 <richt> speaker?
20:34:58 <marcin2> richt: sure
20:35:03 <chaals> rob, intel
20:35:18 <Marcos> darobin: webnotifiwhhhat? :P
20:35:20 <dom> zakim, stop timing
20:35:20 <Zakim> ok, dom
20:35:20 <marcin2> We have at least 2 architectures to handle API and security policy.
20:35:26 <richt> rob: perhaps we don't want a file system API at all considering the inherent security issues
20:35:29 <fhirsch> suggestion made not to have File API at all, rather just have shared data API etc
20:35:34 <sicking> i sort of agree
20:35:41 <marcin2> The first one is to have on set of APIs and related security policy.
20:36:09 <richt> Topic: Web Notifications
20:36:29 <slewontin> Whether you have a policy mechanism or not you still have policy, its just implicit rather than explicit
20:36:39 <fhirsch> issue: is File API appropriate abstraction/interface
20:36:39 <trackbot> Created ISSUE-40 - Is File API appropriate abstraction/interface ; please complete additional details at http://www.w3.org/2009/dap/track/issues/40/edit .
20:36:47 <richt> marcos: HTML5 originally had web notifications framework but not much interest so removed
20:36:48 <marcin2> The second architecture is to have an API (e.g. FileAPI as it is now) not to be governed by the security policy at all together with the complementary API that is governed by the security policy.
20:36:48 <dom> right, but the debate is whether you want to allow for an explicit policy mechanism
20:36:53 <JariA> JariA has joined #dap
20:37:05 <richt> marcos:  tried to revive it.
20:37:35 <richt> marcos: from opera, we've explored soft notifications (non modal) - accumulative notifications
20:38:12 <richt> marcos: took notifications out of widgets interface spec. want it to be seperate and make it work with the wider web
20:38:20 <richt> marcos: clean slate...where do we go from here?
20:38:33 <chaals> [/me notes that ARIA also has a concept of notifications, although within a web app - aria-liveregion and friends]
20:38:49 <richt> John, Google: draft proposal submitted on how we could move forward on the spec
20:38:54 <richt> John, Google: do we want to look at it
20:38:56 <richt> marcos: sure
20:39:11 <ArtB> http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification
20:39:34 <dom> s/John,/John Gregg,/
20:40:09 <shepazu> Zakim, pointer?
20:40:09 <Zakim> I don't understand your question, shepazu.
20:40:15 <marcin2> arun: "policy file" is just representation of the policy, specifically for its exchange
20:40:39 <dom> RRSAgent, pointer?
20:40:39 <RRSAgent> See http://www.w3.org/2009/11/02-dap-irc#T20-40-39
20:40:48 <AnssiK> I listed related prior art in this mail http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0172.html 
20:41:41 <richt> John_Gregg presents his proposal on moving forward on web notifications
20:42:15 <fhirsch> q+
20:42:22 <dom> zakim, reopen the queue
20:42:22 <Zakim> ok, dom, the speaker queue is open
20:42:31 <richt> darobin: will this proposal be in Chrome?
20:42:36 <fhirsch> q+
20:42:38 <tlr> http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification
20:42:39 <richt> John Gregg, Google: yes. it's in Chrome
20:43:03 <richt> marcos: removed from widgets because it has a wider context
20:43:17 <richt> darobin: this shows interest from browser vendors. comfortable going ahead with the work
20:43:28 <richt> darobin: where? put it in DAP?
20:43:40 <arun> q+ to ask about editor
20:43:49 <richt> Ian, Google: where can it move quickly and gain adoption?
20:43:51 <mib_9prtry> mib_9prtry has joined #dap
20:44:03 <johnnyg> this is John, btw
20:44:39 <richt> s/John Gregg:/johnnyg:/
20:44:43 <richt> s/John Gregg, Google:/johnnyg:/
20:45:38 <richt> fhirsch: question on Google proposal: what's the security proposal
20:46:01 <tlr> q+
20:46:02 <richt> johnnyg: noone can show notifications unless you've allowed it. If you show a notification there must be a way of revoking permission from the UI itself
20:46:11 <dom> q?
20:46:23 <tlr> q-
20:46:49 <tlr> johnnyg, have you thought of security considerations around rate limiting this piece?
20:46:52 <richt> ArtB: would be good to have a show of hands of proposed participation in this work
20:47:31 <mjs> mjs has joined #dap
20:47:31 <richt> a few hands in the area. there is interest in particpation in this
20:47:37 <richt> s/area/air
20:48:09 <richt> dom: this is not currently part of DAP charter.
20:48:14 <richt> dom: webapps may need rechartering
20:48:28 <richt> Ian, Google: perhaps it doesn't need to be a Device API
20:48:49 <richt> s/webapps may/DAP may/
20:49:40 <richt> chaals: is it in the webapps charter?
20:49:49 <richt> shapeazu: could be interpreted to be in webapps charter
20:49:57 <MikeSmith> RRSAgent, make minutes
20:49:57 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html MikeSmith
20:50:01 <richt> s/shapeazu/shepazu
20:50:04 <anne> http://www.w3.org/2008/webapps/charter/ search for "platform"
20:50:25 <richt> chaals: who's going to edit the spec?
20:50:34 <richt> johnnyg: us. webapps makes sense to me.
20:50:43 <richt> chaals: let's do this in webapps then
20:51:24 <Marcos> Marcos has joined #dap
20:51:43 <jorlow_> jorlow_ has joined #dap
20:51:50 <MikeSmith> RRSAgent, make minutes
20:51:50 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html MikeSmith
20:52:02 <dom> RRSAgent, draft minutes
20:52:02 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
20:52:05 <Travis> Travis has left #dap
20:52:17 <Marcos> Marcos has joined #dap
20:52:30 <fhirsch> rrsagent, generate minutes
20:52:30 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html fhirsch
20:52:35 <Zakim> -Salon_5
20:54:26 <soonho> soonho has left #dap
20:55:12 <mjs> mjs has joined #dap
20:59:27 <Zakim> -arve
20:59:28 <Zakim> UW_DAP(TPAC)11:30AM has ended
20:59:29 <Zakim> Attendees were Salon_5, +1.781.534.aaaa, arve, Thomas, +1.781.534.aabb
20:59:44 <paddy> paddy has joined #dap
21:10:02 <kaz> kaz has joined #dap
21:10:10 <kaz> kaz has left #dap
21:10:36 <maxf> maxf has joined #dap
21:21:09 <noahm> noahm has joined #dap
21:32:45 <Kai> Kai has joined #dap
21:33:39 <paddy> paddy has joined #dap
21:38:32 <DanC> DanC has joined #dap
21:46:04 <Marcos> Marcos has joined #dap
21:46:19 <shiki> shiki has joined #dap
21:47:18 <paddybyers> paddybyers has joined #dap
21:50:17 <marengo> marengo has joined #dap
21:50:24 <shepazu> shepazu has joined #dap
21:50:36 <weinig> weinig has joined #dap
21:51:41 <pererik> pererik has joined #dap
21:52:24 <mani> mani has joined #dap
21:53:36 <mjs> mjs has joined #dap
21:54:55 <NEWTON_VAGNER_DIN> NEWTON_VAGNER_DIN has joined #dap
21:55:56 <drogersuk> drogersuk has joined #dap
21:56:39 <paddy> paddy has joined #dap
21:57:20 <Kangchan> Kangchan has joined #dap
21:59:11 <sicking> sicking has joined #dap
22:01:08 <pererik> pererik has left #dap
22:01:56 <darobin> darobin has joined #dap
22:02:10 <Vladimir> Vladimir has joined #dap
22:02:55 <dom> Topic: MMI/DAP WG joint meeting
22:03:47 <Bryan> Bryan has joined #dap
22:04:39 <Claes> Claes has joined #dap
22:04:43 <fhirsch3> fhirsch3 has joined #dap
22:04:44 <slewontin> slewontin has joined #dap
22:04:47 <Marcos> Marcos has joined #dap
22:04:55 <slewontin> ScribeNick: slewontin
22:05:07 <slewontin> topic: Multi Modal Interaction
22:06:05 <fhirsch3> jim outlined architecture on white board - interaction manager and modal itnerfaces
22:07:54 <slewontin> Jim Barnett: presents MMI architecture
22:07:54 <weinig> weinig has left #dap
22:08:02 <soonho> soonho has joined #dap
22:08:47 <slewontin> Frederick: asks where the architecture lives. Components can live wherever they are most efficiently implemented: on the device, in the net, etc.
22:10:05 <slewontin> Robin: asks how multimodal interaction is choreographed. Answer is that this is the job of the Interaction Manager
22:10:19 <mjs> mjs has left #dap
22:10:36 <marcin> marcin has joined #dap
22:10:42 <tlr> tlr has joined #dap
22:11:28 <jorlow> jorlow has joined #dap
22:11:50 <paddy> paddy has joined #dap
22:11:52 <slewontin> Frederick: asks how related to XProc(?) Answer could be used as interaction manager
22:12:12 <dom> rrsagent, this meeting spans midnight
22:12:35 <nwidell> nwidell has joined #dap
22:13:07 <slewontin> Jim Barnett: events are very generic, not mode specific
22:13:48 <NEWTON_VAGNER_DIN> NEWTON_VAGNER_DIN has joined #dap
22:15:40 <slewontin> Frederick: the topic of interest here is how this relates to Device APIs. Answer is that modality components may use device APIs
22:16:04 <slewontin> Frederick: seems that device API not directly related to MMI
22:16:19 <Kai_> Kai_ has joined #dap
22:17:05 <slewontin> Debbie(?): Do we need a tutorial on Device APIs? Robin describes DAP work at a high level: security policy and set of APIs
22:17:35 <anne> anne has left #dap
22:17:43 <dom> s/(?)//
22:18:13 <claudio> claudio has joined #dap
22:18:46 <Ingmar> Ingmar has joined #dap
22:19:31 <slewontin> Frederick: DAP will produce APIs which MMI might want to use.
22:19:36 <claudio2> claudio2 has joined #dap
22:20:27 <slewontin> Debbie: Need to make sure that there is nothing in DAP that conflicts with the MMI model. One important issue is that MMI is entirely async. Another is that APIs need XML representation.
22:20:48 <noahm> noahm has joined #dap
22:21:16 <slewontin> Robin: Async should not be an issue. In terms of XML, we are mostly thinking at API level, but in most cases not data formats.
22:21:52 <slewontin> Robin: we would typically use DOM 3 events. 
22:22:07 <DanC> DanC has joined #dap
22:22:26 <johnnyg> johnnyg has joined #dap
22:23:39 <Marcos> Marcos has joined #dap
22:23:59 <slewontin> We are still at the point of deciding whether we need policy and how policies would be processed. We are not at the level of specifying, for example, security related events that could be fit into the MMI model.
22:24:43 <slewontin> Raj(?): Security is an issue for MMI, but MMI does not define security policies.
22:25:04 <Kai> Kai has left #dap
22:25:10 <Kai> Kai has joined #dap
22:26:09 <slewontin> ?: main security issue in MMI is security of events between modalities rather than within modalities. Since the architecture is distributed and may be distributed over more than one document, we can't just use DOM3 events.
22:26:57 <slewontin> Previous comment from Micheal B(?) of MMI wg.
22:27:22 <JonathanJ> JonathanJ has joined #dap
22:27:34 <slewontin> Frederick: seems like XML security is a more appropriate place for this.
22:29:12 <slewontin> Michael: from device API perspective mainly interested in things like what device features are available for input.
22:29:18 <darobin> System Info: http://dev.w3.org/2009/dap/system-info/
22:29:25 <slewontin> Debbie: presents use case
22:30:00 <timeless_mbp> timeless_mbp has joined #dap
22:30:06 <fhirsch3> example - use camera api to take picture as a modality component
22:32:59 <slewontin> Robin: asks if there are implementation that would allow you to write an MMC in JavaScript. This would be most relevant to DAP
22:33:36 <slewontin> Raj: Yes this could be done. Michael: but of course the app might not all be in a single JS context.
22:33:52 <JereK> JereK has joined #dap
22:34:19 <slewontin> Robin: the use case is for developers to define an MC in content
22:34:35 <Marcos> Marcos has joined #dap
22:36:34 <slewontin> Michael et al: context and language independent.
22:39:24 <slewontin> Frederick: DAP model assumes that APIs are invoked in a known context (e.g. widget with known credentials)
22:39:47 <fhirsch3> note that DAP apis assume invocation environment in web applications or widgets, so may not fit arbitrary invocation environment
22:40:06 <fhirsch3> potential issue might be security enforcement mechanism 
22:40:31 <slewontin> Robin: so this might be an issue for security and user granting of permissions
22:40:31 <fhirsch3> robin notes user interaction model may also have impact, e.g. ui to take picture
22:41:00 <fhirsch3> example use case - see webcam at home, take picture of intruder in house
22:43:08 <slewontin> Frederick: MC could be any arbitrary code, could run anywhere. This won't work with a security model that makes certain assumptions about the environment in which caller runs.
22:43:30 <Claes> Claes has joined #dap
22:43:31 <noahm> noahm has joined #dap
22:44:10 <AnssiK> JereK: what about the user interaction API mentioned in the policy, we had discussion earlier on alignment with the HTML5 menu element
22:44:31 <dom> s/JereK:/JereK,/
22:44:45 <maxf> maxf has joined #dap
22:44:55 <DanC> DanC has joined #dap
22:46:37 <AnssiK> JereK: here's a link to the discussion http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0207.html
22:47:02 <dom> s/JereK:/JereK,/
22:48:08 <slewontin> Frederick: use of DAP APIs in another context than Web is a new topic.
22:48:24 <Bryan> q+
22:49:09 <fhirsch3> dom notes that only web security context is is dap scope
22:49:30 <fhirsch3> stephen notes that any application can write javascript binding to use dap api
22:51:05 <slewontin> DOM: Its not that we won't take into consideration the MMI model, but we won't take this actively into account. If MMI finds issues with our model, they should provide input about this.
22:51:23 <slewontin> s/DOM/dom
22:52:55 <slewontin> Frederick: we need to get input on requirements for DAP apis from MMI
22:53:24 <fhirsch3> issue: include MMI in DAP specification reviews, including APIs and security
22:53:24 <trackbot> Created ISSUE-41 - Include MMI in DAP specification reviews, including APIs and security ; please complete additional details at http://www.w3.org/2009/dap/track/issues/41/edit .
22:54:26 <fhirsch3> issue: able to use of MMI for user interactions
22:54:26 <trackbot> Created ISSUE-42 - Able to use of MMI for user interactions ; please complete additional details at http://www.w3.org/2009/dap/track/issues/42/edit .
22:54:47 <schittur2> schittur2 has joined #dap
22:55:03 <Bryan> q-
22:55:54 <dom> close ISSUE-41
22:55:54 <trackbot> ISSUE-41 Include MMI in DAP specification reviews, including APIs and security closed
22:56:08 <slewontin> Robin: one important conclusion is that MMI should review DAP specs.
22:57:05 <darobin> ACTION: Robin to make sure that MMI is kept abreast of our work
22:57:05 <trackbot> Created ACTION-42 - Make sure that MMI is kept abreast of our work [on Robin Berjon - due 2009-11-09].
22:57:05 <slewontin> action: Robin to forward specs to MMI
22:57:05 <trackbot> Created ACTION-43 - Forward specs to MMI [on Robin Berjon - due 2009-11-09].
22:57:49 <darobin> MMI's work: http://www.w3.org/2002/mmi/Group/#Specs
22:58:45 <fhirsch3> issue was calling DAP API from non web application , e.g. native code Multimedial component
22:59:28 <fhirsch3> deborah - another example on  non-web context might be calendar running on  a server
22:59:30 <timeless> timeless has joined #dap
22:59:41 <fhirsch3> robin notes that web page doing access makes it in web context
23:01:03 <drogersuk> drogersuk has joined #dap
23:04:02 <drogersuk> Food: http://westfield.com/valleyfair/dining/
23:12:52 <dom> RRSAgent, draft minutes
23:12:52 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
23:16:08 <Zakim> UW_DAP(TPAC)11:30AM has now started
23:16:14 <Zakim> UW_DAP(TPAC)11:30AM has ended
23:16:15 <Zakim> Attendees were 
23:19:24 <mani> mani has joined #dap
23:26:43 <claudio2> claudio2 has joined #dap
23:27:09 <Marcos> Marcos has joined #dap
23:27:17 <johnnyg> johnnyg has joined #dap
23:35:18 <Claes> Claes has joined #dap
23:35:45 <darobin> darobin has joined #dap
23:35:59 <ArtB> ArtB has joined #dap
23:39:14 <Kai> Kai has joined #dap
23:39:23 <timeless> ScribeNick: timeless
23:39:29 <timeless> Scribe: timeless
23:39:37 <timeless> Present+ 
23:39:46 <timeless> Present+ Josh Soref
23:39:47 <wonsuk> wonsuk has joined #dap
23:39:52 <DanielColoma> Present+ DanielColoma
23:40:17 <Bryan> Present+ BryanSullivan
23:40:54 <slewontin> slewontin has joined #dap
23:42:05 <marcin> marcin has joined #dap
23:43:07 <timeless> AB: highlights agenda
23:43:30 <timeless> FH: we might drop the second item into the next time slot (pending Hixie)
23:43:47 <timeless> AB: some of these warp spec items might be already resolved
23:44:05 <timeless> AB: status?
23:44:18 <timeless> RB: I believe i've addressed all the comments i've received ...
23:44:30 <timeless> ... we will probably need a round of review
23:45:06 <timeless> ... the big issue that remains is UPnP
23:45:31 <Zakim> UW_DAP(TPAC)11:30AM has now started
23:45:38 <Zakim> + +1.781.534.aaaa
23:45:38 <timeless> ... LAN
23:45:52 <Zakim> - +1.781.534.aaaa
23:45:53 <Zakim> UW_DAP(TPAC)11:30AM has ended
23:45:53 <Zakim> Attendees were +1.781.534.aaaa
23:46:07 <timeless> Suresh: asking about last calls
23:46:27 <timeless> RB: we'll need another LC, so yes, we're taking comments
23:46:55 <timeless> AB: Quick review/summary...
23:47:10 <timeless> ... this is the only section of widgets which relates to policy and thus DAP
23:47:36 <timeless> RB: the goal of widget access is to create the simplest policy, to avoid conflicting with DAP
23:48:01 <timeless> ... the goal is to enable widgets to specify resources they need to access
23:48:21 <timeless> ... the policy is fairly straightforward. basically there are features that can be enabled in a widget
23:49:02 <timeless> ... There's a widget execution scope: APIs available to the widget's code
23:49:20 <timeless> ... There's an external execution scope: This doesn't have access to granted APIs
23:49:51 <timeless> ... there is a concern. Code loaded off the network can be loaded in the widget's running scope.
23:50:14 <timeless> ... Finally, things which are external to a widget need to be enabled by the <access> element.
23:50:32 <claudio> claudio has joined #dap
23:50:41 <timeless> AB summarizes Widget Access 5.1
23:51:07 <Suresh> q+
23:51:31 <richt> q+
23:51:51 <timeless> MC: when did pattern change to origin?
23:52:11 <timeless> (s/AB summarizes/RB summarizes/)
23:52:33 <timeless> RB: there was discussion on the list, it was made to match CORS
23:52:45 <timeless> ... I'm open to changes, I don't care
23:53:43 <timeless> MC: I'm surprised, because it wasn't something we were thinking of when we originally wrote it out.
23:53:49 <timeless> ... I don't have an opinion at this time.
23:54:01 <timeless> RB: before we go to another LC, i'd like to ask the WG to review it
23:55:24 <richt> q?
23:56:09 <timeless> I created an action against ArtB
23:56:10 <darobin> ack Suresh 
23:56:23 <timeless> Suresh: thanks Robin. In general, I think we're supportive
23:56:50 <ArtB> ArtB has joined #dap
23:56:59 <ArtB> q?
23:57:05 <timeless> ... I heard it mentioned as linked to "feature", but i didn't see it mentioned in the document
23:57:54 <timeless> Suresh: Currently Feature and Access are not tied together
23:58:02 <timeless> MC: This reminds me of what RIM did ...
23:58:21 <timeless> Suresh: Based on a per domain basis, you want to be able to load modules or not
23:58:36 <timeless> ... for all the access elements, I would just load all the features or not
23:59:00 <timeless> ... in terms of linking them, I think we have the bits to do it
23:59:14 <timeless> MC: it was mentioned that network access could probably be a feature
23:59:31 <johnnyg_> johnnyg_ has joined #dap
00:00:15 <timeless> RB: The goal of the spec was to stay very simple
00:00:23 <timeless> ... everything that will add will have a high cost
00:00:31 <dom> q?
00:00:32 <marcin> q+
00:00:34 <timeless> Suresh: What are you asking for?
00:00:42 <timeless> RB: It would need to be shown to be very important
00:01:38 <dom> q?
00:01:38 <timeless> Suresh: I would have to provide use cases explaining how it would make sense?
00:01:54 <timeless> AB: and the best scenario is that the feedback would be before the 19th
00:02:06 <Bryan> q+
00:02:12 <timeless> RichT: what about redirects?
00:02:30 <Suresh> To clarify - we think there is a value to link the <access> and <feature> elements
00:02:33 <timeless> RB: If you grant access to a.com; a.com redirects to b.com
00:02:52 <timeless> ... it depends on whether redirects are allowed from a.com to b.com
00:02:52 <ArtB> q?
00:02:56 <timeless> ack richt
00:03:15 <timeless> RichT: I'm afraid that the domain owner might change
00:03:28 <jmorris> jmorris has joined #dap
00:03:43 <timeless> Benoit: Another way to put this is that a.com is an umbrella
00:03:43 <dom> [I'm not sure we should discuss these details now in the joint meeting; but it seems at least that this ought to be clarified in the spec]
00:03:54 <fhirsch3> q+
00:04:00 <timeless> ... behind a.com is redirects to b/c/d.com
00:04:17 <timeless> RB: my pushback on that is that you're asking for extra complexity in the spec
00:04:17 <fhirsch3> q-
00:04:35 <timeless> ... there are already ways to do that with dns, server side proxying, etc...
00:05:07 <timeless> Benoit: So we specify that in the spec
00:05:11 <timeless> [by example?]
00:05:47 <timeless> RB: we're not going to list for every single protocol everything that you must not do
00:05:55 <fhirsch3> +1 to keeping complexity low
00:06:12 <timeless> DOM: It's not clear what are the limits for a network request
00:06:23 <ArtB> q?
00:06:29 <timeless> ... I assume that HTML5 has origins already defined
00:06:39 <timeless> RB: the same thing applies with XHR
00:06:42 <johnnyg> johnnyg has joined #dap
00:06:54 <timeless> ... If you ask for something from your domain and it redirects you. You're in trouble.
00:07:02 <timeless> RB: Please file a comment to the mailing list before Nov 19
00:07:07 <timeless> ack marcin
00:07:19 <timeless> Marcin: I'm not sure where the changes are
00:07:28 <timeless> RB: everywhere
00:07:32 <timeless> AB: everywhere
00:07:37 <timeless> Marcin: What is the main change?
00:07:39 <Marcos> Marcos has joined #dap
00:07:42 <timeless> [substantive change]
00:07:56 <timeless> RB: pretty much everything has been rewritten
00:08:17 <timeless> --- we lost power in the room ---
00:08:20 <dom> XmlHTTPRequest defines what is to be done with HTTP Redirects: http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method
00:08:28 <youenn> youenn has joined #dap
00:08:42 <dom> (importing presumably the "same-orgins rules" from HTML5)
00:08:55 <timeless> RB: the entire processing system was changed
00:09:01 <timeless> RB: the rules for matching were changed
00:09:08 <timeless> RB: the rules for origin ....
00:09:22 <ArtB> q?
00:10:02 <timeless> Marcin: I ranged a concern about mailto: / sms:
00:10:10 <tlr> tlr has joined #dap
00:10:13 <timeless> ... in DAP we're going to work on APIs that access mails...
00:10:20 <timeless> RB: that's completely outside the scope of WARP
00:10:45 <timeless> [RB points to the explicit exclusion in the spec]
00:11:39 <timeless> RB: if there's a scheme that lets me load an SMS into an iframe.. fine.. why should it be forbidden?
00:12:01 <timeless> Marcin: We are thinking about retrievable resources
00:12:12 <timeless> [ mailto: isn't a retrievable resource]
00:12:25 <arve> arve has joined #dap
00:12:27 <dom> s/<timeless>/<timeless_scribe>/
00:12:47 <darobin> q?
00:12:53 <timeless> ack Bryan
00:12:54 <darobin> ack Bryan 
00:13:22 <marcin> is "retrievable resource" defined somewhere?
00:13:25 <timeless> Bryan: If I need to grant access, i need to grant once for http, and once for https?
00:13:28 <timeless> RB: yes
00:13:45 <marcin> Is 200 OK + Content-Lenght: 0 a resource?
00:13:55 <timeless> Bryan: If I want to access everything over http and only some things over https, there's no easy way to do it?
00:13:58 <timeless> RB: correct
00:14:02 <dom> [a spec always define arbitrary semantics, doesn't it?]
00:14:19 <timeless> RB: We're trying not to create a technically complex spec to solve use cases we believe are in the minority
00:14:33 <timeless> Bryan: The statement about "any linked resources" ...
00:14:40 <dom> [rfc 2396 uses the phrase "network retrievable"; I don't know if it defines it]
00:15:12 <timeless> ... like subdomains, we should have a way to specify some limited set of resource types
00:15:28 <fhirsch3> s/Lenght./Length/
00:15:29 <timeless> ... So I could say "images are ok from everywhere", but "scripts are only ok from some places"
00:16:09 <timeless> RB: say I grant access to images. And the server redirects the image to image?some-javascript
00:16:29 <timeless> RB: the widget can retrieve the uri and evaluate the javascript
00:16:44 <timeless> Bryan: So is that normal?
00:16:57 <timeless> RB: No, but a widget / js can do it
00:17:15 <JereK> q?
00:17:25 <timeless> RB: Also, SVG is an "image", but it regularly will execute/embed scripts
00:18:16 <paddy> I will be shortly
00:18:21 <timeless> [ we got power back - thanks ]
00:18:23 <dom> s/<timeless>/<timeless_scribe>/
00:18:45 <paddy> For the policy agenda item, 10 minutes?
00:18:47 <timeless> AB: Bryan: please send comments to the mailing list
00:19:03 <darobin> q?
00:19:04 <dom> q?
00:19:05 <ArtB> q?
00:19:14 <timeless> FH: I'm waiting for Ian before we talk about ...
00:19:47 <JereK> [Bryan, seems like you'd want to restrict/allow access to resources by content type - worth the complexity?]
00:20:12 <darobin> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0011.html
00:20:32 <nwidell> nwidell has joined #dap
00:20:35 <timeless> Bryan: In UPnP, the environment is completely different
00:20:56 <timeless> ... there are no domain names, just ip addresses
00:21:35 <timeless> RB: the issue is that local ip ranges cover millions of IPs
00:21:59 <timeless> AB: so, do we want to support these?
00:22:05 <JereK> s/Bryan: In UPnP/Marcin: In UPnP/
00:22:15 <AnssiK> for private address space, see 3. section http://tools.ietf.org/html/rfc1918
00:22:23 <timeless> s/Bryan/Marcin/
00:22:50 <timeless> Marcin: UPnP ~ DNLA
00:22:58 <soonho> soonho has joined #dap
00:23:05 <Marcos> Marcos has joined #dap
00:23:10 <timeless> s/DNLA/DLNA/
00:23:15 <timeless> Marcin: we are able to determine that DLNA is "local network"
00:23:29 <darobin> q?
00:23:31 <darobin> q+
00:23:31 <timeless> ... for BONDI we ...
00:23:57 <darobin> q-
00:24:14 <timeless> Marcin: there are use cases where you can virtually download images, and then upload them to some network
00:24:41 <darobin> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0372.html
00:24:45 <timeless> Marcin: I think this is covered in my email messages
00:25:11 <timeless> Marcin: I think multicast is covered by DLNA
00:25:32 <amachin> amachin has joined #dap
00:25:32 <timeless> RB: could this be covered by a new attribute?
00:25:36 <marcin> marcin has joined #dap
00:25:43 <timeless> RB: I'm trying to divide up the work so that we can ship stuff
00:25:54 <timeless> RB: I'm not saying this isn't something important for some people
00:26:03 <timeless> RB: There are two ways to do this
00:26:14 <timeless> ... either there's a separate spec that defines a delta to WARP
00:26:19 <timeless> ... or it's a new version for WARP
00:26:34 <timeless> AB: what can you specify and bring as input within 2 weeks
00:26:57 <timeless> FH: if it has consensus and is available within 2 weeks
00:27:33 <timeless> Marcin: an attribute [localonly/allow local]
00:27:39 <timeless> tlr: How does this scale to IPv6?
00:27:43 <timeless> Present+ tlr
00:28:11 <timeless> tlr: I'm vehemently opposed to anything that relies on the specific 192./similar
00:28:20 <timeless> tlr: I think you're on a very dangerous path here. don't do it
00:28:41 <timeless> Marcin: I think DLNA only runs on ipv4
00:28:55 <timeless> ... it will live much longer in home networks
00:29:08 <timeless> AB: we need to wrap up
00:29:17 <timeless> AB: thanks Robin, Frederick
00:29:39 <dom> "The future transition from IPv4 to IPv6 will be handled in the DLNA Networked Device Interoperability Guidelines in a manner that enables devices based either on IPv4 or IPv6 to work well together." http://www.dlna.org/industry/why_dlna/key_components/network/
00:30:26 <timeless> FH: can you be both on the lan and internet at the same time...
00:30:34 <timeless> scribe is leaving
00:30:40 <timeless> RB: thanks scribe
00:30:44 <darobin> Hixie: you wanna come over?
00:30:51 <dom> s/Hixie:/Hixie,/
00:32:42 <Claes> scribe Claes
00:33:06 <dom> ScribeNick: Claes
00:33:39 <dom> Topic: Policy requirements
00:33:43 <timeless_mbp> timeless_mbp has joined #dap
00:34:03 <dom> RRSAgent, draft minutes
00:34:03 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
00:34:10 <Kai> Kai has joined #dap
00:34:25 <Zakim> UW_DAP(TPAC)11:30AM has now started
00:34:32 <Zakim> + +0148375aaaa
00:34:41 <paddy> Present+ Paddy_Byers
00:34:41 <dom> zakim, call Salon_5
00:34:41 <Zakim> ok, dom; the call is being made
00:34:43 <Zakim> +Salon_5
00:34:53 <Claes> Reviewing comments by Laura_Arriba
00:35:16 <Claes> Paddy on the phone
00:36:05 <wonsuk> Present+ Wonsuk_Lee
00:36:10 <Claes> Defintions, device capability editorial
00:36:11 <JereK> http://dev.w3.org/2009/dap/policy-reqs/
00:36:13 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0243.html Laura’s comments
00:36:40 <paddy> It's very hard to hear
00:37:37 <Claes> Device Capability defintion mapping to Features. Get defintion of Features more elaborate
00:38:25 <Claes> Get wording right
00:39:38 <drogersuk> drogersuk has joined #dap
00:39:55 <dom> (I don't think the notion of strings should appear in the policy requirements, really)
00:40:06 <timely> timely has left #dap
00:41:01 <Claes> Laura: Paddy's defintion in later email is more accurate that the current one
00:41:11 <Marcos> Marcos has joined #dap
00:41:33 <Claes> Above refering to def of Feature
00:41:44 <Bryan> http://bondi.omtp.org/1.1/CR/
00:42:55 <dom> -> http://bondi.omtp.org/1.1/cr/security/BONDI_Architecture_and_Security_v1.1_CR.pdf BONDI Architecture and Security 1.1
00:42:56 <Claes> Laura: Policy def Reqs: 2nd bullet: Unclear what flexibility means
00:43:09 <dom> "A Feature corresponds to specific functionality provided by a Web Runtime,
00:43:09 <dom> made available by a defined set of Web Runtime behaviours and JavaScript
00:43:09 <dom> interfaces
00:43:09 <dom> "
00:43:30 <Claes> fhirsch: Who writes the policy?
00:43:34 <slewontin> slewontin has joined #dap
00:43:56 <Bryan> q+
00:44:48 <dom> [I think the key question is not whether policy is needed, but whether interoperability on policy definition/processing is needed]
00:44:59 <Claes> Marcin: Differ between presentation of policy and who writes it
00:45:42 <Claes> Fhirsch: Who are the actors?
00:46:43 <Claes> Paddy: Agrees with fhirsch
00:47:04 <dom> [this suggests we need detailed use cases]
00:47:35 <dom> q+
00:47:38 <dom> ack Br
00:47:50 <slewontin> q+
00:49:02 <Claes> Bryan: Doesn't consider this an issue. The are a number of ways policies can be originated. We can and should what to do in the event of no policy but should not define who creates the policy
00:49:41 <Claes> Marcin: Absence of a policy is a policy
00:49:41 <JereK> [if policy file is absent, does that mean there is a default policy?]
00:49:49 <Bryan> q-
00:50:49 <JereK> q?
00:51:17 <JereK> ack dom
00:52:40 <fhirsch3> dom notes that if interoperability is not important then perhaps DAP does not need to define policy mechanisms
00:52:51 <fhirsch3> we need detailed use cases to understand who the actors are and the flows
00:52:52 <shepazu> shepazu has joined #dap
00:52:53 <Claes> Dom: Need to define detailed use cases and clear actors
00:52:57 <fhirsch3> +1 from stephen to Dom
00:53:23 <fhirsch3> q?
00:53:29 <fhirsch3> ack slewontin
00:53:36 <DanielColoma> DanielColoma has joined #dap
00:53:48 <Bryan> q+
00:54:43 <Claes> Steve: Someway to guarantee that SW is consistent. Comapre with MIDP, every op has a different model for signing creating interop problems.
00:55:34 <Claes> Steve: We should issue policy recommendations
00:57:27 <Claes> Steve: There is no point in std policy if we don't achive consistent behaviour between platforms
00:57:52 <Claes> Fhirsch: Need use cases and actors
00:58:01 <shepazu> shepazu has joined #dap
00:59:08 <dom> ack B
00:59:09 <Suresh> q+
01:00:04 <dom> [the question is not whether you *can* achieve interoperability, but whether it is needed]
01:00:08 <JereK> JereK has joined #dap
01:00:28 <Qiuling> Qiuling has joined #dap
01:00:48 <Claes> Bryan: Believs there is  way to define policy. We done that in Bondi. Don't ignore the problem. The policy does need to be defined and policy processing has to be defined
01:00:49 <Claes> Bryan: Believs there is  way to define policy. We done that in Bondi. Don't ignore the problem. The policy does need to be defined and policy processing has to be defined
01:01:02 <howard218> howard218 has joined #dap
01:02:46 <Claes> Where can a explicit user action be consent?
01:03:06 <slewontin> q?
01:03:12 <slewontin> q+
01:03:56 <Claes> Bryan: In the developing process the policy has to be defined
01:04:54 <darobin> q?
01:04:55 <Bryan> q-
01:05:22 <fhirsch3> need use cases, look at enforcement
01:05:34 <fhirsch3> suresh notes requirements before use cases might be premature
01:05:39 <dom> [in particular, we need someone to take an action item to start with use cases]
01:06:14 <dom> ack sur
01:06:16 <Claes> Suresh: We  have to step back. Policy user context or eg widget context
01:06:19 <Hixie> darobin, sorry, ended up in i18n. still need me today?
01:06:42 <dom> ack slew
01:06:46 <dom> q+ dom
01:06:46 <howard218> howard218 has joined #dap
01:07:54 <Claes> Steve: Agree on IOP goal. However, not efficient to discuss policy language and policy processing
01:08:28 <slewontin> slewontin has joined #dap
01:08:42 <fhirsch3> dom notes declaring intent to use features is important
01:09:02 <fhirsch3> dom also notes subsequent action whether user consent or policy enforcement is another question
01:09:22 <fhirsch3> dom not clear we need format around policy and need for interop on this
01:09:57 <slewontin> The main value to specifying a policy standard is that it enables an ecosystem in which Web apps and widgets have consistent behavior across many devices.
01:10:02 <darobin> Hixie, it'd be nice if you could come over yes
01:10:42 <fhirsch3> laura  notes letting developer write policy can be risky if they are writing malware
01:11:08 <slewontin> Having an interoperable policy spec is a necessary but not sufficient condition for such consistency.
01:11:10 <Claes> Laura: Can't always let the developer create policies. 
01:11:29 <Claes> Bryan: Need a system to manage trust
01:11:30 <Hixie> darobin: k, omw
01:11:40 <dom> q+ to suggest that Bryan should take an action to propose use cases
01:11:47 <fhirsch3> q+
01:12:19 <JereK> [so dev says what they want to use, policy says what they can use - but for dev to write policy is meaningless]
01:12:27 <Claes> Laura: Developer can not define the features his/her app has access to
01:13:58 <Claes> Fhirsch: Bring Hixie in and contiue with Laura's comments
01:14:15 <Suresh> I agree with what dom said before on the layered apporach i.e. a part where the developer provides an intent by declaring access and feature and the other part where you enforce a policy on top of that 
01:14:39 <howard218> howard218 has joined #dap
01:14:44 <dom> ACTION: Bryan to offer use cases of policy interoperability needs
01:14:44 <trackbot> Created ACTION-44 - Offer use cases of policy interoperability needs [on Bryan Sullivan - due 2009-11-10].
01:15:00 <Claes> Laura: Developer can define which features that are requested but not which features hat are allowed to access
01:15:06 <richt> let's keep the use cases simple if possible
01:15:30 <dom> (simple but clear on who's involved)
01:15:44 <richt> dom, agreed
01:15:46 <dom> Topic: HTML5 Security Model
01:16:00 <Claes> Hixie joined
01:16:42 <fhirsch3> goals - understand basics of model, what is important to DAP, evolution 
01:18:05 <paddy> yes, thnx
01:18:42 <dom> [another possible question: the role/formalization of the top frame in access to special APIs]
01:19:41 <Claes> Hixie: Several aspects to security in HTML5. Biggest pattern used same origin, i.e. scheme, host name or a port. A script is allowed to access only same origin. Generally a script pointing to another domain is not ok. 
01:23:07 <Claes> Hixie: Issues wtih images...Cross origin scripts is a secuirty problem. 
01:25:35 <Claes> Hixie: Can make the security even worse due origin model (did catch Hixie's example)
01:25:59 <johnnyg> johnnyg has joined #dap
01:26:56 <Claes> Hixie: Issues with files, e.g. with drag and drop.
01:30:01 <Claes> Hixie: Origin header contains origin of request in XHR. Manipulation of origin header
01:30:32 <AnssiK> q+
01:30:56 <dom> queue= Anssik
01:33:16 <Qiuling> Qiuling has left #dap
01:33:55 <fhirsch3> ack anssik
01:37:13 <Claes> scribe needs 2 mins pause
01:38:22 <dom> ack An
01:38:36 <dom> Anssik: how can we apply this origin model to widgets?
01:39:34 <Claes> scribe back
01:39:36 <dom> ... could we leverage the Origin header in the context of widgets?
01:40:30 <fhirsch3> q?
01:40:46 <dom> Adam Barth
01:40:54 <Claes> Hixie: Talk to    Adam Bart about origin header
01:42:46 <dom> "top level browsing context"
01:43:14 <dom> "first script" is the script at the bottom of the call stack
01:43:38 <dom> + "origin" concept
01:45:23 <Claes> Hixie: Using HTML 5 top level  browser  concept, orign concept, first script (script in bottom of call stack) concept etc...
01:48:57 <dom> q+ to ask about API design anti-patterns
01:50:00 <Claes> Bryan: No of uses cases that expect automatic action
01:51:05 <Claes> Hixie: E.g. once granted access to files to a web site this can be remembered
01:51:29 <Claes> Hixie: Explicit user action can be long-lived
01:51:31 <fhirsch3> ack dom
01:51:31 <Zakim> dom, you wanted to ask about API design anti-patterns
01:52:33 <Bryan> Bryan: some use cases benefit from automated file storage based upon initial explicit consent or implicit consent, e.g. based upon trust in the webapp source
01:52:37 <fhirsch3> + privacy
01:52:50 <fhirsch3> q+
01:55:13 <Claes> Hixie: Major principle: Don't rely on a modal prompt
01:58:20 <Claes> Hixie: Design according to a speciifc mode of operation in mind but do not mandate it
02:02:07 <paddy> fhirsch, will you be continuing with agenda items 9c, 9d or finishing after this item?
02:05:01 <JereK> q?
02:05:31 <dom> RRSAgent, draft minutes
02:05:31 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
02:05:49 <Zakim> - +0148375aaaa
02:05:58 <JereK> JereK has left #dap
02:06:34 <dom> zakim, list attendees
02:06:34 <Zakim> As of this point the attendees have been +0148375aaaa, Salon_5
02:06:38 <dom> zakim, drop salon_5
02:06:38 <Zakim> Salon_5 is being disconnected
02:06:39 <Zakim> UW_DAP(TPAC)11:30AM has ended
02:06:41 <Zakim> Attendees were +0148375aaaa, Salon_5
02:06:45 <dom> RRSAgent, draft minutes
02:06:45 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-dap-minutes.html dom
02:07:00 <paddy> +0148375aaaa is paddy
02:07:00 <dom> RRSAgent, bye
02:07:00 <RRSAgent> I see 9 open action items saved in http://www.w3.org/2009/11/02-dap-actions.rdf :
02:07:00 <RRSAgent> ACTION: claes should issue recommendation on the granularity of the security system [1]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T18-25-29
02:07:00 <RRSAgent> ACTION: chaals to Collate use cases - what are the exact write API use cases for the web. Hoe the two initiatives can layer. [2]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T19-54-35
02:07:00 <RRSAgent> ACTION: chaals to shepperd the discussion on File API, Reader, Writer, FS Browser layers; collecting use cases [3]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T19-54-43
02:07:00 <RRSAgent> ACTION: Robin to check that Chaals shepperds the discussion on file API, Reader, Writer, FS Browser layers; collecting use cases [4]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T19-55-20
02:07:00 <RRSAgent> ACTION: Arun to write up security considerations section of existing File API spec. in preparation for FPWD [5]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T20-12-58
02:07:00 <RRSAgent> ACTION: ifette to start drafting a unitarian file API [6]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T20-15-26
02:07:00 <RRSAgent> ACTION: Robin to make sure that MMI is kept abreast of our work [7]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T22-57-05
02:07:00 <RRSAgent> ACTION: Robin to forward specs to MMI [8]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T22-57-05-2
02:07:00 <RRSAgent> ACTION: Bryan to offer use cases of policy interoperability needs [9]
02:07:00 <RRSAgent>   recorded in http://www.w3.org/2009/11/02-dap-irc#T01-14-44