Am in a hurry so just quick in passing:
I do see the dangers of macros/extensions in the installation already. It may be true that KM is not yet popular enough or not interesting enough for more intelligent bad guys, but frankly, every kid can do it, and there are tons of evil idiots out there. And the first one could already badly damage the whole project. Just imagine anyone uploading a malicious macro to the wiki (maybe with an external download link, or just plain certain dos commands in the displayed kmm text to copy, that most users won't notice), shortly after a clueless user installs it and - BANG...
But fully agree that it must be possible to customize at least skins!
no no no, it's not like that..this can never happen. macros are text files.. kmeleon does not have a special mime association for kmm files. in other words..they are not like xpi service and firefox where clicking an xpi link executes a remote installation.. a macro link with a kmm extension in kmeleon will merely trigger a save or download prompt like an other file. the only way a macro will be saved in the macros folder is with consent, the user will choose to save that file and this is not the case in the macros wiki regardless of km popularity.. the wiki displays the macro and the user copies it to a manually created kmm..then saves it to the macros folder so even if that folder any folder in kmeleon is restricted, the user will have to allow access first so we go back again to the first question:
can a macro pose a security risk if its folder is granted access?
the answer is no.
for a macro to pose a security risk those conditions must be met:
1- a macro can be installed online without permissions or user consent or in the background
2- a macro can instantly carry a payload once it has been installed
3- a macro can be modified or replaced with malicious code remotely by scripts on a website
4- a macro has to be a dynamic file, meaning kmeleon can accept realtime modifying on a kmm file and apply the changes instantly
those 4 conditions are impossible and can never be met unless the code of both kmeleon and the macro engine are changed to allow it9i.e. dorian and kko makes changes to accommodate such features like xpi service)
the bottom line is, security-wise; it doesn't make any difference whatsoever whether the kmeleon root folder is restricted or not
if keeping the folder locked didn't affect how a user can customise and essentially how kmeleon functions, then it wouldn't matter.. like for example a browser like firefox, where all it's editable files, chrome.css and its extensions are all saved in the profile.
but in kmeleon many editable files are in the root..almost all of them so it's not just skins.. kmeleon has menu entries to access all its cfgs..menus, icons, accels, commands..all of them are accessible from within kmeleon, if keeping the folder locked or restricted then what's the point of those entries? the user is not allowed to edit them and they just become for show..look you change accels or toolsbars with those files, but sorry..you can not edit them..you can only view them??
let's not get paranoid like microsoft, in every piece of software as simple as a notepad there can be a security risk if the user doesn't know what they are doing.. let's not turn kmeleon into a nanny browser and even that won't be true..it will be just restricting kmeleon without any security advantages and no one wants to see users coming in complaining about not being able to follow the documentation in customising and the problem will always be the restricted rights.. we 've already seen the beginning of that with settings not saved on vista and 7 with single user installation.