08:36:52 RRSAgent has joined #devices 08:36:52 logging to http://www.w3.org/2008/12/11-devices-irc 08:37:09 zakim, this will be foo 08:37:10 ok, tlr; I see Team_(foo)08:36Z scheduled to start now 08:37:13 zakim, code? 08:37:13 the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr 08:40:48 Team_(foo)08:36Z has now started 08:40:56 + +358.504.83aaaa 08:41:42 +[Vodafone] 08:42:02 zakim, aaaa is olli 08:42:02 +olli; got it 08:43:16 Anil has joined #devices 08:45:48 smb has joined #devices 08:46:43 arve has joined #devices 08:47:11 Topic: Towards a community-controlled security policy for Widgets by Marcos Caceres (W3C Invited Expert) 08:47:49 PHB has joined #devices 08:47:59 scribe: PHB 08:48:04 maxfroumentin has joined #devices 08:48:58 Presentation: Widgets 1.0 08:49:17 Dowan has joined #devices 08:50:00 Marcos Caceres: A child of web 2.0 community driven approach 08:50:27 ... wikipedia facebook and so on, malware is rampan in these systems, botnets by the billion, etc. 08:50:42 s/rampan/rampant 08:50:43 okay dokay 08:52:35 smb has joined #devices 08:56:44 smb has joined #devices 08:58:11 Questions 08:58:31 q+ claes, maxf 08:58:33 Doug: Is this in packaging? How is it enforceable? 08:58:58 Doug: I wanna write a web ap and use this packaging and I say feature name = URI yes or no and 08:59:16 Marcos: exception 08:59:56 Doug: this is a feature for widgets specifically, not pages in general 09:00:02 Marcos: yes 09:00:15 q+ paddy 09:00:52 Marco: This is somthing that should be part of widget engines just like anything else, as 09:01:11 today we would use for geo-priv, later gate access to cameras and so on. 09:01:23 ... also protected by digital signatures 09:01:25 ack claes 09:01:53 09:02:03 Max: what does the last URL mean 09:02:37 this could be used for a "Web App", by linking a given page to a config file (e.g. with the elements declared there? 09:02:43 Marcos: it means this represents a feature (geolocation) with a particular level of precision (100m) 09:02:46 q+ 09:02:59 ack maxf 09:03:01 q+ adrian 09:03:57 This is both a least priv mechanism and a api mechanism, by inspecting the manifest can determine the level of features required 09:04:22 zakim, list conferences 09:04:22 I see Team_(foo)08:36Z active and no others scheduled to start in the next 15 minutes 09:04:22 Marcos: yes 09:04:44 zakim, who's here? 09:04:44 On the phone I see olli, [Vodafone] 09:04:45 On IRC I see smb, Dowan, maxf, PHB, arve, Anil, RRSAgent, Zakim, madofo, ArtB, dougt, StewartB, tlr, adrian_hb, MikeSmith, matt, hendry, dom 09:05:40 Doug: There are going to be some APIs like camera which have stuff built into them that don't have a privacy concern until they are in another system, this is going to get messy, have a manifest that talks about web runtimes, may be a good feature for the Web in general not just widgets 09:06:41 Adrian: a good model that could also be used on the web, wonder about feedback, what aspect of feature that should be visible. 09:07:01 Marcos, our concern has been how to get access to the information 09:07:21 s/Marcos,/Marcos:/ 09:07:34 q? 09:07:36 Adrian: Does it handle privacy 'this is my location keep as long as you like 09:07:36 smb has joined #devices 09:07:41 queue= 09:08:22 PHB: I saw units at the end of the URL for geolocation. I think there's no need for other units other than SI. I also think the device should be able to lie to the widgets. 09:08:46 madofo has joined #devices 09:09:07 PHB: When I load a game on my daughter's machine, it asks for system privileges, for no good reason. If this is going to be practical on the large scale, you need to be able to say "You have it", but then you don't. 09:09:15 marcos: I don't think that goes in the spec. 09:09:20 PHB: No I think you do. 09:10:34 .. In cas of API you can say I need this feature, in the case of a manifest you can say these are the features I need. Don't want to allo an inspection API that allows device to find out everything it is allowed to know. 09:10:52 s/../Paddy:/ 09:11:39 ?? General question are we doing a widget spec or a web spec. We have a charter to focus on a narrow spec. Want think beyond widgest but finish 09:11:46 s/??/ArtB:/ 09:11:47 s/??/Art:/ 09:12:18 Marcos: this supports multiple software security models, lease comment. 09:13:34 Doug: two points, not sure at this point what the value is of a declared set of featues for a widget, couple that with the social screen this will be reslved by itself. If you have a webapp that is going to get signed, you are going to have a machine that determines that the feature is required. Social screening works. 09:13:36 q+ 09:13:55 Doug: every firewfox web app has been reviewed 09:14:32 ?? cantsee: +1 the metadata 09:15:22 pauld has joined #devices 09:15:33 s/?? cantsee/PaulD 09:15:35 s/firewfox web app/firefox addon 09:15:44 Doug, going into last call next week 09:15:53 s/PaulD/PaulD:/ 09:16:23 cites Cory Doctorow's Metacrap: http://www.well.com/~doctorow/metacrap.htm 09:16:45 rrsagent, where am i? 09:16:45 See http://www.w3.org/2008/12/11-devices-irc#T09-16-45 09:17:35 RRSAgent, make log public 09:19:17 marcos has joined #devices 09:20:54 Presentation: Steve Lewontin 09:21:58 Topic: Web Runtime Policy Based Security by Steve Lewontin (Nokia) 09:22:15 fhirsch3 has joined #devices 09:23:58 fjh has joined #devices 09:24:26 zakim, who is here? 09:24:26 On the phone I see olli, [Vodafone] 09:24:27 On IRC I see fjh, marcos, pauld, madofo, smb, Dowan, maxf, PHB, arve, Anil, RRSAgent, Zakim, ArtB, dougt, StewartB, tlr, adrian_hb, MikeSmith, matt, hendry, dom 09:30:41 maxfroumentin has joined #devices 09:37:05 Steve: Q&A 09:38:31 [didn't hear]: What is you view on Web applications verify ? dynamically accessed web content 09:38:51 Steve: Use the location from where the content came as the primary trust attribute 09:39:43 Steve: yes TLs, hard to tell if content has been modified, particularly on movable USB drives, signed code artifact around is the only trusted scalable solution 09:39:56 Martin: Questions related to BONDI, 09:40:05 Martin: do you want to contribute to there> 09:40:28 Steve: open to participate in other solutions, want open-y-ness 09:40:47 Art: no, nothing else to add 09:41:03 Marcos: Who actually designs the policy 09:41:19 Steve: good question as policies are not easily designed. 09:41:54 Steve: Whoever designs policy should be person responsible if something goes wrong. 09:42:30 {?]: update 09:42:48 Steve: We don't provide a method of update but there are many ways to do that 09:42:59 smb has joined #devices 09:43:04 Topic: Security Model for browsing and widgets by Olli Immonen 09:47:27 for anyone who cares, my slides are own my own web page: http://www.cs.columbia.edu/~smb/talks/webapi.pdf 10:00:20 Topic: BONDI: A Web based security model fit for purpose by Nick Allott (OMTP Office), David Rogers (OMTP Office), Geoff Preston (OMTP Office) 10:16:22 fjh: Have you considered taking the XACML variant to the OASIS TC? 10:16:35 Nick: Have considered doing that but not as a dependency 10:16:47 fjh: Is this big or small, seems small 10:17:01 Nick: small. 10:18:12 Paddy?: Have identified issues, would like to take them back to XACML? 10:18:23 s/Paddy ?/Paddy/ 10:18:40 ??: Discussed identification of target APIs? Have you considered maping out API surface area? Is that in scope 10:18:46 Nick: yes 10:18:54 s/??/Anil/ 10:19:44 Anil: Are you tinking of W3C compliant widgests or W3C Bondi compliant widgets? 10:19:52 DKA has joined #devices 10:19:59 Nick: Not trying to create a parallel universe here. Complimentary 10:20:01 s/tinking/thinking/ 10:20:08 s/widgests/widgets/ 10:20:18 Art: just thinking of whom your recipient in W3C might be for this work 10:20:24 Nick: why we are here 10:21:09 Nick: have relatively well speced scoped for certain widgets, but not all, don't know where is best for others, 10:21:32 Nick: Geolocation, persistence.. different locations in W3C. 10:21:46 Nick: W3C community needs to decide what goes where. 10:23:04 Max: you are going to use many different specs as sources, how are you going to keep consistency between them 10:23:17 Max: even in W3C geo is at odds with others 10:23:39 Nick: For all of the different APIs have different companies working on them so consistency is already an issue. 10:23:56 Nick: Consistency review led to changes 10:24:21 (it would be interesting to send that feedback about inconsistency between fileio and geo to the relevant w3c groups) 10:24:22 Nick: conflicting constraints want consistency but existing ones are eviating slightly. 10:24:39 Nick: working model is to have 1:1 mapping where a W3C pproach exists. 10:24:51 ??:IPR 10:25:03 smb has joined #devices 10:25:10 Nick: WTAI stuff been arounf for 7 years. 10:25:59 Thomas: what is relationship of your proposals to OMA specs 10:26:18 Ben has joined #devices 10:26:28 fjh: From psotion of project manager how would this look, 10:27:13 Nick: lets break it down into, there is open source implementation and then there is the standardization veneer on the top want to get as many pieces ratified in w3C structure as possible 10:27:43 Nick: so come in with spec and canidate code that works. 10:28:04 Art: Managing expectations, get worried about accelerated security standards. 10:28:08 Nick: thats life 10:28:34 Nick: there are real implementations being rolled out that may or may not be secure. 10:29:00 Nick: when we say accelerated we are trying to apply any strategy we can to accelerate. open source is one such 10:29:16 should also consider bringing XACML modifications and profile work to OASIS XACML TC. 10:29:47 Doug: one o the thing not clear on is, phone status is interesting as I have a mobile browser 10:30:31 ... have no idea if DCCI is right thing to use for phone support, might be completely differently, is the opposite way to we did geo 10:30:54 ... geo knows a lot about the web, little bout geo 10:31:19 ... DCCI is opposite, are you going to implement it all? 10:31:22 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml 10:32:17 Nick: we defined a set of requirments, existing, mapped to DCCI requirements, thats the basis, real problem, on the ontology as it stands at the moment is location, there is also the geolocation API 10:32:43 DCCI is general purpose API, there is also a specific api that gives more detail. 10:32:56 there is redundancy but that is just the way things are 10:33:20 Tlr: how does dynamic API relate to DCCI 10:33:42 Nick: from memory there are some provisions for API discovery to say if things are there or not. 10:34:48 Paddy: principle is that bondi or any other org is not going to be the only party that defines api. will be many others. 10:34:52 dom: +1 10:35:12 art: have any of the interface specs that bondi has cretd today have dependence on DCCI 10:35:21 NickL: Only the phone status 10:36:25 matt: have advantage to sing one api, might want to have an event handler for all events and use DCCI for that 10:36:32 it's an architectural frankenstein... "brains!" 10:36:43 tlr: break, reconvene at 11 10:36:44 heh. 10:38:14 [[ DCCI could also be more valuable if you don't believe marcos' assertion that there won't be millions of these ]] 10:40:08 -olli 10:40:21 smb has joined #devices 10:45:08 disconnecting the lone participant, [Vodafone], in Team_(foo)08:36Z 10:45:11 Team_(foo)08:36Z has ended 10:45:12 Attendees were +358.504.83aaaa, [Vodafone], olli 10:53:55 smb has joined #devices 11:04:48 http://www.amazon.com/Extech-RHT10-Humidity-Temperature-Datalogger/dp/B001AFFVWQ/ref=pd_bbs_sr_5?ie=UTF8&s=hi&qid=1228989978&sr=8-5 11:06:58 Topic:WebVM - Security policy for device API access by Paddy Byers (Aplix), Kai Hendry (Aplix) 11:07:21 pauld has joined #devices 11:09:07 ScribeNick: marcos 11:09:19 marcos cannot suck ore at scribing than PHB 11:09:48 rhillebr has joined #devices 11:10:11 PB: WebBM is a plugin that allows API access to devices. It's use cases are both widgets (packaged web apps) and web pages. 11:10:25 s/WebBM/WebVM/ 11:10:56 PB: WebVM supports binding to java APIs and making them available as javascript APIs 11:12:00 PB: hence, it is extensible as the JavaAPIs, like JSRs, are defined elsewhere and they can be available in javascript... 11:12:29 PB presents the architecture at large... 11:13:08 PB: webVM sits as part of the standard architecture that browsers already use 11:13:44 PB: there is a security manager that intervenes in the process.... 11:14:51 PB: wrt security, webVM supports a fine-grained security model which is somewhat similar to what has been discussed this morning 11:15:59 rhillebr has joined #devices 11:16:36 PB describes how the whole thing stitches together wrt digital signatures and identifying where a package came from. 11:17:41 PB: we need to support existing security models that are currently in use in the software world. But with the possibility of extending on those. 11:18:17 smb has joined #devices 11:18:44 PB: it's still up to the user to decide if they trust the software, but with the combined trust model that is provided by using signatures and that the software won't do more than it says it will do. 11:19:43 PB: need to support multiple signatures. The problem is that operators or distributors will delete any signature that authors put on the software. This is problematic from the standpoint of non-repudiation 11:20:02 (who authored the widget in the first place is lost) 11:21:32 PB: the problem is that the permissions are not fine grained enough in current models. Eg. gmail asking for web access, instead of access to just gmail 11:21:48 s/gmail/gmail.com 11:23:27 PB: with a common base, fine grained permissioning can be shared across apps and stored persistently... but at the same time, it gives user more control by allowing the user to override the declared permissions 11:24:40 PB: in the model have at the moment, the page that contains the application/content determines the rights 11:26:00 Zakim has left #devices 11:26:31 PB: there is problematic because if the page is compromised then malicious code can get access to those rights 11:27:39 PB: on widgets, they rely on the id (which is a URI).... operators can grant rights based on the certs.... need to support multiple signature profiles for right access 11:29:16 PB: for when java code, instead of the javascript, tries to do something that would be deemed security sensitive on the platform, it is not allowed because permissions are based on the page context and not by Java. 11:29:56 (the above being part of the WebVM security model) 11:30:36 PB: hence the java packages can be treated as being secured by the WebVM model as a whole. 11:31:38 PB: the XACML-inspired model, is a tree, it has a target for rules, rules have conditions and effects. 11:33:22 PB: there were certain things in XACML that we were not able to do. We added support for undefined values. We added combining rules, and other rules like ones related, for example, particular phone numbers... we submitted this to the BONDI work. 11:33:29 s/work/project 11:34:07 PB: for standardization, a security model should not be hard coded into the spec... 11:35:01 PB: we are not trying to solve every problem, but we can cover a lot of use cases. 11:35:49 AB: this remote provisioning functionality, is that something is going to specify? 11:36:48 PB: it's something that bondi has worked on. But we havent worked on how you identify the authority to configure parts of the policy 11:37:20 PB: we don't distiguised which parts of the policy tree are controlled by which authority 11:37:40 s/distiguised/distiguish 11:39:23 ML: Widget security models... different views between web pages and widgets... 11:40:12 ML: the main difference is the different installation procedure... but to the user the are as the same. 11:41:21 smb has joined #devices 11:41:33 ML: for the case of widgets.... support for digital signatures. Protection domains... we want to see some sort of declarative model to declare what capabilities it want to use 11:42:45 ML: untrusted and trusted widgets. Untrusted widgets, without origin, then they cannot be trusted on the device. A trusted widget being one with a signature that can be mapped into a security domain. 11:43:42 ML: having predefined policies that trusted and untrusted widgets can map to. But also giving the end-use some authority/access-rights over the policies 11:44:13 ML presents a declarative model for device API access. 11:44:41 ML: then we come to Web Applications. One way to identify the web app is via TLS/SSL 11:45:11 ML: the web app is verifiable via it's origin and cert 11:45:43 ML: we want to see some alignments between the widget and web apps world. 11:46:02 ML: we want the users to view them as the same. 11:46:53 I think I heard a use case today for having several distinct signature classes defined in the widget signature spec. *at* *least* "author" and "intermediary" (aka operator) 11:49:10 StewartB has joined #devices 11:49:11 some random questions... end of presentation 11:49:37 PP: Software components for Secure Mobile Web Apps Platforms 11:49:59 maybe "role" of the signer 11:50:12 PP: we work for Ericsson Research... we are not part of the product section... 11:50:37 PP: lab phones are ugly on purpose :) 11:51:09 PP: prototyping a completely widget-based terminal 11:51:25 PP: based on widget spec, linux, etc 11:51:38 next slide... 11:51:58 PP: need separation of concerns 11:52:33 PP: we are dodging the policy issue... looking at sofware component models instead 11:53:17 PP: ...software component models... such as DCOM, COM, etc... 11:53:44 PP: because we rely on IDL, this is a fairly language independent 11:54:14 PP: using IDL to some converter, we can produce a javascript equivalent 11:54:27 PP: translating this into javascript makes a lot of sense... 11:55:03 PP: of course, there are limitations such as memory pointers, etc. So we avoid those 11:55:20 PP presents the basic architecture 11:56:42 PP describes how it all works together... [but the scribe is confused] 11:58:50 PP: advantages include good separation concerns, language independence, using COM gives us a single point of entry to the platform. Once we secure that, we have something good. But there are some challenges: maintaining runtime identity, dynamically downloaded shim layers, performance, and user experience. 11:59:39 DA: I have 2 questions, how do you declare intent within the package? 12:00:43 PP: that is the way we do it. The granularity, we use part of the w3c config document stuff. But we have a UUID that is verifiable at runtime so we know the interface that is being invoked. 12:01:06 NA: does UUID mean you need some kind of registration authority? 12:01:10 PP: no 12:02:06 DA: about shim layers... do you think standardization can help with the creation of that shim layer? 12:03:09 PP: we come form the platform side of things... I see the user for the device manufacture to be able to avoid locking down the final APIs. I see the need for a well defined shim layer. 12:03:28 NA: final presentation for this session... 12:04:10 FM: security by contract for the embedded internet 12:04:53 Topic: security by contract for the embedded internet 12:05:51 FM: ... you can't completely trust everyone, not even someone like google because everyone can be hacked... 12:06:18 FM describes 4oD 12:06:26 smb has joined #devices 12:06:37 ... it installs P2P software 12:06:49 ... it's not shady software... or is it? 12:07:11 ... it's hidden license agreement... 12:08:01 ... that you legally allow your machine to be used this way... and you have a problem talk to your ISP. 12:08:41 ... the user can't even protect them selves by suing because it's in the license agreement 12:10:19 ...so what is to be in a contract. It has to be machine readable. 12:10:38 ... should be embedded in the manifest 12:10:47 ...same as in widgets 1.0 12:11:27 how about n3 :) 12:11:31 ... declarations in a simple format.. if BEFORE/AFTER api.. 12:13:59 FM: ... and then it runs or the user takes the risk. 12:15:59 q+ 12:16:03 ws-policy intersection relevant to matching task, eg. how to intersect policies needs to be understood 12:16:08 ? 12:16:20 http://www.w3.org/TR/2007/REC-ws-policy-20070904/ 12:16:37 FM: what platform stakeholders want... no violation of the platform policy (don't go ringing strange numbers), What developers want... for the enforcement policy to not break the application, etc.... what user s want is that the application is safe and good for them... 12:17:52 FM shows demo 12:18:05 smb has joined #devices 12:18:56 FM: here we have a chess application that is untrusted 12:19:11 FM: ... you can select the policy you want.. 12:19:29 FM: eg, no sms, 12:19:49 FM: ... so we deploy and run. The application is not signed... 12:20:08 FM: ... so the policy is set up. 12:20:38 FM: it shows info about the application. the user agrees and the game runs 12:20:58 FM: so now we play chess over SMS 12:22:14 NA makes a chess move. 12:22:56 FM, if I try to move. An error dialog pops up and kills the application because of the security violation 12:23:04 NA: any questions 12:25:39 smb has joined #devices 12:27:22 adrian_hb has joined #devices 12:27:45 s/NA /NA: / 12:27:53 s/FM,/FM:/ 12:28:22 rrsagent, draft minutes 12:28:22 I have made the request to generate http://www.w3.org/2008/12/11-devices-minutes.html matt 12:29:47 s/FM describes/FM: describes/ 12:30:12 AB: my worry is, there is evidence that the user will most likely screw up policy selection. 12:30:15 rrsagent, draft minutes 12:30:15 I have made the request to generate http://www.w3.org/2008/12/11-devices-minutes.html matt 12:30:32 s/AB/AvB 12:31:08 Meeting: Workshop on Security of access to device APIs from the Web 12:31:18 P?: the reason was the active x would nag you, and then nag you again, and so on till the user clicked yes 12:31:22 Chair: Nick Allot, Thomas Roessler 12:31:25 s/P?/PHB/ 12:31:38 rrsagent, draft minutes 12:31:38 I have made the request to generate http://www.w3.org/2008/12/11-devices-minutes.html matt 12:32:24 ??: how do you see these applications getting on the devices? 12:32:31 s/??/dougt/ 12:32:31 s/??/DougT/ 12:33:05 FM: I see that you would get it from operators, but it could be from anyone. 12:34:34 Topic: themes so far today 12:34:54 NA identifies some common themes that have emerged 12:35:36 widget and web differences? 12:35:39 I'd personally like that we keep in mind that tools are never going to save us 12:35:39 ...policy management is important by difficult. 12:35:47 s/by/but 12:36:29 arve: +1 12:37:48 I'd also like to add that centralized authorities are unlikely to save us either, see Aurora Feint/address book debacle 12:38:56 PB: when I got to my banking website, when the banking website presents me with a iframe I still trust it. There are still lots of problems on the Web. Is there prerequisites that we need to solve on the Web first? Are we just going to throw our hands in the air and say "nothing works securely"? 12:39:38 TLR: so, to reiterate, there are problems with web browsers today, do we need to solve those first? 12:39:52 NA: we don't need to answer that now, but leave it for later today 12:41:34 AB: what are the topics for this afternoon? 12:43:11 AvB: the tools wont save us! :D 12:44:17 ... discussion about declarations, authors will copy and paste... 12:46:12 ??: sure, community might help, but sandbox is really important here. 12:46:38 s/??/Lucas/ 12:46:39 s/??/Lucas/ 12:48:47 suggest WG consider using existing standards, such as XACML. May wish to share noted needs with OASIS TC to determine fit with most recent XACML work, possible profiling in that TC might be possible. 12:49:02 Unfortunately WebIDL wouldn't work as a policy language 12:49:12 it lacks certain capabilities you are going to want 12:49:17 (esp. regarding network) 12:49:28 Doing general policy work might be hard, some work has been done in this area in WS-Policy (eg how to determine intersection of policies with alternatives etc) 12:49:51 arve, I think the suggestion of WebIDL was not suggested for policy, just the interface definitions 12:49:52 lunch 12:57:25 smb has joined #devices 13:01:42 smb has joined #devices 13:08:28 smb has joined #devices 13:09:11 fjh has joined #devices 13:16:27 fjh has joined #devices 13:19:32 pauld has joined #devices 13:38:12 fjh has joined #devices 13:43:41 Dowan has joined #devices 14:00:07 fjh has joined #devices 14:07:45 scribe:Matt 14:08:16 Topic: Brainstorming on Conclusions 14:09:02 tlr: Agenda, now until 3:30 one session, could be the end then or go from 4-5 as well. 14:09:06 cited XML 2006 talk on policy languages: http://2006.xmlconference.org/programme/presentations/63.html 14:09:37 tlr:A number of themes have come up. 14:09:41 tlr: What ever gets done should be the same for the Web as for widgets. 14:09:57 tlr: I'd like to deep dive on that. 14:10:37 tlr: In the policy related presentations we had about identifying actors and sites. Deep dive on that. 14:11:04 tlr: How do we identify and name the actors? 14:11:19 tlr: Another thing we said: API's identified and defined in machine readable format 14:11:41 tlr: marcos said it could just be a URI with some known constraints, for instance. 14:11:52 tlr: API discovery. 14:12:04 tlr: Policy management. 14:12:13 tlr: Themes in the discussion on this: declaration of intent 14:12:22 tlr: -- apps identifying the APIs used at install time. 14:12:52 tlr: exchanging policies as well. 14:13:01 tlr: On policy management, I'd like for us to be able to report on the level of interest there 14:13:14 tlr: UI and usability arguments have been brought up numerous time. Difficult to standardize.. 14:13:47 tlr: Coordination of any work that might come out of this workshop. Whhat do we need to consider within this environment? What about the work within the W3C? 14:13:57 tlr: I'd like the report to reach some conclusions on there as well. 14:14:09 tlr: Are there points that have been missed? 14:14:32 DKA: Anything on those topics, can we think about charter fodder, think in terms of deliverables that we can work on, either in an existing group or another. 14:15:08 tlr: Yes, that is what I meant by scope, thanks. 14:15:18 Topic: Web and Widgets, should they be the same? 14:15:34 Dowan has joined #devices 14:15:42 DKA: It's a philosophical more than technical point. 14:15:53 DKA: Widgets work should be extending the Web into being able to operate offline. 14:16:00 +1 to DKA 14:16:08 DKA: The work on APIs should be extending the Web into being able to securely access capabilties on a Web device. 14:16:23 DKA: How do we make sure the work we're doing extends the Web rather than 'break' it. 14:17:06 Lucas: I think of widgets in terms of context of the widget. If it's in a page on a browser, or if it's on the desktop, or with total system access... 14:17:24 Lucas: You can get into the semantics... I don't think widgets on the desktop need to be fully privileged 14:17:52 Paddy: Arve said there's no argument that the APIs shouldn't be the same between the two. 14:18:18 Paddy: In BONDI we identified two differences. The way in which you express a dependency on an API.... 14:18:44 Paddy: Two differences: 1. 2. If you have a policy the . 14:19:21 ??: I agree, the only difference being the declaration aspect. Widgets have a way of providing identity that Web apps don't. Perhaps the widget model is more secure or more established. More possibilities. 14:19:29 DKA has joined #devices 14:19:31 s/??/Adrian/ 14:19:39 EMScamking has joined #devices 14:20:07 If a widget run time is created with the same constraints as the browser, then they're essentially identical. 14:20:36 arve: If they're identical or not is philosophical in one way, but also they are something more: full fledged applications written in the Web as a platform. 14:20:47 arve: As such, I'd say all Web applications/pages are a subset of widgets 14:21:08 "browsers are widgets" -- dougt 14:21:10 ArtB: We could rathole on this discussion (and surely will). 14:21:39 ArtB: If in your mind there is some reason to differentiate between these two things, and it will maniftest itself as different work items I'd like to know 14:22:10 PHB: I'd be cautious of us saying "Let's limit our scope of inquiry because that will make our work shorter"... Groups that chop stuff out arbitrarily tend to take longer as the scope expands. 14:22:28 StewartB has joined #devices 14:22:42 DKA: I think this is an important question because: are we designing part of the Web or are we creating a new way to write Java apps on your phone. 14:22:54 DKA: I think it's much more interesting and relevant if we do the first. 14:23:04 tlr: I'm biased that the first one is important. 14:23:21 tlr: If people here think it's more the second one, then maybe we shouldn't make assumptions. 14:24:03 dougt: There is a third category beyond Web and Widgets, Desktop like applications, like AIR, and fx Prism. 14:24:04 fjh has joined #devices 14:24:19 dougt: The Web in the browser on your desktop... The Web in your browser on your phone... 14:24:46 arve: Is there a difference between AIR and widgets? 14:25:11 Lucas: Ratholing some more: we probably shouldn't redefine applications as widgets. 14:25:23 Lucas: At Adobe they wanted to call AIR applications widgets. 14:25:39 Lucas: There is that space between a Web app and a Desktop app, and that's a big space. I don't think it's productive to define widgets. 14:26:02 dom: Paddy identified two ways in which widgets are different than Web apps: 1. a manifest and 2. trust model. 14:26:15 dom: The fact that widgets have a manifest could easily be extended to a Web site. 14:26:58 dom: In terms of defining a security model for this stuff, does it matter or not if these two are different? In one case you have well-defined distribution and identity model, and in the Web you don't have that policy. 14:27:40 Paddy: 14:28:06 Lucas: The difference betweeen Web app and applications isn't meanignful... 14:28:19 s//one way people make a difference between applications and web sites is that applications go through an installation process/ 14:28:21 diff is implicit installtion process 14:28:29 Lucas: 14:28:31 For the record: I was using "Java Apps" as an example of a "closed ecosystem" of mobile applications (i.e. not "The Web"). 14:28:55 tlr: Packaging, trust model, identity... these are the three things we see. 14:29:02 dougt: I think these are more the same than different. 14:29:22 tlr: I would say don't introduce technology in the widget space that makes it unnecessarily difficult to use in the Web space. 14:29:30 ArtB: If that's not a design goal than marcos should clarify it. 14:29:46 s/than/then/ 14:30:17 smb: There are a fair number of problems with marrying the Web and the desktop. The properties of trust are very different. Where decisions are made, etc... 14:30:30 smb: Windows 95 help files for instance. 14:30:43 smb: They were in MS hypertext-like things. 14:30:56 smb: They had helpfiles that were capable of executing dangerous code. 14:31:09 smb: Download an .hlp file and it could format your hard drive. 14:31:34 same could be said of Word documents, a popular conduit of malware 14:31:38 smb: XP SP 2 tagging stuff in file metadata that came in from the net, so that it wouldn't be treated as trusted content... 14:31:52 smb: That allowed you to distinguish stuff that could be trusted and that which can't. 14:31:59 smb: We need a very bright line at the trust boundary. 14:32:19 smb: Cookies, stored one per file... could be stored on disk with trusted JavaScript in it. 14:33:20 tlr: We seem to be assuming as a given that we will see application like things written in HTML and JavaScript. Is there an additional trust boundary that we can put in? 14:33:25 "Applications-like things written in HTML and Javascript" -- tlr 14:33:54 tlr: We have a Web page that has an origin there, and that's the only thing we know about it's origin. Can we trust it and give it capabilities. 14:34:04 smb has joined #devices 14:34:07 tlr: Are we taking the policy for granted? 14:34:53 tlr: What I heard in Aplix presentation: we have different types of identity. We can base the decision on signature. The Origin is the only thing we have on the Web. 14:35:24 tlr: Is that all there is to be said about identity or are there other points that need covering? 14:36:00 marcos: at the moment a widget may not have a manifest and therefore no identity 14:36:15 marcos: Should we mandate an identity in widgets? If a widget doesn't have an id, should it run? As it is now if it doesn't have an id it'll still run. 14:36:30 PHB: If we're blurring the desktop and the Web and becoming more complacent, then that's bad. 14:36:41 PHB: We don't want to treat the Web the way we have the desktop. 14:36:52 PHB: How ever, I don't mind if we go the other way, where the controls from the Web come to the desktop. 14:36:55 fjh has joined #devices 14:37:13 PHB: The desktop is also the accumulation of things we receive from external sources: be it a CD ROM or a download. 14:37:32 PHB:So I'm fine to blur it if it means more rather than less. 14:37:43 smb: I agree, but I know when I put a CD in, vs a drive by download. 14:38:02 tlr: Where are we in terms of identification? 14:38:17 tlr: Are we getting to a requirement for the widget specs to include additional ID? 14:38:30 tlr: Something manifest based that is on a finer scale than an origin. 14:39:39 Lucas: You can view as the wrong APIs in the wrong context, or the failure of the installation experience. There's not a requirement for a Web page to have a strong identity. I'm not sure why widgets . Then we have to consider signing the manifest, which would be expensive as well. 14:39:49 marcos: we have the ID. 14:40:03 Lucas: But it's useless, just assume the ID of some popular widget and then they can't revoke it... 14:40:18 smb: You can always have a default with a minimal safe API. No ID necessary. 14:40:27 Lucas: Right. That's the basic Web-type sandbox. 14:40:41 Lucas: That's what sandboxes are for. Safe widgets would basically be Web pages. 14:41:08 Paddy: You can compare this with midlets that aren't signed by anyone, and run in a mediated environment. 14:41:23 Paddy: There's no reason, if you have a mediation that always occurs. 14:41:43 Lucas: That's going to have a impression on user experience. 14:42:06 [I think the premises of this workshop is "great powers come with great responsibilities" - we only need to put more requirements on content/developers if that content needs more power (and thus make incur more risk to their users)] 14:42:08 Lucas: In the Web model you still have some things that need to succeed. 14:42:20 arve has left #devices 14:42:33 tlr: There are different forms of identity that can hopefully be translated into a proper kind of framework.\ 14:43:42 andrei: There is a level of trust, regardless of whether it's Web or widget, that determines which policy is invoked. It doesn't effect the framework at all. 14:43:50 s/andrei/adrian/ 14:44:13 smb has joined #devices 14:44:27 Topic: API identity and naming 14:44:41 tlr: The declaration of intent probably seemed to be the common agreement. 14:44:43 claudio has joined #devices 14:45:12 tlr: Web apps and perhaps widgets, that want to use extended APIs should find a way to declare their intent to use these APIs, and that should probably be declarative. 14:45:26 tlr: But someone said in the Web apps case that you need to use an API to declare what APIs you use... 14:45:47 tlr: Is there any disagreement with the need to start witing up a declarative model for Web apps and Widgets to declare their intent to use a certain extended API. 14:46:34 tlr: Repeat: I heard there was almost total agreement that there should be a way for widgets (at the very least) to declare what APIs they're going to use. 14:46:48 tlr: Does that extend to Web apps or is this a place where they should diverge? 14:47:23 dougt: We saw a setup where you had the list of features and a yes/no, we talked about who was supposed to manifest that... it seems like it'd be a good thing to have when we construct their run-time. 14:47:43 dougt: When we construct it at runtime, then we could selectively add it based on manifest. 14:48:02 dougt: In the Web you put the object in there, and you notify the user as expected 14:48:11 dougt: This is almost a P3P model for widgets. 14:48:25 dougt: Minimizes the surface area of any potential attacks, but not sure how good it would be for the Web. 14:48:36 ??: It'd be useful for Web applications to declare as well 14:49:11 The dialogs for when the Web application is invoked for the first time, but in a declaration you can confirm before use 14:49:19 s/??/Claes/ 14:49:54 smb: I think there's a lot of good reasons for having this on the Web as well. Yesterday I said about a high assurance declaration, but you've got a sandbox around this thing, that only exposes those interfaces and that's it... 14:50:17 smb: There are usability issues, but at least you have a concrete basis that it can do this and nothing else. 14:51:10 mark?: I'd agree with smb, that as well as giving the UA and the user this assurance of the sandbox, it also let's the developer define the constraints of the sandbox. Then as a developer, even if there is a case where my widget runs malicious code accidentally, then I know it'll still be safe. 14:51:38 tlr: This might map into deliverables. What APIs and how do you declare them? What concrete framework can we come up with for this declaration? 14:51:49 Nick: Can we reuse that same mechanism in the Web context as well. 14:52:09 Anil: As long as we give the UA enough flexibility to chose the user experience, then providing the building blocks is good. 14:52:17 +1 to smb - using manifest to limit apis instantiated, thus those not in manifest cannot be used even in attack 14:52:18 Anil: Let the implementors decide how they are used. 14:52:32 +1 14:53:28 Lucas: Is there consensus around the run-time must ensure that the application can only run the APIs that are declared. 14:53:43 Nick: Yes, otherwise it's the run-time with least privilege. 14:53:49 to anil :) 14:54:33 ??: there's nothing restricting the container from evaluating policies in run-time. 14:54:38 smb: But then...?? 14:55:01 s/...??/you lose the interest of having a declarative manifest 14:55:19 tlr: You can look in the manifest in at least two ways. A convience for the run-time, and the other is 14:55:42 pauld: A good real example is FaceBook, having an application on FB ends up with every possible control being ticked and then people dare not tick those off because they want the app to work. 14:55:48 s//a way to sandbox and protect the user against abuse/ 14:56:13 pauld: what we saw in Caja is at run-time figuring out what it's doing, then look at the policy... 14:56:35 pauld: If the policy isn't set up, then looking into metacap up front... it just isn't going to work. 14:56:59 Paddy: There is a difference between static and dynamic situations here... In the widget case you see the declarations well-ahead of making the calls. 14:57:11 Paddy:If you're signing them, you can use that declaration as input to signing them. 14:57:25 s/metacap/metacrap/ 14:57:45 Paddy:In the case of a Web app, that may be a case of fetching the doc and then fetching the declaration. It doesn't add any strength to download a second document. It's metacrap. 14:58:16 Paddy: There's no way to do this with the Nokia APIs... the permission check is made at the time. 14:58:59 Fabio: We have two interpretations of intent, at worst I need all of these. If you declare this is all you need, then you might want to mandate sandboxes, but another interpretation is that "at least I need this much". 14:59:22 Anil: I think we're debating implementations. 14:59:40 Anil: Who would be anti such a declarative set in the manifest? 15:00:27 Anil: Implementors can figure out what to do with it... the manifest could be useful: 1. if my widget needs a camera then you can stop at install time. 2. security, if it's unsigned and declared up-front, the UA can do things. 15:00:36 Anil: I think we should avoid implementation details. 15:00:54 Anil: I'm sure BONDI will have best practices all around this, with differences for Web apps and widgets. 15:01:13 tlr: I agree, but I note that there are two use cases that Fabio pointed out that may be useful. 15:01:19 smb has joined #devices 15:01:39 Lucas: Putting a bunch of privileges in the manifest is I think a UI problem. 15:02:08 Lucas:If you have a manifest, you can provide guidance at installation: "This app can steal your data!" or "This app can't really do much". 15:02:29 Lucas:If we don't do that ahead of time all we can do is a piecemeal approach, such as "This thing wants to use the network". 15:02:44 Lucas: I think we need a manifest like this in human readable format ahead of time. 15:03:01 smb: There are scenarios where A but not B is secure and B but not A is secure. 15:03:29 smb: Read top secret file, but write to a normal file for instance. 15:03:47 smb: From the security perspective it's a contract between implementor and the system, and the system will hold you to that. 15:04:08 smb: As a software engineer why shouldn't I declare? 15:04:38 tlr: I hear implemenation disagreements here. 15:05:20 Anil: In the Web app case, since things are a bit more dynamic, then there may be cases where the requirements change. How would we handle that with a declarative policy? In the widget case that's probably less of a problem. 15:05:37 smb has joined #devices 15:05:42 tlr: That's an interesting and important question that will show up in the report. 15:05:55 Topic: Where should concrete APIs be addressed? 15:06:07 in reality, Facebook apps ask for everything, in case they later need it 15:06:11 Nick:Where should the API work go? 15:06:25 Nick: accepting the fact that we have multiple APIs, does there need to be consistency? 15:06:51 Nick: A few drivers for that: 1. developers life simpler 2. security implementations might impose some things on API design. 3. discovery 15:07:37 dougt: The APIs you're talking about, the developer would be able to query which devices are present? What's the scope there? 15:07:44 Nick: The immediate one is "Is it there?" 15:08:17 Nick: As an app developer, there's variants of a camera API and you want to find which one is there. 15:09:37 tlr:I think we heard this morning that concrete API proposals will be coming the way of the W3C. Where should we do this work. 15:09:50 tlr: Are there design patterns, code requirements on device APIs, and how should that be reflected? 15:10:02 ArtB: we might want to be a bit careful about the meaning of device APIs. 15:10:21 ArtB: Geo is a device API in my mind. Are we putting requirements on tha group? 15:10:21 s/tha /that / 15:10:34 ArtB: Are we putting requirements on the Web API work that's in the charter of WebApps? What is a device API? 15:10:46 tlr: Is there a concrete API that you're referring to? 15:11:09 ArtB: The WebIDL spec has some useful information. 15:11:23 tlr: Maybe there is no interest in this, other than a note in a workshop report. 15:11:28 ArtB: Who is going to do the work, what is the priority? 15:12:09 Nick: Specific example: multiple APIs with a shared security framework. What is the way that's done, and is it standardized? Standard exceptions/errors, etc. Should it go in the WebIDL spec, should it be... 15:12:48 marcos: It'd be good to have a WG Note that outlines the principals that we want in the Web APIs. Asynch APIs, extensible parameters, etc. Who would do that work? I don't know 15:13:12 tlr: I hear at this point that it's coming up in discussions. 15:13:46 marcos: OpenAJAX Alliance also wrote and submitted it to , if they want to submit it as a Note that's a good idea. 15:13:46 -> http://www.openajax.org/member/wiki/Mobile_Device_APIs_Style_Guide Mobile Device APIs Style Guide from Open Ajax Alliance 15:14:08 Topic: Concrete APIs 15:14:40 Nick: Contacts, messaging, where do they fiit in current w3c scope? Which charter do they fit into? 15:15:41 tlr: What interest is there in diving into other APIs. 15:16:06 steve: Been working on a set of APIs for a while now. Working on them being NOT Nokia specific and getting them into the w3c. 15:16:32 smb has joined #devices 15:16:32 Matt: That sounds like a reasonable thing to submit to stimulate further discussion. 15:17:06 ArtB: Submission the appropriate WG or a Submission to the w3c. 15:17:20 s/n the/n to the/ 15:17:28 Topic: Policy Description 15:17:43 tlr: Let's recall the use case that Paddy had in mind... 15:18:39 smb: Not going to define a policy language sitting here. Interacts with the naming of the API, think they have to be designed together. Some of the criteria specified, I think you want some semantics associated with the name for instance. Look at something and know how it relates to previous policies for instance. 15:18:48 Steven: Why does that interact with API naming? 15:19:20 smb: The manifest you're downloading will say: "I need to interact with the get location GPS thing or JPEG 2004 thing", and you say "What is that?!". You want it to be comprehensible. 15:19:50 Steven: You can name capabilites in a reasonable way, and map them to the actual things. 15:19:59 smb: You run into trouble with two names for the same thing, but yes... 15:20:46 Paddy: We have a framework, widgets can be given certain rights, and we have a language describing those things... any use case with exchanging policy... there were big differences, trust domains, or fine grained concerns, or what have you. 15:21:02 fjh has joined #devices 15:21:06 Paddy: Even if you don't want an interoperable way to do that, you ... 15:22:04 ArtB: I agree that we have all these different models so we need to step way up as far as I'm concerned. I think the use cases are where we need to begin. What are the requirements? Frederick has pointed out that there is prior art, etc. 15:22:23 Paddy: Wasn't saying use cases weren't important, just in 15:22:49 pauld: I think if we can agree on something like: You say camera and I say camera and we mean the same thing. 15:22:58 fjh: I think policy language gets very complicated. 15:23:13 pauld: It's like a schema language. You start with a list and end up with a turing complete machine... 15:23:17 fjh: ?? 15:23:39 pauld: That problem is being solved in many ways... when I say "camera" but you talk about "optical device".. well, that doesn't work. 15:23:53 andre: Would you say this is linked to the development of API. 15:24:18 andre: No matter who the provider is of the Geo API, as long as the interface fits with the specification, then the policy should have some way of saying that it fits with that specificatoin. 15:24:31 andre: For any API you have that fits that specification, then your policy matches that as well. 15:24:37 s/specificatoin/specification/g 15:25:03 s/fjh: ??/fjh: I'd argue it's actually quite difficult to develop a good policy framework/ 15:25:08 Nick: You implicitly put constraints on the interface design. Any implementations should not have different security constraints around it. 15:25:16 smb has joined #devices 15:25:26 Nick: The contacts API for instance, one might have to go into the network to retrieve it which has some cost. 15:25:47 policy language may be easy to write, but it might be harder in practice to compare policies for intersection or determine if policies are equivalent, or deal with cases of and/or/not etc. doing from scratch could be a larger project, 15:25:56 ArtB: Are we going to start building dependecies here? 15:26:19 ArtB: The manifest stuff right now is straight forward. From an architectural perspective, I'm concerned about dependencies. 15:26:33 s/dependecies/dependencies/ 15:27:58 tlr: I think we can do the policy framework conceptualization before we do the language and before we figure out differences between Web apps and widgets... 15:29:23 dom: Straw poll of standardizing in the policy framework domain? spending resources and time developing standards for that? 15:29:38 fjh: When you say policy framework, are you talking about access control policy or contracts or...? 15:30:05 tlr: The conceptual framework that may fit whatever you want. Who are the actors, what decisions may be made, e.g. origins, frameset, identity. 15:30:28 tlr: If this summary doesn't make sense, please say it now... 15:30:34 ArtB: I think we lost some details. They are important. 15:30:41 ArtB: Are you skipping the use acase and requirements. 15:30:50 rrsagent, draft minutes 15:30:50 I have made the request to generate http://www.w3.org/2008/12/11-devices-minutes.html matt 15:31:00 ArtB: I'm not sure what the question is anymore. 15:31:51 tlr: We have in the discussion that at the advanced level, fully fledged policy exchange frameworks. These frameworks make assumptions on what the framework and policies are, they make assumptions about identity and constraints... 15:32:29 tlr: The minimum work item would be about articulating this, but shying away from the and it would enable the ability of applications to work in a reasonably consistent environment. 15:32:40 tlr: The framework for applications to speak relatively the same language. 15:33:16 Nick; Using these frameworks, I've established a trust relationship with my favorite app providers, I go to another operator, am I able to preserve those settings? that would imply an exchangable policy. 15:33:54 pauld: Even within browsers on the desktop, you can have a session, establish trust, move to another browser and not have that trust. Going across operators is rather ambitious. 15:33:55 ArtB has joined #devices 15:34:14 tlr: Who is interested in expending resources and time to extend the policy mechanisms that Nick just described? 15:34:32 fjh: Where does this fit with the OASIS group? 15:34:46 fjh: I'd help with that sort of thing, but I think we need materials to run by them. 15:34:47 hands raised from rep of Mozilla, OMTP, Vodafone, MarcosC; a maybe from Nokia 15:34:57 tlr: Who would be participating in such a group? 15:35:06 s/MarcosC/Marcos C Inc. :D 15:35:09 aplix too dom 15:35:34 "yes" from Nokia 15:37:24 ArtB: Isn't the security context looking at UI considerations? 15:37:43 tlr: I saw shaking heads on UI considerations. what about policy management? 15:38:15 Nick: Policy is who can do what where and when, while management is being able to change those policies. 15:38:30 ArtB: Is policy management in scope for BONDI. 15:38:37 s/BONDI./BONDI?/ 15:38:47 Nick: 15:38:56 ArtB: You're making a clear distinction between policy and management? 15:38:59 Nick: We're trying to. 15:39:09 tlr: Coordination briefly. 15:39:26 tlr: Break for 20, little more scoping on policy description, and then coordinatino needs, then go home. 15:40:09 Dowan has left #devices 15:42:46 smb has joined #devices 15:49:21 smb has joined #devices 15:49:58 pauld has joined #devices 15:54:56 smb has joined #devices 15:58:04 fjh has joined #devices 16:02:18 smb has joined #devices 16:07:05 Topic: And So We Enter The End Game 16:07:20 scribe: pauld 16:07:39 tlr: more scoping the policy description and coordination cases 16:08:01 .. Nick mentioned portability of policy in the broadest sense 16:09:07 fjh: wants to raise related work which has been done in XAML, which are we talking about? 16:09:35 s/XAML/XACML/ 16:10:44 steve: strict adherence to the current XACML shouldn't be a requirement, a subset seems to be desirable 16:11:09 fjh: yeah, you don't want the charter to preclude you doing something intelligent! 16:11:32 .. you want to evaluate it and use it if it's suitable 16:11:56 steve: is XACML good enough for defining trust policies? 16:12:55 tlr: the second of the points, how to use whatever mechanism we come up with for expression is more interesting, not so much the expression mechanism itself 16:13:34 s/which are we/the mechanism, and how to use the mechanism, which are we/ 16:13:55 smb has joined #devices 16:14:56 tlr: are we on the same page, writing a policy which is actually about enforcement is important 16:15:10 tlr: discovery in scope, or out of scope? 16:15:46 DKA: in scope, but not core. It's a supporting use-case 16:16:32 Lucas: out of scope only in so far as implementation, happy to define the format, but not how to do the discovery 16:16:48 reminder: "DCCI" is not an insult in most countries 16:17:06 dougt: this could descend into DCCI! 16:17:27 sorry for the hate. 16:17:34 it was my upbringing. 16:19:36 tlr: in discussing policy mechanisms, I'm hearing taking discovery into account is OK, but it mustn't drive things 16:20:38 Lucas: use-case, not core 16:20:55 marcos: policy can override a manifest 16:21:39 steve: I'm looking at the heading of the slide, we're talking about "discovery" but it's deeper than we're going 16:21:52 Paddy: it might be in scope, that's enough to say, no? 16:22:12 should we start qualifying things out of scope with RFC2119 keywords? 16:22:27 so that we can argue on "MAY" or "SHOULD" a bit longer 16:23:45 tlr: describes oriented landscape of PKOS, privacy and other communities, not currently doing normative work 16:24:16 tlr: other points we should talk about? 16:25:15 tlr: portability is important 16:25:40 steve: capability and permission semantics and evaluation algorithms important to me 16:26:14 ??: anything to say about the management piece? 16:26:39 tlr: not feeling energy in the room to discuss management, but if you have work, say now! 16:27:08 ??: is there consensus management is out of scope for the W3C 16:27:16 steve: doesn't seem to be a W3C thing 16:27:31 s/??:/art/ 16:27:36 s/??:/art/ 16:27:55 tlr: anything else out of scope? 16:28:27 steve: I put JavaScript sandboxing out of scope 16:28:49 dougt: you see that as an implementation detail? 16:29:18 steve: policy should be flexible enough to control the sandbox 16:29:47 tlr: work currently in HTML describing access policy for method invocation and attribute referencing 16:30:36 tlr: HTML5 coordination is required 16:32:01 tlr: method and attribute scoping seems out of scope, but availability or otherwise of methods to a sandbox - is that in scope? 16:32:52 steve: there is some possible overlap, e.g. inheritance of privilege to iframes 16:33:44 tlr: interaction with HTML5 DOM - SOP etc in scope. 16:34:02 .. fundamentally different capability models - out of scope 16:34:31 .. impact of SOP, framesets etc on device APIs - in scope 16:35:04 .. enforcement of policies through hiding, security exceptions etc, - in scope 16:35:09 ArtB has joined #devices 16:35:42 Adrian: is this tied to JavaScript, some manifest requirements, e.g enabling camera, may not require JS 16:36:18 tlr: *waves hands* we can craft appropriate text for that 16:37:16 tlr: crafts list of Scoping on Slide 16:37:51 .. no more features? 16:38:53 tlr: coordination: we have PLING, XACML TC, HTML5, Webapps, geolocation, XML Security 16:39:13 .. geopriv 16:39:32 ty 16:39:54 DKA: Mobile Web Best Practices 16:40:10 tlr: and BONDI? 16:40:15 Nick: it's implicit 16:40:21 s/tlr:/DKA:/ 16:40:24 .. OpenAjax 16:41:46 Nick: we've covered all the bases, except Policy Management (lost point in loud boat hooting) 16:42:15 .. the devil is in the detail of course 16:42:46 tlr: the scope we're talking about is for something new, not something you can sneak into an existing WG 16:43:15 tlr: Nick and I will come up with minutes and a workshop report 16:43:42 RRSAgent, make minutes 16:43:42 I have made the request to generate http://www.w3.org/2008/12/11-devices-minutes.html ArtB 16:44:06 .. will circulate them amongst the attendees before publishing, though the logs have been made public 16:44:28 +1 thanks to Dom 16:45:42 tlr: formal thanks to Dom for pulling this workshop together, wouldn't have happened without you. Also many thanks to Vodafone and Daniel Applequist for hosting, thanks to Nick for co-chairing! 16:45:47 ADJOURNED 16:45:57 RRSAgent, make minutes 16:45:57 I have made the request to generate http://www.w3.org/2008/12/11-devices-minutes.html pauld 16:46:34 matt has left #devices 16:47:28 RRSAgent, bye 16:47:28 I see no action items