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