Спасёт от теоретической возможности утечки данных чужих сайтов с использованием атаки Spectre из JS на каком-нить сайте. Разве что сам у себя сайт сможет что-то подглядеть случайно :)
Meltdown и Spectre — разные уязвимости. Возможность что-то сделать из JS заявлена только для Spectre (и то, судя по всему, целенаправленно получить какие-то полезные данные именно с использованием JS там практически нереально). Для Meltdown такого не заявлено.
В моём изначальном сообщении, на которое вы ответили, я указал, что JS не даёт возможности обратиться за данными по произвольному указателю. Нет такой операции как класс. Вы привели пример совершенно не в тему, поскольку у вас запускается нативный код, у которого проблем с использованием произвольных указателей нет.
Во-первых, рабочего кода там нет. Там есть только вот эти 5 строк, которые лишь маленький кусочек необходимого кода (содержимое остального кода там описано словами и очень примерно):
if (index < simpleByteArray.length) {
index = simpleByteArray[index | 0];
index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
localJunk ^= probeTable[index|0]|0;
}
Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи. В-третьих, не заявлено, что можно целенаправленно прочитать всю память своего процесса из JS. Как я вижу, с использованием этой методики максимум могут быть сделаны выводы о содержимом каких-то случайных блоков памяти своего процесса, в зависимости от того куда при выполнении JS была физически помещена переменная массива.
Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.
Больше похоже на заявление от представителей жёлтой прессы. Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступны. В общем, или покажите рабочий пруф, или не распространяйте сомнительную информацию и не нагнетайте бесполезную панику.
FASMG в принципе можно обучить собирать под любую платформу, потому что набор инструкций там — это просто макросы. То есть x86 и всё остальное там реализовано просто наборами макросов. PE-файлы и таблицы релоков тоже формируются на макросах.
Вы опять мимо. Quantum Render — это не про поддержку каких-то свойств в CSS. Это более низкоуровневый компонент, который браузер использует для «сборки» конечной картинки. Цитата:
The goal of the Quantum Render project is to take the WebRender compositor in Servo and embed it in Firefox. It will replace Gecko's existing compositor, interfacing with Gecko's main-thread layout code. As WebRender is written in Rust and uses a very different design approach, we expect to get stability and performance benefits from this switch.
Вам стоило бы немного немного разобраться в тех вещах, о которых вы пытаетесь говорить. На этом я завершаю разговор с вами, ибо уже очевидно, что продолжать его нет смысла.
UTF-8 как локаль для консоли не работает по-моему до сих пор. Но утверждать не буду.
Кстати, в Microsoft рассматривают вариант обучения рантайма работать в UTF-8. И вы можете поставить свой голос там (и тут тоже). Идеальным был бы вариант, если бы ещё и все *A функции из Win32 API научились бы понимать UTF-8 как одну из локалей (которую программа выбирает сама себе при загрузке, например). К сожалению, сильно надеяться на такой вариант расширения Win32 API не приходится.
Во-первых, по ссылки ничего не написано про firefox — и это ясно и понятно, ведь вы ничего мне не показали, и не покажете. Во-вторых, что за привычка такая — болтать и не показывать?
Похоже, что вы всё же не читали что там написано. А там чётко сказано:
This is the first big technology transfer of Servo tech to Firefox. Along the way, we’ve learned a lot about how to bring modern, high-performance code written in Rust into the core of Firefox.
We’re very excited to have this big chunk of Project Quantum ready for users to experience first-hand. We’d be happy to have you try it out, and let us know if you find any issues.
Firefox's new parallel CSS engine — also known as Quantum CSS or Stylo — is enabled by default in Firefox 57 for desktop, with Mobile versions of Firefox to follow later on. Developers shouldn't notice anything significantly different, aside from a whole host of performance improvements.
По второй ссылке, где описывается следующий компонент, почти готовый к внедрению (Quantum Render), чётко сказано, что оно ещё не в релизе, но войдёт в него в скором времени:
But there’s another big piece of Servo technology that’s not in Firefox Quantum quite yet, though it’s coming soon.
Не вижу причин не верить Mozilla и здесь.
Я уже сказал, что серво не умеет в css
Как же он тогда работает? Quantum CSS не занимается рендерингом вообще. Он занимается разбором CSS и быстрыми ответами на вопрос какие из правил применимы к каждому из тысяч элементов на каждой странице. Это всё что он делает. Если демка Servo (которая действительно очень сыра) не может отрендерить какое-то правило правильно — это не вина этого компонента. Он не отвечает за это.
Думаю, если задаться целью, то можно станцевать как-нибудь так, и таки получить возможность устанавливать старые расширения в обычных релизных версиях браузера.
Во-первых, менеджер памяти может выгружать из RAM неиспользуюмую память только страницами, по 4 килобайта. То есть если по коду разбросано много вот таких вот блоков «if», и все они не слишком велики — то большая часть этого кода всё равно будет оставаться в памяти.
Во-вторых, кода, который занимался загрузкой старых расширений, там не так много. Представьте себе HTML-документ, в который вы динамически подключаете дополнительные скрипты, которые меняют поведение этого HTML-документа как им вздумается. Вот примерно так и работали старые расширения. Код, который загружал их — крошечный, по сравнению с остальным кодом браузера. Погоды он не делает. Расширения сами по себе могли сильно замедлять работу браузера (особенно самые старые, которые работали с интерфейсом браузера через синхронные вызовы), но не сам код их загрузки.
К слову, этот код загрузки старых расширений на самом деле даже не отключён. Это я дезинформировал вас. Он работает. Ему просто запретили загружать пользовательские расширения. А вот расширения, подписанные самой Mozilla (не addons.mozilla.org!) — работают, и Mozilla этим пользуется для расширений, которые нельзя сделать средствами WebExtensions. Подробности вот тут, смотрите «legacy extension», как видите даже в обычных релизах они доступны, но только для расширений от самой Mozilla.
Обе ссылки про Firefox. Mozilla переносит некоторые наработки из Servo в Gecko, и обозвали этот проект Quantum. Если бы вы прочитали хоть немного то что по ссылке, то поняли бы, что это это не только про парсинг. Это ещё и про быстрый ответ на вопрос «нужно ли применять это правило для этого вот элемента?», которое браузер задаёт этому движку CSS каждый раз при каждом рендеринге любого элемента на странице. Там же объясняется почему этот процесс не так тривиален, как кому-то могло бы показаться.
Ну да, 65535 кодпоинов оказалось маловато. В последнем стандарте уже 136755 символов. Текущая схема кодирования UTF-16 позволяет использовать до 1112064 кодпоинтов.
Старые расширения имели доступ ко всем потрохам браузера (никакого стабильного внешнего API не было), и это связывало разработчикам браузера руки. Поэтому сейчас, во время больших внутренних изменений в браузере, они отключили поддержку старых расширений. На самом деле она ещё имеется в браузере, и в ночнушках (и Developer Edition) можно активировать её обратно. Но разработчики сейчас активно выпиливают старые технологии из браузера. Например, вот прогресс по выпиливанию XBL-компонентов из браузера. Как видите, подавляющее большинство всё ещё на месте. Такие изменения не делаются за одну ночь. Тут возможно на несколько лет работы. Но на данный момент поддержка старых расширений отключена искусственно. Код их поддержки и всех соответствующих технологий (XUL, XBL) всё ещё в браузере. Впрочем, это не они замедляли работу браузера. Их выпиливают просто для унификации и упрощения движка. XBL заменяют на стандартные Web Components, а XUL заменяют на HTML. Вот когда XBL и XUL не останется внутри кода интерфейса браузера — тогда их поддержку можно будет убрать из кода движка. Но это случится не так скоро.
А вот 50% времени разработки на 50% скорости — редкость. Тому же скайпу 50% не помогут — он все равно будет тормозить.
Если прирост производительности будет 50% за год разработки даже с 75% замедлением появления новых фишечек из-за этого, то глядишь за столько лет сколько он тормозит — им стало бы приятно пользоваться. И кто-то даже может быть начал бы рассматривать его как адекватный мобильный IM. А тормозит он с самого появления в 2010 (говорю про версию под Android).
Не вижу причин, почему UTF-16 мог бы быть оптимальнее. С первыми версиями стандарта Unicode казалось, что UTF-16 удобнее, потому что один кодпоинт гарантированно занимал 2 байта. Можно было легко получить длину строки из количества занимаемых ей байт, нельзя было случайно обрезать строку посреди символа. Но так как теперь один кодпоинт в UTF-16 может занимать и 4 байта, то эти преимущества исчезают. Зато появляется зависимость от порядка байт и повышенный расход памяти.
Я лично сравнивал Firefox 52, PaleMoon и Firefox 57. Всё без расширений. Firefox 57 был ощутимо проворнее. Обратное, думаю, можно будет увидеть на слишком старых машинах — требования к RAM, конечно же, несколько подросли. Накладные расходы на поддержку нескольких процессов.
Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи. В-третьих, не заявлено, что можно целенаправленно прочитать всю память своего процесса из JS. Как я вижу, с использованием этой методики максимум могут быть сделаны выводы о содержимом каких-то случайных блоков памяти своего процесса, в зависимости от того куда при выполнении JS была физически помещена переменная массива.
Впрочем соглашусь, что за исключением очень редких случаев, писать прямо на асме нет смысла.
Более того, в описании новшеств Firefox 57 также чётко упоминается, что Quantum CSS уже в Firefox:
По второй ссылке, где описывается следующий компонент, почти готовый к внедрению (Quantum Render), чётко сказано, что оно ещё не в релизе, но войдёт в него в скором времени:Не вижу причин не верить Mozilla и здесь.
Как же он тогда работает? Quantum CSS не занимается рендерингом вообще. Он занимается разбором CSS и быстрыми ответами на вопрос какие из правил применимы к каждому из тысяч элементов на каждой странице. Это всё что он делает. Если демка Servo (которая действительно очень сыра) не может отрендерить какое-то правило правильно — это не вина этого компонента. Он не отвечает за это.
Во-первых, менеджер памяти может выгружать из RAM неиспользуюмую память только страницами, по 4 килобайта. То есть если по коду разбросано много вот таких вот блоков «if», и все они не слишком велики — то большая часть этого кода всё равно будет оставаться в памяти.
Во-вторых, кода, который занимался загрузкой старых расширений, там не так много. Представьте себе HTML-документ, в который вы динамически подключаете дополнительные скрипты, которые меняют поведение этого HTML-документа как им вздумается. Вот примерно так и работали старые расширения. Код, который загружал их — крошечный, по сравнению с остальным кодом браузера. Погоды он не делает. Расширения сами по себе могли сильно замедлять работу браузера (особенно самые старые, которые работали с интерфейсом браузера через синхронные вызовы), но не сам код их загрузки.
К слову, этот код загрузки старых расширений на самом деле даже не отключён. Это я дезинформировал вас. Он работает. Ему просто запретили загружать пользовательские расширения. А вот расширения, подписанные самой Mozilla (не addons.mozilla.org!) — работают, и Mozilla этим пользуется для расширений, которые нельзя сделать средствами WebExtensions. Подробности вот тут, смотрите «legacy extension», как видите даже в обычных релизах они доступны, но только для расширений от самой Mozilla.
hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo
hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank
Старые расширения имели доступ ко всем потрохам браузера (никакого стабильного внешнего API не было), и это связывало разработчикам браузера руки. Поэтому сейчас, во время больших внутренних изменений в браузере, они отключили поддержку старых расширений. На самом деле она ещё имеется в браузере, и в ночнушках (и Developer Edition) можно активировать её обратно. Но разработчики сейчас активно выпиливают старые технологии из браузера. Например, вот прогресс по выпиливанию XBL-компонентов из браузера. Как видите, подавляющее большинство всё ещё на месте. Такие изменения не делаются за одну ночь. Тут возможно на несколько лет работы. Но на данный момент поддержка старых расширений отключена искусственно. Код их поддержки и всех соответствующих технологий (XUL, XBL) всё ещё в браузере. Впрочем, это не они замедляли работу браузера. Их выпиливают просто для унификации и упрощения движка. XBL заменяют на стандартные Web Components, а XUL заменяют на HTML. Вот когда XBL и XUL не останется внутри кода интерфейса браузера — тогда их поддержку можно будет убрать из кода движка. Но это случится не так скоро.