Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

[Frederick Hirsch]

The Widget Signature spec is not an API definition so probably does  
not need to define how signature status information is returned. 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.  
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.

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

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

[mp] No this was pretty much my understanding. Maybe my comment wasn't
clear enough... IMO [Widgets-DigSig] should result in a list of
signature status values. How the widget user agent responds to those
values should be dependent on the security policy of the widget user
agent.

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.

[mp] Well I would argue that the [Widgets-DigSig] will never  
identify a
widget package as invalid although it may decide that one or more
signature(s) are invalid. The security policy of the device may decide
that the widget shouldn't be installed based on the result of  
processing
the signature file(s) but that is a different thing. I think that best
we can do in the P&C spec is say whether or not the widget is signed
(and even this could be tricky).

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.

[mp] I'll be available to work on this next week

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

[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
<mark.priest...@vodafone.com> 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 <domain> 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 connection. Some widgets may
only operate when there is a network connection, whereas others may
degrade gracefully.

This sounds like something authors need to deal with, not user  
agents.

So to provide a degree of future-proofing we would like to suggest
something like:

<access>
  <network use="true/false" required="true/false"/> </access>

We might not need this at all, actually: If we go down the
declaring domain route, then network is off unless a domain is
declared.

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

This needs further discussion.

Sorry for not raising this earlier but it has only become apparent
when considering in more detail how the access element would be  
used.

No probs.



----------------------------------------------------------------------
--
----------------------
Editorial comments

----------------------------------------------------------------------
--
----------------------
6 Widget Resources

First 5 bullets should say "and/or" rather than "or" ?

"Zero and/or more" sounds weird to me (i.e., "Zero and more").
If you feel strongly about this, I will change it; otherwise,
I would prefer to leave it as is.

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

That was a mistake, the sentence now reads:
"The container for localized content is a folder at the root
of the widget whose folder-name case insensitively match the
string 'locales/'. A container for localized content may
contain zero or more localized folders."

Also sentence has an extra "the" in the middle, i.e. "whose
*the* first"

fixed.

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

Ok, I think there was a more significant problem: I've defined
"custom start files" and "default start files". As a result, I
changed that whole section.

And then to combine the last two sentences before the default start
files table to:

"A widget user agent will attempt to locate a file entry whose
file-name case insensitively matches one of the default start files
based on the order they appear in the table below (from top
to bottom). "

Can you please check that section again and let me know if the
rewrite is ok?

-----------------------------------------------
7.1 Namespace

It seems a bit tough that an invalid configuration document
results in
a invalid widget as the configuration document is optional. Also, if
the configuration document in the localised folder is invalid, it
could be the case that there is a valid configuration
document at the
root of the widget.

I don't have a strong opinion on this and have no objection
to leaving
the text as it is, I just wondered if there was a reason why this
approach had been taken?

Although I agree that it's a bit cruel on developers, we made
this decision to make the behavior of configuration documents
predictable.
I feel pretty strongly that we should leave it as is.

-----------------------------------------------
7.2 Proprietary Extensions

Should the "may" be a "should"? Otherwise, it could be
interpreted as
suggesting that vendors may equally use other approaches?

Right, fixed. This should, in fact, be a must (i.e., if you
want to extend, then you must use your own namespace).

-----------------------------------------------
7.9 The icon Element

(disclaimer - I may well be talking rubbish here as the following
comments are based on a _very_ basic understanding of graphics
formats)

The text says that if the icon is vector format then the height and
width attributes will be used, however, isn't one the point of using
vector graphics that they could be re-sized to fit the
available space.

Yes and no. Beyond certain sizes (e.g., too little, too big),
the rendering engine may have undesirable effects on a design
(think, for example, of a really tiny font having anti-alias
applied to it:
because of sub-pixel interpolation, it becomes too blurry to
read. The same can happen with graphics, very thin lines can
vanish or become blurry, which can make a design look crappy).
In such cases, it may be desirable to use a bitmap.

Therefore shouldn'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).

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.

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.

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

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.

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

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.

Very much appreciate Vodafone taking the time to conduct this review.

Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au