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
On 2015-02-16 18:07, Anne van Kesteren wrote:
On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren
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
On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren
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 compariso
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
clie
On Mon, Feb 16, 2015 at 11:19 AM, Anders Rundgren
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
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 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 p
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 car
On 2015-02-16 09:34, Anne van Kesteren wrote:
On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton 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
On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton 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
On Mon, Feb 16, 2015 at 3:17 AM, Florian Bösch wrote:
> On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton 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 at
On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton 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 is
On Mon, Feb 16, 2015 at 2:15 AM, Florian Bösch wrote:
> On Mon, Feb 16, 2015 at 8:09 AM, Anders Rundgren
> 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
On Mon, Feb 16, 2015 at 1:48 AM, Florian Bösch wrote:
> On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote:
>>
>> 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 contr
14 matches
Mail list logo
