Re: The futile war between Native and Web

> 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.net@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
>

Received on Sunday, 15 February 2015 21:59:48 UTC