Re: The futile war between Native and Web

On 2015-02-16 16:54, Michaela Merz wrote:
> This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care.  The web is THE universal applicable platform for .. well .. everything.  So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing).

On paper it is doable, in reality it is not.

You would anyway end-up with proprietary "AppStores" with granted "Apps" and then I don't really see the point insisting on using web-technology anymore.
General code-signing like used in Windows application doesn't help, it is just one OK button more to click before running.

Anders

>
> I am aware of the old notion, that JavaScript crypto is not "safe". But I say it *can*' be.  CSP is a huge leap forward to make the browser a safe place for the handling of confidential data.
>
> Michaela
>
> On 02/16/2015 03:40 AM, Anders Rundgren wrote:
> > On 2015-02-16 09:34, Anne van Kesteren wrote:
> >> On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton <noloader@gmail.com> wrote:
> >>> 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.
> >>
> >> What would you suggest instead?
> >>
> >>
> >>> 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), ...
> >>
> >> So you would like physical storage on disk to be segmented by eTLD+1
> >> or some such?
> >>
> >> As for the certificate issues, did you file bugs?
> >>
> >>
> >> I think there definitely is interest in making the web suitable for
> >> this over time. It would help if the requirements were documented
> >> somewhere.
> >
> > There are no universal and agreed-upon requirements for dealing with
> > client-certificates which is why this has been carried out in the past
> > through proprietary plugins.  These have now been outlawed (for good
> > reasons), but no replacement has been considered.
> >
> > There were some efforts recently
> > http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/
> > which though were rejected by Mozilla, Google and Facebook.
> >
> > And there we are...which I suggest a "short-cut":
> > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/0000.html
> > which initially was pointed out by Ryan Sleevy:
> > https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/0000.html
> >
> > Anders
> >
>
>

Received on Monday, 16 February 2015 16:19:52 UTC