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.
Running trusted code in the untrusted web - A writeup
For those who frown at the idea of calling native (trusted) applications from the untrusted web [1], here is a writeup of how you could run trusted web-code inside of a untrusted web-application. Regarding the use-cases, there are many ranging from phone-dialers on support pages to payments [2]. Since you probably do not want to rewrite browsers from scratch, the most logical is building on running trusted code in IFRAMEs so that the existing protection scheme can be reused. The difference with existing IFRAMEs is that the code must be trusted by the platform which also means that it must be fetched from the platform: iframe trustedapp=com.example.PaymentRequest ... /iframe This code should appear to the browser as coming from a virtual domain. The only communication possible is through postMessage(). If the referenced application isn't available in the local cache, the browser should presumably consult the device-specific AppStore. A side-effect of this specification is that trusted web-applications may be device-specific which actually is a plus since it reduces the need to standardize access to the OS and HW layer. That is, there could be a new class of standardized trusted web-applications where only the invoke/postMessage part is standardized! Cheers, Anders Rundgren 1] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html 2] Although not entirely compliant with the above, the following demo https://mobilepki.org/WebCryptoPlusPlus does the same thing from a user's perfective.
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
