Re: [WARP] Last Call comments (1)
On Sep 15, 2009, at 21:12 , Marcin Hanclik wrote: I do not think they are so different. Frederick is correct in his interpretation of the intent of the specification: they are meant to be different. feature points to anything, we can still build the interpretation. But it is meant and intended for APIs. We could extend it for a zillion things, e.g.: feature uri='http://example.com/widgets/icon' param name='src' value='/icons/myapp.svg/ /feature But I don't believe that that would be helpful. I think it can be disputable what access is for. WARP says: A network resource is a retrievable resource of any type that is identified by a URI that has a DNS or IP as its authority. Then, how to fit e.g. sms: or tel: schemes into this context? This limitation is *exactly* what access was designed for. If you go back to the (long) discussions that the WG had before WARP was birthed, you'll see this. Basically, at this point in time there are two options: define a complete security policy model that would cover everything that can be done, or address a trivial 80/20. There was clear agreement that the first option is DAP's responsibility. We thought about not doing anything at all, but that option was rejected because we're already seeing different approaches (Opera widgets, BONDI, JIL — they all have different things there). So the resolution was to go with the simple 80/20 approach that handled the common accessing a web resource or REST API case in a boolean fashion, did describe what happened to content that is expected to behave in a Web fashion, but didn't go anywhere that would risk trampling on DAP's territory. Schemes such as sms and tel are definitely out of scope for this simple approach. Even if they weren't they would *still* be out of scope for access because they aren't network resources. You can't make an XHR request to sms:, it is meaningless to have img src='tel:...'/. These are therefore rejected immediately — just because it has a scheme doesn't mean it's a network resource, those are two completely separate things. Now there could be a policy for accessing SMS or phone from within an API, for instance one that would limit to only one phone number, or perhaps to a given price limit (per minute, per SMS), or a frequency, or a maximal total cost per month. But none of that is related to access. @subdomains makes also little sense for those schemes. That's because those schemes make little sense for access. You're finding faults that are there because you're expecting it to address use cases that aren't there. Apart from DNS/IP issues, I assume that some Web resources are not meant to be retrievable, e.g. POSTing a form uses URI to send information to, and not to retrieve a resource. Actually POST is perfectly allowed to retrieve an entity (and often does) so long as the response status isn't 204. If we would like the spec to be future-/scheme-proof, we could prepare the model based on actual schemes, as e.g. suggested in my below email. I don't think that that is a good idea. This specification addresses the requirements of today. When and if we need to add new schemes, we can do so. The intent is that WARP is a simply, stop-gap solution to address today's interoperability issues at the level of requirement which they have. When we need more power, the expectation is that DAP will have provided it, that we'll be able to express access in DAP terms, and that DAP will provide the extensibility mechanism. -- Robin Berjon - http://berjon.com/
Re: [WARP] Last Call comments (1)
On Sep 7, 2009, at 15:11 , Marcin Hanclik wrote: is pretty simple, logical, and gets the job done for most use cases. The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains). There is a major distinction here. When you use mailto: or tel:, it triggers an external application (email client, phone dialer) and you can decide from within that application whether to enact those. If you have access to a messaging or calling API, then you can do those stealthily — but that's not WARP's problem, it's DAP's problem. What WARP is concerned with is whatever access can be made without user interaction (an img/@src, or an XHR request) that is possible today in a WRT. Anything else is out of scope, and is DAP's job. -- Robin Berjon - http://berjon.com/
Re: [WARP] Last Call comments (1)
On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote: As stated in my original email, one of the targets is that access is not an obstacle for DAP. The design was based on: - not restricting DAP's ability to define a security policy - enabling boolean access to URIs - having pattern matching that covers most cases - making sure that web content that works outside of a widget can work inside a widget It is currently undefined how the related access control will be done and we would probably want to avoid the situation that access is deprecated once DAP is ready with their model. Quite the contrary. If all goes well DAP's security policy will be available within a couple years, and after that we'll need another year before it ships as presumably it'll have some degree of complexity. That's all fine but the problem that we have today is that people are shipping implementations with support for something a lot like access but that are not compatible. Just off the top of my head I know that Opera has their own stuff (which was the original proposal), BONDI has network-access which is different, JIL has something of their own with different default rules, and Microsoft has a widget engine using access from the December 2008 PC draft. What WARP does is that it provides the strictly minimal solution that will make interoperability possible before DAP finishes its work, while adhering to its fundamental design principles. If it gets obsoleted, superseded, set on fire in public displays of wrath, or trampled by a horde of arctic hippopotami on MDMA then great. The primary goal is to gain 3 years of interoperability which we need to have. A complementary goal is that since we want content created conforming to WARP today to be valid forever is that the policies that WARP enables should be expressible using whatever DAP comes up with, so that access can be defined as simply a syntactical shortcut to DAP. In other words it is future-proof *because* it is simple. It's extensible (if we need to, which I don't think we should) because it's XML (and because its processing model is intended for that). -- Robin Berjon - http://berjon.com/
Re: [WARP] Last Call comments (1)
On Sep 10, 2009, at 15:00 , Frederick Hirsch wrote: Is the fundamental difference of feature and access the following: feature - API set expected to be possibly used access - network resource to be accessed. Exactly. I think that part of the confusion stems from the different uses of URIs. For features they're just identifiers, for access they're locators (or partial patterns on locators). -- Robin Berjon - http://berjon.com/
RE: [WARP] Last Call comments (1)
Hi Robin, I understand the 80/20 principle. It is about quality. I am however not sure that publication of the spec as is will result in the companies listed below to adjust to the correct meaning. BONDI has network-access which is different It was done, because there was no access when BONDI discussed this. And actually in BONDI no-one seems to be against the proposals of making the design more robust based on feature. My proposal is not about syntax, but about semantics that is missing in WARP. 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: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, September 17, 2009 4:41 PM To: Marcin Hanclik Cc: Marcos Caceres; public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote: As stated in my original email, one of the targets is that access is not an obstacle for DAP. The design was based on: - not restricting DAP's ability to define a security policy - enabling boolean access to URIs - having pattern matching that covers most cases - making sure that web content that works outside of a widget can work inside a widget It is currently undefined how the related access control will be done and we would probably want to avoid the situation that access is deprecated once DAP is ready with their model. Quite the contrary. If all goes well DAP's security policy will be available within a couple years, and after that we'll need another year before it ships as presumably it'll have some degree of complexity. That's all fine but the problem that we have today is that people are shipping implementations with support for something a lot like access but that are not compatible. Just off the top of my head I know that Opera has their own stuff (which was the original proposal), BONDI has network-access which is different, JIL has something of their own with different default rules, and Microsoft has a widget engine using access from the December 2008 PC draft. What WARP does is that it provides the strictly minimal solution that will make interoperability possible before DAP finishes its work, while adhering to its fundamental design principles. If it gets obsoleted, superseded, set on fire in public displays of wrath, or trampled by a horde of arctic hippopotami on MDMA then great. The primary goal is to gain 3 years of interoperability which we need to have. A complementary goal is that since we want content created conforming to WARP today to be valid forever is that the policies that WARP enables should be expressible using whatever DAP comes up with, so that access can be defined as simply a syntactical shortcut to DAP. In other words it is future-proof *because* it is simple. It's extensible (if we need to, which I don't think we should) because it's XML (and because its processing model is intended for that). -- Robin Berjon - http://berjon.com/ 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: [WARP] Last Call comments (1)
Hi Robin, Herewith I reply to both your recent answers [1] and [2]. It is good for me to see that the intentions and scope of the WARP spec get clarified upon discussion. Schemes such as sms and tel are definitely out of scope for this simple approach. If so, then please add clear rules to the spec which schemes are in scope. These are the hints: a) A network resource is a retrievable resource of any type that is identified by a URI that has a DNS or IP as its authority. So here sms: and tel: seem out of scope. What about E164 and DNS [3]? Another edge case: sms:+41796431851;pid=smtp:i...@dret.net from [4] b) This special value provides a means for an author to request from the user agent unrestricted access to resources through any and all schemes and protocols supported by the user agent. Here the set of schemes is infinite. So I suggest adding the relevant text, e.g. This special value provides a means for an author to request from the user agent unrestricted access to network resources through any and all schemes and protocols that have DNS or IP as its authority and that are supported by the user agent. Schemes such as sms and tel are definitely out of scope for this simple approach. Even if they weren't they would *still* be out of scope for access because they aren't network resources. You can't make an XHR request to sms:, it is meaningless to have img src='tel:...'/. These are therefore rejected immediately - just because it has a scheme doesn't mean it's a network resource, those are two completely separate things. Can you do XHR to mailto:? Or img src='mailto:...'? But mailto: is explicitly mentioned in WARP. There is a major distinction here. When you use mailto: or tel:, it triggers an external application (email client, phone dialer) Not necessarily. My mail client may be another widget/webapp. Similarly to tel: (depends on DAP). and you can decide from within that application whether to enact those. If you have access to a messaging or calling API, then you can do those stealthily - but that's not WARP's problem, it's DAP's problem. From the security point of view it does not matter whether a message or a call was accomplished by a programmatic call to device API or by an external application that was triggered by the URI embedded in a widget. If restricted, it should simply not happen. I understand that this is a DAP issue, therefore I suggest to leave it all to DAP. In general, if the text of WARP specifies that WARP is only about http, https, and XHR I could live with it. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1113.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1114.html [3] http://www.ietf.org/rfc/rfc2916.txt [4] http://tools.ietf.org/html/draft-wilde-sms-uri-00#section-2.4 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: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, September 17, 2009 4:27 PM To: Marcin Hanclik Cc: Marcos Caceres; public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) On Sep 7, 2009, at 15:11 , Marcin Hanclik wrote: is pretty simple, logical, and gets the job done for most use cases. The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains). There is a major distinction here. When you use mailto: or tel:, it triggers an external application (email client, phone dialer) and you can decide from within that application whether to enact those. If you have access to a messaging or calling API, then you can do those stealthily - but that's not WARP's problem, it's DAP's problem. What WARP is concerned with is whatever access can be made without user interaction (an img/@src, or an XHR request) that is possible today in a WRT. Anything else is out of scope, and is DAP's job. -- Robin Berjon - http://berjon.com/ 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: [WARP] Last Call comments (1)
Hi Robin, Please bear in mind that my proposal moves the access's @uri to param name=uri value=XXX/ and not to feature's @name. The distinction is clear. Thus there seems to be no confusion. 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: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, September 17, 2009 4:43 PM To: Frederick Hirsch Cc: Marcin Hanclik; public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) On Sep 10, 2009, at 15:00 , Frederick Hirsch wrote: Is the fundamental difference of feature and access the following: feature - API set expected to be possibly used access - network resource to be accessed. Exactly. I think that part of the confusion stems from the different uses of URIs. For features they're just identifiers, for access they're locators (or partial patterns on locators). -- Robin Berjon - http://berjon.com/ 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: [WARP] Last Call comments (1)
Hi Robin, I am further trying to align the syntax and semantics of WARP. The design was based on: ... - enabling boolean access to URIs ... As in the previous emails, I assume that WARP should more underline the retrievable character of the network RESOURCE. Then mailto: should not be mentioned at all (or mentioned as not in scope for WARP, bad example due to non-retrievability etc). Then the following sentence: However, a user agent may grant access to certain URI schemes (e.g., mailto:) without the need of an access request if its security policy considers those schemes benign. could be rephrased e.g. to: It is out of the scope of this specification how schemes other than http, https and interfaces other than XmlHttpRequest access the network. Similarly I assume that e.g. a element is out of the scope, this could entail that openURL from widget interface would be excluded as well (aka my previous email). 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: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, September 17, 2009 4:41 PM To: Marcin Hanclik Cc: Marcos Caceres; public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote: As stated in my original email, one of the targets is that access is not an obstacle for DAP. The design was based on: - not restricting DAP's ability to define a security policy - enabling boolean access to URIs - having pattern matching that covers most cases - making sure that web content that works outside of a widget can work inside a widget It is currently undefined how the related access control will be done and we would probably want to avoid the situation that access is deprecated once DAP is ready with their model. Quite the contrary. If all goes well DAP's security policy will be available within a couple years, and after that we'll need another year before it ships as presumably it'll have some degree of complexity. That's all fine but the problem that we have today is that people are shipping implementations with support for something a lot like access but that are not compatible. Just off the top of my head I know that Opera has their own stuff (which was the original proposal), BONDI has network-access which is different, JIL has something of their own with different default rules, and Microsoft has a widget engine using access from the December 2008 PC draft. What WARP does is that it provides the strictly minimal solution that will make interoperability possible before DAP finishes its work, while adhering to its fundamental design principles. If it gets obsoleted, superseded, set on fire in public displays of wrath, or trampled by a horde of arctic hippopotami on MDMA then great. The primary goal is to gain 3 years of interoperability which we need to have. A complementary goal is that since we want content created conforming to WARP today to be valid forever is that the policies that WARP enables should be expressible using whatever DAP comes up with, so that access can be defined as simply a syntactical shortcut to DAP. In other words it is future-proof *because* it is simple. It's extensible (if we need to, which I don't think we should) because it's XML (and because its processing model is intended for that). -- Robin Berjon - http://berjon.com/ 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: [WARP] Last Call comments (1)
Hi Frederick, I do not think they are so different. feature points to anything, we can still build the interpretation. We can build new worlds on top of feature and param elements, independently of any spec IMHO. feature does not necessarily have to point to the same category of components, we can define the categories in any way, e.g. by various IRI namespaces. I think it can be disputable what access is for. WARP says: A network resource is a retrievable resource of any type that is identified by a URI that has a DNS or IP as its authority. Then, how to fit e.g. sms: or tel: schemes into this context? @subdomains makes also little sense for those schemes. Apart from DNS/IP issues, I assume that some Web resources are not meant to be retrievable, e.g. POSTing a form uses URI to send information to, and not to retrieve a resource. If we would like the spec to be future-/scheme-proof, we could prepare the model based on actual schemes, as e.g. suggested in my below email. Experience from CORS could also help. if so, doesn't feature imply both the loading and permission to access a library, whereas access is about accessing a resource. E.g. generic network access (not to specific resource, but just to the information whether the WUA is online/connected) may be regarded as runtime component of the WUA or its environment. 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: Thursday, September 10, 2009 3:01 PM To: Marcin Hanclik Cc: Frederick Hirsch; public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) Is the fundamental difference of feature and access the following: feature - API set expected to be possibly used access - network resource to be accessed. if so, doesn't feature imply both the loading and permission to access a library, whereas access is about accessing a resource. if this is correct, aren't these fundamentally different? regards, Frederick Frederick Hirsch Nokia On Aug 27, 2009, at 2:06 PM, ext Marcin Hanclik wrote: Hi All, Here are a couple of the Last Call comments to WARP LCWD [1]. They were already partially presented in my emails [2] and [3]. The comments below are more of architectural nature than just editorial fixes. That is why the arguments together with the derived understanding are followed by the proposed changes to the specification. The proposed changes below are incomplete. MOTIVATION / ARGUMENTS The main motivation for the changes proposed below is the syntax and the underlying architecture related to the treatment of the network access - from the widget's or web application's point of view - as the resource to which access is to be controlled by some security policy. The specification that underlies the overall widgets ecosystem, Widgets 1.0: Packaging and Configuration (further referred to as PC) [4], defines a method to express the dependency of the widget on a resource/component, namely the feature element. PC in [5] - the definition of the feature element - states: A feature is a runtime component The feature element serves as a standardized means to request the binding of an (IRI) identifiable runtime component to a widget for use at runtime. ...a widget can attempt to access the feature identified by the feature element's name attribute. PC [6] states non-normatively: The Widgets 1.0: Access Requests specification defines a means to request access to URI-identifiable resources (e.g. resources on the Web) (see [Widgets-Access]). On the other hand, however, WARP states [7]: The purpose of this specification is precisely to define the security model for network interactions from within a widget that has access to sensitive information, and to provide means for a widget to declare the need to access specific network resources so that a policy may control it. And [8] A network resource is a retrievable resource of any type that is identified by a URI that has a DNS or IP as its authority. WARP states that it addresses [9] the requirements [10] and [11]. [10] R52 Default Security Policy: A conforming specification MUST specify a default security policy that limits the privileges afforded to a widget at runtime. The default security policy MUST be specified in such a way that it forces a widget package to explicitly request permission to use particular device capabilities (see also the Security Declarations requirement). [11] R54 Security Declarations: A conforming specification MUST specify or recommend a means for declaring that an instantiated widget will require access to resources or services that have the potential to introduce a security risk for an end user. A conforming specification SHOULD also make it possible to externalize and associate security
Re: [WARP] Last Call comments (1)
Is the fundamental difference of feature and access the following: feature - API set expected to be possibly used access - network resource to be accessed. if so, doesn't feature imply both the loading and permission to access a library, whereas access is about accessing a resource. if this is correct, aren't these fundamentally different? regards, Frederick Frederick Hirsch Nokia On Aug 27, 2009, at 2:06 PM, ext Marcin Hanclik wrote: Hi All, Here are a couple of the Last Call comments to WARP LCWD [1]. They were already partially presented in my emails [2] and [3]. The comments below are more of architectural nature than just editorial fixes. That is why the arguments together with the derived understanding are followed by the proposed changes to the specification. The proposed changes below are incomplete. MOTIVATION / ARGUMENTS The main motivation for the changes proposed below is the syntax and the underlying architecture related to the treatment of the network access - from the widget's or web application's point of view - as the resource to which access is to be controlled by some security policy. The specification that underlies the overall widgets ecosystem, Widgets 1.0: Packaging and Configuration (further referred to as PC) [4], defines a method to express the dependency of the widget on a resource/component, namely the feature element. PC in [5] - the definition of the feature element - states: A feature is a runtime component The feature element serves as a standardized means to request the binding of an (IRI) identifiable runtime component to a widget for use at runtime. ...a widget can attempt to access the feature identified by the feature element's name attribute. PC [6] states non-normatively: The Widgets 1.0: Access Requests specification defines a means to request access to URI-identifiable resources (e.g. resources on the Web) (see [Widgets-Access]). On the other hand, however, WARP states [7]: The purpose of this specification is precisely to define the security model for network interactions from within a widget that has access to sensitive information, and to provide means for a widget to declare the need to access specific network resources so that a policy may control it. And [8] A network resource is a retrievable resource of any type that is identified by a URI that has a DNS or IP as its authority. WARP states that it addresses [9] the requirements [10] and [11]. [10] R52 Default Security Policy: A conforming specification MUST specify a default security policy that limits the privileges afforded to a widget at runtime. The default security policy MUST be specified in such a way that it forces a widget package to explicitly request permission to use particular device capabilities (see also the Security Declarations requirement). [11] R54 Security Declarations: A conforming specification MUST specify or recommend a means for declaring that an instantiated widget will require access to resources or services that have the potential to introduce a security risk for an end user. A conforming specification SHOULD also make it possible to externalize and associate security declarations with a particular widget package (e.g., by allowing security declarations to be securely acquired from an external trusted authority over HTTP). This MUST include a means of declaring the APIs that a widget expects to access. When possible, a conforming specification MUST specify a means to verify the authenticity and integrity of security declarations included in the widget package (e.g. by using Digital Signatures). One of the motivations against the @required attribute on access element was prompting [12], and prompting is included the current LCWD [9]. Therefore it is unclear what the argumentation against @required attribute is (this is related to the semantics of the access and feature elements as outlined below). The above statements result in the following understanding: 1. WARP specification actually defines the syntax for expression of dependency of a widget only on network resources. So here, the name of the specification is misleading (taking into account only this point, we could require it be named Widgets 1.0: Network Access Policy). 2. The dependency of a widget on network resources is atomic and unconditional. 3. The resource is identifiable by URI. 4. The URI-identifiable resources are not necessarily truly remote network resources. 5. Since network access introduces various risks (e.g. when roaming) the requirement [11]: A conforming specification MUST specify or recommend a means for declaring that an instantiated widget will require access to resources or services that have to the potential to introduce a security risk for an end user. seems not to be fully satisfied, since the access to network resources is unconditional in
RE: [WARP] Last Call comments (1)
Hi Marcos, Re 99% fulfillment of the needs: As stated in my original email, one of the targets is that access is not an obstacle for DAP. It is currently undefined how the related access control will be done and we would probably want to avoid the situation that access is deprecated once DAP is ready with their model. So we may fulfill 99% of the needs now, but 1% in a few months with the access element. That is why I proposed a more robust and extensible (hopefully future-proof) design of the functionality based on feature element. What's more, the conditional character of feature brings flexibility to the design of widgets/webapps and may be important from their usability point of view. I don't understand the above sentence, can you give me an example of what you mean? Here I refer to the absence of the @required attribute on access element and its presence on feature element. By flexibility I mean the fact that access to some web resource could be conditional (i.e. not-required). Let's say my widget wants to retrieve resources from 2 websites / domains. One website provides the core functionality of the widget, i.e. the resources from it are mandatory/required, instantiation of the widget without access to those resources makes no sense etc. The second website provides additional functionality, a kind of nice-to-have for my widget. So access to the resources from this website is optional (@required=false). 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: Marcos Caceres [mailto:marc...@opera.com] Sent: Monday, September 07, 2009 3:37 PM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) Marcin Hanclik wrote: Hi Marcos, is pretty simple, logical, and gets the job done for most use cases. The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains). Access requests for those are not relevant, IMO. Those would be controlled by the policy of the UA. (e.g., policy may say all 'tel:' and 'mailto:' are allowed and handled by the appropriate scheme handler - the phone dialer or the mail app.) I don't see any use case for access uri=mailto:*...@gmail.com; or access uri=tel:+47*. That's overkill, IMO. access covers the common (+99%) use case of accessing stuff on the Web. Like I said, other scheme handlers can handle tel, mailto, etc. like is currently done by browsers. It is also not the case for the distinction between programmatic vs. declarative/URL (not sure how to name it :) ) access. Those aspects may be important from the DAP's security model perspective. Key word here is may: you are adding solutions before you have a problem. Just focus on solving the issue at hand. Most use cases currently entails a few assumptions implicitly, e.g. relation to installation-time or dynamic access to the resource etc. Let me make the assumptions explicit: Most use cases for Opera = the Opera gallery of Widgets and what our developer community need and want. They want access to, for instance, the flickr API, the Google APIs, Twitter, etc. and the ability to mash up stuff really quickly, painlessly, and easily. They (and I) want a super easy to use platform that kicks ass for developing and delivering client-side applications. My goal is to give that to them:) I'm sure your goals are the same. In the future, they might want access to features provided by dap. Hopefully, they won't have to request those through a feature element (i.e., the APIs will just be there for them to use without requesting them), but, in the unfortunate case that they do have to request them, I want to make sure it's as simple as possible. What's more, the conditional character of feature brings flexibility to the design of widgets/webapps and may be important from their usability point of view. I don't understand the above sentence, can you give me an example of what you mean? Kind regards, Marcos 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: [WARP] Last Call comments (1)
Hi Marcos, What you did in 192 characters, the access element does in 52. That is the point of the access element: to make these kind of annoying declarations easy to write. I do not think that the conciseness is the main driver of this aspect of the config.xml. What matters seems to be semantics, specifically in the light of the security model and selectiveness of the intentions. The size of the expression could be lowered a bit, e.g. the IRI could be changed from; http://www.w3.org/widgetfeatures/networkaccess/http to http://www.w3.org/wf10/na/http and so on. From another angle: We seem to agree to have implicit API versioning (in DAP) that result in multiplication of the size of the runtime code (note the performance impact), so having a few more characters in config.xml with clearly defined semantics seems not to be an issue, I think. 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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Friday, September 04, 2009 5:04 PM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [WARP] Last Call comments (1) Hi Marcin, I tried to respond to this email, but in all honesty, I can't follow your line of argumentation. Maybe you can list your main points as a list (sorry, I'm a bit simple)... From what I got, I agree that WARP is over reaching: It does not address the requirements it lists from the Widgets 1.0: Requirements document. Otherwise, I'll just leave it to Robin to respond. I've made some notes on the proposed changes. On Thu, Aug 27, 2009 at 8:06 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: PROPOSED CHANGES Given the semantic similarities (or equivalence) between: access uri=http://example.org; subdomains=true/ and e.g.: feature name=http://www.w3.org/widgetfeatures/networkaccess/http; required=false param name=uri value=http://example.org/ param name=subdomains value=true/ /feature What you did in 192 characters, the access element does in 52. That is the point of the access element: to make these kind of annoying declarations easy to write. I propose the following: 1. Change the name of the specification to Widgets 1.0: Network Access Feature and focus on per-URI-scheme definition of the syntax dependencies and functionality. Examples: a) The following feature could replace the generic network access (proposed in the LCWD as * for @uri attribute): feature name=http://www.w3.org/widgetfeatures/networkaccess; required=true / b) The following features could define the http and https access feature name=http://www.w3.org/widgetfeatures/networkaccess/http; required=false param name=uri value=http://example.org/ param name=subdomains value=true/ param name=ports value=80, 8080/ /feature feature name=http://www.w3.org/widgetfeatures/networkaccess/https; required=true param name=uri value=https://example.org/ param name=subdomains value=false/ param name=interface value=XMLHttpRequest/ !-- port defaults to 443 -- /feature c) The following feature could define access to SMS feature: feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; required=true param name=uri value=sms:+16177166200/ /feature feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; required=true param name=countrycallingcodes value=1,48,49,34/ /feature 2. Rewrite parts of the specification - specifically section 3, while keeping its majority as is - to adhere to the syntax of the feature and param elements as outlined above. 3. Refrain from specifying the default policy; remove the word security from the specification (since this is to be handled in DAP). 4. Focus in the specification text only on declarative aspects of the intention of the author of the widget, leaving e.g. prompting aspects for DAP. I.e. assuming that the network access is conditional, what are the implications for the widget's code and author in case the network access is not present or its presence is dynamic? (e.g. provide a definition of the event mechanism). 5. In order to be able to define the IRI for network access feature, another document should probably be prepared that would also define the namespace for the further feature definitions (e.g. http://www.w3.org/widgetfeatures/). 6. Focus in the specification only on http and https. subdomains attribute / value of the parameter is valid mainly for this protocol family (also including e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is no RFC for some) have their own specificities, e.g. country calling/dialing codes, shortcodes. Thanks. Kind regards, Marcin [1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/ [2] http://lists.w3.org/Archives/Public
Re: [WARP] Last Call comments (1)
Marcin Hanclik wrote: Hi Marcos, What you did in 192 characters, the access element does in 52. That is the point of the access element: to make these kind of annoying declarations easy to write. I do not think that the conciseness is the main driver of this aspect of the config.xml. In a lot of cases, it is. It's the reason we don't have wrapper elements for icons, etc. What matters seems to be semantics, specifically in the light of the security model and selectiveness of the intentions. Yes, this is of course, far more important. But making the expression of intent as easy to express as possible is very important (hence the conciseness, and taking out as much work as possible for developers) The size of the expression could be lowered a bit, e.g. the IRI could be changed from; http://www.w3.org/widgetfeatures/networkaccess/http to http://www.w3.org/wf10/na/http and so on. No, we don't need another namespace. Even a short convoluted one. access in the widget namespace is already defined. I.e., access already means http://www.w3.org/wf10/na/http;, and it is much easier to remember and use. From another angle: We seem to agree to have implicit API versioning (in DAP) that result in multiplication of the size of the runtime code (note the performance impact), so having a few more characters in config.xml with clearly defined semantics seems not to be an issue, I think. We are entering a bikeshed discussion here. What we should be asking is if the expression of intent is clear in the declaration: 1. I wanna access resource X on the Web? what is the most brain-dead simple way I can do that? For me, personally, saying: access uri=http://bla.com/some/resource; is pretty simple, logical, and gets the job done for most use cases. Kind regards, Marcos
RE: [WARP] Last Call comments (1)
Hi Marcos, is pretty simple, logical, and gets the job done for most use cases. The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains). It is also not the case for the distinction between programmatic vs. declarative/URL (not sure how to name it :) ) access. Those aspects may be important from the DAP's security model perspective. Most use cases currently entails a few assumptions implicitly, e.g. relation to installation-time or dynamic access to the resource etc. What's more, the conditional character of feature brings flexibility to the design of widgets/webapps and may be important from their usability point of view. 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 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: [WARP] Last Call comments (1)
Marcin Hanclik wrote: Hi Marcos, is pretty simple, logical, and gets the job done for most use cases. The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains). Access requests for those are not relevant, IMO. Those would be controlled by the policy of the UA. (e.g., policy may say all 'tel:' and 'mailto:' are allowed and handled by the appropriate scheme handler - the phone dialer or the mail app.) I don't see any use case for access uri=mailto:*...@gmail.com; or access uri=tel:+47*. That's overkill, IMO. access covers the common (+99%) use case of accessing stuff on the Web. Like I said, other scheme handlers can handle tel, mailto, etc. like is currently done by browsers. It is also not the case for the distinction between programmatic vs. declarative/URL (not sure how to name it :) ) access. Those aspects may be important from the DAP's security model perspective. Key word here is may: you are adding solutions before you have a problem. Just focus on solving the issue at hand. Most use cases currently entails a few assumptions implicitly, e.g. relation to installation-time or dynamic access to the resource etc. Let me make the assumptions explicit: Most use cases for Opera = the Opera gallery of Widgets and what our developer community need and want. They want access to, for instance, the flickr API, the Google APIs, Twitter, etc. and the ability to mash up stuff really quickly, painlessly, and easily. They (and I) want a super easy to use platform that kicks ass for developing and delivering client-side applications. My goal is to give that to them:) I'm sure your goals are the same. In the future, they might want access to features provided by dap. Hopefully, they won't have to request those through a feature element (i.e., the APIs will just be there for them to use without requesting them), but, in the unfortunate case that they do have to request them, I want to make sure it's as simple as possible. What's more, the conditional character of feature brings flexibility to the design of widgets/webapps and may be important from their usability point of view. I don't understand the above sentence, can you give me an example of what you mean? Kind regards, Marcos
Re: [WARP] Last Call comments (1)
Hi Marcin, I tried to respond to this email, but in all honesty, I can't follow your line of argumentation. Maybe you can list your main points as a list (sorry, I'm a bit simple)... From what I got, I agree that WARP is over reaching: It does not address the requirements it lists from the Widgets 1.0: Requirements document. Otherwise, I'll just leave it to Robin to respond. I've made some notes on the proposed changes. On Thu, Aug 27, 2009 at 8:06 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: PROPOSED CHANGES Given the semantic similarities (or equivalence) between: access uri=http://example.org; subdomains=true/ and e.g.: feature name=http://www.w3.org/widgetfeatures/networkaccess/http; required=false param name=uri value=http://example.org/ param name=subdomains value=true/ /feature What you did in 192 characters, the access element does in 52. That is the point of the access element: to make these kind of annoying declarations easy to write. I propose the following: 1. Change the name of the specification to Widgets 1.0: Network Access Feature and focus on per-URI-scheme definition of the syntax dependencies and functionality. Examples: a) The following feature could replace the generic network access (proposed in the LCWD as * for @uri attribute): feature name=http://www.w3.org/widgetfeatures/networkaccess; required=true / b) The following features could define the http and https access feature name=http://www.w3.org/widgetfeatures/networkaccess/http; required=false param name=uri value=http://example.org/ param name=subdomains value=true/ param name=ports value=80, 8080/ /feature feature name=http://www.w3.org/widgetfeatures/networkaccess/https; required=true param name=uri value=https://example.org/ param name=subdomains value=false/ param name=interface value=XMLHttpRequest/ !-- port defaults to 443 -- /feature c) The following feature could define access to SMS feature: feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; required=true param name=uri value=sms:+16177166200/ /feature feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; required=true param name=countrycallingcodes value=1,48,49,34/ /feature 2. Rewrite parts of the specification - specifically section 3, while keeping its majority as is - to adhere to the syntax of the feature and param elements as outlined above. 3. Refrain from specifying the default policy; remove the word security from the specification (since this is to be handled in DAP). 4. Focus in the specification text only on declarative aspects of the intention of the author of the widget, leaving e.g. prompting aspects for DAP. I.e. assuming that the network access is conditional, what are the implications for the widget's code and author in case the network access is not present or its presence is dynamic? (e.g. provide a definition of the event mechanism). 5. In order to be able to define the IRI for network access feature, another document should probably be prepared that would also define the namespace for the further feature definitions (e.g. http://www.w3.org/widgetfeatures/). 6. Focus in the specification only on http and https. subdomains attribute / value of the parameter is valid mainly for this protocol family (also including e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is no RFC for some) have their own specificities, e.g. country calling/dialing codes, shortcodes. Thanks. Kind regards, Marcin [1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/ [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0294.html [4] http://www.w3.org/TR/widgets [5] http://www.w3.org/TR/widgets/#the-feature-element [6] http://www.w3.org/TR/widgets/#the-widget-family-of-specifications [7] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#introduction [8] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#definitions [9] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#design-goals-and-requirements [10] http://www.w3.org/TR/widgets-reqs/#default-security-policy [11] http://www.w3.org/TR/widgets-reqs/#security-declarations [12] http://www.w3.org/2009/06/09-wam-minutes.html [13] http://www.w3.org/2009/05/DeviceAPICharter [14] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022264.html 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 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
