Re: Charter Addition Proposal: "Trusted Code" for the Web

Am I right in thinking that your proposal isn't about how to declare a
web-delivered piece of code as "trusted", but rather about defining
how to communicate between (untrusted) web code and (trusted) native
code delivered with the hardware or browser?

There's some work going on in that area … Marijn, do you have a good
link for the "communicate with device-specific hardware" idea? Or have
we not really written that down anywhere?

However, the history of letting web pages send messages to "trusted"
native code isn't good. See all the security vulnerabilities around
NPAPI and ActiveX. The "trusted" native code is generally not actually
trustworthy when under attack. It'd be good to hear from WebAppSec
about what kinds of restrictions could make things as safe as
possible. This doesn't need a charter extension since the charter
already includes "provide review of specifications from other Working
Groups".

Jeffrey

On Mon, Mar 23, 2015 at 12:18 AM, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> Trusted Code for the Web
>
> Existing security-related applications like authentication, payments, etc.
> are all based on that a core-part is executed by statically installed
> software that is supposed to be TRUSTED.
>
> Since web-based applications are transiently downloaded, unsigned and come
> from any number of more or less unknown sources, such applications are by
> definition UNTRUSTED.
>
> To compensate for this, web-based security applications currently rely on a
> hodge-podge of non-standard methods [1] where trusted code resides (and
> executes) somewhere outside of the actual web application.
>
> However, because each browser-vendor have their own idea on what is secure
> and useful [2], interoperability has proven to be a major hassle.  In
> addition, the ongoing quest for locking down browsers (in order to make them
> more secure), tends to break applications after browser updates.
>
> Although security applications are interesting, they haven't proved to be a
> driver.  Fortunately it has turned out that the desired capability ("Trusted
> Code"), is also used by massively popular music streaming services,
> cloud-based storage systems, on-line gaming sites and open source
> collaboration networks.
>
> The goal for the proposed effort would be to define a vendor- and
> device-neutral solution for dealing with trusted code on the Web.
>
> This proposal should also be considered as an alternative to permissions for
> system-level APIs like Bluetooth: By using specific external APIs for each
> access-type or service, rich functionality is enabled without necessarily
> bothering users with hard to understand security prompts.  That new APIs can
> be developed by anybody makes this scheme more agile than the "SysApps"
> approach.
>
>
> References
>
> 1] An non-exhaustive list include:
> - Custom protocol handlers.  Primarily used on Android and iOS.  GitHub also
> uses it on Windows
> - Local web services on 127.0.0.1.  Used by lots of services, from Spotify
> to digital signatures
> - Browser plugins like NPAPI/ActiveX.  Used (for example) by millions of
> people in Korea for PKI support but is now being deprecated
> - Chrome native messaging.  Recent solution which enables Native <=> Web
> communication
>
> 2] https://code.google.com/p/chromium/issues/detail?id=378566
>
>
>

Received on Monday, 23 March 2015 18:19:05 UTC