W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Tue, 14 Apr 2009 18:57:22 -0400
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, ext Marcos Caceres <marcosc@opera.com>, "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, Web Applications Working Group WG <public-webapps@w3.org>
Message-Id: <EA00F898-9880-4633-9C94-711AFA321EB9@nokia.com>
To: Barstow Art (Nokia-CIC/Boston) <Art.Barstow@nokia.com>

I do not understand the attack, but can envision cases where  
precluding access could cause problems. Examples might be user "see  
what is signed" or access to signature properties.

Is this an access control issue rather than a general specification  

regards, Frederick

Frederick Hirsch

On Apr 13, 2009, at 7:03 AM, Barstow Art (Nokia-CIC/Boston) wrote:

> On Apr 9, 2009, at 1:44 PM, ext Marcos Caceres wrote:
>> On 4/9/09 3:56 PM, Arthur Barstow wrote:
>>> On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote:
>>>> On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
>>>> <Mark.Priestley@vodafone.com> wrote:
>>>>> Hi Art, All,
>>>>> If there is no use case for accessing this information (I was
>>>>> after why
>>>>> you would want to access this information because I think just
>>>>> saying it
>>>>> might be interesting to do so isn't justification enough), then
>>>>> I think
>>>>> my original proposal holds - make the signature files
>>>>> unavailable to the
>>>>> widget at runtime.
>>>>> For clarification I was not suggesting that an API should be
>>>>> added to
>>>>> the DigSig spec but rather that some of the information could be
>>>>> exposed
>>>>> via an API defined in the APIs and Events spec. But I don't
>>>>> think this
>>>>> is necessary or worth the additional specification effort.
>>>> FWIW, I agree with Mark.
>>> Please propose text that will address your concerns.
>> In the P&C spec, I would add something like:
>> "A user agent MUST make the digital signature available only to
>> implementations of the [Widgets-DigSig] specification.
> I don't understand why we would want to create this type for a P&C UA.
>> A user agent MUST
>> NOT allow read access to any digital signature in the widget
>> package at
>> runtime.
> I think this conflates requirements for a P&C UA with the
> requirements for Widget [Runtime] UA. As such, I disagree with what
> you are trying to prescribe here and think the specs should remain
> silent on this (or perhaps defer this to a definition of a Widgets UA
> runtime model).
> I still cannot understand why you want to preclude a widget from
> being able to access *all* of its resources. Perhaps it would be
> helpful if you would elaborate on the risk(s) you are trying to
> mitigate.
> -Regards, Art Barstow
>> In other words, a user agent MUST NOT allow a start file, or
>> any other file or resource inside or outside the context of the  
>> widget
>> (e.g., a script or stylesheet), or API, or feature, to read any
>> digital
>> signature file within the widget package. At runtime, a user agent
>> make it seem as if digital signatures do not exist in the widget
>> package
>> by, for example, excluding them from any file listings, and not
>> allowing
>> them to be accessed via a URI."
>> That's just some quick draft text, please feel free to change, add,  
>> or
>> whatever.
Received on Tuesday, 14 April 2009 22:58:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC