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 Wednesday, 19 March 2014 23:14:10 UTC