Re: The futile war between Native and Web

On 2015-02-16 17:27, Michaela Merz wrote:
>
> Well - there is no "direct" pathway between the browser and the chip card terminal. And .. of course can the user manipulate all of Javascript client-side, eg. patch variables to his liking. But that is true (though harder) for any code that runs client side. The card terminal could provide a rest api that would allow a browser to post the amount to be paid into the terminal. That would be a very safe solution - not only in regard to web, but in regard to any communications with the card terminal as there would be now vulnerable code on the client.

On the web there is no card terminal so it has to be emulated by client code.
Who is supposed to sign this code?  How is it invoked by a web merchant? How it is distributed?
So my discussion has nothing to do about vulnerability of JS.

Anyway, I think we will soon see that Apple simply "calls" their Apple Pay "App" from the web because it preserves all the goodies "as is".
Why is simple and practical wrong?

Anders


>
> mm.
>
>
> On 02/16/2015 10:19 AM, Anders Rundgren wrote:
> > 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
> >> >
> >>
> >>
> >
> >
>
>