On 6 February 2013 10:52, micah anderson <mi...@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: > http://mjg59.dreamwidth.org/22465.html > > 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 > choice." 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 stewardship". 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 <r...@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 one. On 6 February 2013 11:23, Andreas Bader <noergelpi...@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 > system. 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. -tom -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
