Re: [9fans] Inferno plug-in security

[anothy@cosym.net]

anssi wrote:
//Certainly, you are right.

oh, good.

//But the first and easy step for Inferno plug-in security is to let the Web
//browser user decide, what "objects" are bound to the name space.

i guess. i don't relly have any opinion as to which is more important or
should be there first, authentiction or authorization. it doesn't seem like
building a namespace defined per-module is really useful without reliably
knowing who that module is. well, there's always a default case, but as i
said earlier, that either ends up being too restrictive or too permissive.

still, you are correct in that the 'build a namespace' part of the problem is
an effective way to address the authorization issue, is a needed step, and
is probably more easialy solved.

eric wrote:
//...you are addressing a situation like a web page which may have all
//kinds of unknown modules...

yes, that's one example. but even a web page with one module has the
same issues behind it.

//...then i don't believe that signing is security. just because the module
//came from microsoft and was signed with the super-private microsoft
//key, doesn't mean that the module doesn't do things that you don't allow.

oh, more acuratly, if it came from microsoft, it probably means it _does_
do things i don't like. ☺ but sure, we don't want to allow _any_ module
signed by _anyone_ to do _anything_, just because it's signed. but i
probably trust modules written by me to do pretty much anything - make
network connections, write to my display, access local files, whatever.
same with modules written by VN, the Labs, or a few other individuals. on
the other hand, i probably don't trust modules from M$ or people i've
never heard of to do much - say, no network connections, no looking at
local files. in order to tell which permissions to use - which sandbox to
construct - i need to know who i'm dealing with.

of cource, this is much harder than simply defining a restrictive sandbox
for all modules to play in (which is basically what we've got now). maybe
a simpler alternative would be that when loading a module, a box pops up
with a series of check boxes for things like "make network connections"
and "access local files", determining what this module can do? simpler
than the user constructing a custom namespace for each module.
-α.