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

Hi Art,

On 4/13/09 1:03 PM, Arthur Barstow 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.

Ok, I see the confusion here. It should really have said,

"If a user agent implements [Widgets-Digsig], then it MUST ..."

Implementing [Widgets-DigSig] is always optional. We have similar weak 
dependencies for <preference> and A&E, as well as another weak 
dependency on [Widgets-DigSig] in Step 4... So, I guess they are not 
really "dependencies", more like specified conditions in the presence of 
an implementation of particular specifications.

>
>> 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.

True.

> 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).

Agreed.

> 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.

Please see Mark's emails[1][2]. He outlined the problem pretty clearly 
and use cases for the author accessing the signature have not been 
presented.

Kind regards,
Marcos

[1]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0018.html
[2]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0466.html

Received on Monday, 13 April 2009 11:29:37 UTC