Comments 84
В плане защиты как минимум, вебом я недоволен целиком. Слишком много векторов атаки, чтобы уверенно сказать, что мы «защищены от самых дешевых атак».
Конечно, это кажется сложнее, потому что надо разрабатывать с нуля. Но рано или поздно количество всяких архитектурных костылей и прослоек достигает критического, или же изначально заложенные идеи начинают слишком уж мешать, и в итоге почти любой проект рано или поздно переписывается с нуля или почти с нуля. Иногда даже не раз. Netscape → Mozilla, Firefox → Servo (возможно), IE → Edge (не полностью с нуля, но уверяют о очень капитальных переделках), DOS/Windows 9x → Windows NT (в контексте ОС для десктопа), Win32 → UWP (или на чём там нынче под вин10 пишут, сильно не слежу), Mac OS 9 → Mac OS X, Blender 2.4 → Blender 2.5 ну и так далее.
Веб кривой до невозможности, с этим трудно спорить. Но заменить его можно только сообща. Либо имея достаточно ресурсов, как у Фейсбука, например. И цель у них может быть соответствующая —
Вот тогда и не будет всяких XSS и нанесения вреда хосту.
да и про доступ к файлам
спрашивает, если надо что то открыть не в своей локальной песочнице и к примеру на внешней флешки то нужны пермишены.
Тольуо увы у Android сейчас 3 разные системы для открытия файлов не из родной директории. :( Это куча костылей для каждой версии андроида.
Вы предлагаете вернуться во времена IE7 опять. Там эта "безопасность" была именно так и реализована. Вместо просмотра страниц тыкаем на постоянно всплывающее окно блокировок.
После десятого-двадцатого запроса "разрешить ли приложению XXX доступ к YYY" у пользователя выработается условный рефлекс, и он будет нажимать соответствующую кнопку быстрее, чем дочитывать до конца текст вопроса.
Даже если окажется разрешённым больше, чем необходимо, это всё равно лучше, чем сейчас.
для пользователей, кто хоть немного разбирается
Под это определение попадает меньше процента пользователей, это раз. Даже те, кто разбирается задолбаются разрешать приложению каждый чих и либо скажут «вот тебе права на всё, только отстань уже», либо снесут к чертям, это два.
А ещё случается так, что автор продаёт своё приложение не очень порядочным людям или сам решает срубить зелени (см. AdBlock с его «заплати и твоя
Хотя пример iOS с «либо ты думаешь как работать с урезанными правами, либо проваливай из магазина» показывает, что да, требовать можно. Иногда.
Даже те, кто разбирается задолбаются разрешать приложению каждый чих и либо скажут «вот тебе права на всё, только отстань уже», либо снесут к чертям, это два.
Когда они «задолбаются», если на большую часть запросов достаточно будет ответить один раз за всё время использования приложения? А оставшиеся разрешения — даже если поставят «разрешать всегда», всё равно будет лучше, чем сейчас.
При этом можно будет выкладывать/распространять/использовать конфиги разрешений для приложений, то есть достаточно взять чей-нибудь адекватный конфиг и будет уже неплохо для начала.
К сожалению похоже современный веб все больше похож на реальный мир.
Масса публикаций на хабре в последнее время о том как пытаются следить за пользователем… ломятся в окна, в двери, смотрят что ешь, что заказываешь, что смотришь, что пишешь в email…
Отгородиться от веба высоким забором будет всё актуальнее.
Ставить AdBlock, Ghostery, NoScript, RequestPolicy и т.п. вещи — это не уровень обычного пользователя. Для массового пользователя необходима защита из коробки. С объяснением зачем необходимо то или иное разрешение.
«Если у вас паранойя, это еще не значит, что вас не преследуют». В таком мире будет востребована анонимность.
Зачем крупным разработчикам бороться за приватность пользователей, если у них доход с продажи этой самой приватной инфы, хоть и опосредованный?
Мне кажется, что создавать новый Web нужно со стандартизации виртуальной машины, API браузера, API межпрограммного общения (аналоги OAuth и других протоколов в новой реализации). Нужно понимать, что современный Web не стоит на месте, браузеры внедряют новые возможности (работа со звуком и видео, уведомления на рабочем столе, HTTP/2). При разработке NewWeb нужно заложить расширяемость с учетом обратной совместимости. А вопросы IDE вообще не должны подниматься на этапе формирования идеи/концепции.
Ничего удивительного: если использовать SQL на веб-сервере самым очевидным образом, то он будет нормально работать, но незаметно сделает сервер уязвимым для взлома. Параметризованные запросы помогают, но это сбоку привинченное решение, которое не в каждой ситуации можно использовать.
prepared statements оказались костылем, оооок. Я то думал что это основной способ делать sql запросы, к тому же безопасный.
Но теперь средний размер веб-страницы превышает 2 мегабайта, не говоря уже о веб-приложениях. Даже скучные веб-странички со статичным текстом часто содержат массу минифицированных скриптов, в которых без машинной помощи вы не сможете даже начать разбираться.
В бинарных программах еще сложнее разобраться. Где же плюсы?
Требование: сериализация данных должна быть автоматической типизированной, бинарной и неизменной от хранилища данных до фронтеда.
А что, кто то мешает это сделать уже сейчас?
Вторая проблема в том, что машинам тоже сложно воспринимать URL'ы
Которые для этих же машин и писались, ооок.
Например, подумайте, что мешает вашему серверу установить куки для домена .com. А что насчёт kamagaya.chiba.jp?
Насколько я помню браузер запрещает ставить куки для чужих доменов (могу ошибаться, не проверял).
Просмотр исходника определённо помог мне столько раз, что я не могу сосчитать
Зато предлагаемую автором бинарную хрень вы просто не прочитаете.
Результаты выполнения SQL-запроса нельзя нативно отправить по соединению HTTP или встроить в веб-страницу
Мне кажется автор предлагает добавить еще больше дырок в его реализацию.
Ещё одним способом выполнения этого требования может стать умная IDE: если позволить разработчикам сначала работать с нетипизированными структурами (всё что определяется как Any), среда выполнения может попробовать определить, какими должны быть исходные типы, и транслировать эту информацию обратно в IDE. Затем она может предложить замену на лучшие аннотации типов. Если разработчик сталкивается с ошибками приведения типа во время работы программы, то IDE может предложить снова ослабить ограничение.
Нехватало еще чтобы IDE было обязательным требованием для разработки.
Грустный приговор веб-платформе, что WebAssembly — единственная попытка добавить новый язык, и этим языком является C… на котором, я надеюсь, вы не захотите писать веб-приложения!
Я думаю здесь можно остановиться, ибо некомпетентность автора доходит до предела.
Wasm это все что сможет скомпилироваться в wasm, как минимум все что компилируется в llvm, а это уже не мало.
Достаточно нам XSS, чтобы добавлять сверху ещё уязвимости типа двойного освобождения одной и той же памяти.
Ага, double free в виртуальной машине, очень смешно. Просит добавить новый язык, а когда ему дают платформу на которой можно вообще разные языки использовать — не, не надо говорит.
Да, это значит, что я хочу оставить возможность использовать JavaScript (на высокой скорости), помимо Ruby, Python, Haskell, и да — C, C++ и Rust тоже останутся в игре. Всё это возможно благодаря двум действительно классным проектам, которые называются Graal и Truffle, о которых я подробно рассказывал. Эти проекты позволяют JVM запускать даже код на неожиданных языках (таких как Rust) в виртуализированной среде, быстро и и интероперабельно
А кто мешает их гонять вместе с рантаймом поверх wasm? это по сути тоже самое, но оно уже реализовано!
Песочница OpenJDK годами подвергалась упорным атакам, и разработчики браузеров усвоили ряд болезненных уроков. Последний 0-day эксплоит датируется 2015-м годом, а предыдущий был в 2013-м. Всего два 0-day эксплоита в песочнице за пять лет — неплохо, на мой взгляд, особенно с учётом того,
с учетом того, что java потом из браузеров выкинули, и эксплойты стало писать не так рентабельно.
Бинарных структур данных недостаточно. Нужны ещё и бинарные протоколы
Которые уже есть. Тот же messagepack вполне себе эффективно гоняется по http.
Платформа, которая хочет конкурировать с вебом, должна серьёзно озаботиться вопросами безопасности, поскольку это важнейшее обоснование для её создания и конкурентное преимущество. Это главная вещь, которую невозможно легко исправить в вебе. То есть нам нужны: бинарные структуры данных с безопасной типизацией и бинарные API, RPC, криптографические сессии и идентификация пользователей.
Платформа которая хочет конкурировать с вебом, должна озаботиться вопросами собственной необходимости. Нам нужны: перечисление всего что с безопасностью слабо связано, например бинарные протоколы. И как же они улучшают безопасность? а вот дебажить все это — одно удовольствие.
Да, как раз хотел написать то же самое. Жесть на жести. Но про SQL и webAssembly круче всего. Уровень некомпетентности зашкаливает разумные пределы.
Графоманство какое-то…
Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.
Очевидно, что у автора катастрофически не хватает кругозора, понимания работы определённых вещей, зато нездоровая любовь к каким-то определённым реализациям каких-то конкретных решений, да ещё и в java мире.
Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.
Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....
Эх, статья-статья. Грустно...
Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.
Очевидно, что у автора катастрофически не хватает кругозора, понимания работы определённых вещей, зато нездоровая любовь к каким-то определённым реализациям каких-то конкретных решений, да ещё и в java мире.
Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.
Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....
Эх, статья-статья. Грустно...
насколько я понимаю, фьючерсов нету нигде кроме Java мира
Неправильно вы понимаете.
Также возможна реализация единой виртуальной машины, встроенной в систему. В байткод этой ВМ будут компилироваться все языки, что также увеличит многообразие. Ну а ОС будут реализовывать стандарт этой ВМ и пытаться сделать более быструю и крутую реализацию)
Эх, розовые мечты…
Я ещё не дочитал статью, но уже возмущён:
Создание GUI в Matisse, редакторе UI с автоматическим выравниванием и ограничителями. Да здравствует (новый стильный) король?
Автор уже который раз (и в первой статье и в этой) рассуждает так, как будто перетаскивать кнопочки мышкой на формочку — удобнее, чем писать код (html/css/js).
Нет, это не так! По многим причинам:
- В GUI вы можете разместить кнопочку на окне фиксированного размера. Совершенно непонятно, что произойдёт с ней, если окно другого размера. Или экран другого размера. Когда у пользователей есть и компьютеры с мониторами самых разных размеров и разрешений, и планшеты, и телефоны (а у планшетов и телефонов есть ещё горизонтальная и вертикальная ориентация), нам бы хотелось, чтобы интерфейс работал при любом разрешении и размере экрана. Когда мы пишем код руками, мы сразу можем задать поведение (всякие Media Queries и разные обёртки над ними). Когда мы делаем интерфейс в GUI, нам нужно отдельно как-то задавать поведение.
- Тыкать мышкой GUI — просто медленнее, чем писать код.
- Как это потом хранить и версионировать? А как мержить? Это же всё равно хранится во всяких файлах (xml?). То есть, нам всё равно придётся работать с текстовыми файлами. Так давайте сразу работать с текстовыми файлами и затачивать наши инструменты для работы с текстовыми файлами.
В GUI вы можете разместить кнопочку на окне фиксированного размера. Совершенно непонятно, что произойдёт с ней, если окно другого размера. Или экран другого размера.
В нормальных GUI для создания GUI это вообще не проблема. Помню, ещё во времена Delphi можно было нормально мышкой накидать форму с динамической расстановкой элементов.
Сейчас можно глянуть на дизайнер UI в Android Studio: там можно сразу посмотреть макет на разных экранах, использовать всю мощь всяких разных LayoutManager-ов, прибиндить разметку к данным, и тд
Тыкать мышкой GUI — просто медленнее, чем писать код.
Далеко не всегда. Иногда удобнее написать код, иногда набросать мышкой элементы на форму, иногда чередовать
Как это потом хранить и версионировать? А как мержить? давайте затачивать наши инструменты для работы с текстовыми файлами
Так вот эти GUI-билдеры и есть заточенный инструмент. Под капотом они просто передвигают блоки кода и просто рендерят это всё на экран сразу. Версионировать и мёржить всё это можно точно так же, как и текст (потому что это и есть текст).
Помню, ещё во времена Delphi можно было нормально мышкой накидать форму с динамической расстановкой элементов.
Я помню, как во времена Delphi я с этим мучился, и я знаю, насколько просто это сделать сейчас, с помощью HTML и CSS. Особенно, если взять какой-нибудь фреймворк типа бутстрапа, где всё уже сделано.
Так вот эти GUI-билдеры и есть заточенный инструмент. Под капотом они просто передвигают блоки кода и просто рендерят это всё на экран сразу. Версионировать и мёржить всё это можно точно так же, как и текст (потому что это и есть текст).
Да, я про это и говорю. Если нам нужно что-то смержить, нам всё равно надо будет лезть в код. Следовательно, нужно одновременно понимать, как этот код работает и помнить, куда нужно ткнуть мышкой, чтобы сделать кнопку. То есть, эти GUI не избавляют нас от сложности, они добавляют ещё один уровень сложности.
А вообще, ИМХО, чтобы веб-стандарты превратились в хорошие стандарты построения (общих) приложений, им не хватает многоуровневости: должны быть API/стандарты и более низких уровней, чем в W3C Web.
Если бы микрософт не пыталась захватить мир и открыла технологию для всех то может быть взлетело.
Этот проект Yahoo тогда забуксовал. Хотя, по-моему, работа web на серверах БД дала бы ряд преимуществ: упрощение, универсализация, масштабирование, скорость. Интернет превратился бы в совокупность взаимосвязанных БД и клиентов к ним. Это не отменяло бы работу традиционного web, но браузеры могли бы работать дополнительно и в таком режиме.
Двадцать минут потратил чтобы найти статью — никак.
А чем это отличается от того, чтобы обращаться к прикладным серверам, которые возвращают "данные об интерфейсе и наполнении"?
Насколько я понимаю.
В то время как теоретически всё это можно заменить серверами баз данных.
… которые будут выполнять те же самые функции (потому что кто-то же должен их выполнять). В чем отличие-то?
но упрощается разработка
Почему вдруг? То, что вы раньше писали для прикладного сервера, придется писать для БД.
и масштабирование
А это и вовсе не так, потому что многослойное приложение масштабировать проще — у разных уровней разные требования к масштабированию. БД как раз не очень хорошо масштабируются.
В БД легко создавать любые структуры и связи между сущностями.
Если проект Yahoo загнулся, значит на то были причины. Не могу найти информации по этому проекту, и времени этому посвятить не могу.
Обычно то что делается в рамках единой системы становится проще и согласованнее, чем собранное из разных независимых или взаимозависимых систем.
Ну да, вы увеличиваете связность и приходите к монолиту. Который монолит немедленно становится проблемой в развитии и масштабировании.
В БД легко создавать любые структуры и связи между сущностями.
Вы не поверите, но на прикладном сервере — тоже.
Вот только среди веб разработчиков много любителей не особо умных IDE в стиле sublime, notepad++, vim. Плюющихся при любой попытке подсунуть что-то с кучей интерфейсов, которыми проще всего управлять мышкой.
SQL и PHP относятся к бэкенду, и мешать они могут разве что его разработчикам, но никак ни вебу в целом.
Кстати говоря, вэб изначально таким не планировался, производители браузеров потом его испоганили, тк вместо того, что делает обычная программа — кидается ошибками — начали пытаться и отрисовать то, что не до конца поняли, хоть как-нибудь, и скрипты исполнить хоть как-нибудь.
По-моему лечится вкладкой "Console" в инструментах разработчика
OpenOffice, который пытается распарсить xls, не всегда успешно. Архиваторы на Windows, которые не всегда понимают архивы сделанные на Mac.
В любом проекте, где одни разработчики пытаются поддержать результат работы других разработчиков, будет место такому раздраю. Проблемы можно попробовать решить при помощи спецификации, но чем сложнее система, тем больше шансов на разночтения.
http2 кое-какие беды порешал…И добавил новые, посидите на нём с плохой связью (которая может быть и внезапно на стороне хостинг-провайдера). У вас его «конвейер» встанет и вся сессия повесится на несколько минут. Для обычного пользователя поможет только выход из обозревателя. Короче HTTP2 плох если пакеты вдруг теряются. Пока сам не нарвался, относился к этому скептически.
Веб взял верх над Delphi и Visual Basic не потому что JavaScript настолько крут. Есть более глубокие причины.
Т.е. вы хотите сказать что жопоскрипт-таки «крут»? Перед расстрелом из реактивного говномёта дадим автору шанс и сделаем вид будто он просто некорректно составил предложение. Ну или на худой конец, что подобная нелепица — погрешности перевода.
Ну какое отношение к безопасности имеет текстовый или бинарный протокол? TLS бинарный протокол, но это никак не спасет от ошибок в реализации
Что последует за вебом?