[IronPython] DLR, OS X/Linux & other languages
miha.valencic at gmail.com
Fri Dec 26 14:54:19 PST 2008
I "knew" I had that coming. :) It is exactly as you point out + more... but
given the context, I think that we don't need sandboxing in the same way we
don't have sandboxing for <insert downloadable application name>. It would
be nice and UAC can be viewed as a step in this direction (although just for
"admin-required" operations). Management would be harder... but come to
think of it, modern mobile phones have some sort of sandboxing with
different permission sets built into JVMs. (on some devices, you can specify
which operations you allow and you can specify for which operations you want
to be asked every time if you allow them).
Will check the PDC materials, thanks.
I think we're completely off-topic now.... although it's a very interesting
topic so far. :) [redirect to private email?]
To recap: desklet in my opinion is not just sth you download from the web.
It is something which can also be signed and distributed on a CD, you
"install it" like a regular program and launch it. It has access to system
resources (file system, CD drive, audio, camera,...) and whatnot.
It could very well be run in two modes. Sandboxed (same sandboxing as a
browser) and "Free", where it has the same access as every other app on the
With next-gen OSs, we might have sandboxing for every app (like virtualized
environment for the running app -- something like that is possible today
with ThinApp and other solutions), but until then, I wouldn't treat them
differently than any other user-installable applicaiton. The point here is
"user-installable", of course.
2008/12/26 Keith J. Farmer <kfarmer at thuban.org>
> If you think sandboxing is not necessary on the desktop, consider a
> Trojan attack using desklets.
> A buddy of mine in MSN suggests you check out the "Web Sandbox" materials
> for PDC 2008 for backgrounder, and comments that while the desktop used to
> be considered an isolation boundary -- it used to be considered
> fully-trusted. However, we now know this to be foolish, so if you want to
> secure downloaded code you either block things completely, or you go into
> more interesting security.
> I also don't personally consider your "ugly workaround" all that ugly. If
> it makes it more palatable, you could consider it a security scoping
> mechanism, which I think would be a great thing to have in WPF, and just
> have it use Silverlight as an implementation detail.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users