RE: File writing ponderings (was: Re: Security evaluation of an example DAP policy)
+1 to this idea The issue is that DAP tries to handle CRUD for multiple types of data. If we want to consider input type=file/ for reading files, then we may think of something like the following potential API design pattern: a) output type=file/ to possibly trigger File Save As dialog (if it is not only to be programmatic) that would also communicate via URN with JS b) for other types of data we could have input type=contact /, input type=event / etc, plus output type=XXX/ for those types. The output's would be handled by platform specific UIs, similarly to input type=file/ handled by File Open Dialog. BTW: File Open Dialog (actually any similar Dialog) may be regarded as the prompt (oneshot etc) in the policy-based API. This aspect is usually left to implementations. In case of file API the issue is about abstraction of the path with URN. So the path could be available in the policy-based approach, whereas only URN would be available in the policy-less design. If the File API changes urn attribute to url, we could handle both already now. Thanks, Marcin From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On Behalf Of Aaron Boodman [...@google.com] Sent: Saturday, November 21, 2009 9:31 AM To: Jonas Sicking Cc: Robin Berjon; Adam Barth; public-device-a...@w3.org; public-webapps WG Subject: Re: File writing ponderings (was: Re: Security evaluation of an example DAP policy) On Sat, Nov 21, 2009 at 12:26 AM, Jonas Sicking jo...@sicking.cc wrote: Hmm.. This is a very interesting idea. Definitely worth exploring more. What I had in mind was basically something like this: 1. An API for creating File objects by concatinating strings, Blobs, ByteArrays (or whatever they'll be called, see Maciejs proposals to public-webapps and public-script-coord). A mimetype and a default name (possibly without extension) would also be assigned to the File in some fashion. 2. A API that given a File object brings up the normal Safe File As dialog. FWIW, this is what I had in mind, too, back when I used to think about such things. - a Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Security evaluation of an example DAP policy
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon ro...@berjon.com wrote: On Nov 20, 2009, at 00:22 , Adam Barth wrote: It's emails like this that make me skeptical of the security work being done in the device APIs working group. *sigh* I feel like a broken record. It feels like I've spent my time since TPAC involved in an endless repeat of the following discussion: - You must support security at the API definition level!!!1 - Yes. That is the plan. That is what we will do. We've already agreed to that. - Okay... But... You must support security at the API definition level!!!1 - ... DAP will handle security at the API definition level. Full stop. Now, there may be participants in the WG who believe that policy could *also* be used in browsers, or other such things. That may or may not be the possible, practical, doable, implementable, safe. You may or may not agree. The fact is, for the purpose of trusting that DAP will handle security at the API definition level, it doesn't matter because: DAP will handle security at the API definition level. If you don't like the policy stuff, don't implement the policy stuff. You can still implement the APIs because, you know what? DAP will handle security at the API definition level. If later a policy-based approach surfaces that changes your mind and makes you want to support it, that's also fine. But for the immediate purpose of creating DAP APIs that can work in browsers it doesn't matter because DAP will handle security at the API definition level. Is this clearer? Would people mind if we had this DAP conversation just on the DAP list and cut down on the cross-posting? It's not as if WebApps didn't see some traffic already. Oh, and yeah, DAP will handle security at the API definition level. Imma let you finnish, but HTML has the greatest security of all times. Of all times! :) Ok, in all seriousness. I don't think we'll be able to get any further until there are actual API proposals on the table. At that point I think the various browser vendors and other interested parties can express actual concrete opinions on the security level of the API. However I figured that people might be reluctant to come up with proposals unless they know what the requirements were. And while I don't think there are any hard and fast requirements, I was hoping to shed some light on at least how we think about these things at mozilla. I do hope that that has become somewhat clearer. And I'm looking forward to seeing actual proposals so that we can move from meta discussions to technical discussions. / Jonas
File writing ponderings (was: Re: Security evaluation of an example DAP policy)
Starting a new thread since the other one was more of a meta-discussion, this one has more technical meat on it. On Fri, Nov 20, 2009 at 9:23 AM, Robin Berjon ro...@berjon.com wrote: On Nov 20, 2009, at 17:40 , Adam Barth wrote: On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon ro...@berjon.com wrote: DAP will handle security at the API definition level. Full stop. Can you elaborate on what this means concretely? For example, how is security handled at the API definition level for the file writing API? Well, if you're asking me to define how we're going to do it for all the APIs before they've been written, it's gonna be a smidge hard :) I've been noodling a little bit over the file writing case, and have some ideas that at this stage involve hand-waving, have not been validated by the WG or in fact anyone else, and are subject to change (I only took on the action to work on this yesterday, and haven't really sat down to do it right yet). One idea, which Max had, was to tack this onto input type=file. The file browsing dialog we have today would work the same, but would have an extra checkbox (unchecked by default) saying Enable writing back to this file. The file object would become available in the same way as for reading, but would also support writing. It has limited but real use cases, such as loading a document (HTML, image, whatever) which can be edited in the page and saved back. The problem is that it doesn't allow for creating a new document (the initial save) — I haven't cracked that one yet (creating new files, even if they can't overwrite existing ones, has clear issues). My main concern with this idea is that I'm not sure how to make it clear to the user that access is granted both for reading and writing. It could be that the initial save happens through a download dialog — something which users are familiar with. This I like better. More below. Another option I had in mind was an extension to Element, e.g. Element.attachData(someFileObject). Said element would then, when dragged out of the browser, drop the content of the file there. It's been a while since I've looked at ongoing work on the cut-paste/drag-drop stuff and I've been meaning to take a good look at it precisely for this. I suspect that if the security issues are solved for those, then we might be able to piggy back on them to create files safely. But that's just a braindump. Hmm.. This is a very interesting idea. Definitely worth exploring more. What I had in mind was basically something like this: 1. An API for creating File objects by concatinating strings, Blobs, ByteArrays (or whatever they'll be called, see Maciejs proposals to public-webapps and public-script-coord). A mimetype and a default name (possibly without extension) would also be assigned to the File in some fashion. 2. A API that given a File object brings up the normal Safe File As dialog. / Jonas
Re: File writing ponderings (was: Re: Security evaluation of an example DAP policy)
On Sat, Nov 21, 2009 at 12:26 AM, Jonas Sicking jo...@sicking.cc wrote: Hmm.. This is a very interesting idea. Definitely worth exploring more. What I had in mind was basically something like this: 1. An API for creating File objects by concatinating strings, Blobs, ByteArrays (or whatever they'll be called, see Maciejs proposals to public-webapps and public-script-coord). A mimetype and a default name (possibly without extension) would also be assigned to the File in some fashion. 2. A API that given a File object brings up the normal Safe File As dialog. FWIW, this is what I had in mind, too, back when I used to think about such things. - a
RE: Security evaluation of an example DAP policy
Hi Jonas, Thanks for your comments. The below policy actually blocks access to all device APIs for all websites (up to bugs in the RE, now I think it should be /.*/ instead of /.+/), thus actually expresses the currently applied policy available in the browsers. I.e. it already works to some extent :) I assume the clear arguments raised in this mail thread will be very helpful for DAP and BONDI. Handling data exchange between scripts and OS via input element with explicit user consent is another paradigm that I believe will be explored. We could think of some mapping of the APIs from/to input to be able to realize functionally same scenarios with minimal change of the code. E.g. input type=contact would be a kind of equivalent to addressbook.getContact() or so. The differentiation could be as above, but the properties of the objects retrieved by both above scenarios could match for easy integration. Personally I perceive it as a design pattern. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Friday, November 20, 2009 2:04 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Thu, Nov 19, 2009 at 4:49 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, Maciej, It seems that the policy that you would accept would be: policy-set combine=deny-overrides policy description=Default Policy for websites. Simply denying all API that are covered by some device capability:) target subject subject-match attr=class match=website func=equal/ /subject /target rule effect=deny condition resource-match attr=device-cap func=regexp/.+//resource-match /condition /rule /policy /policy-set Let's see how DAP will evolve then. Given that I don't know the specifics about this policy format I can't comment on the above policy specifically. However I will note that the security experts at Mozilla did agree that opening a non-modal dialog asking for access to geo-location was considered acceptable, as I noted in a previous email. I don't know what effect that has on the above policy. I don't know what policy other browsers have used in this area. / Jonas Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Security evaluation of an example DAP policy
These are reasons, but I think the greatest cause of our concern is that we have not seen any examples of how policies can provide the same level of security that baking security into the API from the beginning can provide. All too often the policy based approaches fall back on either asking the user or simply denying access--both of which are not viable solutions in most cases within the browser. If we take security into account when designing the APIs we can often find creative approaches that satisfy all of the requirements/use-cases while providing an API that can be on by default. On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: My understanding from reading the thread is that the concern is with complexity, increased attack surface due to mechanisms that can be used in unanticipated ways or misconfigured, and management issues. Thus though policy can state a simple approach, I'm not sure the above concerns are addressed by that expression. I think we need to work through the use cases, both for those that do need a policy language and those that do not, then consider if APIs have various methods as Robin suggested, or otherwise how it will all fit together. regards, Frederick (not as chair) Frederick Hirsch Nokia On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote: Hi Jonas, Maciej, It seems that the policy that you would accept would be: policy-set combine=deny-overrides policy description=Default Policy for websites. Simply denying all API that are covered by some device capability:) target subject subject-match attr=class match=website func=equal/ /subject /target rule effect=deny condition resource-match attr=device-cap func=regexp/.+//resource-match /condition /rule /policy /policy-set Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - Maciej Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Security evaluation of an example DAP policy
Jeremy Thanks. I want to make sure I understand the concerns. I guess the question is whether one can bake all the security in that is needed for various (possibly conflicting) use cases, including those that do not presume user interaction. An argument for policy is to decouple the mechanism from the decision criteria to get that flexibility, while making sure the mechanism is secure. On the other side I hear the concern that the mechanism cannot be as secure. I note that the policy requirements document includes some use cases Paddy contributed in an earlier email: http://dev.w3.org/2009/dap/policy-reqs/#use-cases So for example, how does one bake in these: The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. Reliably identified Websites can send and receive SMS except to premium rate numbers. Do we need to go into more detail on these two (as examples)? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote: These are reasons, but I think the greatest cause of our concern is that we have not seen any examples of how policies can provide the same level of security that baking security into the API from the beginning can provide. All too often the policy based approaches fall back on either asking the user or simply denying access--both of which are not viable solutions in most cases within the browser. If we take security into account when designing the APIs we can often find creative approaches that satisfy all of the requirements/use-cases while providing an API that can be on by default. On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: My understanding from reading the thread is that the concern is with complexity, increased attack surface due to mechanisms that can be used in unanticipated ways or misconfigured, and management issues. Thus though policy can state a simple approach, I'm not sure the above concerns are addressed by that expression. I think we need to work through the use cases, both for those that do need a policy language and those that do not, then consider if APIs have various methods as Robin suggested, or otherwise how it will all fit together. regards, Frederick (not as chair) Frederick Hirsch Nokia On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote: Hi Jonas, Maciej, It seems that the policy that you would accept would be: policy-set combine=deny-overrides policy description=Default Policy for websites. Simply denying all API that are covered by some device capability:) target subject subject-match attr=class match=website func=equal/ /subject /target rule effect=deny condition resource-match attr=device-cap func=regexp/.+//resource- match /condition /rule /policy /policy-set Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org ; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - Maciej Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Security evaluation of an example DAP policy
I'm not saying that there is no need for policies (you listed two great examples of where they can be useful). They seem useful for overriding default secure behavior that we require for the web. All that I (and I believe others) am saying is that security cannot completely be decoupled from the implementation and differed to policies. Especially in APIs that we want to expose to the web. I'd even go as far as to say that differing to policies or asking the user for permission should be a last resort. On Fri, Nov 20, 2009 at 2:29 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Jeremy Thanks. I want to make sure I understand the concerns. I guess the question is whether one can bake all the security in that is needed for various (possibly conflicting) use cases, including those that do not presume user interaction. An argument for policy is to decouple the mechanism from the decision criteria to get that flexibility, while making sure the mechanism is secure. On the other side I hear the concern that the mechanism cannot be as secure. I note that the policy requirements document includes some use cases Paddy contributed in an earlier email: http://dev.w3.org/2009/dap/policy-reqs/#use-cases So for example, how does one bake in these: The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. Reliably identified Websites can send and receive SMS except to premium rate numbers. Do we need to go into more detail on these two (as examples)? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote: These are reasons, but I think the greatest cause of our concern is that we have not seen any examples of how policies can provide the same level of security that baking security into the API from the beginning can provide. All too often the policy based approaches fall back on either asking the user or simply denying access--both of which are not viable solutions in most cases within the browser. If we take security into account when designing the APIs we can often find creative approaches that satisfy all of the requirements/use-cases while providing an API that can be on by default. On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: My understanding from reading the thread is that the concern is with complexity, increased attack surface due to mechanisms that can be used in unanticipated ways or misconfigured, and management issues. Thus though policy can state a simple approach, I'm not sure the above concerns are addressed by that expression. I think we need to work through the use cases, both for those that do need a policy language and those that do not, then consider if APIs have various methods as Robin suggested, or otherwise how it will all fit together. regards, Frederick (not as chair) Frederick Hirsch Nokia On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote: Hi Jonas, Maciej, It seems that the policy that you would accept would be: policy-set combine=deny-overrides policy description=Default Policy for websites. Simply denying all API that are covered by some device capability:) target subject subject-match attr=class match=website func=equal/ /subject /target rule effect=deny condition resource-match attr=device-cap func=regexp/.+//resource-match /condition /rule /policy /policy-set Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - Maciej Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail
Re: Security evaluation of an example DAP policy
Marcin do you have any more comment on any of the following from the draft policy requirements document? http://dev.w3.org/2009/dap/policy-reqs/#use-cases Example Widget use cases, to give examples of the types of policy that might be expressed: • A Widget whose signature chains to operator root can read and write from the PIM databases. • A Widget downloaded from weather.example.com can access geolocation coordinates if the user says it’s OK. • The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. • All Widgets with a reliably identified author can save data persistently if the user says it’s OK. • No Widget can get my location, no matter who trusts it. Example web site use cases, to give examples of the types of policy that might be expressed: • A reliably identified website can access geolocation coordinates if the user confirms it’s OK. • Any Website in a subdomain of mynetwork.example.com can read phone status properties. • Reliably identified Websites can send and receive SMS except to premium rate numbers. • evil.example.com cannot access any device APIs. • The weather.example.com foo widget can access geolocation coordinates but only if it’s embedded on the foo home page. Do you have any more to add, or better use cases? I was going to ask about premium rate numbers so thanks for bringing that up. Can anyone please volunteer to provide more detail on the use cases or additional use cases? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 10:12 AM, ext Marcin Hanclik wrote: Hi, Reliably identified Websites can send and receive SMS except to premium rate numbers. There seems to be no worldwide pattern to recognize the premium numbers based on the number itself, this could be some network operators service or something similar IP-geolocation databases. The policy would be very long if we would put all the worldwide available premium numbers into it. Therefore this use case is not fully doable out of the box. However, BONDI allows to (reliably?) identify websites and allows to control sending and receiving SMS. The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. I am not sure what weather.example.com Widget. I assume it is the widget that was downloaded from weather.example.com. The BONDI policy format would encode this e.g. like this: policy-set combine=deny-overrides policy description= target subject subject-match attr=class match=website func=equal/ subject-match attr=uri.host match=weather.example.com func=equal/ /subject subject subject-match attr=class match=widget func=equal/ subject-match attr=install-uri.host match=weather.example.com func=equal/ /subject /target rule effect=deny condition combine=or environment-match attr=roaming func=equalinternational/ resource-match /condition /rule rule effect=permit //this seems not needed condition combine=or environment-match attr=roaming func=equalnational/ resource-match /condition /rule /policy /policy-set Thanks, Marcin P.S. I think I will not write more policies until there is some use case that is not doable (at least in my opinion. I may be wrong.) Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: Friday, November 20, 2009 3:29 PM To: ext Jeremy Orlow Cc: Frederick Hirsch; Marcin Hanclik; Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin Berjon; public-device-a...@w3.org; public- webapps WG Subject: Re: Security evaluation of an example DAP policy Jeremy Thanks. I want to make sure I understand the concerns. I guess the question is whether one can bake all the security in that is needed for various (possibly conflicting) use cases, including those that do not presume user interaction. An argument for policy is to decouple the mechanism from the decision criteria to get that flexibility, while making sure the mechanism is secure. On the other side I hear the concern that the mechanism cannot be as secure. I note that the policy requirements document includes some use cases Paddy contributed in an earlier email: http://dev.w3.org/2009/dap/policy-reqs/#use-cases So for example, how does one bake in these: The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. Reliably identified Websites can send and receive SMS except to premium rate numbers. Do we need to go into more detail on these two (as examples)? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote: These are reasons, but I think the greatest cause of our concern
RE: Security evaluation of an example DAP policy
Hi Frederick, My comment inline below. I think, it would be good if someone else involved in BONDI verified my below statements. Do you have any more to add, or better use cases? I was going to ask about premium rate numbers so thanks for bringing that up. As below, maybe we should ask GSMA or anyone else responsible for premium numbers (are they assigned on national or international level? Or both?) ? Copied from below for easy summary: * The weather.example.com foo widget can access geolocation coordinates but only if it's embedded on the foo home page. [MH] I do not know what weather.example.com foo widget embedded on the foo home page means. I assume it is a combination of download URI with author/distributor signature. Therefore I would generously assume that it is doable. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: Friday, November 20, 2009 4:30 PM To: Marcin Hanclik Cc: Frederick Hirsch; ext Jeremy Orlow; Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy Marcin do you have any more comment on any of the following from the draft policy requirements document? http://dev.w3.org/2009/dap/policy-reqs/#use-cases Example Widget use cases, to give examples of the types of policy that might be expressed: * A Widget whose signature chains to operator root can read and write from the PIM databases. [MH] Expressible with BONDI policy. * A Widget downloaded from weather.example.com can access geolocation coordinates if the user says it's OK. [MH] Expressible with BONDI policy. * The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. [MH] Expressible with BONDI policy. * All Widgets with a reliably identified author can save data persistently if the user says it's OK. [MH] Expressible with BONDI policy. * No Widget can get my location, no matter who trusts it. [MH] Expressible with BONDI policy. Example web site use cases, to give examples of the types of policy that might be expressed: * A reliably identified website can access geolocation coordinates if the user confirms it's OK. [MH] Expressible with BONDI policy. * Any Website in a subdomain of mynetwork.example.com can read phone status properties. [MH] Expressible with BONDI policy. * Reliably identified Websites can send and receive SMS except to premium rate numbers. [MH] No definition of the premium rate numbers as in my previous email (intentional or not). Therefore not doable out of the box. (Maybe we should ask GSMA?) * evil.example.com cannot access any device APIs. [MH] Expressible with BONDI policy. * The weather.example.com foo widget can access geolocation coordinates but only if it's embedded on the foo home page. [MH] I do not know what weather.example.com foo widget embedded on the foo home page means. I assume it is a combination of download URI with author/distributor signature. Therefore I would generously assume that it is doable. Do you have any more to add, or better use cases? I was going to ask about premium rate numbers so thanks for bringing that up. Can anyone please volunteer to provide more detail on the use cases or additional use cases? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 10:12 AM, ext Marcin Hanclik wrote: Hi, Reliably identified Websites can send and receive SMS except to premium rate numbers. There seems to be no worldwide pattern to recognize the premium numbers based on the number itself, this could be some network operators service or something similar IP-geolocation databases. The policy would be very long if we would put all the worldwide available premium numbers into it. Therefore this use case is not fully doable out of the box. However, BONDI allows to (reliably?) identify websites and allows to control sending and receiving SMS. The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. I am not sure what weather.example.com Widget. I assume it is the widget that was downloaded from weather.example.com. The BONDI policy format would encode this e.g. like this: policy-set combine=deny-overrides policy description= target subject subject-match attr=class match=website func=equal/ subject-match attr=uri.host match=weather.example.com func=equal/ /subject subject subject-match attr=class match=widget func=equal/ subject-match attr=install-uri.host match=weather.example.com func=equal/ /subject /target rule effect=deny condition combine
Re: Security evaluation of an example DAP policy
On Nov 20, 2009, at 01:26 , Maciej Stachowiak wrote: For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. That's good, because it's not part of the plan to do such a thing. The writer level for the File API, which I'm tasked to draft up, certainly doesn't plan any such thing. There is interest in a Directory level, but it's lower. And I would expect it to only be available to widgets, or /perhaps/ to some sort of virtual local file system accessed through a localFS object à la localStorage (with quotas, security considerations that UAs shouldn't implement that by actually storing files on the FS as that could open up a bunch of issues, etc.). -- Robin Berjon - http://berjon.com/
Re: Security evaluation of an example DAP policy
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon ro...@berjon.com wrote: DAP will handle security at the API definition level. Full stop. Can you elaborate on what this means concretely? For example, how is security handled at the API definition level for the file writing API? Adam
Re: Security evaluation of an example DAP policy
On Nov 20, 2009, at 17:40 , Adam Barth wrote: On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon ro...@berjon.com wrote: DAP will handle security at the API definition level. Full stop. Can you elaborate on what this means concretely? For example, how is security handled at the API definition level for the file writing API? Well, if you're asking me to define how we're going to do it for all the APIs before they've been written, it's gonna be a smidge hard :) I've been noodling a little bit over the file writing case, and have some ideas that at this stage involve hand-waving, have not been validated by the WG or in fact anyone else, and are subject to change (I only took on the action to work on this yesterday, and haven't really sat down to do it right yet). One idea, which Max had, was to tack this onto input type=file. The file browsing dialog we have today would work the same, but would have an extra checkbox (unchecked by default) saying Enable writing back to this file. The file object would become available in the same way as for reading, but would also support writing. It has limited but real use cases, such as loading a document (HTML, image, whatever) which can be edited in the page and saved back. The problem is that it doesn't allow for creating a new document (the initial save) — I haven't cracked that one yet (creating new files, even if they can't overwrite existing ones, has clear issues). It could be that the initial save happens through a download dialog — something which users are familiar with. Another option I had in mind was an extension to Element, e.g. Element.attachData(someFileObject). Said element would then, when dragged out of the browser, drop the content of the file there. It's been a while since I've looked at ongoing work on the cut-paste/drag-drop stuff and I've been meaning to take a good look at it precisely for this. I suspect that if the security issues are solved for those, then we might be able to piggy back on them to create files safely. But that's just a braindump. I'm sorry if this all feels handwavy but if you're looking for assurance that things that haven't been defined yet are good, I can't give it. All I give is the assurance that the *principles* are there, and will be enforced. -- Robin Berjon - http://berjon.com/
RE: Security evaluation of an example DAP policy
Hi, The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. How do we cover the additional 113 million+ domain names (and x number of subdomains) on the web via a policy such as this? Is that a blanket 'deny all' and a fall back to user prompting for those 113 million web sites not explictly included in a policy document? Most importantly from the previous questions, does domain-based policy then work in the web context? If a policy covers 10,000 domains (or, let's say, 1 million domains) is the ability to reach 1% of web content enough incentive to provide a web policy? Reliably identified Websites can send and receive SMS except to premium rate numbers. If policy is interchangeable, and we have e.g. 100 policy providers, how does the developer have confidence that each policy provider has selected the same set of premium phone numbers to block? Can such a policy be intentionally extended to prohibit non-threatening use cases at the expense of the user? If this is such an integral security issue, it should be possible to bake it in to the API itself? If it is not possible to bake it in, and the security decision is subjective based on whoever is providing a policy, then is this something web developers will be able to reliably and consistently code against? What is the legal responsibility (for data loss / misuse / corruption / etc) that policy providers take on by 'guaranteeing the web'? Is a policy provider liable for actions that it decides on behalf of a user? Over e.g. 1 million web domains? I appreciate the input of solid use cases such as this for discussion. I look forward to a use case that shows a clear reason for policy in a web context considering the massively distributed and centrally unmanageable nature of the web world - one of the tenants of its design that arguably continues to make it so successful. Kind Regards, Richard -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: 20 November 2009 15:13 To: Frederick Hirsch; ext Jeremy Orlow Cc: Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: RE: Security evaluation of an example DAP policy Hi, Reliably identified Websites can send and receive SMS except to premium rate numbers. There seems to be no worldwide pattern to recognize the premium numbers based on the number itself, this could be some network operators service or something similar IP-geolocation databases. The policy would be very long if we would put all the worldwide available premium numbers into it. Therefore this use case is not fully doable out of the box. However, BONDI allows to (reliably?) identify websites and allows to control sending and receiving SMS. The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. I am not sure what weather.example.com Widget. I assume it is the widget that was downloaded from weather.example.com. The BONDI policy format would encode this e.g. like this: policy-set combine=deny-overrides policy description= target subject subject-match attr=class match=website func=equal/ subject-match attr=uri.host match=weather.example.com func=equal/ /subject subject subject-match attr=class match=widget func=equal/ subject-match attr=install-uri.host match=weather.example.com func=equal/ /subject /target rule effect=deny condition combine=or environment-match attr=roaming func=equalinternational/resource-match /condition /rule rule effect=permit //this seems not needed condition combine=or environment-match attr=roaming func=equalnational/resource-match /condition /rule /policy /policy-set Thanks, Marcin P.S. I think I will not write more policies until there is some use case that is not doable (at least in my opinion. I may be wrong.) Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: Friday, November 20, 2009 3:29 PM To: ext Jeremy Orlow Cc: Frederick Hirsch; Marcin Hanclik; Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy Jeremy Thanks. I want to make sure I understand the concerns. I guess the question is whether one can bake all the security in that is needed for various (possibly conflicting) use cases, including those that do not presume user interaction. An argument for policy is to decouple the mechanism from the decision criteria to get that flexibility, while
RE: Security evaluation of an example DAP policy
Hi Adam, Thanks for your review! This is what the BONDI specs need :) I am sorry that you are skeptical and believe that with joint forces BONDI and DAP will end up with a good solution. If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. To handle this use case a more general regular expression could be defined. E.g. the following would have to be inserted into the prompt-oneshot section resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / and the following into deny section resource-match attr=param:name func=regexp/(C|c):\\(.+)/resource-match / Anyway, the BONDI FS is guarded as below. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? Please note that access to FS is guarded by FileSystemManager.resolve that is described as: Validates and resolves the given location to a File handle and returns a handle. A valid location is prefixed with a valid root or default location and must address an existing and accessible file. The path is resolved and visible to the JS code, but is it not necessarily readable or writable as is. For this there are getDefaultLocations and getRootLocations methods. In other APIs there are already cases around e.g. inContacts that refer to the device-specific information on the policy level. It's emails like this that make me skeptical of the security work being done in the device APIs working group. We try to stay positive and be constructive :) Thanks, Marcin From: Adam Barth [...@adambarth.com] Sent: Friday, November 20, 2009 12:22 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Security evaluation of an example DAP policy If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? It's emails like this that make me skeptical of the security work being done in the device APIs working group. Adam On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Maciej, Thanks for your review! The page http://www.w3.org/2009/dap/ does not yet include the BONDI 1.1 Candidate Release at [1]. The device capabilities [2] could be regarded as a compact form of security considerations within BONDI APIs. It should be noted that the device capabilities - although related to BONDI APIs - could be regarded as generic enough to incorporate any APIs. Based on the BONDI policy format specification, I would propose to start with the following default policy for the Web: policy-set combine=deny-overrides policy description=Default Policy for BONDI API device capabilities within Win2K environment target subject subject-match attr=class match=website func=equal/ subject-match attr=uri.scheme match=http func=equal/ /subject subject subject-match attr=class match=website func=equal/ subject-match attr=uri.scheme match=https func=equal/ /subject /target rule effect=deny condition combine=or condition combine=and condition combine=or resource-match attr=device-cap match=io.file.read/ resource-match attr=device-cap match=io.file.write/ /condition condition combine=or resource-match attr=param:nameC:\WINNTresource-match / resource-match attr=param:nameC:\Documents and Settingsresource-match / /condition /condition condition combine=or resource-match attr=device-cap match=devicestatus.set/ resource-match attr=device-cap match=commlog.clear/ /condition /condition /rule rule effect=prompt-session condition combine=or resource-match attr=device-cap match=location.position/ resource-match attr=device-cap match=devicestatus.get/ resource-match attr=device-cap match=devicestatus.list/ condition combine=and condition combine=or resource-match attr=param:inContactsundefinedresource-match / /condition condition combine=or resource-match attr='device-cap' match='messaging.email.send' resource-match attr='device-cap' match='messaging.mms.send' resource-match attr='device-cap' match='messaging.sms.send' resource-match attr='device-cap' match='messaging.binary.send' /condition /condition /condition /rule rule effect=prompt-oneshot condition combine=or
RE: Security evaluation of an example DAP policy
Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\.+/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. Thanks, Marcin From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On Behalf Of Marcin Hanclik [marcin.hanc...@access-company.com] Sent: Friday, November 20, 2009 1:00 AM To: Adam Barth Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: RE: Security evaluation of an example DAP policy Hi Adam, Thanks for your review! This is what the BONDI specs need :) I am sorry that you are skeptical and believe that with joint forces BONDI and DAP will end up with a good solution. If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. To handle this use case a more general regular expression could be defined. E.g. the following would have to be inserted into the prompt-oneshot section resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / and the following into deny section resource-match attr=param:name func=regexp/(C|c):\\(.+)/resource-match / Anyway, the BONDI FS is guarded as below. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? Please note that access to FS is guarded by FileSystemManager.resolve that is described as: Validates and resolves the given location to a File handle and returns a handle. A valid location is prefixed with a valid root or default location and must address an existing and accessible file. The path is resolved and visible to the JS code, but is it not necessarily readable or writable as is. For this there are getDefaultLocations and getRootLocations methods. In other APIs there are already cases around e.g. inContacts that refer to the device-specific information on the policy level. It's emails like this that make me skeptical of the security work being done in the device APIs working group. We try to stay positive and be constructive :) Thanks, Marcin From: Adam Barth [...@adambarth.com] Sent: Friday, November 20, 2009 12:22 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Security evaluation of an example DAP policy If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? It's emails like this that make me skeptical of the security work being done in the device APIs working group. Adam On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Maciej, Thanks for your review! The page http://www.w3.org/2009/dap/ does not yet include the BONDI 1.1 Candidate Release at [1]. The device capabilities [2] could be regarded as a compact form of security considerations within BONDI APIs. It should be noted that the device capabilities - although related to BONDI APIs - could be regarded as generic enough to incorporate any APIs. Based on the BONDI policy format specification, I would propose to start with the following default policy for the Web: policy-set combine=deny-overrides policy description=Default Policy for BONDI API device capabilities within Win2K environment target subject subject-match attr=class match=website func=equal/ subject-match attr=uri.scheme match=http func=equal/ /subject subject subject-match attr=class match=website func=equal/ subject-match attr=uri.scheme match=https func=equal/ /subject /target rule effect=deny condition combine=or condition combine=and condition combine=or resource-match attr=device-cap match=io.file.read/ resource-match attr=device-cap match=io.file.write/ /condition condition combine=or resource-match attr=param:nameC:\WINNTresource-match / resource-match attr=param:nameC:\Documents and Settingsresource-match / /condition /condition condition combine=or resource-match attr=device-cap match=devicestatus.set/ resource-match attr=device-cap match=commlog.clear/ /condition /condition /rule rule effect=prompt-session condition combine=or resource-match attr=device-cap match=location.position/ resource-match attr
Re: Security evaluation of an example DAP policy
On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\.+/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). / Jonas
Re: Security evaluation of an example DAP policy
On Nov 19, 2009, at 4:00 PM, Marcin Hanclik wrote: Hi Adam, Thanks for your review! This is what the BONDI specs need :) I am sorry that you are skeptical and believe that with joint forces BONDI and DAP will end up with a good solution. If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. To handle this use case a more general regular expression could be defined. E.g. the following would have to be inserted into the prompt-oneshot section resource-match attr=param:name func=regexp/(C|c):\\ (.+)\\(.+)/resource-match / and the following into deny section resource-match attr=param:name func=regexp/(C|c):\\ (.+)/resource-match / Anyway, the BONDI FS is guarded as below. Allowing write access to *any* file with just a one-shot confirmation prompt is unacceptable for the browser context. Or even read access. That's why the File API starts with input type=file which has the user take an affirmative step to choose a file, rather than confirming the Web page's choice of file. This may seem like a subtle issue but it makes a huge difference to the security implications. Access after a blanket prompt to access to read any file, to send email as the user, to read or write the contacts list, and to record via the camera all sound like extremely risky designs. Launching an app after a oneshot prompt is also extremely dangerous. Combined with other functionality, this can put a Web site one user confirmation away from running arbitrary native code. This is the kind of issue that needs to be considered up-front in the design, rather than bolted on by a policy. Many of these issues have to be addressed in the API design, not just by tweaking a policy file, to be truly Web-safe. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? Please note that access to FS is guarded by FileSystemManager.resolve that is described as: Validates and resolves the given location to a File handle and returns a handle. A valid location is prefixed with a valid root or default location and must address an existing and accessible file. The path is resolved and visible to the JS code, but is it not necessarily readable or writable as is. For this there are getDefaultLocations and getRootLocations methods. In other APIs there are already cases around e.g. inContacts that refer to the device-specific information on the policy level. It's emails like this that make me skeptical of the security work being done in the device APIs working group. We try to stay positive and be constructive :) When a security design seems fundamentally mistaken, I think it's important to be really clear about the problems, even if that comes off as blunt or harsh to some people. Regards, Maciej
Re: Security evaluation of an example DAP policy
On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - Maciej
RE: Security evaluation of an example DAP policy
Hi Jonas, Maciej, It seems that the policy that you would accept would be: policy-set combine=deny-overrides policy description=Default Policy for websites. Simply denying all API that are covered by some device capability:) target subject subject-match attr=class match=website func=equal/ /subject /target rule effect=deny condition resource-match attr=device-cap func=regexp/.+//resource-match /condition /rule /policy /policy-set Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - Maciej Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
