Re: Food for thought (resurfacing)

On Tue, Jul 29, 2014 at 6:58 PM, Noah Mendelsohn <nrm@arcanedomain.com>
wrote:

>
> On 7/29/2014 8:57 PM, Alex Russell wrote:
>
>  Today, we know that TCO on a non-auto-updating windows computer managed by
>> a central administrator is many times that of an equivalently spec'd
>> auto-updating ChromeOS device.
>>
>
> ...and you've demonstrated that what percentage of that claimed TCO saving
> is due to auto-update?


Well, it's hard to separate the long-term impact of verified boot from
auto-update from agressive sandboxing. What we do know is that even
well-designed sandboxes develop holes. We've seen this over time, and our
biggest mitigation for that is ensuring that we can get patches out faster
than the bad guys can pwn boxes and repair owned boxes automatically. We're
not running randomized trials on users about this -- it would be unethical
to deprive them of sandboxing or auto-update now that we know how effective
they are -- but there are natural comparison points. OSes with
slowly-updating software (which is the natural consequence of adding
friction to updates, updates which users -- even admins -- are rarely in a
position to reason about) are owned more frequently, incur higher operating
costs in the form of mitigating software (bit9, AV, firewalls, etc.), even
when running auto-updating software like Chrome.

I don't think we've published comparative numbers on this point, however.


> Could it also be due to the fact that the architectures of the systems are
> tremendously different,


They're really not. ChromeOS is Linux-derived.


> the levels of functions provided by the systems are tremendously
> different,


Onus is on you to quantify this...and for us (the W3C and browser vendors)
to shrink any capability gap to zero (excepting insecurities, of course).


> the level of end user configurability e.g. for unusual attached devices as
> much different, etc.
>

Chrome Apps and FirefoxOS apps allow programmatic connection to serial
ports, USB, and many other sorts of "unusual attached devices". No, we're
not in a world of downloading the drivers to the latest soundblaster card,
but then most systems from most manufacturers are integrated to at least
that point today.


> I think you're over-simplifying the argument as least as much as you
> suggest Larry is. I still say it's a tradeoff: auto-updates done right on
> certain systems are likely to improve security. I've also seen updates that
> compromised security, and in an auto-update environment you're delegating
> the responsibility for ensuring that such updates aren't activated. I
> really think this is a complex tradeoff: yes, there can be significant
> advantages in security and for other reasons when auto-update is done; is
> there any contradiction in also saying that there can be significant
> disadvantages.


No, but I didn't claim that there weren't both theoretical and practical
disadvantages. Only that they're vastly outweighed by the advantages.


> I still think it's a tradeoff and that the cost/benefit depends on the
> system, who's creating the updates, what the threats are, etc., etc., etc.


> Noah
>