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