Search Mailing List Archives
[liberationtech] Chromebooks for Risky Situations?
tom at ritter.vg
Wed Feb 6 08:30:44 PST 2013
On 6 February 2013 10:52, micah anderson <micah at riseup.net> wrote:
> Can you say what you mean here? What is SOP in this context?
ChromeOS's 'Apps' are all extensions or webpages. One can't interact
with any other do to the standard Same Origin Policy browsers enforce.
It's what stops evilco.com from reading your logged in gmail.com tab
in FF/Chrome/IE/any browser today.
> I would be surprised if you actually 'bricked' these systems, since
> neither operating system you mention involves a procedure that has the
> risk of bricking a device. I suspect this is hyperbole?
Well, I have a colleague rebuilding a FDE Ubuntu computer right now
because we can't figure out how to repair its partition table and get
it to boot without a LiveCD. It's probably possible, but we're pretty
technical people and we made the call it would take less time to
recreate the machine than 'fix' it. Similarly, I recently paid the
gentoo tax while upgrading udev and not having a kernel switch turned
on - wouldn't boot, requiring me to LiveCD it, enable the setting,
recompile the kernel and replace it.
So bricked in the sense of it's now a brick and might as well be sold
for parts - you're right, that's hyperbole. But for a non-technical
person, with no access to someone to repair a machine for him/her - I
don't know, I think it might as well be bricked. They can't fix it on
their own, and it's not going to boot.
>> - Verified Boot, automatic FDE, tamper-resistant hardware
> All of this reminds me of this post:
> which concludes:
> "Some people don't like Secure Boot because they don't trust
> Microsoft. If you trust Google more, then a Chromebook is a reasonable
> choice. But some people don't like Secure Boot because they see it as an
> attack on user freedom, and those people should be willing to criticise
> Google's stance. Unlike Microsoft, Chromebooks force the user to choose
> between security and freedom. Nobody should be forced to make that
I don't disagree with the notion that Chromebooks, Windows 8, iOS, and
other examples make you choose between "Insecure and running your own
stuff" and "Secure and running their stuff". I completely agree with
it. I do disagree with a phrase of your except "Chromebooks force the
user to choose between security and freedom" - I would rephrase it
"Chromebooks force the user to choose between freedom and Google's
My gender-inspecific-nontechnical-family-member is not interesting in
running after-market app stores or tethering apps on their phone, so
if security was the only concern I would recommend iPhone because it
is harder to root. Similarly, if an activist is not going to run
third party apps or 'jailbreak' their device (and nobody is going to
take the responsibility to do it for them and then be full time tech
support) - choosing a more secure, albeit stewarded by Google/Apple,
system makes sense. I know some people don't believe this, and I know
some people (like RMS) say we should always fight the good fight and
never give way...
But if you nailed me down and said "Make a computer recommendation,
someone's life may depend on it." Depending on who their adversary is,
I would probably not make the Free OS recommendation.
On 6 February 2013 10:52, Rich Kulawiec <rsk at gsp.org> wrote:
> On Wed, Feb 06, 2013 at 10:24:28AM -0500, Tom Ritter wrote:
>> - ChromeOS's update mechanism is automatic, transparent, and basically
>> foolproof. Having bricked Ubuntu and Gentoo systems, the same is not
>> true of Linux.
> Concur on this point, and wish to ask a related question:
> Many operating systems and applications and even application extensions
> (e.g., Firefox extensions) now attempt to discover the presence of updates
> for themselves either automatically or because a user instructs them to do.
> Is there any published research on the security consequences of doing so?
> (What I'm thinking of is an adversary who observes network traffic
> and thus can ascertain operating system type/version/patch level,
> installed application base/version/patch level, etc.)
I don't know of any research to point you to.
Obviously any automatic or manual upgrade process is fraught with
peril, as it is essentially designed to be an endpoint for remote code
execution. It would be nice if Google or Microsoft did a case study
on how they architected their update systems. Obviously MSFT's went
screwy with Flame, but I still think there's lessons we can learn.
To Michael's point, how these systems deal with rollbacks and network
isolation is interesting. I've heard that Tor Project's Thandy is an
implementation of a research paper that covers this and other topics,
but I can't find a reference. Maybe someone can find it and provide
On 6 February 2013 11:23, Andreas Bader <noergelpizza at hotmail.de> wrote:
> I think SL, Debian, Suse or CentOS are not less secure than ChromeOS.
> And if there is a secure problem then you have enough control to fix the
I disagree with this. All of those OS (I'm actually not sure of
'SL'?) do not do process isolation. If I get code execution in FF, I
can compromise thunderbird. You are not able to 'fix' this except by
rewriting the OS or doing some jinky hack to run every app as a
separate user. Likewise, every app running is not written to the
quality that Chrome Browser/ChromeOS is. Additionally, the OS and the
applications are stewarded by different people, and the interface
between those groups leads to bugs. Put a $100K bounty on exploiting
a desktop app running in one of those OSs and see how quickly you get
takers. And finally, I think most people who say "you have control to
fix things" forget that the 'you' in this context is a person who does
not write code (python even, let alone c), does not know what a
partition table is, does not compile their own kernel, doesn't even
have a compiler installed, doesn't understand the nuances of security
- and just needs their computer to work.
More information about the liberationtech