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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
