Re: Suggesstions on "Widgets 1.0: Packaging and Configuration" document

Hi Oguz,

On Fri, Jul 17, 2009 at 11:07 AM, Oguz
Kupusoglu<oguz.kupusoglu@gmail.com> wrote:
> Hi,
>
> I have read the the following document:
>
> Widgets 1.0: Packaging and Configuration
> W3C Candidate Recommendation 14 July 2009
> http://dev.w3.org/2006/waf/widgets/
>
> Please find below my suggestions.
> Best regards,
>
> Oguz Kupusoglu
>
>
>
>
> Suggestion 1
>    Using a separate XML file named “proprietarty.xml” for specifying all the
>    proprietary extensions to the "Configuration Document". It will be found
>    at the place of the "Configuration Document".
>
>    Rationale
>        * Keeping the config.xml file fully standard.
>        * Easier maintenance by combining all non-standard stuff separately..
>        * Allowing reviewers see the proprietary stuff quickly and cleanly.
>        * However, From i18n point of view maintaining one  more file may be
>          a burden.

This is technically already supported. As it is proprietary, a
proprietary user agents could simply search for this file. I don't
think should be part of the spec, as we don't want to encourage people
to make proprietary widgets.

>
> Suggestion 2
>    Using a separate XML file named “preferences.xml” for persistently saving
>    the user preferences.  It will be found at the place of the "Configuration
>    Document".
>
>    Rationale
>        * When the related Widget is updated or reset, the Widget Engine can
>          easily check or restore the preferences.
>        * Allowing reviewers see the preferences quickly and cleanly.
>        * However, From i18n point of view maintaining one  more file may be
>          a burden.

One basically can't write anything into the widget archive because it
would break digital signatures. It would also mean that two widgets
could not be run simultaneously without  overwriting each others
preferences. This is better handled by, for instance, saving the
preferences to a server and then reloading them if needed or exporting
them out to a safe location somehow (e.g., with the upcoming fileIO
API).

> Suggestion 3
>    Assume each widget has a "complaint line": by simply activating it,
>    preferably adding some text, the user will inform the widget author and
>    widget host, widget gallery or AppStore, that something is wrong with the
>    widget. The complaint proceeding depends on the widget host policy. For
>    example, if the number of complaints hit a pre-defined threshold the widget
>    host may remove the problematic widget or can simply record the number of
>    complaints. In fact, this idea is already proposed by Marcos Caceres, see
>    "Position on Widget Security" ( http://datadriven.com.au/ ).

Right, what I proposed was more based on enabling the user agent to
have a number of "trusted authorities" on which it could rely to
either "allow" or "disallow" (or kill) privileges of a widget. Work
related to this (an by no means in related to my position paper) will
be undertaken by a new working group called the Device Access and
Policy Working Group, which is starting in September.

>    Rationale
>        * If a widget is used by technically illiterate people, there should be
>          an easy-to-use method for them to inform somebody that something is
>          wrong with a widget before they remove the widget. I don't expect
>          these people to go to the original place where they downloaded the
>          widget to take action. However, if such an easy-to-use built-in
>          "complaint line" is available, such people will take action. I am
>          working on some widgets to be used on TV's by ordinary people, and
>          ease of use with a remote controller is a prime concern for me.
>

The widget packaging specification provides all the bits that would be
needed to make such a proposal work. However, formal specification is
beyond the scope of the widgets 1.0 family of specs.

>
> Suggestion 4
>    From marketing point of view download rankings are important. For example,
>    "Download rankings are key to success since users trawl the most-popular
>    lists for games."* Assume each widget has a "rating" option. By activating
>    it, the user will send a rating between 0 and 5. Hence, the widget
> hosts may
>    maintain two separate listings: one is download ranking and the other is
>    user rating.
>
>    * Washington Post, Gabriel Madway, Big game publishers muscle in
> on iPhone's
>      upstarts, 15 July 2009
>
>    Rationale
>        * If a widget is used by technically illiterate people, there should be
>          an easy-to-use method for them to inform somebody their verdict on the
>          widget.
>        * At any moment t, the widget users while looking for new widgets have
>          more listing to check. This will reduce the pressure on the “download
>          ranking” list.

Again, this is an idea the working group has also considered. Note,
however, that rating cannot be part of a widgets metadata (for it
would be too easy to falsify). This is why such things are absent from
the configuration document format and are best saved outside the
widget.  Like I said above, it is not possible to store dynamic data
inside a widget package, for it would break the security model
provided by digital signatures.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 20 July 2009 17:19:09 UTC