Search Mailing List Archives
[liberationtech] Chromebooks for Risky Situations?
unclezzzen at gmail.com
Wed Feb 13 02:22:39 PST 2013
> 2. Abandon all-singing all-dancing applications. They're enormous.
> They use massive code bases which in turn use massive libraries. And to
> borrow from the quoted passage above, they make it harder to peek under
> the hood. So: no GUI. Don't tell me it can't be done -- I've done
> it. Anyone who can use Thunderbird can use mutt, for example. And given
> the enormous reduction in attack surface as well as required system
> resources, this effort should go as far as possible.
Even if "the average activist" could master mutt (I use it regularly, and
feel like a noob :) ), it only applies to devices that have a keyboard.
If we're talking about phones and tablets (not many people carry a notebook
in a demonstration, when they witness violence, etc.), GUI is not a nicety.
GUI should be as streamlined as possible, and this means html-based (like
Mozilla's B2G), but it's not easy to minimize the attack surface:
fine-grained permissions for everything.
- Interface with low-level services (e.g. telephony, address book),
subject to strict permissions (e.g. notepad doesn't need gps)
- Most important: enable users control over these complex permission
systems in a way that is not too complex (that's the hard part, because
these things *are* complex)
- Also important (and missing in existing platforns): ability to log how
these permissions are used (e.g. cloud storage service has permission to
access network. does it also do it when it wasn't supposed to?). End users
aren't supposed to understand the data they log, but they *should* be
able to generate forensic logs and submit them to geeks/orgs they trust for
inspection. Of course - we shouldn't allow remote activation of logging,
and this functionality should be password protected :)
> 3. Abandon the idea of application installation, updates, etc. These
> mechanisms present an attack surface. So don't have them, period.
> Make the entire distribution, OS and applications, one monolithic
> self-contained entity. No app downloads. No updates. No choices.
> (Of course this is additional motivation to make it as small as possible.)
> You want a new version? Then you get a new version, in its entirety.
There are too many use cases:
If a community decides to use alternatives to social media like ostatus or
they need such an app. If they don't - they shouldn't have it on their
phones (less is more secure).
Does this mean that each such community needs a local distro?
What happens if there's a security upgrade of one of the apps, does
everyone upgrade the entire distro?
This could make zero-day last a lot longer.
What if an activist is a member of 2 communities (one uses ostatus, the
other - gnu concensus).
Does she need a custom distro? Who would maintain it?
This could also stifle innovation. Suppose someone invents a new app (e.g.
broken-cam redundancy storage). They'd have to reach all local "distro
czars" and convince them to add the app, how would the peer-review process
work? We'll end up with Vatican-scale internal politics :)
I agree that freedom also means freedom to shoot yourself in the leg, but
the ability to choose more than a single clearing house (a-la apt sources)
as opposed to a single "who's your daddy" app store (let alone an
monolithic distro) is healthier: Clearing houses don't need to be
responsible for "everything" (e.g. they can specialize in sms, video,
etc.), and users can authorize a minimal set of sources covering their
needs, and then install *some* of what these sources provide (just like apt
Sorry to sound corny, but bazaars still beat cathedrals. This never stopped
being true, it's just that the invention of the "smart" phone raised a
whole generation of users who've never seen a bazaar, and they're the 99% :(
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech