Re: The futile war between Native and Web

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.

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
>> >
>>
>>
>
>