И без GDPR утечка персональных данных представляет существенные репутационные риски. GDPR к ним добавляет произвольные штрафы. Штрафы — это, конечно, неприятно, но не всё ли равно, когда твоя компания уже банкрот?
И получить отписку об удалении данных, хотя все прекрасно понимают что на самом деле данные всё равно удаляются лишь пометкой об удалении. Только недалёкий человек поверит что его данные в самом деле удалены. Закон для идиотов, от идиотов.
У них наверняка такая же тема как с примером с аккумуляторами. Если просто продавать магниты, то проблем не будет, а если продавать магнит с пометкой "для остановки счётчика воды" или с подобной (для чего их сейчас используют?), то это будет отказ.
Читаю ваш комментарий и понимаю что вы действительно не понимаете что делает CDN, каким образом работает, какое отношение имеет к "виртуалка" и Апачу, и так далее. Взять хотя бы объяснение про причины именно такой работы. Вы действительно считаете что под каждое доменное имя не заводят отдельную конфигурацию, или, например, не выделяют какие-то конкретные IP согласно внутренних алгоритмов CDN?..
Чтобы вам помочь и объяснить действительно все детали и особенности работы современных CDN, статью нужно сделать в два раза длинней. Извините, на такое я не готов пойти. И это будет статья не про доменное прикрытие, а про архитектуру CDN.
Если у вас есть конкретные предложения по улучшению конкретно этой статьи, но не такие, чтобы статью пришлось увеличить в два раза, очень жду.
Телеграм не просто может менять IP адреса, а может и выдавать разным людям — разные IP адреса. Значит цензура просто не сможет знать все IP адреса, которыми пользуется Телеграм, подглядывая за работой официального клиента. Даже блокировкой подсетей от этого не защититься: ведь как заблокировать то, не знаешь что?..
Значит тут остаётся только вариант прессовать провайдеров облачных услуг чтобы те выгнали Телеграм со своих мощностей, что и происходит. РКН сейчас как такие гопники-рэкетиры пытаются сыграть с Телеграмом ещё раз ту карту, с которой у них получилось раньше с Zello, без стеснения заявляя что символично блокируют ровно половину IP адресов AWS. Правда, учитывая незначительность российского рынка для облачных компаний, важность облачных сервисов для российских организаций, и политический накал ситуации (Жаров находится под санкциями), в этот раз трюк пока не работает так, как в прошлый раз.
Современные и даже уже устаревшие процессоры легко делают AES со скоростью больше гигабайта в секунду, о каких тоннах угля вы говорите? Десять-пятнадцать лет назад шифрование может быть и было проблемой, но в наше время затраты на шифрования ничтожны по сравнению с преимуществами в части безопасности и конфиденциальности, которые оно даёт.
Простите ради бога, но если бы подобная статья была совсем для совсем далёких от IT читателей, которые ни одной идеи о работе HTTP не имеют, то какое место такой статье было бы на Хабре, который позиционирует себя как крупнейший в Европе ресурс для IT-специалистов? У нас тут технически подкованная аудитория, которую не удивишь RFC 2616. На Хабре да на пальцах рассказывать про заголовок Host — всё равно что своих читателей не уважать.
Нет, не упустили. Эта идея действительно сработает если цензор не будет присматриваться к деталям, а это будет если ваше приложение (а мы говорим об обходе цензуры для приложений), не будет представлять сколько-нибудь особого интереса. Телеграм явно не такое приложение никому не интересное приложение. Потому такую идею будет сложно применить на практике для сколько-нибудь популярных приложений.
Не Телеграм, а Signal. И даже не Signal, а хакеры из группы APT29. До того как эти личности начали для своих тёмных делишек использовать эту возможность, никому не было дела до того что Signal использует google.com для обхода цензуры. В статье даже написано что Signal пользовался этим приёмом больше года. Всё это время его приёмы никому не мешали.
Не просто запомнить, а наложить это новое знание на все другие знания о методах обычных объектов, у которых как правило противоположное поведение. Тут сразу появляется широкое поле для всевозможных ошибок.
Признаться честно даже если такие массивы будут иммутабельные, это нисколько не сделает PHP как язык лучше, а наоборот — сделает работу с массивами ещё сложней и запутанней, чем она уже есть.
Например, сейчас ты вызываешь функцию и получаешь результат. Плохая или хорошая функция, всё очень понятно и однозначно.
В отличии от старых функций, с таким новым API типа как у объектов нужно будет в голове держать кучу контекстов: что это и не настоящий объект, и что он не меняется, и что нужно обязательно сохранять результат в какой-то другой переменной. Стоит ли такое новое API таких новых требований — я не уверен.
Функции, работающие с массивами, не меняют исходный массив, за некоторым исключением. Вы считаете что методы вида $arr->map(...) и $arr->filter(...) должны следовать исходной семантике, или должны менять исходный массив, на котором они вызываются?
Если первое, то значит ли что ваше API всегда нужно будет использовать вызывая методы по цепочке?..
Если второе, то каким образом, вы считаете, пользователь вашего API сможет сохранять исходный массив, если объекты в PHP по умолчанию передаются по ссылке? Всегда использовать clone при присвоении массивов?..
В том числе из-за таких вопросов мы до сих пор используем array_map, а не делаем composer install ... и используем какую-то библиотеку, реализующую подобный функционал, даже не смотря на то, что такие библиотеки уже есть. Они просто неудобны в использовании, потому подобного функционала вы не увидите в самом языке.
И без GDPR утечка персональных данных представляет существенные репутационные риски. GDPR к ним добавляет произвольные штрафы. Штрафы — это, конечно, неприятно, но не всё ли равно, когда твоя компания уже банкрот?
Недопустимость утечек стала ещё более важна.
И получить отписку об удалении данных, хотя все прекрасно понимают что на самом деле данные всё равно удаляются лишь пометкой об удалении. Только недалёкий человек поверит что его данные в самом деле удалены. Закон для идиотов, от идиотов.
Ключ в открытой сети?
Нет проблем! Вы можете указать любой номер телефона, никакой проверки отправкой SMS магазины не делают.
Почти 30% оставшихся — не поддерживают, к сожалению.
У них наверняка такая же тема как с примером с аккумуляторами. Если просто продавать магниты, то проблем не будет, а если продавать магнит с пометкой "для остановки счётчика воды" или с подобной (для чего их сейчас используют?), то это будет отказ.
Читаю ваш комментарий и понимаю что вы действительно не понимаете что делает CDN, каким образом работает, какое отношение имеет к "виртуалка" и Апачу, и так далее. Взять хотя бы объяснение про причины именно такой работы. Вы действительно считаете что под каждое доменное имя не заводят отдельную конфигурацию, или, например, не выделяют какие-то конкретные IP согласно внутренних алгоритмов CDN?..
Чтобы вам помочь и объяснить действительно все детали и особенности работы современных CDN, статью нужно сделать в два раза длинней. Извините, на такое я не готов пойти. И это будет статья не про доменное прикрытие, а про архитектуру CDN.
Если у вас есть конкретные предложения по улучшению конкретно этой статьи, но не такие, чтобы статью пришлось увеличить в два раза, очень жду.
Телеграм не просто может менять IP адреса, а может и выдавать разным людям — разные IP адреса. Значит цензура просто не сможет знать все IP адреса, которыми пользуется Телеграм, подглядывая за работой официального клиента. Даже блокировкой подсетей от этого не защититься: ведь как заблокировать то, не знаешь что?..
Значит тут остаётся только вариант прессовать провайдеров облачных услуг чтобы те выгнали Телеграм со своих мощностей, что и происходит. РКН сейчас как такие гопники-рэкетиры пытаются сыграть с Телеграмом ещё раз ту карту, с которой у них получилось раньше с Zello, без стеснения заявляя что символично блокируют ровно половину IP адресов AWS. Правда, учитывая незначительность российского рынка для облачных компаний, важность облачных сервисов для российских организаций, и политический накал ситуации (Жаров находится под санкциями), в этот раз трюк пока не работает так, как в прошлый раз.
Современные и даже уже устаревшие процессоры легко делают AES со скоростью больше гигабайта в секунду, о каких тоннах угля вы говорите? Десять-пятнадцать лет назад шифрование может быть и было проблемой, но в наше время затраты на шифрования ничтожны по сравнению с преимуществами в части безопасности и конфиденциальности, которые оно даёт.
Простите ради бога, но если бы подобная статья была совсем для совсем далёких от IT читателей, которые ни одной идеи о работе HTTP не имеют, то какое место такой статье было бы на Хабре, который позиционирует себя как крупнейший в Европе ресурс для IT-специалистов? У нас тут технически подкованная аудитория, которую не удивишь RFC 2616. На Хабре да на пальцах рассказывать про заголовок
Host— всё равно что своих читателей не уважать.Нет, не упустили. Эта идея действительно сработает если цензор не будет присматриваться к деталям, а это будет если ваше приложение (а мы говорим об обходе цензуры для приложений), не будет представлять сколько-нибудь особого интереса. Телеграм явно не такое приложение никому не интересное приложение. Потому такую идею будет сложно применить на практике для сколько-нибудь популярных приложений.
Уже сама формулировка "сайт без https" в наше время вызывает вопросы. Let's Encrypt опять же.
По умолчанию и из коробки такая проверка не делается, правильно?
Не Телеграм, а Signal. И даже не Signal, а хакеры из группы APT29. До того как эти личности начали для своих тёмных делишек использовать эту возможность, никому не было дела до того что Signal использует google.com для обхода цензуры. В статье даже написано что Signal пользовался этим приёмом больше года. Всё это время его приёмы никому не мешали.
Не просто запомнить, а наложить это новое знание на все другие знания о методах обычных объектов, у которых как правило противоположное поведение. Тут сразу появляется широкое поле для всевозможных ошибок.
Не обязательно однозначно, но предсказуемо. Достаточно запомнить как работает конкретная функция, не нужно держать в голове ещё какие-то концепты.
Признаться честно даже если такие массивы будут иммутабельные, это нисколько не сделает PHP как язык лучше, а наоборот — сделает работу с массивами ещё сложней и запутанней, чем она уже есть.
Например, сейчас ты вызываешь функцию и получаешь результат. Плохая или хорошая функция, всё очень понятно и однозначно.
В отличии от старых функций, с таким новым API типа как у объектов нужно будет в голове держать кучу контекстов: что это и не настоящий объект, и что он не меняется, и что нужно обязательно сохранять результат в какой-то другой переменной. Стоит ли такое новое API таких новых требований — я не уверен.
Функции, работающие с массивами, не меняют исходный массив, за некоторым исключением. Вы считаете что методы вида
$arr->map(...)и$arr->filter(...)должны следовать исходной семантике, или должны менять исходный массив, на котором они вызываются?cloneпри присвоении массивов?..В том числе из-за таких вопросов мы до сих пор используем
array_map, а не делаемcomposer install ...и используем какую-то библиотеку, реализующую подобный функционал, даже не смотря на то, что такие библиотеки уже есть. Они просто неудобны в использовании, потому подобного функционала вы не увидите в самом языке.Как вы технически собираетесь сделать "контейнер" с телегой? Ну например, вы будете делать
docker run ...что?Вообще здесь лишнее, тут нет вопросов. Если не секрет, вы систематически мониторите реестр на предмет своих IP, или это разовая ситуация по случаю?