Marcelo E. Magallon wrote:
Unlike Firefox'es, epiphany's extensions aren't run in a sandbox[0], are they? And they aren't Javascript, they are full blown binary code, with access to the dynamic loader and whatnot.
I'm actually not sure that Firefox extensions are sandboxed. But yes, Epiphany extensions are capable of doing some very serious damage. If a malicious extension is installed it can do anything the user can do.
The first problem with that is binary compatibility among... well among a whole load of stuff: different Linux architectures, different OSes, different Linux distributions for the same architecture, ...
We have to worry about architecture, Epiphany versions and Mozilla versions. Those will have to be specified in the XML file format I described at the top of this thread, but right now I'm just working on getting something functional. Don't worry -- this stuff is on its way.
The second is more serious: security. This screams Outlookish nightmare. *Please* make installing extensions a very concious decision and provide a highly visible way of *not* allowing them (a "Enable Extensions", default "no", right under "Enable Javascript" would be a start).
I'm not sure a separate pref to disable extensions is really necessary. When an extension is installed it will not be enabled -- the user will have to go enable the extension manually. But most of our efforts, of course, should go towards making it clear to the user that he must trust his extension source.
And in this respect the binary incompatibility situation is a plus: which architecture/Epiphany/Mozilla version will a virus writer choose? He can't choose them all at once. Why not just write an Outlook plugin instead ;).
I'm not all that sure that $HOME-installed extensions will ever become popular, as opposed to distro-supplied extensions and manually-compiled ones. But don't worry, I'm not ignoring security.
-- Adam Hooper adamh densi com
Attachment:
signature.asc
Description: OpenPGP digital signature