RE: Proposal for an Application Management API

Ok, thanks Marcos.

Yes, there are really sensitive system level APIs, such as Telephony and Application Management for which "super privileged" access rights are required. We can always discuss if it is worth the effort to standardize APIs that are available to a very limited group of developers but if it helps interoperability and if the API design is good it is probably worth the effort.

Other SysApps APIs, TCP and UDP, contacts, etc, are still sensitive but could probably be exposed to a larger community of web developers through appropriate security mechanisms. Either using web security mechanisms or through packaging the app in a native app container and trust the security framework of the target platform, a la Cordova. 

Nice to hear about your discussions on the TCP/UDP socket API as a web platform API using the web security mechanisms. I am happy for any further information on this topic.

BR
  Claes 



Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com

sonymobile.com



> -----Original Message-----
> From: Marcos Caceres [mailto:w3c@marcosc.com]
> Sent: den 20 mars 2014 00:14
> To: public-sysapps@w3.org; Nilsson, Claes1; Kostiainen, Anssi
> Cc: Sato, Naoyuki (TDG); Isberg, Anders; Igarashi, Tatsuya; Falk,
> Mattias; Jovanovic, Zoran
> Subject: RE: Proposal for an Application Management API
> 
> 
> 
> On March 19, 2014 at 6:44:20 PM, Nilsson, Claes1
> (claes1.nilsson@sonymobile.com) wrote:
> > > I really like the idea of having only one type of web application
> > and web execution environment and having all APIs available to all
> > developers. However, I don't think it is realistic to assume that all
> > APIs are available to all web developers. How are you seeing other
> > SysApps APIs, for example the Telephony API? Access to certain APIs
> > has to be limited to apps that are by some methods considered to be
> > trusted.
> 
> Sure, or they don't have to be exposed or implemented in JS at all.
> It's just fine to have a lot of these things be system/native services
> that a web application calls into (either through an API, like
> something resembling web intents - or through a URL, like `tel:` or
> `ams:`). But having "telephony" as a black box seems fine to me, given
> all the security restrictions, privacy issues, and need to have it be
> something super privileged (thus can happily be implemented in c++,
> rust, or whatever ... or even in JS, but it's unlikely browser vendors
> will ever share/run one another's dialers).
> 
> > This trust may not have to be achieved through a specific web
> > execution environment if we can find a way, within "the normal
> > browser" to use existing security mechanisms such as TLS and CSP to
> > prevent misuse of sensitive APIs.
> 
> Sure. This is something we need to research.
> 
> > So we need a concept of trusted web applications and I like the idea
> > of hosted, not packaged, trusted web apps.
> >
> > Which is your view on the security issues with providing sensitive
> > APIs such as Telephony, TCP and UDP Sockets and Application
> Management?
> 
> Basically that we need to pick our security battles based on services
> and applications that we want to build. For example, it is possible to
> print from browsers without needing to have a "print API" (the same
> applies to telephony). Even if we were to do a privileged API like
> TCP/UDP and Application Management, we need to be realistic about how
> much that code can be shared across runtimes. OR the API design is so
> good that all of us would benefit from it being standardized even if we
> can't put it on the Web (currently where TCP/UDP potentially sits with
> it being built on top of WHATWG Streams).
> 
> A little off topic, but the people that I've spoken to about TCP/UDP
> sockets are quite excited to see if we can make that a web platform API
> somehow (i.e., one that does play nice with the web security model).
> There is a lot of work to be done there, obviously. But I think we have
> the right mix of people to hopefully find a way to make that happen.
> 
> 
> 
> 
> 
> 
>

Received on Thursday, 20 March 2014 12:54:18 UTC