были случаи, что Роском блокировал учётки разработчиков???
Понятия не имею.
Когда будут тогда и приходите. Теоретически может метеорит завтра упасть и тогда технологии точно никакой не будет. А на практике всё по другому.
И как вы будете с этих двадцати хостингов сводить информацию в один файл?
Очень просто! Сайты будут статичными. Вся информация хранится в файле соответствий в xml. Захожу в админку, прописываю ip адрес где находится файл xml и всё. Сайт работает! Конечно это я объясняю на пальцах. На самом деле найдётся миллион технологий, которые мне облегчат задачу. И будет всё работать совсем по другому.
Как не имеет отношения??? А DoubleDomain технология на что? Именно она и говорит и подтверждает достоверность второго сайта, который тоже имеет сертификат.
Какие это политики безопасности при этом нарушаются???
Где вы это берёте? Нет таких пунктов в соглашении с разработчиком!
developer.chrome.com/webstore/terms
были случаи, что Роском блокировал учётки разработчиков???
Это не спасает от банального удаления файла.
когда файл лежит на зарубежном noname хостинге спасает.
Ну и прокси тоже блокируются…
Пример, пожалуйста. Я ни разу не слышал о блокировке прокси. По какому закону?
А главное, если есть такой прокси — то зачем нужен ваш механизм, почему просто через прокси не пойти?
Потому что мой механизм работает на скорости интернета. И предоставляет возможность обращения по разным протоколам, например http, ftp, nmdc. А прокси — это облезлый кот в мешке))
и, как следствие, вся ваша красивая идея про аптайм с грохотом летит в мусорку.
Я просто уже где-то об этом писал. Сайт находится отдельно от файла соответствий (БД). Простейший сайт я смогу хранить раскопировать на 20 разных хостингов. При блокировке текущего сайта я просто буду менять сайт В этого сайта и всё. Заблокировали по ip адресу хостинг — поменял домен В. Заблокировали — поменял. Заблокировали по домену — вообще хостинг не надо менять, поменяю только no-ip домен, что делается в 60 секунд! Всё просто. Главное доступ к файлу БД, а не сайту. Сайт — это вторично.
Кстати, а откуда возьмется сертификат от первого сайта, учитывая что сайт недоступен?
Не откуда не возьмётся. Первого сайта нет. Зато будет красивая табличка DoubleDomain, которая будет означать — всё хорошо, зато есть сайт В и у него есть сертификат!..
А у нас что 20 разных БД? Всё та же БД с соответствиями сайтов.
Это значит, что ваше утверждение «переход на сайт В выполняется в случае [...] редиректа 301, 302, 303, 307» ложно.
Вы правы. Люди не понимающие сути технологии могут понять не правильно. Хотя, если подумать, то нужно как-то понять на какой сайт В будет происходить переадресация. Тогда всё становится правильно и логично.
Ваша «маленькая кнопочка» прячет от пользователя эту информацию.
Точно так же, как прячется информация о сертификате.
Кстати, а где посмотреть на код вашего расширения, не ставя его?
Конечно же скоро на Гитхабе у меня в репозиториях.
Таким образом, один (из двух возможных) критериев для замены домена в вашей технологии — это «незарегистрированный хостнейм». Как вы собираетесь это определять? Как это поможет во всех остальных описанных вами ситуациях (авария, DDos, блокировка)?
Очевидно проверять соответствие в БД по полному запросу и второй раз по домену.
Очевидно увидит переадресацию 302.
Куда?
Туда куда указал переадресацию. DD — тут не будет ни на что влиять.
по крайней мере, в вашем описании — прячет от пользователя информацию о реальном хосте и сертификате, с которого пришел трафик.
Ну можно там маленькую кнопочку нарисовать в url с буквами DD. Это так просто, что программист не стал бы это спрашивать.
А что пользователь увидит, когда нажмет на «детали сертификата»?
Увидит всю правду. Что там два сайта и два сертификата, а он сейчас на втором. По маленькой кнопочке пользователь может узнать всё что захочет разумеется.
Пункты 4.2.b и 4.4.1.2 соглашения разработчика Google Chrome Web Store.
Где вы это берёте? Нет таких пунктов в соглашении с разработчиком!
А что — прокси? Вы даже не описали, как вы его использовать будете.
Буду запускать проксированный ajax запрос конечно же.
Ну и да, вы полностью проигнорировали второй описанный вектор атаки.
Мне не показалось это каким-то вектором атаки.
«механизм, которым «владелец сайта» эти файлы формирует» — работоспособность обеспечивается файлом соответствий. Обновление и доступ к файлу соответствий обеспечивается обновлением расширения. Думал мы это уже обсудили.
В данном контексте урл — это доменное имя. Их регистрируют у доменных регистраторов.
Что увидит пользователь, у которого установлено расширение DoubleDomain, если я подключу свой сайт к DoubleDomain, при выполнении этого запроса?
Очевидно увидит переадресацию 302.
Основная задача https — это гарантировать конфиденциальность и подлинность трафика.
DoubleDomain не нарушает этих принципов. Гарантия 100%. Ведь только хозяин сайта может установить сайт В. Какая разница установил он сайт А или сайт В или поставил сайт А, как сайт В. Это всё не важно. Если есть https, то будет шифрование. Трафик от одного хозяина сайта. Доверие к трафику 100% и не % меньше! И это при условии, что сервис предоставляет изготовитель браузера, которому доверие должно быть 200%.
Так учетку может заблокировать только компания Гугл! Причём тут Роском? Или были случаи, что Роском блокировал учётки разработчиков??? Что-то не припомню такого.
И вы ничего не написали про прокси. Что с прокси? Прокси тоже уже блокируют??? Где информация???
Теоретически-то можно всё что угодно. Но есть практика, которая, почему-то совсем не вяжется с вашей теорией.
Например сайты торент трекеров никто не блокирует… что говорить о p2p хабах, которые исчисляются сотнями и тысячами. Видимо не всё так просто, как пишите вы.
Тоже не плохая идея. Создать универсальный, локальный ДНС сервер с загружаемыми зонами. Тогда все программы будут работать правильно. Но это немного сложнее.
«неправильный url» — это url, который нигде не зарегистрирован.
Как это влияет на определение ошибочной ситуации?
Повлияет прямо. Так как владелец сайта и только владелец сайта может создавать перенаправления со своего сайта, либо отключить их вообще. Т.е. полный контроль над перенаправлениями.
Это прямо противоречит идеологии HTTPS, вообще-то.
Почему? Ведь основная задача https — это шифровать трафик. Браузер, конечно сам будет открывать второй сайт. Так что это очень безопасно и трафик шифруется и сайт открывается. Какие недостатки???
Как же так? А это??:
Будет, либо получение файла через прокси, либо 20 разных источников и при заблокированных 5 на утро я буду запускать обновление, которое добавит новые 5 источников.
Это, простите, каким образом вы это собираетесь реализовать?
Уже реализовал! Посмотрите принцип работы расширения! Это возможно силами api расширения.
А что здесь «ошибочного»?
Ну не правильный же url. Тут я использую терминалогию js программиста, который написал расширение. В api это событие совершенно точно называется error. Поэтому ошибка.
Как это влияет на определение ошибочной ситуации?
Что за ошибочная ситуация???
А при чем тут ваше расширение? Вы, вроде бы, для мира технологию предлагаете.
Для мира и пусть продумывают программисты мировые. Внедрить технологию в браузер не сложно. Там совсем другими категориями люди мыслят. Например там будет речь идти уже о изменении запросов на лету. Вообще да. Логически получается, что для сайта В нужен свой сертификат. А браузер просто будет делать подмену незаметно для пользователя. Да да. Незаметную подмену https сайтов.
Думаю это не большая беда для того у кого сайт заблокировали совсем :-)
И вы не забывайте, что недоступности сервиса совсем не будет! Мы же решили это в процессе обсуждения. Будет, либо получение файла через прокси, либо 20 разных источников и при заблокированных 5 на утро я буду запускать обновление, которое добавит новые 5 источников.
100% Бесперебойный сервис!
Где я написал, что это будет даунтайм??? Отсутствие обновлений не означает, что всё лежать будет. Всё будет работать, просто без ежесекундных обновлений. Замечу, что отсутствие падения после блокировки Роскомом тоже очень не плохо.
Вот именно этот алгоритм и хранят закрытые сервера no-ip компании. И именно этот алгоритм может менять любая no-ip компания по своему усмотрению. Что они и делают! Например, берут деньги за его работу. А если деньги не заплатил — отключают алгоритм. И они могут делать это, потому что они и только они хранят этот алгоритм и управляют им. Так где гарантии, что алгоритм не изменится на перенаправление всех no-ip сайтов на пару минут на проксирующий сайт с подменой каких-нибудь adsense.com???
А что вообще критичного в обновлении? Есть локальная копия всех соответствий. Ну подумаешь 2 часа не будет обновлений и что? Это означает то что не будет новых изменений, а старые все будут работать, как работали.
А я вам прямо сейчас скажу: стандартный способ решения называется… dns-сервер. Старая, проверенная, работающая технология.
Dns сервер стоит выше по очереди обращения запроса пользователя. Сначала на днс сервер, а потом уже по условию в DoubleDomain.
Что такое «ошибка доступа к сайту»?
Вас не смущает, что все 3хх коды используются сайтами при нормальной работе и не означают, что с сайтом что-то случилось?
Ошибка доступа к сайту — это когда вы набираете не существующий сайт и переходите на него.
3хх коды — да используются сайтами. И могут свободно продолжать использоваться. Для того что бы прекратить их использование необходимо выполнить все условия:
1) пользователям этих сайтов поставить расширение DoubleDomain.
2) на сайте DoubleDomain подтвердить владение сайтом
3) добавить соответствие подтверждённого сайта А и любого сайта В.
Это может сделать только хозяин сайта А.
Опять-таки, вы же хотите сделать подмену незаметно для пользователя? И как в этом случае это будет сочетаться?
Пока что рано об этом вообще думать. Так как в моём расширении используются iframe, которые совсем, почти не открывают https сайты.
Ну что-то тором я никак не могу начать пользоваться. Я бы не сказал, что тор это проще. Тор — это как раз сложнее. Расширение позволяет пользоваться привычным браузером, а тор — это какой-то другой неизвестный браузер. Что в нём? Кто знает. Может бекдор? :-D Шутка.
Моё расширение просто и понятно. Ставишь и имеешь бесперебойный доступ. Не ставишь и имеешь страницы с ошибками.
Исходный код открыт. Бери и модернизируй. И вообще многие берут, правят имя и версию и выставляют, как своё расширение. Ничего не поделать… этого не запретить.
Не думаю, что будет много файлов. Для доступа к файлам, конечно есть фтп.
Что это??? Конкретно какие мелочи???
Лично в моей программе всё уже давно работает и давно. И не работало бы без этой прекрасной технологии.
Вы там, что меняетесь? Разные люди пишут???
Как не известен! Разработчик будет — разработчик браузера! Доверие к нему 200%!!!
Ну пусть тогда банк либо откажется от этой технологии, либо исправит свои политики.
Когда будут тогда и приходите. Теоретически может метеорит завтра упасть и тогда технологии точно никакой не будет. А на практике всё по другому.
Очень просто! Сайты будут статичными. Вся информация хранится в файле соответствий в xml. Захожу в админку, прописываю ip адрес где находится файл xml и всё. Сайт работает! Конечно это я объясняю на пальцах. На самом деле найдётся миллион технологий, которые мне облегчат задачу. И будет всё работать совсем по другому.
Информацию в файл записывает сайт.
Какие это политики безопасности при этом нарушаются???
были случаи, что Роском блокировал учётки разработчиков???
когда файл лежит на зарубежном noname хостинге спасает.
Пример, пожалуйста. Я ни разу не слышал о блокировке прокси. По какому закону?
Потому что мой механизм работает на скорости интернета. И предоставляет возможность обращения по разным протоколам, например http, ftp, nmdc. А прокси — это облезлый кот в мешке))
Я просто уже где-то об этом писал. Сайт находится отдельно от файла соответствий (БД). Простейший сайт я смогу хранить раскопировать на 20 разных хостингов. При блокировке текущего сайта я просто буду менять сайт В этого сайта и всё. Заблокировали по ip адресу хостинг — поменял домен В. Заблокировали — поменял. Заблокировали по домену — вообще хостинг не надо менять, поменяю только no-ip домен, что делается в 60 секунд! Всё просто. Главное доступ к файлу БД, а не сайту. Сайт — это вторично.
Не откуда не возьмётся. Первого сайта нет. Зато будет красивая табличка DoubleDomain, которая будет означать — всё хорошо, зато есть сайт В и у него есть сертификат!..
А у нас что 20 разных БД? Всё та же БД с соответствиями сайтов.
Вы правы. Люди не понимающие сути технологии могут понять не правильно. Хотя, если подумать, то нужно как-то понять на какой сайт В будет происходить переадресация. Тогда всё становится правильно и логично.
Точно так же, как прячется информация о сертификате.
Конечно же скоро на Гитхабе у меня в репозиториях.
Очевидно проверять соответствие в БД по полному запросу и второй раз по домену.
Туда куда указал переадресацию. DD — тут не будет ни на что влиять.
Ну можно там маленькую кнопочку нарисовать в url с буквами DD. Это так просто, что программист не стал бы это спрашивать.
Увидит всю правду. Что там два сайта и два сертификата, а он сейчас на втором. По маленькой кнопочке пользователь может узнать всё что захочет разумеется.
Где вы это берёте? Нет таких пунктов в соглашении с разработчиком!
Буду запускать проксированный ajax запрос конечно же.
Мне не показалось это каким-то вектором атаки.
«механизм, которым «владелец сайта» эти файлы формирует» — работоспособность обеспечивается файлом соответствий. Обновление и доступ к файлу соответствий обеспечивается обновлением расширения. Думал мы это уже обсудили.
В данном контексте урл — это доменное имя. Их регистрируют у доменных регистраторов.
Очевидно увидит переадресацию 302.
DoubleDomain не нарушает этих принципов. Гарантия 100%. Ведь только хозяин сайта может установить сайт В. Какая разница установил он сайт А или сайт В или поставил сайт А, как сайт В. Это всё не важно. Если есть https, то будет шифрование. Трафик от одного хозяина сайта. Доверие к трафику 100% и не % меньше! И это при условии, что сервис предоставляет изготовитель браузера, которому доверие должно быть 200%.
И вы ничего не написали про прокси. Что с прокси? Прокси тоже уже блокируют??? Где информация???
Теоретически-то можно всё что угодно. Но есть практика, которая, почему-то совсем не вяжется с вашей теорией.
Например сайты торент трекеров никто не блокирует… что говорить о p2p хабах, которые исчисляются сотнями и тысячами. Видимо не всё так просто, как пишите вы.
Тоже не плохая идея. Создать универсальный, локальный ДНС сервер с загружаемыми зонами. Тогда все программы будут работать правильно. Но это немного сложнее.
«неправильный url» — это url, который нигде не зарегистрирован.
Повлияет прямо. Так как владелец сайта и только владелец сайта может создавать перенаправления со своего сайта, либо отключить их вообще. Т.е. полный контроль над перенаправлениями.
Почему? Ведь основная задача https — это шифровать трафик. Браузер, конечно сам будет открывать второй сайт. Так что это очень безопасно и трафик шифруется и сайт открывается. Какие недостатки???
Как же так? А это??:
Будет, либо получение файла через прокси, либо 20 разных источников и при заблокированных 5 на утро я буду запускать обновление, которое добавит новые 5 источников.
Уже реализовал! Посмотрите принцип работы расширения! Это возможно силами api расширения.
Ну не правильный же url. Тут я использую терминалогию js программиста, который написал расширение. В api это событие совершенно точно называется error. Поэтому ошибка.
Что за ошибочная ситуация???
Для мира и пусть продумывают программисты мировые. Внедрить технологию в браузер не сложно. Там совсем другими категориями люди мыслят. Например там будет речь идти уже о изменении запросов на лету. Вообще да. Логически получается, что для сайта В нужен свой сертификат. А браузер просто будет делать подмену незаметно для пользователя. Да да. Незаметную подмену https сайтов.
И вы не забывайте, что недоступности сервиса совсем не будет! Мы же решили это в процессе обсуждения. Будет, либо получение файла через прокси, либо 20 разных источников и при заблокированных 5 на утро я буду запускать обновление, которое добавит новые 5 источников.
100% Бесперебойный сервис!
Dns сервер стоит выше по очереди обращения запроса пользователя. Сначала на днс сервер, а потом уже по условию в DoubleDomain.
Ошибка доступа к сайту — это когда вы набираете не существующий сайт и переходите на него.
3хх коды — да используются сайтами. И могут свободно продолжать использоваться. Для того что бы прекратить их использование необходимо выполнить все условия:
1) пользователям этих сайтов поставить расширение DoubleDomain.
2) на сайте DoubleDomain подтвердить владение сайтом
3) добавить соответствие подтверждённого сайта А и любого сайта В.
Это может сделать только хозяин сайта А.
Пока что рано об этом вообще думать. Так как в моём расширении используются iframe, которые совсем, почти не открывают https сайты.
Моё расширение просто и понятно. Ставишь и имеешь бесперебойный доступ. Не ставишь и имеешь страницы с ошибками.
Исходный код открыт. Бери и модернизируй. И вообще многие берут, правят имя и версию и выставляют, как своё расширение. Ничего не поделать… этого не запретить.