Хотел длинно написать но думаю это лишнее.
1) полезность: выработка общей дисциплины касательно ответственного отношения к чужим данным; да, я понимаю что эти (из статьи) требования сами по себе ничего не дадут, данные всё так же будут терять/взламывать/красть/продавать, и я понимаю что государство не показывает инициатив к пресечению всего указанного (никого не посадили ни за какие утечки), но если вдруг они смогут начать хотя бы с этой стороны — всё равно хорошо, может потом, на фоне уже выработанной дисциплины, и остальное подтянут
2) "вкладываться" по моим оценкам, на конкретно эти требования надо что-то не больше 1 рубля разово с гражданина — это если правильно всё организовать и не распиливать финансирование — там всего то надо организовать включение уже много раз реализованных алгоритмов в основную ветку опенсорсных проектов (сейчас все браузеры опенсорс, топ популярные веб-сервера опенсорс, криптобиблиотеки большинство тоже опенсорс); думаю если всё аккуратно оформить, прислать куда надо патчи/пуллреквесты, документировать итд — причин не принимать данную поддержку у них не будет, и это не такие уж затраты
Требования вполне разумные. И даже в тех местах, где их сейчас реально технически сложно исполнить — полезные. Но исполнение (в комплексе) никуда не годится. Никто не хочет вкладываться в это в ущерб своим финансам, при том что конкуренты не вкладываются. В том числе и гос конторы. А если бы всё сделали строго "с такого-то дня проверяем и закрываем тех кто не успел, на отговорки и на степень аффилированности к государству плевать" — ну да, был бы некоторый кризис, но в итоге получили бы обратную связь ко всем регламентам, довели бы до хорошего вида и таки сделали бы все нужные инструменты (по-хорошему — опенсорсные и бесплатные).
Первый раз слышу чтобы победу IE кто-то благом воспринимал, кроме Microsoft'а.
А касательно гугла — по-моему с самого начала существования хрома было ясно это это инструмент монополизации и надо его максимально избегать. Лично я им не пользовался вообще никогда.
Крайне сомневаюсь что технически возможно спрятать апи (ключи доступа или что там), если его клиентская часть реализована в свободно распространяемом софте.
Хотя с другой стороны множество пользователей данных шпионских сервисов (кому они нужны в хромиуме, да и сам хромиум вообще) и множество компетентных специалистов по реверсу спрятанных ключей (из гуглхрома), вполне возможно, не пересекаются.
По мне так только хорошо если гуглобраузеры (и не только) во всех их вариациях выпилят из максимального количества мест.
Сами ключи в репозитории не хранятся и вышиваются в Chrome при билде вместе с остальными проприетарными фишками.
Ну вот и пример вышесказанного: типичный гуглопользователь считает, что "специалист по реверсу ключей из гуглхрома" это тот, у кого хватит ума разобраться в исходниках из репозитория (не всем дано, да). Так что ключи и правда надёжно спрятаны от всех заинтересованных.
Разместите на своём сайте инструкцию по отключению GSB в браузере, распишите честно, зачем это нужно и агитируйте пользователей её применять. Это, конечно, не спасёт лично ваш сайт от угрозы блокировки описанным в статье способом, и даже особо не изменит итоговый процент пользователей с включёным GSB в мире, но рассматривайте это как свой голос за то, что GSB должен быть ликвидирован. Если все так будут рассуждать и "проголосуют" — он действительно может перестать играть такую роль.
Нам хотелось бы меньше греть воздух, ведь если сократить количество железа в каждом ДЦ хотя бы на 10%, речь уже шла бы о внушительных суммах. При этом, если просто вытащить часть железа, а затем при пиковой нагрузке какой-то из ДЦ отключится, оставшиеся мощности могут не справиться.
По-моему тут что-то недоговорили. Если проблема только в энергопотреблении (как заявлено) то можно простаивающее железо и выключать, а включать только в аварийной ситуации (понятно, не мгновенно, но не думаю что это вызовет проблемы, всё-таки это по идее редкое событие). Или датацентры ежедневно вводятся/выводятся из строя?
Но за само железо в таком случае всё равно придётся платить, да, почему-то об этом не сказано.
Ну ноутбуки и всякие сервера с спец обвязкой ладно, но это же настольный комп. Неужели тут кто-то их воспринимает как неделимый продукт с завода? По-моему такое маркетингово выгодное восприятие пк только эппл смог навязать со своими маками, всё остальное это 100% конструктор и статы (включая цену) определяются суммой статов компонент + никому не нужная наценка сборщика. Всякие теоретически возможные эксклюзивные конструктивные решения с этой сфере не выдерживают конкуренции с универсальностью и 100% заменяемостью на аналоги всех деталей, в том числе для апгрейда хоть спустя 20 лет в той же коробке.
Конкретизируем задачу. Требуется проанализировать код ядра Windows в части переключения с одного потока на другой. Нужно убедиться, что никаких других случаев переключения, кроме трех перечисленных, в ядре нет. Используя результаты анализа и знание конкретного кода, переключающего потоки, требуется организовать работу планировщика так, чтобы заданный поток в течение 20-30 минут не прерывался потоками с более низким приоритетом (из-за работы диспетчера баланса), но при этом не обладал приоритетом «реального времени» и поэтому не мешал различным высокоприоритетным служебным потокам и сервисам.
Мне кажется эта задача решается намного проще и без создания дополнительного бекдор-апи к ядру. Просто динамическое повышение приоритета idle-процессов переставить с 15 на 14, сделав таким образом два уровня реалтаймовости.
Но изучить устройство ядра, конечно, интересно.
Какая хорошая новость, очередной "перспективной" технологии не выдали частоты. Нечего общий эфир засорять своими 4К видеостримингами и прочим неподъёмным мусором, для этого провода есть которые не нарушают своих частных границ. Ещё бы ранее выданные пересмотрели было бы совсем хорошо, но этого не ожидаю.
Ну да, я не точно выразился, и вобщем-то этот вариант упомянул — желающие разумеется могут помочь, но делать они это скорее всего будут там, где статья уже хорошая, чтобы сделать её ещё полезней.
В википедии же подход совсем другой — если статья нужная, то совершенно не важно кто её первоначальный автор, статья от него полностью отделена и в любом случае будет дорабатываться сообществом, а вот вторую такую же (та плохая, напишу хорошую) в качестве альтернативы создать наоборот нельзя.
Хабр это не википедия, не инструмент коллективного написания статей. За статью отвечает только её автор, остальные могут, если хотят, помочь ему исправить недочёты (написав в комментарии или в личку), но делать это не обязаны.
В целом, можно потратить своё время более продуктивно (например, просматривая развлекательные видеоролики), чем занимаясь вытягиванием некачественного контента, когда на ту же самую тему рядом полно качественного от других авторов.
Ну или посмотрим с другой стороны. Допустим, мы таки хотим организовать коллективное творчество. В таком случае автор статьи (тот, кто её опубликовал и может редактировать) — является руководителем "творческой группы". Вы хотите делать полезный контент под руководством того, кто еле разбирается (а то и вообще не разбирается) в теме (при том то сами разбираетесь)? Вряд ли, лучше написать свою статью, изначально более удачную, и остальные желающие поучаствовать лучше поучаствуют в ней. Если же статья в целом положительного качества, но имеет недоработки — за такое минусы никто не ставит. На всякий случай уточню: недоработки — это именно недоработки на фоне общего проделанного труда, а не то, когда кто-то после машинного перевода забыл скорректировать артефакт автопереводчика, или когда кто-то при копипасте из двух разных источников забыл согласовать между собой абзацы, а то в последнее время стало модно такое.
ffmpeg это и есть обёртка, добавляющая командную строку. Можно без неё — изучить api libavformat и прочего. Оказалось что в целом это более-менее несложно, несмотря на отсутствие адекватной документации.
На самом деле я понял что ваш вопрос не об этом, но понял только после того, как прочёл ответы на него (вам нужно не "без командной строки" а "с гуи").
Автор, не занимайтесь демагогией. В текущей системе образования (я не про "дистанционное") много проблем, но это никак не моет служить оправданием этому бреду.
Попытка пустить современный сверхскоростной поезд онлайн-обучения
Он современный в точно том же смысле, как "современное программирование" это веб-скриптошлёпство.
Если что, я сам много чего изучил, сидя за компом и без физических перемещений куда-либо, и не отрицаю, что данный способ чему-то научиться действительно работает. Но задачи общего образования выходят далеко за рамки этого. Более того, склоняюсь к мнению, что собственно получение профессиональных знаний — задача для системы образования вторичная и является (являлась) только официальным предлогом для посещения образовательных заведений. Во время посещения школы сам не понимал важность этих неявных аспектов, позже понял. Вы, может быть, тоже поймёте когда-нить, если повезёт. Но одно дело — ваше личное развитие, а другое — насаждать вредные практики среди остальных членов общества. Это уже либо воинствующая некомпетентность, либо злонамеренное вредительство.
вопрос интеграции ядра и загрузчика (и ее осмысленности — раз уж мы все равно не планируем ограничиваться простыми случаями).
Ну, когда одно с другим разрабатывается общим проектом, почему бы не интегрировать.
Скажите, а как в FreeBSD принято грузиться с nfs/nbd/luks?
Не особо интересовался всякими экзотическими загрузчиками, но думается все отличия заканчиваются на том моменте, где ядро с модулями уже в памяти, а дальше оно уже по штатным конфигам работает. Чтобы ядро загрузить по сети, есть pxeboot (а потом можно смонтировать / из nfs).
Вместо линуксового luks есть geli, пишут что к / оно тоже применимо, подробности лень выяснять, но ядро кажется должно лежать в незашифрованном разделе, загрузчик сам видимо расшифровывать не умеет, ссылки: 12
В FreeBSD загрузчик (не grub) умеет грузить модули для ядра из обычной файловой системы (ufs или zfs) без промежуточных виртуальных дисков. Впрочем что grub+linux мешает делать также я не знаю — файловую систему grub вроде тоже умеет парсить, но пользуется этим крайне ограниченно.
С "адаптацией" технически всё то же самое что в линуксе: модули либо вкомпилены в ядро, либо могут быть подгружены отдельно. Разница в том, что сборка модулей по дефолту включена для вообще всего (и я даже не интересовался можно ли отключить — всё равно оно компилируется быстро), а настройка при пересборке — только списка статически слинкованного в ядро, так что нужные модули после переезда всегда можно догрузить (и без пересборки всяких initrd которых нет). Но если хотите иметь идеальное ядро под конкретное железо (т.е. всё что нужно — статически слинковано, всё что не нужно — убрано в модули и не грузится) то придётся пересобрать, да. Но настройка этого всего всё равно проще чем в линуксе.
Впрочем многие (может и большинство) (как и в Linux-ах) пользуются дефолтным ядром и ничего не пересобирают — запускается оно наверно везде, а всякий тюнинг подгружают модулями.
Вообще — непонятно о чём дискуссия, ветка началась с исправления испорченной системы, а не с переезда. Переезд по-моему и там и там одинаково просто делается, если необязательные пересборки не учитывать.
А вот исправлять систему проще в FreeBSD (если сравнивать с популярными deb/rpm-based системами), потому что её НЕ надо переустанавливать, чтобы вайпнуть состояние пакетного менеджера. Можно просто удалить и создать пустыми /usr/local (если были кастомные конфиги — забекапить /usr/local/etc), /var/db/pkg (а ещё /usr/ports, /var/db/ports, /var/db/portsnap — если пакеты собирались из исходников) — и всё, в системе не осталось никаких следов пакетов, но она осталась в рабочем состоянии (с консолью), все данные (/home и /var) сохранены. Можно заново установить нужные пакеты по списку (заметно более короткому чем обычно в линуксах) и продолжить работу.
Покупки в интернет-магазинах совершают обычно именно люди. Компьютер тут средство доставки информации. С помощью обмана только программ заставить человека что-то купить невозможно, надо обмануть ещё и человека.
Если речь о том, чтобы внедрить трояна который будет покупать с аккаунта человека без его ведома — то это уже не обман и не мошенничество, а несанкционированный доступ к информационной системе или что-то похожее (хотя мошенничество тут тоже могло иметь место, но на другом этапе — как метод внедрения трояна ранее).
В случае же с ботом покупки делает именно бот, и обмануть можно именно бота — человек вообще не в курсе что там происходило, пока логи не посмотрит.
Тут важно кто именно логически нажал кнопку и в каких обстоятельствах.
А вот ещё пример
Внедрение трояна: если вы пришлёте кому-то обманное письмо, при ручном запуске замаскированного кода из которого будет устанавливаться троян — это мошенничество: вы обманули пользователя чтобы тот запустил вредоносный код. Если же троян установлен через уязвимость в каком-то сетевом сервисе — мошенничества нет, есть только взлом информационной системы с несанкционированным доступом.
В случае с ботовской покупкой картинки никакого взлома, разумеется, тоже нет.
Делегируя свои полномочия (принять решение о покупке) неправоспособной сущности (боту) — вы ставите себя в легально уязвимое положение. Не думаю, что авторы законов целенаправленно создали такую ситуацию в те далёкие времена, когда они сочинялись, но ситуация однозначно хорошая.
Нет, когда сайту надо скачать 10мб мусора (да ещё и обязательно в несколько криво синхронизированных потоков) ради вывода простой странички — это проблема сайта, а не сети.
Хотел длинно написать но думаю это лишнее.
1) полезность: выработка общей дисциплины касательно ответственного отношения к чужим данным; да, я понимаю что эти (из статьи) требования сами по себе ничего не дадут, данные всё так же будут терять/взламывать/красть/продавать, и я понимаю что государство не показывает инициатив к пресечению всего указанного (никого не посадили ни за какие утечки), но если вдруг они смогут начать хотя бы с этой стороны — всё равно хорошо, может потом, на фоне уже выработанной дисциплины, и остальное подтянут
2) "вкладываться" по моим оценкам, на конкретно эти требования надо что-то не больше 1 рубля разово с гражданина — это если правильно всё организовать и не распиливать финансирование — там всего то надо организовать включение уже много раз реализованных алгоритмов в основную ветку опенсорсных проектов (сейчас все браузеры опенсорс, топ популярные веб-сервера опенсорс, криптобиблиотеки большинство тоже опенсорс); думаю если всё аккуратно оформить, прислать куда надо патчи/пуллреквесты, документировать итд — причин не принимать данную поддержку у них не будет, и это не такие уж затраты
Требования вполне разумные. И даже в тех местах, где их сейчас реально технически сложно исполнить — полезные. Но исполнение (в комплексе) никуда не годится. Никто не хочет вкладываться в это в ущерб своим финансам, при том что конкуренты не вкладываются. В том числе и гос конторы. А если бы всё сделали строго "с такого-то дня проверяем и закрываем тех кто не успел, на отговорки и на степень аффилированности к государству плевать" — ну да, был бы некоторый кризис, но в итоге получили бы обратную связь ко всем регламентам, довели бы до хорошего вида и таки сделали бы все нужные инструменты (по-хорошему — опенсорсные и бесплатные).
Первый раз слышу чтобы победу IE кто-то благом воспринимал, кроме Microsoft'а.
А касательно гугла — по-моему с самого начала существования хрома было ясно это это инструмент монополизации и надо его максимально избегать. Лично я им не пользовался вообще никогда.
Яндекс раньше появился.
Крайне сомневаюсь что технически возможно спрятать апи (ключи доступа или что там), если его клиентская часть реализована в свободно распространяемом софте.
Хотя с другой стороны множество пользователей данных шпионских сервисов (кому они нужны в хромиуме, да и сам хромиум вообще) и множество компетентных специалистов по реверсу спрятанных ключей (из гуглхрома), вполне возможно, не пересекаются.
По мне так только хорошо если гуглобраузеры (и не только) во всех их вариациях выпилят из максимального количества мест.
wataru
Ну вот и пример вышесказанного: типичный гуглопользователь считает, что "специалист по реверсу ключей из гуглхрома" это тот, у кого хватит ума разобраться в исходниках из репозитория (не всем дано, да). Так что ключи и правда надёжно спрятаны от всех заинтересованных.
Разместите на своём сайте инструкцию по отключению GSB в браузере, распишите честно, зачем это нужно и агитируйте пользователей её применять. Это, конечно, не спасёт лично ваш сайт от угрозы блокировки описанным в статье способом, и даже особо не изменит итоговый процент пользователей с включёным GSB в мире, но рассматривайте это как свой голос за то, что GSB должен быть ликвидирован. Если все так будут рассуждать и "проголосуют" — он действительно может перестать играть такую роль.
По-моему тут что-то недоговорили. Если проблема только в энергопотреблении (как заявлено) то можно простаивающее железо и выключать, а включать только в аварийной ситуации (понятно, не мгновенно, но не думаю что это вызовет проблемы, всё-таки это по идее редкое событие). Или датацентры ежедневно вводятся/выводятся из строя?
Но за само железо в таком случае всё равно придётся платить, да, почему-то об этом не сказано.
Ну ноутбуки и всякие сервера с спец обвязкой ладно, но это же настольный комп. Неужели тут кто-то их воспринимает как неделимый продукт с завода? По-моему такое маркетингово выгодное восприятие пк только эппл смог навязать со своими маками, всё остальное это 100% конструктор и статы (включая цену) определяются суммой статов компонент + никому не нужная наценка сборщика. Всякие теоретически возможные эксклюзивные конструктивные решения с этой сфере не выдерживают конкуренции с универсальностью и 100% заменяемостью на аналоги всех деталей, в том числе для апгрейда хоть спустя 20 лет в той же коробке.
Мне кажется эта задача решается намного проще и без создания дополнительного бекдор-апи к ядру. Просто динамическое повышение приоритета idle-процессов переставить с 15 на 14, сделав таким образом два уровня реалтаймовости.
Но изучить устройство ядра, конечно, интересно.
Какая хорошая новость, очередной "перспективной" технологии не выдали частоты. Нечего общий эфир засорять своими 4К видеостримингами и прочим неподъёмным мусором, для этого провода есть которые не нарушают своих частных границ. Ещё бы ранее выданные пересмотрели было бы совсем хорошо, но этого не ожидаю.
Ну да, я не точно выразился, и вобщем-то этот вариант упомянул — желающие разумеется могут помочь, но делать они это скорее всего будут там, где статья уже хорошая, чтобы сделать её ещё полезней.
В википедии же подход совсем другой — если статья нужная, то совершенно не важно кто её первоначальный автор, статья от него полностью отделена и в любом случае будет дорабатываться сообществом, а вот вторую такую же (та плохая, напишу хорошую) в качестве альтернативы создать наоборот нельзя.
Хабр это не википедия, не инструмент коллективного написания статей. За статью отвечает только её автор, остальные могут, если хотят, помочь ему исправить недочёты (написав в комментарии или в личку), но делать это не обязаны.
В целом, можно потратить своё время более продуктивно (например, просматривая развлекательные видеоролики), чем занимаясь вытягиванием некачественного контента, когда на ту же самую тему рядом полно качественного от других авторов.
Ну или посмотрим с другой стороны. Допустим, мы таки хотим организовать коллективное творчество. В таком случае автор статьи (тот, кто её опубликовал и может редактировать) — является руководителем "творческой группы". Вы хотите делать полезный контент под руководством того, кто еле разбирается (а то и вообще не разбирается) в теме (при том то сами разбираетесь)? Вряд ли, лучше написать свою статью, изначально более удачную, и остальные желающие поучаствовать лучше поучаствуют в ней. Если же статья в целом положительного качества, но имеет недоработки — за такое минусы никто не ставит. На всякий случай уточню: недоработки — это именно недоработки на фоне общего проделанного труда, а не то, когда кто-то после машинного перевода забыл скорректировать артефакт автопереводчика, или когда кто-то при копипасте из двух разных источников забыл согласовать между собой абзацы, а то в последнее время стало модно такое.
ffmpeg это и есть обёртка, добавляющая командную строку. Можно без неё — изучить api libavformat и прочего. Оказалось что в целом это более-менее несложно, несмотря на отсутствие адекватной документации.
На самом деле я понял что ваш вопрос не об этом, но понял только после того, как прочёл ответы на него (вам нужно не "без командной строки" а "с гуи").
Автор, не занимайтесь демагогией. В текущей системе образования (я не про "дистанционное") много проблем, но это никак не моет служить оправданием этому бреду.
Он современный в точно том же смысле, как "современное программирование" это веб-скриптошлёпство.
Если что, я сам много чего изучил, сидя за компом и без физических перемещений куда-либо, и не отрицаю, что данный способ чему-то научиться действительно работает. Но задачи общего образования выходят далеко за рамки этого. Более того, склоняюсь к мнению, что собственно получение профессиональных знаний — задача для системы образования вторичная и является (являлась) только официальным предлогом для посещения образовательных заведений. Во время посещения школы сам не понимал важность этих неявных аспектов, позже понял. Вы, может быть, тоже поймёте когда-нить, если повезёт. Но одно дело — ваше личное развитие, а другое — насаждать вредные практики среди остальных членов общества. Это уже либо воинствующая некомпетентность, либо злонамеренное вредительство.
Ну, когда одно с другим разрабатывается общим проектом, почему бы не интегрировать.
Не особо интересовался всякими экзотическими загрузчиками, но думается все отличия заканчиваются на том моменте, где ядро с модулями уже в памяти, а дальше оно уже по штатным конфигам работает. Чтобы ядро загрузить по сети, есть pxeboot (а потом можно смонтировать / из nfs).
Вместо линуксового luks есть geli, пишут что к / оно тоже применимо, подробности лень выяснять, но ядро кажется должно лежать в незашифрованном разделе, загрузчик сам видимо расшифровывать не умеет, ссылки: 1 2
В FreeBSD загрузчик (не grub) умеет грузить модули для ядра из обычной файловой системы (ufs или zfs) без промежуточных виртуальных дисков. Впрочем что grub+linux мешает делать также я не знаю — файловую систему grub вроде тоже умеет парсить, но пользуется этим крайне ограниченно.
С "адаптацией" технически всё то же самое что в линуксе: модули либо вкомпилены в ядро, либо могут быть подгружены отдельно. Разница в том, что сборка модулей по дефолту включена для вообще всего (и я даже не интересовался можно ли отключить — всё равно оно компилируется быстро), а настройка при пересборке — только списка статически слинкованного в ядро, так что нужные модули после переезда всегда можно догрузить (и без пересборки всяких initrd которых нет). Но если хотите иметь идеальное ядро под конкретное железо (т.е. всё что нужно — статически слинковано, всё что не нужно — убрано в модули и не грузится) то придётся пересобрать, да. Но настройка этого всего всё равно проще чем в линуксе.
Впрочем многие (может и большинство) (как и в Linux-ах) пользуются дефолтным ядром и ничего не пересобирают — запускается оно наверно везде, а всякий тюнинг подгружают модулями.
Вообще — непонятно о чём дискуссия, ветка началась с исправления испорченной системы, а не с переезда. Переезд по-моему и там и там одинаково просто делается, если необязательные пересборки не учитывать.
А вот исправлять систему проще в FreeBSD (если сравнивать с популярными deb/rpm-based системами), потому что её НЕ надо переустанавливать, чтобы вайпнуть состояние пакетного менеджера. Можно просто удалить и создать пустыми /usr/local (если были кастомные конфиги — забекапить /usr/local/etc), /var/db/pkg (а ещё /usr/ports, /var/db/ports, /var/db/portsnap — если пакеты собирались из исходников) — и всё, в системе не осталось никаких следов пакетов, но она осталась в рабочем состоянии (с консолью), все данные (/home и /var) сохранены. Можно заново установить нужные пакеты по списку (заметно более короткому чем обычно в линуксах) и продолжить работу.
С каких пор видеозвонки по http делаются?
А webrtc (звонки через браузер) как раз поверх udp обычно, но к теме это не относится — http там нет.
Покупки в интернет-магазинах совершают обычно именно люди. Компьютер тут средство доставки информации. С помощью обмана только программ заставить человека что-то купить невозможно, надо обмануть ещё и человека.
Если речь о том, чтобы внедрить трояна который будет покупать с аккаунта человека без его ведома — то это уже не обман и не мошенничество, а несанкционированный доступ к информационной системе или что-то похожее (хотя мошенничество тут тоже могло иметь место, но на другом этапе — как метод внедрения трояна ранее).
В случае же с ботом покупки делает именно бот, и обмануть можно именно бота — человек вообще не в курсе что там происходило, пока логи не посмотрит.
Тут важно кто именно логически нажал кнопку и в каких обстоятельствах.
Внедрение трояна: если вы пришлёте кому-то обманное письмо, при ручном запуске замаскированного кода из которого будет устанавливаться троян — это мошенничество: вы обманули пользователя чтобы тот запустил вредоносный код. Если же троян установлен через уязвимость в каком-то сетевом сервисе — мошенничества нет, есть только взлом информационной системы с несанкционированным доступом.
В случае с ботовской покупкой картинки никакого взлома, разумеется, тоже нет.
Делегируя свои полномочия (принять решение о покупке) неправоспособной сущности (боту) — вы ставите себя в легально уязвимое положение. Не думаю, что авторы законов целенаправленно создали такую ситуацию в те далёкие времена, когда они сочинялись, но ситуация однозначно хорошая.
Нет, когда сайту надо скачать 10мб мусора (да ещё и обязательно в несколько криво синхронизированных потоков) ради вывода простой странички — это проблема сайта, а не сети.
Вот же городят костыль на костыле, чтобы криво написанные сайты в криво написанных браузерах меньше лагали.