Re: [widgets] Updates FPWD published

Hi Rainer,
Thanks for your email and for taking the time to do the review.

On Tue, Oct 14, 2008 at 7:02 AM, Hillebrand, Rainer
<Rainer.Hillebrand@t-mobile.net> wrote:
> Dear Marcos,
>
> I have some comments on the FPWD of the "Widgets 1.0: Updates" document.
> a) Abstract: Replace "[...] the model makes use a simple XML documents [...]" by "[...] the model makes use of a simple XML document [...]".
>
fixed.

> b) 2. Introduction: Replace "[...] a multi-step process where by a widget user agent compares [...]" by "[...] a multi-step process where a widget user agent compares [...]".
>

fixed.

> c) 2. Introduction: Replace "[...] the widget user agent must attempt replace [...]" by "[...] the widget user agent must attempt to replace [...]".
>

fixed.

> d) 2. Introduction: Replace "[...] via the rules define in this specification [...]" by "[...] via the rules defined in this specification [...]".
>

fixed.

> e) 2. Introduction: Replace "[...] then that installed widget is said to be up-to-date." by "[...] then that installed widget resource is said to be up-to-date.".
>

fixed.

> f) 2. Introduction: "It is expected that widget user agents will perform updates asynchronously by periodically checking for changes in either the HTTP response codes for the UDD (e.g. a changed HTTP Etag header or using If-Modified-Since) and by processing the UDD itself." This scenario is very likely in case of an implementation for a desktop computer or a set-top box. However, a push mechanism is well established in the mobile environment. Such a push mechanism consists of an SMS message that wakes up an application in a mobile terminal that retrieves any kind of content from a remote server. It could be applied to the automatic widget resource update mechanism as well. The widget resource author would send out notifications to his/her known customers/users via SMS. The widget user agent retrieves the UDD via HTTP. The advantage of this push mechanism is that it does not consume unnecessary processing resources in the mobile terminal and the remote server, does not consume unnecessary transmission capacity in the Web and updates a widget resource as soon as an update is available. The disadvantage is that it is not supported in the IP world. However, we could mention in the specification that a push mechanism could be applied as well. We could add the following sentence to the sentence above: "A push mechanism could be applied as well that pushes a UDD to the widget user agent as soon as an update is available.".
>

Added your suggested text, but as a "note:" until we have more details
about how we could do this. Is there a spec that outlines this SMS
functionality? Also, this sounds like a firm requirement so I've added
to the widgets version 2.0 requirements (unfortunately, our second
last call for requirements finished yesterday so I'm a bit reluctant
to add support for another features... however, this one sounds like a
good one worth exploring in the future):

http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R#Features_Wish_List

> f) 2. Introduction: Replace "[...] as it makes us of the URI to potentially retrieve [...]" by "[...] as it makes use of the URI to potentially retrieve [...]".
>
> g) 2. Introduction: "[...] and relay whether an update is available back to the instantiated Widget. Actually performing the update is left to the discretion of the widget user agent." Shall the instantiated Widget be able to initiate the update process after receiving the information that an update is available? Otherwise, it would not be under a Widget's control to start the actual update process. A Widget could be able to consider whether a mobile terminal is in roaming mode and whether its size is too big. If yes, it could postpone the update process to avoid unexpected costs for a user. As soon as the mobile terminal is attached to the home network, the Widget could ask the user to start the update process.
>

Good point. However, this sounds like an implementation detail (i.e.,
an really good widget engine would be intelligent enough to hold off
dispatching the update notification event to the instantiated widget
till the time was just right).

> h) 4.1 Example Update Description Document: The widgetupdate element supports two attributes that represent URIs. In section 2. Introduction, it is a "IRI from where the widget user agent can retrieve the potential update", for instance. If they are the same, then it should be either a URI or an IRI.
>

Fixed, they are now all URIs. Will add proper IRI support in the next
working draft.

> i) 9. Security concerns: "It is conceivable that the automatic update model could be subject to a man-in-the-middle-attack, as with any unencrypted requests performed over HTTP. For this reason, it is recommended that automatic update are always performed over HTTPS." An unencrypted request performed over HTTP is not necessarily opening up a security hole. As long as a widget resource is cryptographically signed and the widget user agent validates the signature before installation, a widget resource's identity and integrity should be guaranteed.
>

This is true in most situations. However, because of the high cost of
getting a code signing cert, I imagine most widgets will be shipped
unsigned. There are a few situations where this does not work. For
example, if I shipped my original widget unsigned, then my second
widget signed, then blackhat could remove the signature from the
updated widget package and make evil changes.

Given your suggestions, I've changed the text in this section to:
"It is conceivable that the automatic update model could be subject to
a man-in-the-middle-attack, as with any unencrypted requests performed
over HTTP. For this reason, it is recommended that, for widgets that
have not been digitally signed, updates are be always performed over
HTTPS.

Another means of protection is for authors to always digitally sign
their widget resources. During an update, the widget user agent will
then validate the signature before installation, ensuring that a
widget resource's identity and integrity was maintained over the
network. The widget user agent will also verify that the digital
signatures of the currently installed widget and the potential update
certifiably came from the same source."

WRT that last sentence, we still need to work out the details of how
we will do that.

> j) 10.1 Using an Update Description Document: Replace "widget engine" by "widget user agent".

fixed.

> k) 10.1 Using an Update Description Document: Replace "text/xml" by "application/xml".

fixed.

> l) 10.1 Using an Update Description Document: "So, the widget engine then checks that <update id> matches <widget id> and that <widget version> and <update version> are different. If so, then the user is informed that a new update is available." If the <widget version> is not the same like the <update version>, then this will not necessarily mean that a new update is available. The installed Widget Resource could have been retrieved from a web server providing the latest version. The UDD could have been stored on a memory card which could then be quite old. Then the widget user agent must be intelligent enough to compare whether the <widget version> is smaller than the <update version>. If yes, then a new update is available. The question is also whether we define a format for the version number. Is 1.0 "older" than 1.0a?
>

No, they are just different. There is no notion of greater version in
this specification. This makes the model much more flexible (it allows
for rollback, etc).  We had a long email discussion about this about a
year ago [1]. See in particular, Ian Hickson's comments [2].

Kind regards,
Marcos
[1] http://lists.w3.org/Archives/Public/public-appformats/2007Sep/0006.html
[2] http://lists.w3.org/Archives/Public/public-appformats/2007Sep/0026.html
-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 14 October 2008 14:43:21 UTC