Re: The futile war between Native and Web
I am not sure about that. Based on the premise that the browser itself doesn't leak data, I think it is possible to make a web site safe. In order to achieve that, we to make sure, that a) the (script) code doesn't misbehave (=CSP); b) the integrity of the (script) code is secured on the server and while in transit; I believe both of those imperative necessities are achievable. Michaela On 02/19/2015 01:43 PM, Jeffrey Walton wrote: On Thu, Feb 19, 2015 at 1:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Jeffrey Walton wrote: Here's yet another failure that Public Key Pinning should have stopped, but the browser's rendition of HPKP could not stop because of the broken security model: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/. In this story the legitimate user with full administrative access to the systems is Lenovo. I do not really see how actual user agents could have stopped anything here. Timbled agents that act on behalf of someone other than the user might have denied users their right to modify their system as Lenovo did here, but that is clearly out of scope of browsers. -- Like I said, the security model is broken and browser based apps can only handle low value data. Jeff
Re: The futile war between Native and Web
I am not sure about that... Data has three states: (1) Data in storage (2) Data on display (3) Data in transit Because browsers can't authenticate servers with any degree of certainty, they have lost the data in transit state. That leaves a poor choice of options, like side loading on location limited channels. Side loading and location limited channels are not very scalable. Another option is to allow the browser to handle the lower value data and accept the risk. That's what US financial institutions do so they don't lose customers. The final option is to put your trust in the browser platform. That's what many people are happy to do. But its not one size fits all, and it has gaps that become pain points when data sensitivity is above trivial or low. I think it is possible to make a web site safe. In order to achieve that, we to make sure, that a) the (script) code doesn't misbehave (=CSP); b) the integrity of the (script) code is secured on the server and while in transit; I think these are necessary preconditions, but not the only conditions. For what its worth, I'm just the messenger. There are entire organizations with Standard Operating Procedures (SOPs) built around the stuff I'm talking about. I'm telling you what they do based on my experiences. Jeff On Thu, Feb 19, 2015 at 3:55 PM, Michaela Merz michaela.m...@hermetos.com wrote: I am not sure about that. Based on the premise that the browser itself doesn't leak data, I think it is possible to make a web site safe. In order to achieve that, we to make sure, that a) the (script) code doesn't misbehave (=CSP); b) the integrity of the (script) code is secured on the server and while in transit; I believe both of those imperative necessities are achievable. Michaela On 02/19/2015 01:43 PM, Jeffrey Walton wrote: On Thu, Feb 19, 2015 at 1:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Jeffrey Walton wrote: Here's yet another failure that Public Key Pinning should have stopped, but the browser's rendition of HPKP could not stop because of the broken security model: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/. In this story the legitimate user with full administrative access to the systems is Lenovo. I do not really see how actual user agents could have stopped anything here. Timbled agents that act on behalf of someone other than the user might have denied users their right to modify their system as Lenovo did here, but that is clearly out of scope of browsers. -- Like I said, the security model is broken and browser based apps can only handle low value data.
Re: The futile war between Native and Web
On Thu, Feb 19, 2015 at 10:05 PM, Jeffrey Walton noloa...@gmail.com wrote: For what its worth, I'm just the messenger. There are entire organizations with Standard Operating Procedures (SOPs) built around the stuff I'm talking about. I'm telling you what they do based on my experiences. From your arguments though it sounds like they would be fine with buying PCs from Lenovo with installed spyware, which makes it all rather dubious. You can't cite the Lenovo case as a failure of browsers when it's a compromised client. -- https://annevankesteren.nl/
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 3:34 AM, Anne van Kesteren ann...@annevk.nl 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? Sorry to dig up an old thread. Here's yet another failure that Public Key Pinning should have stopped, but the browser's rendition of HPKP could not stop because of the broken security model: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/. Jeff
Re: The futile war between Native and Web
On Thu, Feb 19, 2015 at 6:10 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Feb 16, 2015 at 3:34 AM, Anne van Kesteren ann...@annevk.nl wrote: What would you suggest instead? Sorry to dig up an old thread. Here's yet another failure that Public Key Pinning should have stopped, but the browser's rendition of HPKP could not stop because of the broken security model: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/. That does not really answer my questions though. -- https://annevankesteren.nl/
Re: The futile war between Native and Web
On Thu, Feb 19, 2015 at 12:15 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 19, 2015 at 6:10 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Feb 16, 2015 at 3:34 AM, Anne van Kesteren ann...@annevk.nl wrote: What would you suggest instead? Sorry to dig up an old thread. Here's yet another failure that Public Key Pinning should have stopped, but the browser's rendition of HPKP could not stop because of the broken security model: http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/. That does not really answer my questions though. Good point. Stop letting externalities control critical security parameters unmolested since an externality is not the origin nor the the user. HPKP has a reporting mode, but a broken pinset is a MUST NOT report. Broken pinsets should be reported to the user and the origin so the browser is no longer complicit in covering up for the attacker. Jeff
Re: The futile war between Native and Web
On Thu, Feb 19, 2015 at 4:31 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 19, 2015 at 10:05 PM, Jeffrey Walton noloa...@gmail.com wrote: For what its worth, I'm just the messenger. There are entire organizations with Standard Operating Procedures (SOPs) built around the stuff I'm talking about. I'm telling you what they do based on my experiences. From your arguments though it sounds like they would be fine with buying PCs from Lenovo with installed spyware, which makes it all rather dubious. You can't cite the Lenovo case as a failure of browsers when it's a compromised client. No :) The organizations I work with have SOPs in place to address that. They would not be running an unapproved image in the first place. *If* the user installed a CA for interception purposes, then yes, I would blame the platform. The user does not set organizational policies, and its not acceptable the browser allow the secure channel to be subverted by an externality. I think the secret ingredient that is missing in the browser secret sauce is a Key Usage of INTERCEPTION. This way, a user who installs a certificate without INTERCEPTION won't be able to use it for interception because the browser won't break a known good pinset without it. And users who install one with INTERCEPTION will know what they are getting. I know it sounds like Steve Bellovin's Evil Bit RFC (Aril Fools Day RFC), but that's what the security model forces us into because we can't differentiate between the good bad guys and the bad guys. In native apps (and sometimes hybrid apps), we place a control to ensure that does not happen. We are not encumbered by the broken security model. Jeff
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 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/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren anders.rundgren@gmail.com wrote: 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? Is anyone saying that's wrong? What's wrong is the comparison between native and web. Apple Pay could not have been created through the App Store model either. It's a feature of iOS coupled with the hardware found in the latest iPhone. If we get browsers that operate at the OS level they could deliver similar features. If they don't operate at the OS level they could integrate with what the OS provides. Either way this is something that requires new APIs and UX, whether native or web. -- https://annevankesteren.nl/
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 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/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
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 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/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
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 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/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 11:19 AM, Anders Rundgren anders.rundgren@gmail.com wrote: ... 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. The interesting thing about App Stores and Code Signing is it provides vendor lock-in and maintains revenue streams. So while it has [sometimes] questionable value, its something that we are going to see a lot more of as vendors unofficially use it as a tool to further their internal agendas. Look at how many vendors are supporting Installable Web Apps. Installable Web Apps effectively turns any web server into an App Store. The answer is: Mozilla and Chrome. Jeff
Re: The futile war between Native and Web
On 2015-02-16 18:07, Anne van Kesteren wrote: On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren anders.rundgren@gmail.com wrote: 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? Is anyone saying that's wrong? What's wrong is the comparison between native and web. Well, I have provided a concrete solution for combining native (running trusted code) and web (running untrusted code) which I originally got from Google and is already in practical use. If somebody has a better solution there's huge community out there who is waiting. Anders Apple Pay could not have been created through the App Store model either. It's a feature of iOS coupled with the hardware found in the latest iPhone. If we get browsers that operate at the OS level they could deliver similar features. If they don't operate at the OS level they could integrate with what the OS provides. Either way this is something that requires new APIs and UX, whether native or web.
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 3:17 AM, Florian Bösch pya...@gmail.com wrote: On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton noloa...@gmail.com wrote: I'd hardly consider an account holder's data as high value. Medium at best and likely low value. But that's just me. Of course if the data is compromised it means that an attacker can also remote-control your e-banking interface, and issue payments and so forth. I'm sure that's not high value either? No, that's definitely not high value from my experience with three US financial firms. In US financial, those losses are simply passed on to share holders. Risk is democratized, reward is privatized. Perhaps you should talk to other security architects with experience in financial and see what they have to say. Jeff
Re: The futile war between Native and Web
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. -- https://annevankesteren.nl/
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 2:15 AM, Florian Bösch pya...@gmail.com wrote: On Mon, Feb 16, 2015 at 8:09 AM, Anders Rundgren anders.rundgren@gmail.com wrote: Unfortunately this is wrong and is why I started this thread. Mobile banking applications in Europe are usually featured as Apps. This has multiple reasons; one is that there's no way to deal with client-side PKI and secure key storage in the mobile web. Well Postfinance, Credit Suisse and UBS all have browser based e-banking solutions. Some of them have Apps (usually on iOS/Android) in the app-stores, but these are usually just web-widgets put in a container so they can put it on the store. I'd hardly consider an account holder's data as high value. Medium at best and likely low value. But that's just me. Jeff
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton noloa...@gmail.com wrote: I'd hardly consider an account holder's data as high value. Medium at best and likely low value. But that's just me. Of course if the data is compromised it means that an attacker can also remote-control your e-banking interface, and issue payments and so forth. I'm sure that's not high value either?
Re: The futile war between Native and Web
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/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
The futile war between Native and Web
In theory browsers can support any kind of platform-related function, right? In practice this has proved to be wrong although the reasons vary from lack of standards for the platform feature to support, to security and trust-models models involving other parties than the user and the site connected to. In addition, the concept of trusted web code still doesn't exist and personally I doubt that it will be here anytime soon, if ever. Permissions do not address code trustability either. Yet another difficulty is that the browser vendors and the market occasionally have diverging interests and priorities, leaving the latter lot in a very unfavorable situation w.r.t. innovation. To avoid TL;DR. A browser can do things the native level cannot but this is equally applicable the other way round so an obvious solution is burying the hatchet and rather try to figure out how these great systems could work in concert! Here is a concrete suggestion: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html Sincerely, Anders Rundgren WebPKI.org
Re: The futile war between Native and Web
In practice this has proved to be wrong although the reasons vary from lack of standards for the platform feature to support, I find there are two problems with browser based apps. First is the security model, and second is anemic security opportunities. 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. 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), ... For medium and high value data, that usually leaves hybrid and native apps. With a high value data and a native app, there's usually non-trivial residual risk that usually forces the app into risk acceptance. Yet another difficulty is that the browser vendors and the market occasionally have diverging interests and priorities, leaving the latter lot in a very unfavorable situation w.r.t. innovation. Guys like me don't have a dog in that fight. We don't care about the bells and whistles. We just want to place security controls commensurate with the data sensitivity level. Jeff On Sun, Feb 15, 2015 at 6:19 AM, Anders Rundgren anders.rundgren@gmail.com wrote: In theory browsers can support any kind of platform-related function, right? In practice this has proved to be wrong although the reasons vary from lack of standards for the platform feature to support, to security and trust-models models involving other parties than the user and the site connected to. In addition, the concept of trusted web code still doesn't exist and personally I doubt that it will be here anytime soon, if ever. Permissions do not address code trustability either. Yet another difficulty is that the browser vendors and the market occasionally have diverging interests and priorities, leaving the latter lot in a very unfavorable situation w.r.t. innovation. To avoid TL;DR. A browser can do things the native level cannot but this is equally applicable the other way round so an obvious solution is burying the hatchet and rather try to figure out how these great systems could work in concert! Here is a concrete suggestion: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html
