[TC] Доступность интернет сервисов.
Здравствуйте, уважаемые участники рассылки,
Хочу высказаться по поводу проблемы недоступности для незрячих
некоторых сервисов в интернете.
Первое, из чего, как мне кажется, надо исходить, это понимание целей
применения провайдерами механизмов ограничения доступа к их сервисам.
По-моему, единственная их цель - минимизация злоупотреблений их
ресурсами. Ну, в самом деле, что с того, что зарегистрируется робот. а
не человек? И не ужели человек вручную не может зарегистрировать ящик
для робота? Зло для провайдера заключается в захвате роботом ресурсов
сервера. В нашей дискуссии мы касаемся только одной стороны этой
проблемы. Очевидно, что, например, ограничения на количество
отсылаемых за интервал времени писем, и на количество адресатов в
одном письме, суть проявления той же проблемы. Нам мешает только один
из методов защиты.
Борьба с мешающим нам механизмом защиты может идти по очень широкому
фронту. Можно представить себе достаточно общие решения, например,
законодательное требование к провайдерам обеспечивать доступность к их
сервисам для инвалидов, в частности, для незрячих. Понятно, что
результата на этом пути добиться трудно, но почему бы в Думу не
направить соответствующее открытое письмо, с его размещением там же,
где статья о предлагаемых методах решения? Если даже и не подействует
на депутатов, то создаст некоторое косвенное психологическое давление
на провайдеров.
Банк IP адресов вполне позволяет иметь всем интернет юзерам статические
адреса. Это само по себе сняло массу проблем с отслеживанием
злоупотреблений в интернете. Это - тоже пример общего решения, но
боюсь, работать в этом направлении совершенно бесперспективно.
Во-вторых, я думаю, что провайдерам надо предлагать как можно более
широкий спектр решений, не ограничиваясь одним, оптимальным с нашей
точки зрения.
Я бы разделил недоступные нам сервисы на группы. Сходу напрашиваются
регистрации и отправка SMS. Мне кажется, что для каждой группы
варианты решения не обязательно должны совпадать.
Для регистрации помимо звукового теста можно предложить обычный или
модифицированный метод почтового подтверждения, механизм приглашений
а-ля почтовик gmail.com, и официальное указание провайдера своим
службам технической поддержки принимать по почте заявки на регистрацию
от незрячих.
Проблема отправки SMS тоже может иметь несколько решений, дополняющих
друг друга. Например, если сообщения можно отправлять из личного
кабинета, то проблема сводится к регистрации для получения такого
кабинета, но регистрация - разовая проблема, и отправка SMS для нас
станет доступней.
Теперь несколько слов о звуковом тесте. Я согласен с Анатолием,
крайне маловероятно, что для защиты сервер чего-то генерирует при
каждом запросе от клиента. Это создавало бы огромную дыру в защите от
злоупотреблений. Достаточно простой программе автоматически повторять
вызов теста даже без заполнения формы, чтобы загрузить сервер
бесполезной работой. Механизм использования готовых файлов в
достаточно большом количестве со случайной выборкой из них и с
периодическим, но не слишком частым их обновлением (причём готовиться
файлы будут на другой машине) выглядит достаточно нетребовательным к
ресурсам (объём данных на диске в данном случае хоть и может быть
значительным, но важно то, что он ограничен).
В связи с вышесказанным, по-моему, вариант генерирования звукового теста
налету, будь то синтезатор речи, как предлагал Владимир Довыденков,
или зашумление шаблона, как предлагал Виктор Лавриненко, вряд ли
окажутся приемлемыми для провайдера. Но их ведь совершенно несложно
доработать до механизма, о котором говорил Анатолий. Звуковые файлы
можно записать с микрофона, а можно с синтезатора речи. И зашумливать
их можно однократно, заранее, на другой машине, не покушаясь на
производительность сервера.
Мне кажется, надо признать самим, и подчеркнуть для провайдеров, что
мы не претендуем и не призываем к замене метода защиты. Мы предлагаем
добавить дополнительную, альтернативную (но не в исключающем смысле
слова) технологию, позволяющую и нам воспользоваться замечательными
сервисами прекрасного провайдера.
Предложенная Алексеем Ромашовым идея определять наличие скринридера у
клиента представляется мне остроумной, но требующей серьёзного
продумывания. Слабым местом в ней, мне кажется, является передача
ответа от клиенту к серверу. Как бы сложен не был сам тест, вплоть до
философских вопросов и распознавания образов, реализация должна
защищаться от перехвата ответа. В обсуждавшихся методах это просто
уменьшение вероятности повторения одного и того же вопроса. А при
ответе да/нет вероятность простого угадывания 0.5, что для робота
сущий клад.
Здравствуйте, Владимир.
-----------------------*- Original Message -*ВЛ> Для регистрации помимо звукового теста можно предложить обычный или
Да, регистрация через тех. поддержку тоже выход, но, полагаю, не имеет
особого смысла писать об этом в статье или в письме. Хотябы даже потому,
что он, выход, по-моему, не самый удобный для нас и о нём стоит упомянуть
в том случае, если веб-служба проявит заинтересованность в решении
проблемы, но откажется воспользоваться перечисленными нами способами её
решения.
В общем, на крайний случай.
-----------------------*- Original Message -*ВЛ> Проблема отправки SMS тоже может иметь несколько решений, дополняющих
Здесь, по-моему, речь уже идет не о дополнении механизма, а о его
серьезной перестройки. На что веб-сервисы, уверен, не пойдут.
В любом случае, думаю, нам самим нужно ограничить варианты
технических решений именно их трудоёмкостью. Иначе мы сильно рискуем
растечься мыслью по древу (т.к. таких решений может быть много), но так
и не добиться реальных результатов. Мало кто из админов будет читать
статью в десятки килобайт и еще меньшее количество админов пойдут на
полную переработку механизма отправки SMS.
-----------------------*- Original Message -*ВЛ> Теперь несколько слов о звуковом тесте. Я согласен с Анатолием,
Достаточно поставить ограничение на количество попыток регистрации с
одной сессии чтобы эту проблему напрочь решить.
Я согласен, разумеется, что вариант с генерированием более
ресурсоемкий, чем вариант с выборкой из базы. Но тем хуже для нас, так
как возни с записью тысячи фраз много больше, чем со склеиванием фразы
из фрагментов.
С другой стороны, на сколько я осведомлен, синтезирование речи и
запись этой речи в файл под Linux'ом операция очень шустрая и
нересурсоемкая.
Поймите, синтезатор речи под Linux это не Digalo под Windows,
который две минуты собирается с мыслями, прежде чем прочесть даже два
слова.
-----------------------*- Original Message -*ВЛ> Предложенная Алексеем Ромашовым идея определять наличие скринридера у
Я слабо себе представляю, каким образом JavaScript будет определять
загруженность скринридера. Если ориентироваться на название
исполняемого файла, то это настолько легко подделываемая вещь, что даже
и говорить тут не о чем. Серьезные конторы на это точно не пойдут. О
какой секретности может идти речь, если, скажем, все наши письма в этом
листе автоматически выкладываются в общедоступный архив Subscribe? Да и
секретки куда более сложного характера расшифровываются в инете
практически мгновенно.
Пытаться из JavaScriptа брать сигнатуру exe-файла и вовсе, по-моему,
нереально. Я не знаток этого языка, но вот в чем я уверен, так это в
том, что при нормальных настройках безопасности даже Internet Explorer
не позволит скрипту это сделать.
Уважаемые господа, я предлагаю сосредоточиться и от просто рассуждений
переходить к конкретным правкам статьи и письма с обращением. После
чего уже начинать рассылку.
Между прочим, информация к размышлению: на сею секунду ко мне в
ящик не пришло вообще ни одного письма со ссылками на недоступный сервис
с его почтовым адресом.
Возникает резонный вопрос, нам вообще-то это надо?