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.merz@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 <derhoermi@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.

Received on Thursday, 19 February 2015 21:05:51 UTC