Re: The futile war between Native and Web

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

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
>