W3C home > Mailing lists > Public > public-sysapps@w3.org > September 2012

Re: comment on the draft

From: Jarred Nicholls <jarred@webkit.org>
Date: Mon, 17 Sep 2012 09:27:05 -0400
Message-ID: <CANufG2Of-MSRQd9TrXxWKTXxCrOuKiETRApCy9X_BddOHLW2aQ@mail.gmail.com>
To: Angelo Borsotti <angelo.borsotti@gmail.com>
Cc: public-sysapps@w3.org
On Sun, Sep 16, 2012 at 3:24 AM, Angelo Borsotti

> Hello,
> all we have lived for decades using traditional apps, implemented in C++
> and Java, accessing the local filesystem and the whole OS. It is time to
> shift from these technologies to the new web ones, and implement apps using
> html and javascript -- providing that we can do the same things at least.
> Security is an issue, but it applies to apps implemented with traditional
> technologies.
> When I download Firefox, or Libreoffice, I trust them not to wipe out my
> filesystem or disrupt my OS because I trust the people that implemented
> them and I trust the place from which I downloaded them (i.e. that they are
> not counterfeited and, e.g., contain viruses).
> Once I have installed them I have effectively granted them access to my
> computer.
> This simple scheme could also apply to system web apps. Note that
> downloading a (traditional) app such as Firefox, installing it and running
> it is something that is nowadays done using the web. So, the distinction
> between apps and web apps tends to be confined to the technology that is
> used to implement them. From the users' perspective they differ mostly in
> the way they are installed.
> That said, there is no need to reinvent the wheel. A binding for
> javascript that allows to access the OS, like, e.g. the Posix primitives,
> is all what we need.
> I have seen in the proposal a number of APIs which seem quite dedicated to
> specific system apps. I think that here generality is a must: once we have
> access to the primitives of the OS in some standardized way, we can
> implement any app, much the same as we have done for decades with
> traditional technologies. It is as simple as that. Extra APIs to access
> specific things, such as the Contacts are specific for some particular
> applications, and thus should be provided as an additional part.
> Thank you
> -Angelo Borsotti

I agree completely that the more primitives that are offered, the array of
application types that can be created becomes much wider.  Highly specific
APIs never sat well with me, because their uses are so limited.  If the web
wants to win, we need to go to a lower level and be more generalized.
 Consider for a moment what Microsoft has done (so very well) with Windows

I think one of the biggest proponents to increasing web app security and
establishing trust with users - in addition to sandboxing and permission
manifests - is the notion of signed application code.  To assist in the
"installation" of a self-contained web application [bundle], a standardized
application code signature validation process would help users feel
comfortable that they are opting into exactly what they are expecting and
from the publisher they expected; no more and no less.  There are a lot of
security problems in between that require solutions, but I think this is
the icing on top of the cake to seal the deal.  I can't envision a
successful replacement of native applications without application
signatures & validations.

I'm sure I'm getting ahead of myself, but I think that's an important issue
to resolve in the long scheme of things.

Received on Monday, 17 September 2012 13:27:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:09 UTC