Здравствуйте, b0r3d0m, Вы писали:
B>А в чём, собственно, заключается проблема иметь функции для работы с TCP / UDP сокетами в API браузеров? Какие-то security reasons?
Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса. Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s). В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
Здравствуйте, fddima, Вы писали:
EP>>Я сказал что он быстрее аналогичного C# кода, а не C++. F> Фейспалм мне. Сорри, поздно — затупил.
Ув. EP из темы в тему сравнивает стоимость вызова заинлайненного метода в плюсах, странслированного в web asm пардон, в asm.js. Переклинило. (т.е. к JS оно строго говоря не относится) и делегата шарпа. Делать из этого глобальные выводы на полном серьёзе — троллинг из серии "замеряем работу с числами в питоне без numPy".
Я уже раза три намекал про "когда важен перфоманс, пишут немного в другом стиле", но чего-то не помогает. Нравится передёргивать — флаг в руки, главное чтоб остальные не велись.
В целом ради бога, но зачем это надо — неясно. Тот же торрент клиент на яваскрипт — уже требует доступ к фс. JS — нихрена не быстрый. И вообще веббраузер сейчас — песочница какая никакая, сокеты же неконтролируемы без доп средств. Они одним несложным циклом просто закончатся на клиенте. Да еще за прокси не ходит. Легче прикрутить AJAX + Long Polling, WebSockets нежели городить что-то, что изначально обречено на провал в вебе. Кроме того websockets именно как протокол мало чем ограничивает тебя, в смысле — бинарные сообщения — пожалуйста, двунаправленность и т.п. Это же тот же прикладной сокет, но уже с готовыми своими кадрами/сообщениями, и если не путаю мультиплексированием. Для клиентских веб приложений как раз самое оно, но этим не ограничивается же.
В хроме например remote debugging protocol (devtools) как раз на вебсокетах и построен, выбор вполне ясен. При том in-proc использует те же сообщения, но мимо websocket транспорта. Че еще надо-то? В вебе? Торрент?! Хватит ерундой маяться.
Здравствуйте, Sinix, Вы писали:
S>Ув. EP из темы в тему сравнивает стоимость вызова заинлайненного метода в плюсах, странслированного в web asm пардон, в asm.js. Переклинило. (т.е. к JS оно строго говоря не относится) и делегата шарпа. Делать из этого глобальные выводы на полном серьёзе — троллинг из серии "замеряем работу с числами в питоне без numPy". S>Я уже раза три намекал про "когда важен перфоманс, пишут немного в другом стиле", но чего-то не помогает. Нравится передёргивать — флаг в руки, главное чтоб остальные не велись.
Хоть я к этому и отношусь скептически — всё же зерно истины в его словах есть, в контексте этого треда. В тот большой тред влазить неохота, я его замахался читать в прошлый раз.
Я полностью согласен, что современные JS VM — весьма годные штуки. Другое дело, что .NET в целом — на две головы выше, просто потому что голая VM очень мало кому нужна. А .NET и генерирует код и выполняет его безо всяких приседаний, и имеет кучу библиотек, и GC получше, да и сама VM куда мощнее (хотя бы на уровне примитивных типов). Мне вот не хватает в JS int64 — приходится обходится по месту, чем есть (строки — если id).
У меня профайлер в одном из hot path показывает, что время тупо уходить на интероп... ну там из std::string преобразовывается в какой-нибудь WTF::String. И такие миленькие преобразования по колстэку только в нэйтиве — происходят 3 раза, иногда с копированием, иногда ещё и с конверсией (utf8/utf16), естественно это тянет за собой и аллокации -> в итоге уже плохо. А нерегулярное пропихивание строк в 0.5-4 мегабайта, с такими преобразованиями — и перфоманс превращается в торманз. Ну ничего, бывает, а проц и кеши у нас всё равно резиновые. Будем терпеть пока все либы не перейдут на одну строку , и очевидно std::string едет лесом.
Но вот вызов колбэка в цикле... ну да, это клёва уметь инлайнить, адаптивный/спекулятивный JIT и т.п. С другой стороны тут вот GCC HashTable показывает лучшие результаты (второй, но первый выигрывает не за счет инлайнинга), хотя это чистый C и компаратор никак не может быть заинлайнен. Так что на мой взгляд — значимость в целом думаю переоценена. Естественно где-то это очень нужно, а в синтетике без этого вообще никак нельзя.
Update: А в дотнете давно-давно я занимался и ручным инлайнингом, и ручным инлайнингом алгоритмов с адаптацией под разные вариации входных данных (типа строка, буффер, указатель). Хотя лучше бы как-то уметь сказать компилятору кто здесь.
Здравствуйте, fddima, Вы писали:
F> Я полностью согласен, что современные JS VM — весьма годные штуки.
Кэп
Проблема в том, что производительность этой VM доказывается через "мы тут подкинули формат, который без проблем переводится в бинарный код, и о чудо — он работает так же быстро, как бинарный код!" Мухлёж, как ни крути.
Ну, т.е. проблема не в самом "Xxx быстрее", тут всё ок как раз. А вот с аргументацией ой.
F>Update: А в дотнете давно-давно я занимался и ручным инлайнингом, и ручным инлайнингом алгоритмов с адаптацией под разные вариации входных данных (типа строка, буффер, указатель). Хотя лучше бы как-то уметь сказать компилятору кто здесь.
Ну да. Тяжкое наследие заточенного под энтерпрайз кода. Как только речь шла о более приземлённых вещах, так сразу в форках MS research и realtime gc появлялись, и трансляция в натив нормальная и куча других плюшек. Засада в том, что "прототип? прототип" (с) в основную ветку протащить бывает на порядок сложнее, чем сам прототип сваять. Ибо совместимость, ненормальные клиенты и прочий ад.
Здравствуйте, b0r3d0m, Вы писали:
B>Тут вдруг подумалось.
B>А в чём, собственно, заключается проблема иметь функции для работы с TCP / UDP сокетами в API браузеров? Какие-то security reasons?
B>Да, знаю, что есть WebSockets, но всё же.
Как обычно: хорошая мысля приходит опосля + думали http хватит всем и для всего.
S>Как обычно: хорошая мысля приходит опосля + думали http хватит всем и для всего.
Верно, прошло дофига времени. Так почему же после такого кол-ва времени всё равно решили изобрести абсолютно новый стандарт (WebSockets) вместо добавления уже проверенных временем BSD Sockets? Ну да, они удобны, не спорю, но потребовалось много времени для их стандартизации и внедрения в браузеры. Мне кажется, с BSD Sockets было бы несколько проще.
Здравствуйте, b0r3d0m, Вы писали:
S>>Как обычно: хорошая мысля приходит опосля + думали http хватит всем и для всего.
B>Верно, прошло дофига времени. Так почему же после такого кол-ва времени всё равно решили изобрести абсолютно новый стандарт (WebSockets) вместо добавления уже проверенных временем BSD Sockets? Ну да, они удобны, не спорю, но потребовалось много времени для их стандартизации и внедрения в браузеры. Мне кажется, с BSD Sockets было бы несколько проще.
Про BSD Sockets не скажу (скорее всего секурность, и этим все сказано), а собственно какая разница , если вебсокеты стали уже фактически стали частью стандарта, т.е http 2.0.
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy)
Да и ладно, пускай только к своему же домену и разрешили бы.
CK>В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще
В чём проблема ограничить это на уровне браузера? Грубо говоря, запрещать все обращения вне того же домена.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса.
Это связано с тем, что при HTTP-запросах отправляются куки.
> Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s).
Ну у кого прокси, у того и проблемы. Некоторые прокси позволяют прокидывать произвольные соединения.
> В общем, BSD сокеты — огромная дырища в безопасности
В чём дырища-то?
> представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
vsb>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
Любая уязвимость типа "внедрение javascript", мгновенно превращает посетителей любого сайта в большой ботнет, которым можно досить, скликивать рекламу, накликивать посещаемость и т.п.
Здравствуйте, hi_octane, Вы писали:
vsb>>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса? _>Любая уязвимость типа "внедрение javascript", мгновенно превращает посетителей любого сайта в большой ботнет, которым можно досить, скликивать рекламу, накликивать посещаемость и т.п.
Это и сейчас можно делать. Добавляешь тег <img src="http://rsdn.ru/"/> на какую-нибудь lenta.ru и получаешь ддос. И рекламу скликивать можно, и POST-ы делать. Нельзя только читать ответ от такого запроса. Но ДДОСу это не мешает.
Здравствуйте, vsb, Вы писали:
>> представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда. vsb>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP.
2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает.
3. (Ну и ещё больше) Допустим, что мой реальный IP адрес находится в белом списке на внешнем хосте. Это в свою очередь просто даёт возможность законнектится на хост через telnet/ssh/whatever. Таким образом теперь к нему уже может законнектится бот. Вместо whatever подставьте например безпарольный dev или что тоже может быть — продакшн сервис. Оно надо?
Здравствуйте, fddima, Вы писали:
>>> представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда. vsb>>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
F> 1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP.
Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу.
F> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает.
Это внутренние. Остальные внешние. Твой роутинг никого не интересует.
F> 3. (Ну и ещё больше) Допустим, что мой реальный IP адрес находится в белом списке на внешнем хосте. Это в свою очередь просто даёт возможность законнектится на хост через telnet/ssh/whatever. Таким образом теперь к нему уже может законнектится бот. Вместо whatever подставьте например безпарольный dev или что тоже может быть — продакшн сервис. Оно надо?
Надуманная проблема. Хочешь ограничить — ставь нормальную защиту. Твоё описание это не защита, а фарс.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса. Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s). В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
Проснись, тебя уже обокрали — через веб-странички можно взламывать локальные роутеры и т.п.
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank
Здравствуйте, vsb, Вы писали:
F>> 1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP. vsb>Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу.
Виртуальный хостинг. У меня на одном IP — висит 3 веб приложения. Сокеты без выделения портов разумеется прозрачно этого не могут — это банально неудобно. Там где реально нужны сокеты — люди просто делают приложения на сокетах. WebSockets же хватает головой для JS/сайтов, тем более что вся кухня сериализации сообщений уже реализована и спрятана, и не нужно ломать голову.
F>> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает. vsb>Это внутренние. Остальные внешние. Твой роутинг никого не интересует.
Правильно, мой роутинг — мой — поэтому нечего сайтикам лазить по любым IP адресам, — кто из них кто — он всё равно не знает, но потенциально может соединяться с теми узлами с кем не следует.
F>> 3. (Ну и ещё больше) Допустим, что мой реальный IP адрес находится в белом списке на внешнем хосте. Это в свою очередь просто даёт возможность законнектится на хост через telnet/ssh/whatever. Таким образом теперь к нему уже может законнектится бот. Вместо whatever подставьте например безпарольный dev или что тоже может быть — продакшн сервис. Оно надо? vsb>Надуманная проблема. Хочешь ограничить — ставь нормальную защиту. Твоё описание это не защита, а фарс.
Это вполне обычные правила. Наличие/отсутствие пароля здесь второстепенно. В локальной сети администратор может иметь бОльший прямой доступ по LAN — и банальные коннекты у него работают, когда у других юзеров сети — нет. Таким образом просто произвольный код, о наличии которого при посещении сайта ты даже не знаешь — начинает совершать какие-то коннекты. Криво или нет — это тоже другой вопрос. Такое делают и часто.
Здравствуйте, fddima, Вы писали:
F>>> 1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP. vsb>>Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу. F> Виртуальный хостинг. У меня на одном IP — висит 3 веб приложения. Сокеты без выделения портов разумеется прозрачно этого не могут — это банально неудобно. Там где реально нужны сокеты — люди просто делают приложения на сокетах. WebSockets же хватает головой для JS/сайтов, тем более что вся кухня сериализации сообщений уже реализована и спрятана, и не нужно ломать голову.
Яснее мне не стало, почему same-origin policy или хостинг нескольких сайтов едет лесом от этой фичи. Где реально нужны сокеты — сделать ничего нельзя. Попробуй сделать торрент-клиент на JavaScript, работающий в браузере и коннектящийся по стандартному торрент-протоколу к другим клиентам.
F>>> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает. vsb>>Это внутренние. Остальные внешние. Твой роутинг никого не интересует. F> Правильно, мой роутинг — мой — поэтому нечего сайтикам лазить по любым IP адресам, — кто из них кто — он всё равно не знает, но потенциально может соединяться с теми узлами с кем не следует.
У 99.999% пользователей роутинг соответствует стандартам и этой проблемы нет. Конкретно ты можешь такую фичу отключить или скомпилировать браузер без него. Это не аргумент, чтобы ограничивать функционал.
F> Это вполне обычные правила. Наличие/отсутствие пароля здесь второстепенно. В локальной сети администратор может иметь бОльший прямой доступ по LAN — и банальные коннекты у него работают, когда у других юзеров сети — нет. Таким образом просто произвольный код, о наличии которого при посещении сайта ты даже не знаешь — начинает совершать какие-то коннекты. Криво или нет — это тоже другой вопрос. Такое делают и часто.
LAN это внутренние адреса. Ограничивать доступ к ним можно, проблем нет. Если ты в LAN используешь публичные адреса, проблема тут явно не в браузере.
Здравствуйте, vsb, Вы писали:
vsb>Яснее мне не стало, почему same-origin policy или хостинг нескольких сайтов едет лесом от этой фичи. Где реально нужны сокеты — сделать ничего нельзя. Попробуй сделать торрент-клиент на JavaScript, работающий в браузере и коннектящийся по стандартному торрент-протоколу к другим клиентам.
Несравненно более сложную вещь, чем торрент-протокол — давно сделали. WebRTC для видео и аудио, p2p. Да, оно не работает без посредника, но и торренту для начала работы требуется некий внешний трекер.
.
Тему ту читал как-то долго и нудно. Хорошие результаты в определенных случаях — не показатель сам по себе. Есть куча JS кода который ставит раком JS оптимизаторы. Они все растут и растут, но как только ты попадешь на честный проперти лукап или сканирование цепочки прототипов — чудеса чудесатые резко и больно закончатся. В последних V8 правда он возможно и это прожует. Кроме того бедная система типов не позволяет нормально работать со многими данными. Конечно, написать/скомпилировать в обфусцированный код (я имею ввиду нецелевые применения всяческих типизированных массивов и прочих конструкций) — это хорошо, но по прежнему не везде все применимо.
Если JS/V8/other работают быстрее нормального C++ кода, то скорее всего проблема в C++ коде.
Здравствуйте, fddima, Вы писали:
F>Есть куча JS кода который ставит раком JS оптимизаторы. Они все растут и растут, но как только ты попадешь на честный проперти лукап или сканирование цепочки прототипов — чудеса чудесатые резко и больно закончатся.
Этого всё не нужно в случае использования JS в качестве "байткода" VM (который и генерируется при компиляции C++ -> JS) — и такой байткод очень быстр (asm.js).
Это я к тому, что JS можно рассматривать как VM/платформу, а не как язык для непосредственного написания кода вручную — и в этом случае результирующее приложение может быть очень быстрым.
F> Если JS/V8/other работают быстрее нормального C++ кода, то скорее всего проблема в C++ коде.
Я сказал что он быстрее аналогичного C# кода, а не C++.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Этого всё не нужно в случае использования JS в качестве "байткода" VM (который и генерируется при компиляции C++ -> JS) — и такой байткод очень быстр (asm.js).
V8 о asm.js вроде ж как продолжает ничего не знать о asm.js. А работает довольно хорошо и без. Но, тут я согласен.
EP>Это я к тому, что JS можно рассматривать как VM/платформу, а не как язык для непосредственного написания кода вручную — и в этом случае результирующее приложение может быть очень быстрым.
Тут — опять да, ты прав. Вместе с тем V8 (я работал только с ним), не такой уж идеальный и не уверен во что именно выльется интероп (мы обсуждали ж это уже?). Не все ж одни числодробилки, да и как он будет себя вести — не знаю. Плюс, хром явно собирается с PGO оптимизациями. Насколько мне известно только это дает прирост в V8 на 10-20%, данные старые. Я к тому, что кусок довольно вылизанный --> дает более хорошие результаты чем в среднем по палате.
Хотя говорить о JS именно как о JS VM мне не кажется корректным. В смысле все же в вебе — пока наверное больше исполняется кода фреймворков. :D
Но я смотрю на это немного по другому: банальная страница (мы ж про веб) — это хрен знает что. 20-30 фреймов от ads, кучи беспорядочных включений и самых замысловатых использований, тут тебе и какие-то загадочные setInterval fn 100ms, где fn через jquery выбирает фантастические селекторы. И таймеров таких — штук 30 и их никто не стопает. Я по долгу службы часто анализирую страницы, поэтому насмотрелся всякого. Я уверен, что у тебя бы на странице такой ерунды не было бы. Но если мы внедряем чужой iframe — мы уже имеем шансы того, что нас прерывают по таймеру на неизвестное время. Я скорее в этом смысле. Бардачище. Правда, что странно — работает.
Ну а для торрента... там даже не знаю чистый или не чистый i/o bound. uTorrent у меня скачивая на скорости 10MBps проц почти не кушает.
На современном компе все быстро. А попадаешь за машину послабее — тормоза ощутимы везде, и торренты в браузерах не кажутся хорошей идеей. Вообще браузеры кажутся хреновой идеей. Хотя как прогреются — так и хороши снова.
EP>Я сказал что он быстрее аналогичного C# кода, а не C++.
Фейспалм мне. Сорри, поздно — затупил.
Здравствуйте, Слава, Вы писали:
vsb>>Яснее мне не стало, почему same-origin policy или хостинг нескольких сайтов едет лесом от этой фичи. Где реально нужны сокеты — сделать ничего нельзя. Попробуй сделать торрент-клиент на JavaScript, работающий в браузере и коннектящийся по стандартному торрент-протоколу к другим клиентам.
С>Несравненно более сложную вещь, чем торрент-протокол — давно сделали. WebRTC для видео и аудио, p2p.
WebRTC реализовали на C++ и к делу это не относится. Я не скачаю дистрибутив линукса через торрент используя WebRTC или не проверю почту, используя IMAP. Предлагаешь все протоколы на свете делать частью браузера?
C>Да, оно не работает без посредника, но и торренту для начала работы требуется некий внешний трекер.
Суть не в торренте. Суть в возможности реализовать любой протокол. Torrent, SMTP, IMAP, SSH, FTP, NTP и тд, и всё это на обычном JavaScript.
Здравствуйте, fddima, Вы писали:
F>В целом ради бога, но зачем это надо — неясно.
Для того, чтобы писать более полноценные веб-приложения.
F> Тот же торрент клиент на яваскрипт — уже требует доступ к фс.
Доступ к ФС у яваскрипта есть уже много лет, File API называется.
> JS — нихрена не быстрый.
JS очень быстрый. Один из самых быстрых языков.
> И вообще веббраузер сейчас — песочница какая никакая, сокеты же неконтролируемы без доп средств. Они одним несложным циклом просто закончатся на клиенте.
Ограничения на количество открытых соединений это не проблема.
> Да еще за прокси не ходит.
Передать инфу о текущем прокси тоже не проблема.
> Легче прикрутить AJAX + Long Polling, WebSockets нежели городить что-то, что изначально обречено на провал в вебе.
Тут вопрос не в легче, тут вопрос в принципиальной возможности. Ты не сможешь работать с Jabber через WebSockets. Тебе придётся делать реализацию на сервере, JavaScript-ом передавать туда пароль от моего аккаунта и в этот момент я перестаю пользоваться таким сервисом, потому что мне не надо, чтобы мой пароль попадал в руки третьих лиц.
Здравствуйте, b0r3d0m, Вы писали:
B>А в чём, собственно, заключается проблема иметь функции для работы с TCP / UDP сокетами в API браузеров? Какие-то security reasons?
Веб, он многоликий, в отличие от простого сокета. Скажем, подключение клиента через проксю (или несколько). Подключение серверов к лоад-балансеру. Смена транспорта с HTTP на HTTPS и обратно. И т.п.
Все эти нюансы гонять в виде метаданных через обычный сокет — вот мы и переизобретаем свой HTTP. Вот только поддержка на уровне других участников сетевой инфраструктуры у него будет нулевая...
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Проснись, тебя уже обокрали — через веб-странички можно взламывать локальные роутеры и т.п. EP>
EP>https://en.wikipedia.org/wiki/Cross-site_request_forgery
EP>Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank
думаю они не браузером этот email открывали, а почтовым клиентом
Здравствуйте, chaotic-kotik, Вы писали:
EP>>Проснись, тебя уже обокрали — через веб-странички можно взламывать локальные роутеры и т.п. EP>>
EP>>https://en.wikipedia.org/wiki/Cross-site_request_forgery
EP>>Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank
CK>думаю они не браузером этот email открывали, а почтовым клиентом
Без разницы, это может быть и из браузера. Даже в это сообщение я могу встроить img url который будет дёргать твой локальный роутер изнутри сети.
Ограничения есть, безусловно, тем не менее подобные атаки применяются уже давно, и не являются фантастикой. ЕМНИП даже делают bruteforce паролей к роутерам.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Без разницы, это может быть и из браузера. Даже в это сообщение я могу встроить img url который будет дёргать твой локальный роутер изнутри сети. EP>Ограничения есть, безусловно, тем не менее подобные атаки применяются уже давно, и не являются фантастикой. ЕМНИП даже делают bruteforce паролей к роутерам.
ну, справедливости ради, это уязвимость рутера, и это не доказывает что BSD сокеты в браузере — хорошая идея
Здравствуйте, vsb, Вы писали:
F>> Тот же торрент клиент на яваскрипт — уже требует доступ к фс.
vsb>Доступ к ФС у яваскрипта есть уже много лет, File API называется.
Ну вот попробуй написать файловый менеджер используя чистый браузер. Узнаешь много нового.
Здравствуйте, Ikemefula, Вы писали:
F>>> Тот же торрент клиент на яваскрипт — уже требует доступ к фс.
vsb>>Доступ к ФС у яваскрипта есть уже много лет, File API называется.
I>Ну вот попробуй написать файловый менеджер используя чистый браузер. Узнаешь много нового.
При чём тут файловый менеджер и торрент-клиент? Для торрент-клиента там хватает апи.
Здравствуйте, vsb, Вы писали:
vsb>>>Доступ к ФС у яваскрипта есть уже много лет, File API называется. I>>Ну вот попробуй написать файловый менеджер используя чистый браузер. Узнаешь много нового.
vsb>При чём тут файловый менеджер и торрент-клиент? Для торрент-клиента там хватает апи.
Кхе, кхе — а кто тебе, на секундочку, даст файл по фиксированому пути ? Какие браузеры это умеют ? Что делать с остальными ?
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, hi_octane, Вы писали:
vsb>>>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса? _>>Любая уязвимость типа "внедрение javascript", мгновенно превращает посетителей любого сайта в большой ботнет, которым можно досить, скликивать рекламу, накликивать посещаемость и т.п.
vsb>Это и сейчас можно делать. Добавляешь тег <img src="http://rsdn.ru/"/> на какую-нибудь lenta.ru и получаешь ддос. И рекламу скликивать можно, и POST-ы делать. Нельзя только читать ответ от такого запроса. Но ДДОСу это не мешает.
Тут запрос будет только один раз, а в случае с js — сколько угодно.
Здравствуйте, Skorodum, Вы писали:
_>>>Любая уязвимость типа "внедрение javascript", мгновенно превращает посетителей любого сайта в большой ботнет, которым можно досить, скликивать рекламу, накликивать посещаемость и т.п.
vsb>>Это и сейчас можно делать. Добавляешь тег <img src="http://rsdn.ru/"/> на какую-нибудь lenta.ru и получаешь ддос. И рекламу скликивать можно, и POST-ы делать. Нельзя только читать ответ от такого запроса. Но ДДОСу это не мешает. S>Тут запрос будет только один раз, а в случае с js — сколько угодно.
Ну добавь миллион таких тегов, будет долбить без перерыва.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, b0r3d0m, Вы писали:
B>>А в чём, собственно, заключается проблема иметь функции для работы с TCP / UDP сокетами в API браузеров? Какие-то security reasons?
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса. Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s). В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
Почему про CORS забываем?
Cross-origin resource sharing
Здравствуйте, vsb, Вы писали:
vsb>Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу.
т.е. да здравствуйет ddos от сотен миллионов пользователей веба. И нет, существующими методами через javascript DDoS через, к примеру, dns вы не организуете.
F>> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает.
vsb>Это внутренние. Остальные внешние. Твой роутинг никого не интересует.
т.е. о "белых" подсетях вы не слышали? И про то, что изнутри к ним доступ, зачастую, куда более открытый, чем снаружи.
vsb>Надуманная проблема. Хочешь ограничить — ставь нормальную защиту. Твоё описание это не защита, а фарс.
Ограничение доступа на уровне сети — фарс? Ок, видимо файерволы не нужны, сам vsb сказал-же.