You could get round option B though by doing this:

{

if not (_x in (allVariables missionNamespace)) then {
	// add to mission namespace
	missionNamespace setVariable [_x,"someVar"];
	// now it's ok to delete  :)
    profileNamespace setVariable [_x,nil];
};

} count (allVariables profileNamespace);
saveProfileNamespace;

So if it doesn't exist in MNS already, our jerk admin/hacker matey can add it to MNS, and suddenly it's ok to delete.

Forgot to default delete it if it does already exist:

{

if not (_x in (allVariables missionNamespace)) then {
	// add to mission namespace
	missionNamespace setVariable [_x,"someVar"];
	// now it's ok to delete  :)
    profileNamespace setVariable [_x,nil];
} else {
	// delete it anyway cuz we're a jerk
	profileNamespace setVariable [_x,nil];

};
} count (allVariables profileNamespace);
saveProfileNamespace;

Also, option A (the confirm menu) could be abused by script kiddie. Ex:

Script kiddie sends following code to you (by EH/whatever) to spawn on your machine:

while {true} do {
missionNamespace setVariable ["lol", "haha I made your confirm menu pop up"];
profileNamespace setVariable ["lol", "haha I made your confirm menu pop up"];
saveProfileNamespace;
sleep 3;
};

So you get a request every 3 seconds asking to save some variables.

Sorry, I'm not knocking your idea, it's just a hard issue to regulate imo.

Perhaps then the allVariables function should not work with profileNamespace, at least in MP?

I cannot see a legitimate use for 'allVariables profileNamespace'.

That would be better I think. I mainly use it in the editor for diagnostics anyway. I haven't had cause to think of a reason to use it legitimately in MP.

Still there's nothing to stop someone running some missions in the SP editor, compiling a list of variable names, and sending them to you for your PC to erase. (If they really wanted to blank your KOTH variables for instance)

I think that's probably something that could be managed by scripts.txt or another Battleye scan though.

There was some talk of blacklisting certain scripting commands (similar to cfgRemoteExecCommands) via description.ext, so if that ever appears, then you could blacklist it in your MP session.

I still think multiple var files would be better.
Mission keys and GUI setting etc still go to default profile but is locked to anything but access through engine. e.g activateKey etc

If you want a vars file for storing your specific stuff e.g DLRS or VAS or mission variables for a characters stats. Then profileNamespace has to specify a name e.g
( proflieNamespace "DLRS" ) setVariable ["myVar", _myValue];
saveProfileNamespace "DLRS";

Also has the benefit of keeping things separate in case a mod/script corrupts its var file. If you delete a script/mod that you longer need you can also delete its vars file.

ProfileNamespace is still loaded as a amalgamation of all var files and can be queried as such but any saving must be specified to a certain name that creates/updates it own vars file.

I think that allVariables profileNamespace should definitely be possible in single player. Dont take that away. As for multiplayer, sure, make it disabled by default. It is a super useful command for debugging in non security concerning situations.

Awhile ago I did what OP suggested to restore my profile to defaults, it was actually a good thing. Apart from losing custom positions of UI elements what else OP is afraid of losing?

On the top of my head you may lose things like mission progress saved in profileNamespace. Does the Virtual Arsenal save data in profileNamespace? From a quick look I don't think so.

The extent of the damage would depend on what kind of missions the player is playing.

Before this becomes a problem, 2 things need to happen:

1. a hacker needs to remote exec this on every client
2. it has to be worth it in hacker mind

You have to be really desperate to want to delete custom UI settings that user may or may not have and mission progress that user may or may not have, not to mention there is no "hacking epicness or glory" in it.

IMO - this is a non issue.

Today's dev branch:
Changed: profileNamespace and uiNameSpace disabled for allVariables in MP

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2945723&viewfull=1#post2945723

That is great news, thank you BIS/Adam.

Please undo this change
This command was original added to catch hackers, don't neuter it
It can be used by anti-hacks to dump variable info from suspected hackers.

By doing this change you are allowing hackers to store variables in those namespaces that can't be detected.

---------------

Also it is still possible to remote execute a spawn loop that overrides known values.
After than you can then slowly with a loop (and a small sleep in each iteration to stop user noticing) runs through all possible name combinations + overrides the value in the namespace with nil.

--------------

Better solution
Mission author stop storing info clientside or use an extension if its a SP Game.

I would rather scenario designers, admins and kiddies did not have access to my profile, and also clients not have access to the servers profile. What legitimate information is in my profile that you as a hypothetical server admin, need read/write/overwrite access to?

"That is great news, thank you BIS/Adam."

LOL! Disabling allVariables so that hacker cannot read variable names that are *COMMON* variables for *ALL* clients? How is this a solution, if hacker can just with profileNamespace do {{...} foreach commonVarNames}; instead of {...} foreach allvariables profilenamespace;?