[79115] in cryptography@c2.net mail archive
Re: One Laptop per Child security
daemon@ATHENA.MIT.EDU (Shawn Willden)
Thu Feb 8 16:03:07 2007
From: Shawn Willden <shawn@willden.org>
To: Metzdowd Crypto <cryptography@metzdowd.com>
Date: Fri, 9 Feb 2007 07:23:25 +1100
In-Reply-To: <20070208184249.GS28618@binky.Central.Sun.COM>
X-IntraPower-MailScanner-From: shawn@willden.org
--nextPart2114200.m4sCSyqNFf
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Friday 09 February 2007 05:42, Nicolas Williams wrote:
> On Thu, Feb 08, 2007 at 06:32:44PM +1000, James A. Donald wrote:
> > In this OS, instead the
> > editor asks trusted code for a file handle, and gets the
> > handle to a file chosen by the user, and can modify that
> > file and no other.
>
> If this means pop-up dialogs for every little thing an application wants
> to do then the result may well be further training users to click 'OK'.
=46rom what I read, the design is quite careful to avoid that issue -- in f=
act=20
avoiding it is one of the primary design goals.
=46rom the user's perspective, what James was describing will work just lik=
e any=20
normal application -- the user starts the app, selects "Open File", sees a=
=20
file chooser dialog, picks the file he/she wants to work on and=20
clicks "Okay".
Underneath, what happens is that when the application is started, it sees a=
=20
file system that contains nothing but the app and its supporting libraries.=
=20
When the user clicks "Open File", the app requests the service of the OS,=20
which takes care of displaying the file chooser and getting the user's=20
selection. After the user has chosen the file, the OS then maps the file=20
into the app's file system and returns the pathname so the app can open and=
=20
manipulate it.
> The more complex the application, the harder it is for the user to
> evaluate all its access requests (if nothing else due to lack of
> time/patience).
This is true. The OLPC may have an advantage here because its constrained=
=20
environment (128MB RAM, 512MB persistent storage) will force applications t=
o=20
be simpler, just so they fit.
> As for browsers, you'd have to make sure that every window/tab/frame is
> treated as a separate application, and even then that probably wouldn't
> be enough. Remember, the browser is a sort of operating system itself
> -- applying policy to it is akin to applying policy to the open-ended
> set of applications that it runs.
It might be nice to isolate the tabs, but I think the limitations imposed b=
y=20
Bitfrost on the browser as a whole are sufficient to prevent a large class =
of=20
attacks.
Sorry for continuing this non-crypto discussion, but I think it's a very=20
interesting one.
Shawn.
--nextPart2114200.m4sCSyqNFf
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBFy4bEorKsgteyPa0RAjiQAJ9Je+rOvzj5XKXAxG9JLGT4D6PSegCfRZ31
R5LNvApCe1qONbcVn8r3vxs=
=fsAe
-----END PGP SIGNATURE-----
--nextPart2114200.m4sCSyqNFf--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
