- From: <chaals@yandex-team.ru>
- Date: Mon, 23 Mar 2015 13:30:17 +0100
- To: Anders Rundgren <anders.rundgren.net@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Cc: Dominique Hazael-Massieux <dom@w3.org>
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... 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 12:30:51 UTC