W3C home > Mailing lists > Public > public-sysapps@w3.org > August 2013

Re: [Runtime and Security Model for Web Applications]: Privileged applications and API Access Permissions

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Tue, 27 Aug 2013 03:49:01 +0300
Message-ID: <CANrNqUfENFxd_rYQYu9hGz7uGYG23MadUT68DdWFUd0pqykGDg@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: Xin Sun(联通集团技术部) <sunx5@chinaunicom.cn>, "mounir@lamouri.fr" <mounir@lamouri.fr>, "public-sysapps@w3.org" <public-sysapps@w3.org>
On Tue, Aug 27, 2013 at 12:13 AM, Marcos Caceres <w3c@marcosc.com> wrote:
> On Friday, 23 August 2013 at 04:05, Xin Sun(联通集团技术部) wrote:
>> We’d like to propose two methods and expect more feedback about the feasibility of adding these functions, to improve the security when invoking some economic related APIs such as SMS.
>> 1. Notification would be provided while top-level applications want to send messages by calling the SMS API. Users may authorize the application to send a single message or deal the permission in batch processing mode, which means that the user has the right to define how many messages could be send out at most each time. The OS then generates only the exact or less number of messages for the application instance as constraint before.

> This appears to be orthogonal to the API (and probably should remain so), as it could even be handled at the OS level: sending an SMS could fail for a number of reasons, but the API itself has no business knowing why the SMS was not sent.

Indeed, it is orthogonal. The API should provide mechanisms and not
policies, but the proposal contains a policy (one of the many which
are possible), which is the decision of the implementations.

Then, these are system API's, so should be no different from any native API's.

The mechanisms that are needed: identify the application/origin, the
feature to be used, and based on the match a policy action is taken
(e.g. seamlessly allow, or ask for user permission, or deny, etc).
Notifying the user is a feasible policy, although not too
user-friendly. It also depends on the service settings, since for
instance the user has a flat rate SMS contract, there is no point
annoying the user by asking all the time for permission.

Therefore, we cannot build in such policies into the API itself.

> > 2. A more complex solution is to cooperate with the SMS gateway device. Actually, this is a post-detection way to estimate whether the application has the malicious behavior of SMS API abusing. After message sending each time, the API would immediately make a request to fetch the actual message number has been sent from network gateway. Warning should be made if the SMS gateway transmitted much more messages than user expectation.
> >
>
> This sounds quite complicated - but I don't know enough about SMS gateways to say if this is feasible or not.

It is feasible by the choice of some implementations, but requiring it
as part of compliance would not work, as there are different SMS
services possible, some of them are web services, some are over LTE,
some over 3G/CDMA. Again, these are system API's and should not need
more paranoid policies than any native API's, and again, we cannot
mandate such hard coded policies in the spec. It is up to
implementations to define the security boundaries and policies. The
Runtime model should just provide the mechanisms.

Best regards,
Zoltan
Received on Tuesday, 27 August 2013 00:49:29 UTC

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