Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Hi Rainer, > On Mon, Mar 2, 2009 at 2:56 PM, Hillebrand, Rainer > wrote: > RH: I would recommend not to standardize a base security policy for all > markets on the world. It would take too long. However, we might want to > discuss for Widgets 2.0 whether we would try agreeing on a security framework > defining what needs to be protected, how a security policy is defined (i.e. > format, vocabulary) and how security policies could be provisioned or managed. > Ok, this seems like a reasonable way forward. Not specifying the default security policy is inline with what is currently specified in the P&C spec. I have added your suggestion for V2.0 to the wiki: http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R -- Marcos Caceres http://datadriven.com.au
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Dear Marcos, I added my comments inline. Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Montag, 2. März 2009 15:03 To: Hillebrand, Rainer Cc: public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec On Mon, Mar 2, 2009 at 2:56 PM, Hillebrand, Rainer wrote: > Dear Marcos, > > In order to detect a man-in-the-middle-attack, a widget resource is signed, > either by an author's certificate that I trust or by an author certificate > and a distributor certificate that I trust. "that I trust" means that I have > the proven public keys for these certificates. If an attacker replaces or > adds a file in the widget resource after it was signed then the signatures > will be invalid. If the signatures are stripped off, a file is replaced or > added and the widget resource is signed again with another certificate that I > do not trust then the attack will fail when checking the signature. > Yes, I am only really concerned with the case whereby the signature is removed (I'm aware that it is not possible to do any kind of replacement or tampering of the sig). The security policy that we (Web Apps) have been discussing would allow unsigned widgets to run with full privileges by default. RH: I will be concerned like you that a widget has access to all widget user agent resources regardless of whether: a) it was signed and signatures were left untouched, b) it was signed but the signatures were removed, c) it was unsigned and transported over a secure channel, d) it was unsigned and transported over an unprotected channel. As long as the P&C does not specify any security mechanism that verifies the integrity and the authenticity of a widget resource and that has an influence on the access to widget user agent resources or the processing of the widget, then we have to live with this concern. Then we can only hope that WUA implementers provide their own security mechanism leading to fragmentation in this respect. > I also push for this model because I don't think developers should have to > pay for a cert to have their apps run on a device. RH: From my point of view, signing does not necessarily mean that a developer has to pay for it. On the other hand, I am aware of the note in the P&C saying "How a widget user agent uses a digital signature is determined by the security policy implemented by that widget user agent. As such, this specification does not mandate processing rules dependent on the verification of one or more digital signature documents or on the revocation status obtained for the certificates associated with a verified digital signature document." > I would agree with you that a secure transport will be useful if the widget > resource is unsigned or signed with an unknown certificate. Then it will be > the decision of a security framework and its security policies how such a > widget resource will be treated. > Agreed. A point of contention is whether we standardize a base security policy or not. We might just leave that totally up to implementers. RH: I would recommend not to standardize a base security policy for all markets on the world. It would take too long. However, we might want to discuss for Widgets 2.0 whether we would try agreeing on a security framework defining what needs to be protected, how a security policy is defined (i.e. format, vocabulary) and how security policies could be provisioned or managed. -- Marcos Caceres http://datadriven.com.au
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
On Mon, Mar 2, 2009 at 2:56 PM, Hillebrand, Rainer wrote: > Dear Marcos, > > In order to detect a man-in-the-middle-attack, a widget resource is signed, > either by an author's certificate that I trust or by an author certificate > and a distributor certificate that I trust. "that I trust" means that I have > the proven public keys for these certificates. If an attacker replaces or > adds a file in the widget resource after it was signed then the signatures > will be invalid. If the signatures are stripped off, a file is replaced or > added and the widget resource is signed again with another certificate that I > do not trust then the attack will fail when checking the signature. > Yes, I am only really concerned with the case whereby the signature is removed (I'm aware that it is not possible to do any kind of replacement or tampering of the sig). The security policy that we (Web Apps) have been discussing would allow unsigned widgets to run with full privileges by default. I also push for this model because I don't think developers should have to pay for a cert to have their apps run on a device. > I would agree with you that a secure transport will be useful if the widget > resource is unsigned or signed with an unknown certificate. Then it will be > the decision of a security framework and its security policies how such a > widget resource will be treated. > Agreed. A point of contention is whether we standardize a base security policy or not. We might just leave that totally up to implementers. -- Marcos Caceres http://datadriven.com.au
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Dear Marcos, In order to detect a man-in-the-middle-attack, a widget resource is signed, either by an author's certificate that I trust or by an author certificate and a distributor certificate that I trust. "that I trust" means that I have the proven public keys for these certificates. If an attacker replaces or adds a file in the widget resource after it was signed then the signatures will be invalid. If the signatures are stripped off, a file is replaced or added and the widget resource is signed again with another certificate that I do not trust then the attack will fail when checking the signature. I would agree with you that a secure transport will be useful if the widget resource is unsigned or signed with an unknown certificate. Then it will be the decision of a security framework and its security policies how such a widget resource will be treated. Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Rainer, On Mon, Mar 2, 2009 at 2:01 PM, Hillebrand, Rainer wrote: > Dear Marcos, > > I have some doubts that a secure transport of a widget resource is so > important in case of a signed widget resource. I would agree with you that we > currently do not know how a signature is considered because we do not have a > security framework and security policies that would define the use of > signatures. However, if a user agent implements a security framework that > enforces security policies considering signed widget resources then a secure > transport will not be required. The signature shall guarantee the widget > resource's integrity and authenticity. What would a secure transport add? > The way I see it, secure transport would add protection from a signature being deleted from the archive or replaced all together, with the inclusion of other files (i.e., protects from a man-in-the-middle attack). There may be other things too, but I have not thought of them yet. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Dear Marcos, I have some doubts that a secure transport of a widget resource is so important in case of a signed widget resource. I would agree with you that we currently do not know how a signature is considered because we do not have a security framework and security policies that would define the use of signatures. However, if a user agent implements a security framework that enforces security policies considering signed widget resources then a secure transport will not be required. The signature shall guarantee the widget resource's integrity and authenticity. What would a secure transport add? Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Dienstag, 24. Februar 2009 23:34 To: Frederick Hirsch Cc: ext Priestley, Mark, VF-Group; Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec Hi Frederick, On Tue, Feb 24, 2009 at 11:19 PM, Frederick Hirsch wrote: > The Widget Signature spec is not an API definition so probably does > not need to define how signature status information is returned. You are right, so agreed. > I also agree that it > would be incorrect to define in the Widget Signature spec whether or > not a widget is valid, that is out of scope. Right again. > The spec limits itself to signature > validation. However I would not want to be prescriptive in the > specification to the level of status return codes. Ok, makes sense. > We may want to add a security considerations note along the lines of > > "As distributor signatures are not included in an overall widget > signature, it is possible for signatures to be added or removed and > hence a secure channel for widget delivery might be preferable." Ok, that is also an important security consideration. Should definitely have that in the spec under security considerations or some such section. -- Marcos Caceres http://datadriven.com.au
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Hi Frederick, On Tue, Feb 24, 2009 at 11:19 PM, Frederick Hirsch wrote: > The Widget Signature spec is not an API definition so probably does not need > to define how signature status information is returned. You are right, so agreed. > I also agree that it > would be incorrect to define in the Widget Signature spec whether or not a > widget is valid, that is out of scope. Right again. > The spec limits itself to signature > validation. However I would not want to be prescriptive in the > specification to the level of status return codes. Ok, makes sense. > We may want to add a security considerations note along the lines of > > "As distributor signatures are not included in an overall widget signature, > it is possible for signatures to be added or removed and hence a secure > channel for widget delivery might be preferable." Ok, that is also an important security consideration. Should definitely have that in the spec under security considerations or some such section. -- Marcos Caceres http://datadriven.com.au
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
urce is signed. This could happen regardless of whether or not the signature file was actually valid, or was just named according to the convention for digital signature. To be abused by an attacker it would either be necessary to inject a reference to the file into the widget, which might be difficult, or to hijack an existing reference to a signature file by swapping the intended signature file for the attacker's signature file (with the same name). While this later attack depends on the author providing such a reference in their widget, there are two reasons why the author may currently choose to do this - to get some information about the signature to display to the user, or possibly more likely, to get around the need to sign everything in their widget resource (I thought of this as a way around signing everything so developers will too!). It's not a big hole and the attacks require some "assistance" from developers, but unless there's a reason not to it should be pretty easy to close. -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 04 February 2009 17:35 To: Priestley, Mark, VF-Group Cc: Arthur Barstow; public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec Hi Mark, On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group wrote: Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- -- -- Substantive comments -- -- -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically "If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget.", on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing, but it seemed like a good idea to put this in here at the time. In other words, this is something that is controlled by the Widgets Dig Sig spec. If it turns out that Widgets Dig Sig never results in an invalid widget situation, then I will take this out. I've created a red note in the spec that says "Issue: [Widgets-DigSig] may never identify a widget package as invalid" as a reminder that we need to sort this out. FWIW, I think step 5 is buggy and needs a rewrite (I've added another issue to the spec stating as such). I'll need to work with you to fix it as we progress the Dig Sig spec. --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. Good point. This seems like something that needs to be in the yet to be written a widget runtime security spec. I've added an issue note to the spec so we don't forget about this. Just out of interest, can you present the nature of the security hole? i.e., once an attacker has the signature, say, via an XSS attack, what could they do with it? --- 7.10 The access Element The access element defines a network attribute as "A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. " Based on this description we would like to make the following observations and suggestion: The access element contains security permis
RE: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec)
Comments inline. Thanks, Mark >-Original Message- >From: marcosscace...@gmail.com >[mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres >Sent: 22 February 2009 16:02 >To: Priestley, Mark, VF-Group >Cc: Arthur Barstow; public-webapps >Subject: Re: [widgets] The access element (was: RE: Reminder: >January 31 comment deadline for LCWD of Widgets 1.0: Packaging >& Configuration spec) > >Hi Mark, > >2009/2/19 Priestley, Mark, VF-Group : >> Hi All, >> >> In the email [1] containing my comments against the LCWD of >Widgets 1.0: >> Packaging & Configuration spec, I wrote: >> >>>> 7.10 The access Element >>>> The access element defines a network attribute as "A boolean >> attribute >>>> that indicates that the widget might need to access network >>>> resources >> >>>> as specified in [Widgets-Security]. " >>>> >>>> Based on this description we would like to make the following >>>> observations and suggestion: >>>> >>>> The access element contains security permissions that will be used >>>> as >> >>>> hooks in the yet to be written [Widgets-Security] >specification. The >>>> problem is that the permissions haven't yet been discussed >in detail >>>> and so we may find that we want to represent additional context >>>> other >> >>>> than a black and white "is network access required?". For example, >>>> it >> >>>> may be the case that it is important from a security point of view >>>> to >> >>>> know which bearer or protocol will be used, or to nest a set of >>>> domains/URLs with which the widget wants to communicate. I do not >> have >>>> a strong view on what might be relevant here, and I am not >>>> suggesting >> >>>> that it needs to be considered as part of the last call of the >>>> Packaging and Configuration spec, only that it is likely that the >>>> permission will need to be more complex when we look at it from a >> security perspective. >> >> Marcos replied: >> >>> I think we better start this soon, then. My feeling is that we will >> need some kind of access declarations, and I would like to >> see them in the > configuration document. >> >> My follow up: >> >> Marcos makes the suggestion that he would like to see the access >> element replaced/extended with domains. Vodafone have come to a >> similar conclusion. We feel that a widget author should be able to >> declare the hosts with which they want to communicate. The widget >> should then only be allowed to communicate with those hosts. >> >> This is beneficial for two reasons: >> >> 1.) It allows the widget author to practice the principle of least >> privilege, limiting the potential attack space > >Agreed. > >> 2.) It allows other parties (users, widget distributors, consuming >> widget user agents) to inspect the widget to get some idea >of who the >> widget will communicate with, thereby enabling more sensible >security >> decisions to be made. > >Agreed. > >> There is however one exception that we would like to enable, the >> ability for a widget author to indicate that their widget might be >> expected to communicate with any host. This is to allow for >use cases >> such as widget RSS readers. We would therefore like to propose that >> the access element is extended along the following lines: >> >> >> >> >> >> >> > >Firstly, this assumes communication over HTTP. I think we need >to make this protocol agnostic. How do I indicate I want to >use HTTPs? You would need a special purpose URI parse that can >parse malformed URIs. > >I propose the simpler: > > > > > >The semantics of the URI can be derived from whatever URI type >is used (most likely case will be HTTP, in which case you >parse the URI semantics using RFC2616). User agents can >support whatever URIs they like, or exclude others (e.g., file://). > Agreed - with some comments below >> Declaring would mean that regardless of >> whether the network element contained any child domain elements, the >> author was declaring that they wanted access to any host >(note that by >> default this value would be "false" so only authors who >wanted access >> to any host would be inclined to use it)
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
2009/2/16 Priestley, Mark, VF-Group : > No problem. > > From > http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0346.html: > > > > [mp] The hole is that signature files are excluded from the generation > of the signature values in any other signature files. This means that > if, for example, an attacker added to the widget resource a signature > file containing some malicious content, the malicious content of that > file wouldn't be covered by any of the other signatures but the widget > user agent thinks the entire widget resource is signed. This could > happen regardless of whether or not the signature file was actually > valid, or was just named according to the convention for digital > signature. Ok, good point. > To be abused by an attacker it would either be necessary to inject a > reference to the file into the widget, which might be difficult, or to > hijack an existing reference to a signature file by swapping the > intended signature file for the attacker's signature file (with the same > name). While this later attack depends on the author providing such a > reference in their widget, there are two reasons why the author may > currently choose to do this - to get some information about the > signature to display to the user, or possibly more likely, to get around > the need to sign everything in their widget resource (I thought of this > as a way around signing everything so developers will too!). Ok. > It's not a big hole and the attacks require some "assistance" from > developers, but unless there's a reason not to it should be pretty easy > to close. > > > I realise that this still requires the ability to read in the file, > which would probably have to be via a local Ajax call, not a reference > as I suggested above. You could say that it's a pretty theoretical > vulnerability but if it's easy to fix and there's no negatives then I > think we should address it. Ok, as you saw, I created an issue so we don't forget to address this: http://www.w3.org/2008/webapps/track/issues/83 I also added your description of the hole. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec)
Hi Mark, 2009/2/19 Priestley, Mark, VF-Group : > Hi All, > > In the email [1] containing my comments against the LCWD of Widgets 1.0: > Packaging & Configuration spec, I wrote: > >>> 7.10 The access Element >>> The access element defines a network attribute as "A boolean > attribute >>> that indicates that the widget might need to access network resources > >>> as specified in [Widgets-Security]. " >>> >>> Based on this description we would like to make the following >>> observations and suggestion: >>> >>> The access element contains security permissions that will be used as > >>> hooks in the yet to be written [Widgets-Security] specification. The >>> problem is that the permissions haven't yet been discussed in detail >>> and so we may find that we want to represent additional context other > >>> than a black and white "is network access required?". For example, it > >>> may be the case that it is important from a security point of view to > >>> know which bearer or protocol will be used, or to nest a set of >>> domains/URLs with which the widget wants to communicate. I do not > have >>> a strong view on what might be relevant here, and I am not suggesting > >>> that it needs to be considered as part of the last call of the >>> Packaging and Configuration spec, only that it is likely that the >>> permission will need to be more complex when we look at it from a > security perspective. > > Marcos replied: > >> I think we better start this soon, then. My feeling is that we will > need some kind of access declarations, and I would like to see > them in the > configuration document. > > My follow up: > > Marcos makes the suggestion that he would like to see the access element > replaced/extended with domains. Vodafone have come to a similar > conclusion. We feel that a widget author should be able to declare the > hosts with which they want to communicate. The widget should then only > be allowed to communicate with those hosts. > > This is beneficial for two reasons: > > 1.) It allows the widget author to practice the principle of least > privilege, limiting the potential attack space Agreed. > 2.) It allows other parties (users, widget distributors, consuming > widget user agents) to inspect the widget to get some idea of who the > widget will communicate with, thereby enabling more sensible security > decisions to be made. Agreed. > There is however one exception that we would like to enable, the ability > for a widget author to indicate that their widget might be expected to > communicate with any host. This is to allow for use cases such as widget > RSS readers. We would therefore like to propose that the access element > is extended along the following lines: > > > > > > > Firstly, this assumes communication over HTTP. I think we need to make this protocol agnostic. How do I indicate I want to use HTTPs? You would need a special purpose URI parse that can parse malformed URIs. I propose the simpler: The semantics of the URI can be derived from whatever URI type is used (most likely case will be HTTP, in which case you parse the URI semantics using RFC2616). User agents can support whatever URIs they like, or exclude others (e.g., file://). > Declaring would mean that regardless of > whether the network element contained any child domain elements, the > author was declaring that they wanted access to any host (note that by > default this value would be "false" so only authors who wanted access to > any host would be inclined to use it). I suggest a special case of : > There is IMO an open question as to whether it would better to specify: > > 1. full URLs in place of hostnames, eg: > > http://somehost.com"; /> >From my point of view, yes... as per the rationale above. > 2. hostnames (to allow for use of http and https and other protocols > without requiring multiple declarations), maybe by using an additional > attribute, eg: > > URIs already define all this, so we don't need to break up the URIs into their parts. The semantics of HTTP URIs are well understood and already easily parsed by implementations. > 3. hostnames + paths (to allow authors to restrict access to specific > resources) > > Would be supported by using URIs: http://somehost.com/images/"/> OR http://example.com/resource"; /> The resource could then be exploited (in a good way) at runtime through query strings:
[widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec)
Speaking from a Vodafone perspective and as someone who participates in both W3C WebApps and BONDI, ideally we would like to see the solution specified in W3C and then simply referenced in BONDI. With BONDIs current specifications being at Candidate Release status until the 9th March there is still a good opportunity to achieve this kind of alignment. I realise that it's late in the day to be specifying new elements but I think there are real advantages to extending the access element in the way proposed and it addresses a real use case. As always, comments, questions and suggestions are welcomed! Thanks, Mark [1] http://www.mail-archive.com/public-webapps@w3.org/msg02058.html [2] http://bondi.omtp.org/Documents/CR10/BONDI_Architecture_Security_Task_CR 10.pdf >-Original Message- >From: Marcos Caceres [mailto:marcosscace...@gmail.com] >Sent: 04 February 2009 17:35 >To: Priestley, Mark, VF-Group >Cc: Arthur Barstow; public-webapps >Subject: Re: Reminder: January 31 comment deadline for LCWD of >Widgets 1.0: Packaging & Configuration spec > >Hi Mark, >On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group > wrote: >> >> Hi Marcos, Art, All, >> >> Please find below Vodafone's comments on the Widgets 1.0: Packaging >> and Configuration specification. I have divided them into what I >> consider to be substantive comments and editorial comments. >> >> Thanks, >> >> Mark >> >> >> >-- >> -- >> -- >> Substantive comments >> >-- >> -- >> -- >> Step 5 Process the Digital Signatures >> >> We disagree with the stage 2, specifically "If the file entry is >> deemed by the [Widgets-DigSig] to be an invalid widget, then >a widget >> user agent must treat this widget as an invalid widget.", on >two grounds: >> >> (1) Because one signature is invalid it doesn't mean that all of the >> signatures are invalid; >> (2) Just because one signature or all signatures are invalid >does not >> mean that the widget should not be installed, only that it should >> _not_ be treated as a signed widget. The security policy of >the device >> might be configured not to install an unsigned widget or a >widget with >> an invalid signature but this should be dependent on the security >> policy implemented. > >Sorry, I think you might have misunderstood what I was trying >to say here (probably I did not write it clearly enough). This >assertion is here to deal with instances where the digital >signature deemed by the Widgets Dig Sig spec to be somehow >fully broken or completely non-conforming in such a way that >all processing must stop. I don't yet know if Widgets Dig Sig >will spit out such a result for any digsig it is processing, >but it seemed like a good idea to put this in here at the time. > >In other words, this is something that is controlled by the >Widgets Dig Sig spec. If it turns out that Widgets Dig Sig >never results in an invalid widget situation, then I will take >this out. I've created a red note in the spec that says >"Issue: [Widgets-DigSig] may never identify a widget package >as invalid" as a reminder that we need to sort this out. > >FWIW, I think step 5 is buggy and needs a rewrite (I've added >another issue to the spec stating as such). I'll need to work >with you to fix it as we progress the Dig Sig spec. > >> --- >> Step 4 Locate Digital Signatures for the Widget >> >> I'm not sure whether the packaging and configuration >specification is >> the correct place to do this but IMHO there needs to be a statement >> that a files with a file name corresponding to the naming convention >> for digital signatures are not accessible from the widget once the >> widget is installed / instantiated. Failure to impose this >restriction >> will make it possible to include a signature and then reference it >> from the signed code, which presents a security hole. > >Good point. This seems like something that needs to be in the >yet to be written a widget runtime security spec. I've added >an issue note to the spec so we don't forget about this. > >Just out of interest, can you present the nature of the security hole? >i.e., once an attacker has the signature, say, via an XSS >attack, what could they do with it? > >> --- >> 7
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
No problem. From http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0346.html: [mp] The hole is that signature files are excluded from the generation of the signature values in any other signature files. This means that if, for example, an attacker added to the widget resource a signature file containing some malicious content, the malicious content of that file wouldn't be covered by any of the other signatures but the widget user agent thinks the entire widget resource is signed. This could happen regardless of whether or not the signature file was actually valid, or was just named according to the convention for digital signature. To be abused by an attacker it would either be necessary to inject a reference to the file into the widget, which might be difficult, or to hijack an existing reference to a signature file by swapping the intended signature file for the attacker's signature file (with the same name). While this later attack depends on the author providing such a reference in their widget, there are two reasons why the author may currently choose to do this - to get some information about the signature to display to the user, or possibly more likely, to get around the need to sign everything in their widget resource (I thought of this as a way around signing everything so developers will too!). It's not a big hole and the attacks require some "assistance" from developers, but unless there's a reason not to it should be pretty easy to close. I realise that this still requires the ability to read in the file, which would probably have to be via a local Ajax call, not a reference as I suggested above. You could say that it's a pretty theoretical vulnerability but if it's easy to fix and there's no negatives then I think we should address it. Thanks, Mark >-Original Message- >From: Marcos Caceres [mailto:marcosscace...@gmail.com] >Sent: 13 February 2009 13:27 >To: Priestley, Mark, VF-Group >Cc: Frederick Hirsch; Barstow Art (Nokia-CIC/Boston); public-webapps >Subject: Re: Reminder: January 31 comment deadline for LCWD of >Widgets 1.0: Packaging & Configuration spec > >Hi Mark, >2009/2/12 Priestley, Mark, VF-Group : >> [mp] To be clear I was suggesting that access to signatures was >> restricted from the widget after installation. I was not suggesting >> that they were not more generally available. As you say access to >> signatures after installation (outside of the widget) is useful and >> should be supported. > >Could you please explain what the security implications of >allowing a widget to have access to the signatures at runtime? >(apologies if you have done this in another email, I might >have missed it). > >Kind regards, >Marcos > > > > >-- >Marcos Caceres >http://datadriven.com.au >
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Hi Mark, 2009/2/12 Priestley, Mark, VF-Group : > [mp] To be clear I was suggesting that access to signatures was > restricted from the widget after installation. I was not suggesting that > they were not more generally available. As you say access to signatures > after installation (outside of the widget) is useful and should be > supported. Could you please explain what the security implications of allowing a widget to have access to the signatures at runtime? (apologies if you have done this in another email, I might have missed it). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Hi Frederick, Some comments inline below. Thanks, Mark >-Original Message- >From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] >Sent: 11 February 2009 23:21 >To: Priestley, Mark, VF-Group >Cc: Frederick Hirsch; Marcos Caceres; Barstow Art >(Nokia-CIC/Boston); public-webapps >Subject: Re: Reminder: January 31 comment deadline for LCWD of >Widgets 1.0: Packaging & Configuration spec > >I'm not sure restricting access to a signature is desirable >since signatures are intended to be objects that can be >evaluated etc - there is even a widget requirement that they >can be removed and conveyed independently of the widget. >Thus I assume access to the signature is possible outside the >context of the engine. > [mp] To be clear I was suggesting that access to signatures was restricted from the widget after installation. I was not suggesting that they were not more generally available. As you say access to signatures after installation (outside of the widget) is useful and should be supported. >XML Signature is used in many applications where signatures >are to be shared and used - the idea is that it should be a >secure object in and of itself. If there is a security risk it >should then be addressed, but restricting access to the >signature should not be necessary. > [mp] See above comment - my explanation below explains that while signatures may be secure in of themselves there is (an admittedly edge) case in which the presence of multiple signatures could create a problem. >Addition or removal of signatures might be an issue however, >if signature elements are not included in overall integrity >protection of the entire widget. [mp] Yes, this is the cause of the issue but I think it is a necessary behaviour if we are to allow multiple signatures, which is what we are aiming for. >This might be mitigated to >some degree by certificate requirements, especially if widgets >are always required to be signed. We might want to clarify the >requirements, now they seem to require signing but the email >discussion suggests unsigned widgets as well. [mp] I don't think this is necessary. The requirements, as I understand them, require support for signed widgets but not that all widgets are signed, which I think is fine. To address the issue I outlined below (if we agree that it is an issue) we just need to make the signature files unavailable to the widget at runtime. They are identified by a filename pattern so this shouldn't be hard. > >Is there currently any specification of how policy is >expressed and handled in the context of widgets? I didn't see >anything on the wiki. [mp] Not in the W3C Widgets specs AFAIK >Absent expressed policy, will widget installation and use be >possible? >If so then a simpler rule might be required for signature >validation success since there will be "nobody there" to >evaluate response codes. [mp] I agree that we might need a simple default policy in the case that there is "nobody there", but it should be possible to override this policy if there is a policy has been implemented by "someone" > >Moreover, how is a policy engine to know what a verification >success/ failure for a variety of possible signature >usage/role types and/or signers to be handled, will rules be >expressed in terms of usage/role (e.g. distributor) and what >else? The model is not clear to me. > [mp] without meaning to provide a circular answer, I assume that this will be down to the policy engine. What I think it is important for the Digital Signatures spec to provide is the hooks for the policy engine to act on. >regards, Frederick > >Frederick Hirsch >Nokia > > > >On Feb 6, 2009, at 10:51 AM, ext Priestley, Mark, VF-Group wrote: > >> >> >> Hi Marcos, >> >> More responses to your comments below (marked [mp]). Still >need to get >> back to you on the access element but I need to think about it a bit >> more first. >> >> Thanks, >> >> Mark >> >> >>> -- >>> Step 5 Process the Digital Signatures >>> >>> We disagree with the stage 2, specifically "If the file entry is >>> deemed by the [Widgets-DigSig] to be an invalid widget, >then a widget >>> user agent must treat this widget as an invalid widget.", on two >> grounds: >>> >>> (1) Because one signature is invalid it doesn't mean that >all of the >>> signatures are invalid; >>> (2) Just because one signature or all signatures are >invalid does not >>> mean that the widget should not be installed, only that it should >>> _not_ be treated
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
sible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. Good point. This seems like something that needs to be in the yet to be written a widget runtime security spec. I've added an issue note to the spec so we don't forget about this. Just out of interest, can you present the nature of the security hole? i.e., once an attacker has the signature, say, via an XSS attack, what could they do with it? [mp] The hole is that signature files are excluded from the generation of the signature values in any other signature files. This means that if, for example, an attacker added to the widget resource a signature file containing some malicious content, the malicious content of that file wouldn't be covered by any of the other signatures but the widget user agent thinks the entire widget resource is signed. This could happen regardless of whether or not the signature file was actually valid, or was just named according to the convention for digital signature. To be abused by an attacker it would either be necessary to inject a reference to the file into the widget, which might be difficult, or to hijack an existing reference to a signature file by swapping the intended signature file for the attacker's signature file (with the same name). While this later attack depends on the author providing such a reference in their widget, there are two reasons why the author may currently choose to do this - to get some information about the signature to display to the user, or possibly more likely, to get around the need to sign everything in their widget resource (I thought of this as a way around signing everything so developers will too!). It's not a big hole and the attacks require some "assistance" from developers, but unless there's a reason not to it should be pretty easy to close. -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 04 February 2009 17:35 To: Priestley, Mark, VF-Group Cc: Arthur Barstow; public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec Hi Mark, On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group wrote: Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- -- -- Substantive comments -- -- -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically "If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget.", on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing, but it seemed like a good idea to put this in here at the time. In other words, this is something that is controlled by the Widgets Dig Sig spec. If it turns out that Widgets Dig Sig never results in an invalid widget situation, then I will take this out. I've created a red note in the spec that says "Issue: [Widgets-DigSig] may never identify a widget package as invalid" as a reminder that we need to sort this out. FWIW, I think step 5 is buggy and needs a rewrite (I've added another issue to the spec stating as such). I'll need to work with you to fix it as we progress the Dig Sig spec. --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
eed to sign everything in their widget resource (I thought of this as a way around signing everything so developers will too!). It's not a big hole and the attacks require some "assistance" from developers, but unless there's a reason not to it should be pretty easy to close. >-Original Message- >From: Marcos Caceres [mailto:marcosscace...@gmail.com] >Sent: 04 February 2009 17:35 >To: Priestley, Mark, VF-Group >Cc: Arthur Barstow; public-webapps >Subject: Re: Reminder: January 31 comment deadline for LCWD of >Widgets 1.0: Packaging & Configuration spec > >Hi Mark, >On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group > wrote: >> >> Hi Marcos, Art, All, >> >> Please find below Vodafone's comments on the Widgets 1.0: Packaging >> and Configuration specification. I have divided them into what I >> consider to be substantive comments and editorial comments. >> >> Thanks, >> >> Mark >> >> >> >-- >> -- >> -- >> Substantive comments >> >-- >> -- >> -- >> Step 5 Process the Digital Signatures >> >> We disagree with the stage 2, specifically "If the file entry is >> deemed by the [Widgets-DigSig] to be an invalid widget, then >a widget >> user agent must treat this widget as an invalid widget.", on >two grounds: >> >> (1) Because one signature is invalid it doesn't mean that all of the >> signatures are invalid; >> (2) Just because one signature or all signatures are invalid >does not >> mean that the widget should not be installed, only that it should >> _not_ be treated as a signed widget. The security policy of >the device >> might be configured not to install an unsigned widget or a >widget with >> an invalid signature but this should be dependent on the security >> policy implemented. > >Sorry, I think you might have misunderstood what I was trying >to say here (probably I did not write it clearly enough). This >assertion is here to deal with instances where the digital >signature deemed by the Widgets Dig Sig spec to be somehow >fully broken or completely non-conforming in such a way that >all processing must stop. I don't yet know if Widgets Dig Sig >will spit out such a result for any digsig it is processing, >but it seemed like a good idea to put this in here at the time. > >In other words, this is something that is controlled by the >Widgets Dig Sig spec. If it turns out that Widgets Dig Sig >never results in an invalid widget situation, then I will take >this out. I've created a red note in the spec that says >"Issue: [Widgets-DigSig] may never identify a widget package >as invalid" as a reminder that we need to sort this out. > >FWIW, I think step 5 is buggy and needs a rewrite (I've added >another issue to the spec stating as such). I'll need to work >with you to fix it as we progress the Dig Sig spec. > >> --- >> Step 4 Locate Digital Signatures for the Widget >> >> I'm not sure whether the packaging and configuration >specification is >> the correct place to do this but IMHO there needs to be a statement >> that a files with a file name corresponding to the naming convention >> for digital signatures are not accessible from the widget once the >> widget is installed / instantiated. Failure to impose this >restriction >> will make it possible to include a signature and then reference it >> from the signed code, which presents a security hole. > >Good point. This seems like something that needs to be in the >yet to be written a widget runtime security spec. I've added >an issue note to the spec so we don't forget about this. > >Just out of interest, can you present the nature of the security hole? >i.e., once an attacker has the signature, say, via an XSS >attack, what could they do with it? > >> --- >> 7.10 The access Element >> >> The access element defines a network attribute as "A boolean >attribute >> that indicates that the widget might need to access network >resources >> as specified in [Widgets-Security]. " >> >> Based on this description we would like to make the following >> observations and suggestion: >> >> The access element contains security permissions that will >be used as >> hooks
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
27;t there be a statement saying that the widget user > agent MAY ignore these values? No, the width and height attributes represent the _minimum_ size at which an image may be used. Then, the vector graphic can behave in the manner you describe (i.e., can be used to fill a rendering context larger than the width and height). [mp] Hmm, in this case shouldn't the spec explicitly state that these are minimum height and widths for vector graphics and that the widget user agent may use bigger heights and widths if it wants to? >Equally should there be default sizes in case the attribute is not used? Hmm... good point. I've added that as an issue in the relevant section. [mp] OK - no strong opinion on this I was just really asking a question > In terms of raster graphics the text currently says "If the file > pointed to by the src is a supported raster graphic, this value may be > ignored by the widget user agent." but shouldn't the "may" in this > case be a "should"? Correct, but that "should" should be a "must". Fixed. [mp] Even better, thanks. > --- > 7.13 The feature Element > > In the sentence "The feature is used by an author to denote that, at > runtime, a widget may require access to a feature." the use of "may > require" is very slightly confusing given that the next attribute is > "required". Suggest changing "require" to "try to" or "attempt to". Changed "require" to "attempt to". [mp] Thanks > Likewise in the definition of the name attribute in the sentence "A > URI attribute that identifies a feature required by the widget at > runtime (such as an API)." change "required by" to "that may be used". Done. [mp] Thanks > --- > 8 Steps for Processing a Widget Resource > > The sentence "The steps for processing a widget resource involves ten > steps that a widget user agent must follow, in sequential order, > responding accordingly if any of the steps result in an error." could > be slightly misleading as some of the steps are skipped depending on > the processing in a preceding step. I'm not sure if this is always in > a response to an error? Ok, I changed it to: "The steps for processing a widget resource involves ten steps that a user agent must follow, in sequential order, responding accordingly if any of the steps result in an error or if the specification asks for the user agent to skip a step." Is that any better? [mp] Yep - sorry if I was being over pedantic :( > A minor comment on section 8 as a whole - some of the steps have an > explicit link to go to the next step while others (like 9) don't. It > would be nice if this was consistent. Ok, I checked every step and made sure things are consistent. Once all the comments are done, I'll do another editorial round to make sure everything is more consistent. > In addition, some of the algorithms, for example step 7, could be made > clearer by explicitly stating when to go to the next step (i.e. in > case of success in 7.1 and 7.2). Ok, I did what you said for step 7 and Step 8. Can you let me know which other ones need a rewrite? > Finally, in Step 6 there is a sentence "Else, remove the last subtag > of the range and repeat this step 2.d. (e.g., if the range ...". Just > to be super clear perhaps "this step 2.d." could be change to "and go > to 2.d of this algorithm" Made the change you suggested. [mp] All of the above changes for Section 8 look good to me- thanks. >-Original Message- >From: Marcos Caceres [mailto:marcosscace...@gmail.com] >Sent: 04 February 2009 17:35 >To: Priestley, Mark, VF-Group >Cc: Arthur Barstow; public-webapps >Subject: Re: Reminder: January 31 comment deadline for LCWD of >Widgets 1.0: Packaging & Configuration spec > >Hi Mark, >On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group > wrote: >> >> Hi Marcos, Art, All, >> >> Please find below Vodafone's comments on the Widgets 1.0: Packaging >> and Configuration specification. I have divided them into what I >> consider to be substantive comments and editorial comments. >> >> Thanks, >> >> Mark >> >> >> >-- >> -- >> -- >> Substantive comments >> >-- >> -- >> -- >> Step 5 Process the Digital Signatures >> >> We disagree with the stage
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Hi Mark, On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group wrote: > > Hi Marcos, Art, All, > > Please find below Vodafone's comments on the Widgets 1.0: Packaging and > Configuration specification. I have divided them into what I consider to > be substantive comments and editorial comments. > > Thanks, > > Mark > > > > -- > Substantive comments > > -- > Step 5 Process the Digital Signatures > > We disagree with the stage 2, specifically "If the file entry is deemed > by the [Widgets-DigSig] to be an invalid widget, then a widget user > agent must treat this widget as an invalid widget.", on two grounds: > > (1) Because one signature is invalid it doesn't mean that all of the > signatures are invalid; > (2) Just because one signature or all signatures are invalid does not > mean that the widget should not be installed, only that it should _not_ > be treated as a signed widget. The security policy of the device might > be configured not to install an unsigned widget or a widget with an > invalid signature but this should be dependent on the security policy > implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing, but it seemed like a good idea to put this in here at the time. In other words, this is something that is controlled by the Widgets Dig Sig spec. If it turns out that Widgets Dig Sig never results in an invalid widget situation, then I will take this out. I've created a red note in the spec that says "Issue: [Widgets-DigSig] may never identify a widget package as invalid" as a reminder that we need to sort this out. FWIW, I think step 5 is buggy and needs a rewrite (I've added another issue to the spec stating as such). I'll need to work with you to fix it as we progress the Dig Sig spec. > --- > Step 4 Locate Digital Signatures for the Widget > > I'm not sure whether the packaging and configuration specification is > the correct place to do this but IMHO there needs to be a statement that > a files with a file name corresponding to the naming convention for > digital signatures are not accessible from the widget once the widget is > installed / instantiated. Failure to impose this restriction will make > it possible to include a signature and then reference it from the signed > code, which presents a security hole. Good point. This seems like something that needs to be in the yet to be written a widget runtime security spec. I've added an issue note to the spec so we don't forget about this. Just out of interest, can you present the nature of the security hole? i.e., once an attacker has the signature, say, via an XSS attack, what could they do with it? > --- > 7.10 The access Element > > The access element defines a network attribute as "A boolean attribute > that indicates that the widget might need to access network resources as > specified in [Widgets-Security]. " > > Based on this description we would like to make the following > observations and suggestion: > > The access element contains security permissions that will be used as > hooks in the yet to be written [Widgets-Security] specification. The > problem is that the permissions haven't yet been discussed in detail and > so we may find that we want to represent additional context other than a > black and white "is network access required?". For example, it may be > the case that it is important from a security point of view to know > which bearer or protocol will be used, or to nest a set of domains/URLs > with which the widget wants to communicate. I do not have a strong view > on what might be relevant here, and I am not suggesting that it needs to > be considered as part of the last call of the Packaging and > Configuration spec, only that it is likely that the permission will need > to be more complex when we look at it from a security perspective. I think we better start this soon, then. My feeling is that we will need some kind of access declarations, and I would like to see them in the configuration document. __This has the potential to block progress of this specification.__ > There is also the case in which the network permission may be used to > determine whether or not the user wants to install a widget, This sounds reasonable. > or by the > widget user agent may want to indicate whether or not the widget can run > when there is no available network connect
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec
Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- Substantive comments -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically "If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget.", on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. --- 7.10 The access Element The access element defines a network attribute as "A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. " Based on this description we would like to make the following observations and suggestion: The access element contains security permissions that will be used as hooks in the yet to be written [Widgets-Security] specification. The problem is that the permissions haven't yet been discussed in detail and so we may find that we want to represent additional context other than a black and white "is network access required?". For example, it may be the case that it is important from a security point of view to know which bearer or protocol will be used, or to nest a set of domains/URLs with which the widget wants to communicate. I do not have a strong view on what might be relevant here, and I am not suggesting that it needs to be considered as part of the last call of the Packaging and Configuration spec, only that it is likely that the permission will need to be more complex when we look at it from a security perspective. There is also the case in which the network permission may be used to determine whether or not the user wants to install a widget, or by the widget user agent may want to indicate whether or not the widget can run when there is no available network connection. Some widgets may only operate when there is a network connection, whereas others may degrade gracefully. So to provide a degree of future-proofing we would like to suggest something like: (I realise that the "use" attribute in the above example is a horrible name but I couldn't think of another word for access...There are probably also better ways of capturing the meaning - we open to suggested improvements) Sorry for not raising this earlier but it has only become apparent when considering in more detail how the access element would be used. -- Editorial comments -- 6 Widget Resources First 5 bullets should say "and/or" rather than "or" ? --- 6.5 Content Localization "The container for localized content is a folder at the root of the widget whose the first five characters of the folder-name case insensitively match the string 'locales/'." Why the first five characters only? Also sentence has an extra "the" in the middle, i.e. "whose *the* first" --- 6.6 Start file and Default Start Files Sentence For consistency with other sections I suggest to add: "A default start file is a start file whose file-name case insensitively matches a file-name given in the first column of the default start files below and whose MIME type matches the MIME type given in the second column of the table." before the sentence starting: "A default start file is a start file that a widget user agent..." And then to combine the last two sentences before the default start files table to: "A widget user agent will attempt to l
