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.


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.


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 <noloa...@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:
> Anders

Reply via email to