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

Anders,

  Thank you for the suggestion.  I definitely recognize this as a problem
domain in which there is a long history of interest and innovation, but
where no standardized solution has won out.

  However - the WebAppSec WG has just (last week!) completed our
rechartering process. That process took a lot of time and energy, and it
seems unlikely we want to reopen that work immediately.  The group has also
taken on a much larger scope of deliverables than we have yet worked on,
and I think it is prudent to take some time and see how we do and what
adjustments to our work mode are needed to continue successfully before we
expand it further, and into such a controversial area.

  So far, this group has been unwilling to take on vaguely-defined problem
statements. For something to make it into our charter, we typically have
had:

  1) A concrete proposal.  Every new deliverable we adopted this cycle had
a solid unofficial editor's draft when it was proposed.  This helps
participants understand that the work is indeed possible, that the general
shape of the solution is usable and reasonable to implement, and to
understand the scope of IPR commitments they would be agreeing to.

  2) People signed up to "do the work" as Editors, and, ideally,
experimental implementers.

  3) Informal statements of interest by user agent implementers.  Two
independent, interoperable implementations is a charter requirement of the
group to take something to Recommendation, so if no user agent says they
are interested, or worse, if most or all say they are explicitly not
interested in building something, people tend not to be excited about
investing scarce time and energy in something without a clear future.

thank you,

Brad Hill


On Mon, Mar 23, 2015 at 6:24 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

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