> In practice this has proved to be wrong although the reasons vary from lack > of standards for > the platform feature to support,
I find there are two problems with browser based apps. First is the security model, and second is anemic security opportunities. For the first point, Pinning with Overrides (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect example of the wrong security model. The organizations I work with did not drink the Web 2.0 koolaide, its its not acceptable to them that an adversary can so easily break the secure channel. For the second point, and as a security architect, I regularly reject browser-based apps that operate on medium and high value data because we can't place the security controls needed to handle the data. The browser based apps are fine for low value data. An example of the lack of security controls is device provisioning and client authentication. We don't have protected or isolated storage, browsers can't safely persist provisioning shared secrets, secret material is extractable (even if marked non-extractable), browsers can't handle client certificates, browsers are more than happy to cough up a secret to any server with a certificate or public key (even the wrong ones), ... For medium and high value data, that usually leaves hybrid and native apps. With a high value data and a native app, there's usually non-trivial residual risk that usually forces the app into risk acceptance. > Yet another difficulty is that the browser vendors and "the market" > occasionally have diverging > interests and priorities, leaving the latter lot in a very unfavorable > situation w.r.t. innovation. Guys like me don't have a dog in that fight. We don't care about the bells and whistles. We just want to place security controls commensurate with the data sensitivity level. Jeff On Sun, Feb 15, 2015 at 6:19 AM, Anders Rundgren <anders.rundgren....@gmail.com> wrote: > In theory browsers can support any kind of platform-related function, right? > > In practice this has proved to be wrong although the reasons vary from lack > of standards for > the platform feature to support, to security and trust-models models > involving other parties > than the user and the site connected to. In addition, the concept of > "trusted web code" still > doesn't exist and personally I doubt that it will be here anytime soon, if > ever. Permissions do > not address code trustability either. > > Yet another difficulty is that the browser vendors and "the market" > occasionally have diverging > interests and priorities, leaving the latter lot in a very unfavorable > situation w.r.t. innovation. > > To avoid TL;DR. A browser can do things the native level cannot but this is > equally applicable > the other way round so an obvious solution is "burying the hatchet" and > rather try to figure out > how these great systems could work in concert! Here is a concrete > suggestion: > > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/0000.html >
