Google chrome & native client

Ко всеобщему удивлению, Chome вышел из беты. Все были готовы, что бета будет длиться вечно, как у gmail. Но, понятно, что компо-продАвцы не хотят пред-устанавливать бету на enterprise, а потому пришлось срочно зарелизить. Хотя качество вполне достойно первой версии. RSS, autofill, extensions (включая adblock), native linux and mac versions обещаны. Не слишком заметно произошло появление ещё одного любопытного проекта: native client. Как я понял из анонса, это addon, дающий возможность запускать native code, т.е. программу в машинных кодах из браузера. Все сразу закричали ActiveX и были в корне неправы. В данном случае native code не сможет сделать ничего плохого, в отличие от Active-X, который может всё, из за предварительной верификации кода. Статический анализ кода - вещь популярная (см. например Midori), но готовых решений я пока не видел. Предполагается, что код не будет иметь возможности обращаться к платформе, но сможет работать с предоставленными ему интерфейсами браузера. Поэтому он будет независим от операционной системы, а зависим только от вида процессора. С точки зрения Web-а, это примерно как адобовский flash, только, возможно, быстрее (хотя сравнимо, я полагаю, с будущей 10 версией, если там LLVM). Но реальный смысл появляется, если рассмотреть браузер как платформу. Если запустить браузер поверх некоего мини-ядра, получается полная платформа, которая может запускать приложения, причём работающие с нормальной скоростью. Вот вам и Google OS. Второй смысл этой штуки - это серверные приложение в "облаке". Сейчас у них поддерживаются только Python и Ruby, а с этой штукой добавляется куча нормальных компилируемых языков. Изолированный код легко перемещать и копировать в облаке. Почему мне всё это понравилось? Во первых, потому, что я всегда считал, что модель безопасности должна исходить из ограничения того, что может сделать компонент кода, а не абстрактного "юзера". Я доверяю себе, как "юзеру", но я не доверяю конкретному компоненту кода. А сейчас код, откуда бы он не появился, автоматически может сделать всё, что может сделать "юзер". Во вторых, это может привести к появлению бинарного выполняемого формата, который имеет чётко описанный внешний интерфейс, и в то же время независим от операционной системы. Что давно, уже лет двадцать, ждёт всё прогрессивное человечество. По поводу статического анализа, это непросто в современной архитектуре, где данные и программы перемешаны в памяти. В байт-коде это значительно проще, но хорошие оптимизирующие компиляторы байт-кода, во первых сложны, во вторых, медленны и не защищены от ошибок. Многие, в результате, предпочитают проверять сгенерированный код, особенно если в него добавить некоторые подсказки, (интересующиеся могут погуглить "typed assembler"). Анализатор дизассемблирует код и проверяет все инструкции восстанавливая логику программы, проверяя типы всех операндов, допустимые смещения и т.д. Любой код, который может сделать что-то не то, не будет допущен до выполнения. А сделать можно многое, например, изменить адрес возврата из стека, что выглядит в точности как целочисленное присваивание локальной переменной. Анализатор должен определить не выполняя программы, что по этому смещению нет переменной, а расположен адрес возврата. И многое другое.