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

On 2015-03-23 13:30, chaals@yandex-team.ru wrote:
> Hi Anders,
>
> 23.03.2015, 12:29, "Anders Rundgren" <anders.rundgren.net@gmail.com>:
>>   Although permissions have good uses they do not cover the entire spectrum of "system-level"
>>   applications, at least not in a way that makes sense to me:
>>
>>      http://www.sconnect.com/FAQ/#permissionrequest
>
> I think we're hung up on terminology. "Permission" doesn't have to come
 > from a "permission request in the form of a dialogue". Whatever mechanism
 > mediates access is handling permission...

First off, this is a *very complex topic* so please send whatever input or questions
you may have, publicly or privately, and I will promptly answer to the best of my ability.

I may also have been unclear; I'm advocating a system where the "Trusted Code"
is NOT a part of the Open Web.  The latter only "hooks" into this using a not
yet defined mechanism.

If we are talking the Open Web (we do?), we are dealing with untrusted code so
in that case the code may ask for a permission that the user would have to deal
with (per site) in real-time like shown in the example.  I don't see how it could
be done in any other way.

If we return to TLS client certificate authentication, it may be powered by a
smart card, but since the supporting code is a part of the browser platform the
permission system is by definition proprietary.  Existing implementations do
not bother the user with smart card security prompts.  How come? Because TLS
is a *high-level service* rather than a primitive API.  This is where I see
some light in the tunnel.

Cheers
Anders

>
> cheers
>
>>   The proposed scheme would rather enable high-level, service-oriented APIs that mediate access
>>   to sensitive resources (like TLS client certification authentication already do).
>>
>>   Cheers,
>>   Anders
>>
>>   On 2015-03-23 11:30, chaals@yandex-team.ru wrote:
>>>    + dom@
>>>
>>>    This area was intended to be covered by the sysapps "runtime" work [run], but that group never managed to complete it.
>>>    As well as the use cases Anders mentions, many of the features targeted by "the spec once known as powerful features" [power] which is actively developed by this group are executing "trusted" code, although levels of trust vary.
>>>    Various logged discussions [chatter] have taken place at workshops and similalr events that should be mined for anything useful.
>>>    It is certainly in the area of this WG to work on this area. IMHO working out how parts of a web app can become better trusted is not "replacing" the permissions work, but part of it.
>>>    [run] https://github.com/sysapps/runtime - obsoleted by https://github.com/sysapps/app-lifecycle while the sysapps group was alive. The group is (apparently) dead now, the Community Group formed to take this up doesn't seem to do anything (Anders wrote most of the 5 posts in its archive).
>>>    [power] https://w3c.github.io/webappsec/specs/powerfulfeatures/
>>>    [chatter] http://www.w3.org/2014/07/permissions/ - https://www.w3.org/wiki/TPAC2014/SessionIdeas#Trust_and_Permissions_in_the_Open_Web_Platform - find more with yandex </blatantPlug>
>>>    cheers
>>>    23.03.2015, 08:21, "Anders Rundgren" <anders.rundgren.net@gmail.com>:
>>>>    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
>>>    --
>>>    Charles McCathie Nevile - web standards - CTO Office, Yandex
>>>    chaals@yandex-team.ru - - - Find more at http://yandex.com
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>

Received on Monday, 23 March 2015 13:22:45 UTC