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: Marcos Caceres <w3c@marcosc.com>
Date: Mon, 26 Aug 2013 17:13:23 -0400
To: "Xin Sun(联通集团技术部)" <sunx5@chinaunicom.cn>
Cc: "mounir@lamouri.fr" <mounir@lamouri.fr>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <9CDFCD5ED4054CEE86862E233547993E@marcosc.com>



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.   
> 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.   
Received on Monday, 26 August 2013 21:13:49 UTC

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