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

On 2015-03-23 19:18, Jeffrey Yasskin wrote:

Hi Jeffrey,

> 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?

Close.  In my take on this, trusted code is supplied in native level applications
that have been specifically vetted for this usage.


> 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".

I would of course be extremely happy if somebody have a few precious cycles to
spend on reviewing a presentation/specification which though does not come from
a WG but from an individual as a response to the failed W3C WebCrypto.Next effort
bringing security hardware in the web: http://webpki.org/papers/web2native-bridge.pdf

It is effectively a souped-up version of Chrome Native Messaging.

Cheers
Anders

>
> 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:41:42 UTC