возможно ли снижение привилегий в Javascript?

Интересно, можно ли сбросить привилегии в Javascript?

function takeAwaySetTimeout()
{
  var oldSetTimeout = window.setTimeout;
  window.setTimeout = function()
  {
    console.log("not working anymore!");
  };
}


setTimeout("console.log('this works');",0);  // "this works!"
takeAwaySetTimeout();
setTimeout("console.log('this works');",0);  // "not working anymore!"

к сожалению, мне это кажется сложным, так как простой delete window.setTimeout вернет привилегию! Так что для меня это кажется показательным к тому факту, что, к сожалению, Javascript не предусмотрел отнятые привилегии.

Я знаю, что термин привилегия несколько заимствован. Это предыстория вопроса о том, что я мог бы представить себе любую возможность рабочего удаления [Native Code] function (= что метод .toSource() указывает на его функцию, предоставляемую движком javascript) от доступности в какой-то части как способ защитить код, подвергнутый этому ограничение (привилегии отбрасываются) из-за того, что это не является проблемой безопасности.

уточнение

Я приветствую вашу просьбу о большей ясности и надеюсь, что вы ответите на нее ответственно и снимете "свободный" вопрос! Также обратите внимание, что получение уже двух полезных ответов показывает, что есть люди, которые смогли понять вопрос. Тем не менее, конечно, если это возможно (что-то просто нужна предыстория....), я также стремлюсь к расширению понимания.

«Немного неясно, как ограничение доступа к нативным функциям повысит безопасность. Это серверный или клиентский JavaScript?»

1) не имеет большого значения, на стороне клиента или на стороне сервера. Может быть, чуть-чуть важнее кажется, конечно, на стороне сервера. Поскольку, вероятно, существует больше функциональных возможностей (например, запись в файлы, доступ к файлам...), больше, чем, возможно, сможет сделать более ограниченный Javascript внутри браузера (но учтите мощь нового API... и риски!)

2) возможно, выбор для window.setTimeout() [собственная функция] не идеален (для ясности), так как, возможно, не очевидна прямая связь безопасности. Он был использован, потому что он хорошо известен и является заполнителем. см. (3)

3) я полагаю, что каждая функциональность, предоставляемая коду Javascript, амбивалентна. С другой стороны, за, это обогащает "что он может сделать?" положительно и из лучших побуждений код будет использовать его ответственно. Тем не менее, с против, функциональность может означать доступ к вещам, которые при злоупотреблении могут вызвать проблемы, связанные с безопасностью. Примером может служить внешний Javacript, который будет выполнять XHR и отправлять информацию на сервер, потенциально данные, которые имеют личные данные (т.е. состояние здоровья клиентов). Если бы тогда, например, можно было забрать объект XHR лучше window.XMLHttpRequest, шансы на такое злоупотребление были бы ограничены. Откровенно "нельзя стрелять в кого-то, не имея ружья!". Например, XHR (может быть, яснее, чем setTimeout) является таким оружием. Если «ненадежный код» на самом деле не нуждается в XHR, то разумно отказаться от риска, отказавшись от этой привилегии/функции.

4) Я думаю (также в контексте ответов) этот вопрос эволюционировал. Я думаю, что это ясно, но, пожалуйста, напишите комментарий, если это не так. Хотя изначально Юхана сказал:

Это немного неясно[...]

Я понимаю, что это не было полностью неясным, и, следовательно, теперь оно могло быть достаточно ясным (пожалуйста, рассмотрите полезные ответы), чтобы можно было «отложить» / «освободить Вопрос». Кроме того, если вы нашли вопрос достаточно интересным, чтобы придержать его, то сейчас самое время найти его достаточно интересным, чтобы проголосовать за него ;)