Помощь по разговору:Использование archive.today

Сентябрь 2013 г.

Один из редакторов опубликовал следующее резюме редактирования, удалив слова, комментирующие вопросы авторских прав:

«Удалите крайне неуместное описание, законодательство США не является мировым, поэтому не применяйте его здесь, не говоря уже о том, что это серьезно сбивает с толку, что такое авторское право на самом деле, существует или нет robots.txt, не имеет значения, а в библиотеках действуют другие законы».

Во-первых, никто не утверждал, что законодательство США является мировым. Я лишь говорю, что Википедия не хочет (и не имеет законных оснований) нарушать законодательство США об авторских правах, а также не хочет получать бесконечные запросы на удаление DMCA, что, несомненно, произойдет, если люди начнут ссылаться на статьи Википедии на несанкционированные архивные копии произведений, защищенных авторским правом. Указание на то, что законы об авторских правах в других странах отличаются, очевидно, не имеет значения.

Во-вторых, я согласен, что уважение к роботам и уважение к законам об авторском праве — это две разные вещи. Однако, как поясняет предлагаемая формулировка, файлы исключений для роботов — это единственное известное средство, используемое ответственными веб-архивами для избежания нарушения авторских прав. Если бы у Archive.is был какой-то другой способ избежать нарушения авторских прав, это было бы прекрасно. Но у них его нет. Archive.is содержит большое количество материалов, нарушающих авторские права, в чем каждый может убедиться сам. (См. пример в статье Wikipedia об Archive.is, но вам лучше поторопиться, потому что есть номинация на удаление этой статьи.) Таким образом, тот факт, что Archive.is отказывается соблюдать исключения для роботов для материалов, защищенных авторским правом, тесно связан с тем фактом, что они нарушают закон об авторском праве.

В-третьих, редактор говорит: «У библиотек другие законы». Я не знаю, что это должно значить, но если кто-то думает, что это значит, что библиотекам или онлайн-архивам разрешено нарушать закон об авторских правах, то они ошибаются.

В-четвертых, редактор говорит, что предложенный текст является «крайне ненадлежащим описанием», но обоснование этого заявления основано на недоразумении, отмеченном выше. Предложенный текст полностью приемлем. Википедия не должна быть стороной нарушения авторских прав. Можем ли мы хотя бы согласиться с этим?Weakestletter ( обсуждение ) 21:12, 23 сентября 2013 (UTC) [ ответ ]

Текст, который я удалил, искажает суть, явно написан предвзято и не нейтрально с предубеждением против Archive.is. Это руководство, вместо этого пользователям предоставляется этот текст жирным шрифтом, первым делом на странице, с указанием, что они не должны его использовать, и с юридическими претензиями. Если вы не видите, насколько это неуместно, боюсь, я не смогу это объяснить.
Я заменил текст на самую прямолинейную, беспристрастную версию, которая не делает никаких предположений или заявлений: " Примечание: Archive.is не следует стандарту исключения роботов и может архивировать контент, который владельцы веб-сайта исключили из автоматических поисковых роботов. ". Все остальное — просто добавление подстрекательских выражений вместо того, чтобы быть полезным руководством. И вы не можете предъявлять юридические претензии от имени Wikimedia.
По вашему первому пункту, archive.is не находится в США. Они не обязаны следовать DMCA или любому закону США. И они не нарушают законы США/Канады об авторских правах, которые использует Википедия. Мы ссылаемся на thepiratebay.sx из The Pirate Bay . По вашему утверждению, Википедия нарушает закон.
Что касается вашего вопроса о библиотеках, то у библиотечных служб США (в том смысле, в котором классифицируются архиваторы) есть другие законы относительно нарушения авторских прав, в основном, они ничего не нарушают, если следуют определенным правилам США (это даже есть в прикрепленной ссылке). Google — такая служба. robots.txt — это всего лишь один из способов соблюдения этих правил  США . — HELL KNOWZ   ▎ TALK 22:10, 23 сентября 2013 (UTC) [ ответить ] 
Многие американские журналы и издательства (а я полагаю, что они знают об авторских правах гораздо больше нас и заботятся о них) не видят проблемы в использовании archive.is и ссылке на него . Я предлагаю удалить сигнализацию об авторских правах как неэффективную. 88.15.83.61 (обсуждение) 19:35, 24 сентября 2013 (UTC) [ ответить ]

О последних изменениях тегов

Это было от редактора в конце Wikipedia:Deletion review/Log/2013 28 октября , после чего я его отменил. -- Lexein ( обсуждение ) 14:40, 29 октября 2013 (UTC) [ ответ ]

  • Тег или примечание определенно необходимы для информирования читателей о том, что действие, описанное на странице, находится под активным оспариванием в соответствии с RfC на другой странице. -- SmokeyJoe ( обсуждение ) 20:45, 29 октября 2013 (UTC) [ ответ ]
Нет, он вообще не нужен. Это прошло MFD , и точка. Спор был решен howto сохранен . Никто не поднимал WP:Using Archive.is в период обсуждения RFC WP:Archive.is . Это не считалось релевантным, и это так. Тег удален. Пожалуйста, не добавляйте его повторно. Если вы категорически против удаления, начните другой MFD. Люди делают это постоянно, с редко меняющимися результатами. -- Lexein ( обсуждение ) 23:35, 29 октября 2013 (UTC) [ ответ ]
Перемещено на Wikipedia:Administrators'_noticeboard/Incidents#De-linking_of_Wikipedia:Using_Archive.is_a_challenged_How-To_to_its_RfC . -- SmokeyJoe ( обсуждение ) 00:17, 30 октября 2013 (UTC) [ ответить ]

Как правильно сделать ссылку на http://archi ve.is/jPlGB (добавленный пробел) в ссылке на статью? (Это *было* http://kappapiart.org/join.html) Naraht ( обсуждение ) 17:48, 5 мая 2016 (UTC) [ ответ ]

@ Naraht : archive.li/jPlGB может подойти, но похоже, что контент, на который вы хотели сослаться, был перемещен по новому адресу: http://kappapiart.com/new-members. — LLarson  ( said  &  done ) 18:52, 5 мая 2016 (UTC) [ ответить ]
@ LLarson : Спасибо! за *и* как пользоваться сайтом (с другой страной) *и* за поиск новой национальной страницы. Странно, что она не отображается на первой странице Google. Naraht ( talk ) 18:59, 5 мая 2016 (UTC) [ ответить ]

RfC: Следует ли использовать короткие или длинные форматы URL-адресов?

Следующее обсуждение представляет собой архивированную запись запроса на комментарий . Пожалуйста, не изменяйте его. Дальнейшие правки в это обсуждение вноситься не должны. Ниже приводится резюме сделанных выводов.

Существует четкое согласие, что длинные формы URL-адресов предпочтительны. Длинные формы включают временные метки и исходный URL-адрес. Короткие формы могут использоваться для маскировки назначения и обхода черных списков. Добавление коротких форм URL-адресов не должно приводить к предупреждениям и/или санкциям против добросовестных редакторов.

Любые URL в краткой форме должны быть преобразованы в длинную форму. Это может сделать любой редактор. Также существует четкое согласие, что бот автоматически преобразует краткие формы URL и помечает статьи, используя URL из черного списка.

Примеры длинных форм URL, включающих временные метки и исходный URL:

  • архив.is:http://archive.is/YYYY.MM.DD-hhmmss/http://www.example.com
  • Веб-ссылка:http://www.webcitation.org/5kbAUIXb6?url=http://www.example.com/
( Протокол выходит за рамки данного RFC.)
—  JJMC89  ( T · C ) 00:35, 5 августа 2016 (UTC) 03:27, 5 августа 2016 (UTC)[ отвечать ]

Целью данного запроса предложений (RfC) является оценка консенсуса сообщества относительно предпочтительного формата URL для archive.is и WebCite при использовании в цитатах.

Оба сайта допускают два формата URL: сокращенную и длинную версию. Примеры:

архив.is
  • http://archive.is/YYYYMMDDhhmmss/http://www.example.com
  • http://archive.is/Gt56j
Веб-сайт
  • http://www.webcitation.org/query?url=http://www.example.com&date=YYYYMMDD
  • http://www.webcitation.org/5eWaHRbn4
  • http://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/(используется в dewiki, идентификатор содержит временную метку в кодировке base 62, извлеченную шаблоном de:template:Webarchiv)
(представьте, что они переходят по одной и той же ссылке)

Какой из них предпочтительнее или оба варианта одинаково подходят?

Сопутствующая информация:

  • В документе Using WebCite говорится: «Любой из вариантов подходит для использования в Википедии», а в документе Using archive.is говорится: «[Более длинный] вариант предпочтительнее для использования в Википедии, поскольку он сохраняет исходный URI».
  • В ходе обсуждения RFC archive.is некоторые пользователи высказали опасения, что короткие URL-адреса могут скрывать спам-ссылки, отметив, что сервисы сокращения URL-адресов, такие как bit.ly, были занесены в черный список Википедии.
  • Пользователь немецкой Википедии сказал, что они требуют использовать длинную форму, поскольку, если служба архивации прекратит свою деятельность, они все равно будут знать исходный URL-адрес.
  • Обратную разработку сокращенной ссылки для поиска исходного URI можно выполнить с помощью API WebCite или веб-скрапинга в случае archive.is.
  • WebCite и archive.is по умолчанию используют сокращенную версию при создании новой ссылки или при отображении страницы.

Пожалуйста, оставьте !голос ниже, например, короткий или длинный или любой из них . -- Green C 21:50, 5 июля 2016 (UTC) [ ответить ]

Обсуждение

Это не должно быть RfC — мы всегда используем long. Сокращатели ссылок не допускаются. Карл Фредрик 💌 📧 23:48, 5 июля 2016 (UTC) [ ответить ]

После обсуждения ниже давайте перейдем к длинным, запретим короткие . И я не имею в виду блокировать короткие, просто автоматизировать преобразование в длинные ссылки. Карл Фредрик 💌 📧 08:58, 6 июля 2016 (UTC) [ ответить ]

Запрещены ли сокращатели ссылок или сайты перенаправления? То, что я смог найти, это Wikipedia:Внешние ссылки#Сайты перенаправления . Если нет явного существующего руководства, то имеет смысл продемонстрировать консенсус для одного по тем же причинам, что и для сайтов перенаправления. PaleAqua ( обсуждение ) 05:20, 6 июля 2016 (UTC) [ ответить ]
  • Можно/нужно ли настроить бота для автоматического преобразования коротких ссылок в длинную форму? Особенно учитывая, что ссылка по умолчанию, возвращаемая службами архива, является сокращенной версией. PaleAqua ( talk ) 03:50, 6 июля 2016 (UTC) [ ответить ]
    Может ли это сделать бот? Да, в большинстве случаев. Но без консенсуса сообщества (RfC) для использования длинной формы URL могут возникнуть проблемы в процессе одобрения бота или во время работы бота, если кто-то выдвинет возражение. -- Green C 04:22, 6 июля 2016 (UTC) [ ответить ]
    Понял это. Я предпочитаю длинные , но думаю, что вместо того, чтобы запрещать короткие ссылки, их следует преобразовывать в длинные, вручную или с помощью бота. Архивные ссылки должны быть сопоставимы с мертвым URL, что сложнее сделать с сокращенными ссылками. Я также хотел бы, чтобы URL-адреса archive.is были унифицированы, если это возможно, так как во время бана, похоже, использовались псевдонимы для обхода фильтров. (Я поддержал разбанивание, но все же считаю важным знать о распространенности ссылок и т. д.) PaleAqua ( обсуждение ) 05:20, 6 июля 2016 (UTC) [ ответ ]
    Также будет поддерживать смешанный формат для WebCite согласно комментариям Boshomi ниже. PaleAqua ( обсуждение ) 12:40, 28 июля 2016 (UTC) [ ответ ]
  • Предпочитаю длинные, но не запрещаю короткие — archive.is по умолчанию предоставляет вам короткую версию ссылки, но длинная версия содержит исходный URL — поэтому запуск бота для преобразования их в длинную версию кажется мне идеальным решением — Дэвид Джерард ( обсуждение ) 08:08, 6 июля 2016 (UTC) [ ответить ]
  • ( конфликт редактирования ) Предпочитайте длинные, но не запрещайте короткие – как указано выше. Хотя короткие URL-адреса хороши, вероятно, лучше использовать длинные URL-адреса, учитывая такие проблемы, как возможность обойти черный список спама. Я бы поддержал преобразование их ботом в длинные URL-адреса вместо запрета коротких URL-адресов, а также объединение всех ссылок на домен archive.is в "https://archive.is/" (пока вы этим занимаетесь, измените HTTP на HTTPS) также является хорошей идеей. Обратите внимание, что "сохранение исходного URI" не является проблемой, если редакторы правильно используют шаблон {{ cite web }} , помещая исходный URL-адрес в |url=шаблон, а архивированную версию – в |archiveurl=шаблон. Также обратите внимание, что WebCite использует параметр запроса для исходного URL-адреса в длинной форме, поэтому обойти черный список все еще возможно. Возможно, проще всего было бы заставить бота также проверять их и выполнять декодирование и сопоставление URL-адресов с черным списком, а также сообщать, если он находит ссылку из черного списка. nyuszika7h ( обсуждение ) 08:10, 6 июля 2016 (UTC) [ ответить ]
Примечание: Пожалуйста, прочтите мой комментарий ниже. Теперь я понял, что заставлять бота постоянно убирать после добавления новых ссылок — не очень хорошая идея. nyuszika7h ( обсуждение ) 13:45, 10 июля 2016 (UTC) [ ответить ]
@Nyuszika7H: Хорошая идея о сопоставлении с черным списком. Есть также пустые ссылки, которые не используют шаблоны цитирования, но могут использовать шаблон типа {{ wayback }} . Знаете ли вы другие домены для archive.is и webcitation.org? — Предыдущий неподписанный комментарий добавлен Green Cardamom ( talk • contribs ) 14:01, 6 июля 2016 (UTC) [ ответить ]
@ Green Cardamom : Насколько мне известно, у WebCite нет альтернативных доменов. У Archive.is есть archive.is, archive.today, archive.li, archive.ecи archive.fo. nyuszika7h ( обсуждение ) 14:09, 6 июля 2016 (UTC) [ ответ ]
@ Green Cardamom : Freezepage также имеет краткую форму (например, http://www.freezepage.com/1465141865DVZXYCBROO). 93.185.30.40 (обсуждение) 15:33, 6 июля 2016 (UTC) [ ответить ]
  • Длинный . Давайте уберем одну проблему из умов людей, которые выступают против этого сервиса: запутывание спамерами. — С наилучшими пожеланиями, Кодовое имя Лиза ( обсуждение ) 08:52, 6 июля 2016 (UTC) [ ответить ]
  • Длинный. Если есть хоть какая-то вероятность спамерского злоупотребления короткими ссылками, то короткая форма будет добавлена ​​в черный список в любом случае. ~ Amatulić ( обсуждение ) 13:42, 6 июля 2016 (UTC) [ ответить ]
  • Long для пустых ссылок, Short для использования в шаблонах, таких как {{ cite web }} . Они сохраняют исходный URL и дату захвата в других аргументах, так что это будет уродливым дубликатом и еще одним RFC о том, как бороться с этим дублированием длинных URL, вводя специальные шаблоны для ссылок на архивы или разрабатывая {{ cite web }} для расчета ссылок на архивы самостоятельно или как-то еще. 93.185.30.40 (обсуждение) 15:28, 6 июля 2016 (UTC) [ ответить ]
Не останется ли проблема спама при использовании short в шаблонах? Теоретически бот мог бы выполнять проверку, постоянно проверяя ссылку снова и снова, чтобы убедиться, что она соответствует аргументу url, но это требует больших сетевых ресурсов и обслуживания бота. В идеале бот преобразует из short в long один раз, таким образом редакторы могут визуально увидеть, является ли URL легитимным или нет, а другие боты могут проверить ссылки на наличие в черном списке. -- Green C 16:18, 8 июля 2016 (UTC) [ ответить ]
  • Длинные . Эта страница не может ничего "запрещать", и люди иногда будут добавлять короткие. Мы хотим, чтобы не было никаких возражений (например, от людей, которые ошибочно думают, что WP:CITEVAR магическим образом перекрывает политику WP:OWN , а таких много) о замене коротких ссылок на длинные, информативные, чтобы люди имели представление, куда на самом деле ведет ссылка . —  SMcCandlish  ☺ ☏ ¢ ≽  ʌ ⱷ҅ ᴥ ⱷ ʌ ≼ 18:42  , 6 июля 2016 (UTC) [ ответить ]
    PS: Не возражаю против использования коротких ссылок в шаблонах ссылок, если также присутствует исходный URL.  —  SMcCandlish ☺ ☏ ¢  ≽ ʌ ⱷ҅ ᴥ ⱷ ʌ ≼  18:43, 6 июля 2016 (UTC) [ ответить ]
  • Длинный – на мой взгляд, всегда предпочтительнее, когда ссылка на архив явно содержит исходную ссылку. -- IJBall ( вклад • обсуждение ) 06:43, 8 июля 2016 (UTC) [ ответить ]
  • Длинный - предотвратить использование archive.is для маскировки спама и плохих источников. BrightRoundCircle ( обсуждение ) 08:40, 8 июля 2016 (UTC) [ ответить ]
  • только длинный - короткий URL может быть использован для обхода других черных списков и скрывает, куда вы на самом деле идете. Более того, при необходимости проще получить исходную ссылку обратно, если когда-либо возникнет необходимость использовать другой архив. -- Дирк Битстра T C 06:24, 9 июля 2016 (UTC) [ ответить ]
    • Учитывая, что короткие ссылки могут быть использованы не по назначению (и я, кажется, припоминаю такой случай), я бы предложил блокировать короткие ссылки или, по крайней мере, предупреждать и помечать их фильтром редактирования. -- Дирк Битстра T C 06:27, 9 июля 2016 (UTC) [ ответить ]
  • Лучше настроить бота, чтобы он менял короткие ссылки на длинные сразу после их вставки. Это не работа для человека — читать такое предупреждение, а затем объединять строки. 93.185.30.244 (обсуждение) 11:43, 10 июля 2016 (UTC) [ ответить ]
  • Нет, это не лучше - бот не сможет сохранить преобразованные ссылки (так как они были занесены в черный список), и тогда кто-то позже должен прийти и а) удалить «перенаправление», и б) найти первоначального редактора, который вставил обходную ссылку (и принять меры, где это необходимо). Лучше предотвратить и просветить (что само по себе предотвращает количество правок, и что бот должен сделать довольно косметическое редактирование, и что бот может сделать ошибки при преобразовании, и что все это должно быть дважды проверено еще одним человеком). -- Дирк Битстра T C 12:46, 10 июля 2016 (UTC) [ ответить ]
  • Если бот замечает, что он занесен в черный список, он может поместить тег на статью, как это уже сделано для существующих ссылок, напрямую найденных в черном списке. Хотя я предполагаю, что фильтр редактирования, который сообщает пользователям, как получить ссылку, мог бы работать (для WebCite это просто, для archive.is пользователю нужно сначала нажать ссылку «поделиться»), может быть проще, чем заставлять бота выполнять очистку, теперь, когда я об этом думаю. Но фильтр редактирования не должен полностью блокировать эти правки, по крайней мере на начальном этапе, потому что статьи, которые в настоящее время содержат короткие URL-адреса, должны быть очищены — в идеале ботом. nyuszika7h ( talk ) 13:01, 10 июля 2016 (UTC) [ ответить ]
    • Я в основном предлагал это для недавно добавленных ссылок. То, что там сейчас, действительно должно быть сначала изменено ботом, и некоторая очистка в отношении тех немногих, которые могут быть там и ссылаются на материалы, которые иначе были бы занесены в черный список. -- Дирк Битстра T C 13:19, 10 июля 2016 (UTC) [ ответить ]
  • Если мы придерживаемся принципа долгосрочного соглашения, то хорошей идеей будет фильтр редактирования для новых добавлений ссылок, а также одноразовый бот для очистки старых случаев, что с большей вероятностью будет выполнено, чем демонический бот, который требует дополнительных усилий и обслуживания. -- Green C 15:13, 10 июля 2016 (UTC) [ ответить ]
  • Мне не нравится идея блокировки коротких ссылок. Единственная причина, по которой мы разрешили archive.is, — это сделать редактирование более простым, добавить больше препятствий, через которые нужно пройти, — это негатив. Я предлагаю непрерывного бота, который всегда работает и проверяет, используются ли короткие ссылки, и автоматически заменяет их. Нам нужно, чтобы редактирование было простым — заставлять людей прыгать через препятствия только заставит их думать, что это слишком хлопотно, и они откажутся от своих правок. Карл Фредрик 💌 📧 11:15, 13 июля 2016 (UTC) [ ответить ]
  • @ CFCF : Как я утверждаю ниже, ситуация не сильно отличается от текущей ситуации с URL-сокращателями — люди там должны вернуться и исправить свои ссылки (или могут отказаться от своих правок). Но я бы сначала просто предложил фильтр правок «только с предупреждением» (очевидно, не с предупреждением, а с добросовестным замечанием) и заставил бы бота удлинить все короткие ссылки, которые там есть, и те, которые все равно добавляются. Таким образом, все это помечается (и при некоторой удаче многие люди удлинят свои ссылки, избежав дополнительного редактирования ботом), и легко проверить, что добавляется в любом случае, и если это действительно показывает существенное реальное злоупотребление короткими ссылками (настоящие спамеры не заботятся о предупреждениях, возвратах ботов, блокировках по IP-адресам и т. д.), то мы всегда можем пересмотреть ситуацию (хотя я не ожидаю, что все станет настолько плохо — и могут быть также промежуточные решения). Обратите внимание, что шаблонное решение устранит необходимость для пользователя добавлять ссылку вообще — исходный URL-адрес находится в одном параметре, архивный URL-адрес — в другом параметре — можно выбрать, чтобы шаблон создавал архивную ссылку (что будет работать для большинства) из исходной ссылки и параметра даты архива. Это облегчит работу редактора. — Дирк Битстра T C 11:47, 13 июля 2016 (UTC) [ ответить ]
  • Согласен, документация синтаксиса длинной формы — это простая однократная кривая обучения; и использование шаблонов для внешних ссылок (например, ). Это правильные решения, которые уже используются другими архивами, такими как Wayback. Разрешать короткие URL-адреса против политики , а затем предполагать, что бот будет исправлять преднамеренные ошибки навсегда, — не очень хорошая идея по целому ряду причин. В любом случае, я определенно не буду писать бота, который будет это делать. Может быть, кто-то другой это сделает... мы говорим о сотнях часов труда и личных обязательствах на неограниченные годы вперед. Эти боты не запускаются сами по себе, у них постоянные проблемы с форматированием страниц из-за нерегулярной природы данных wikisource, это не просто поиск и замена регулярных выражений, вам приходится иметь дело с deadurl, archivedate, , soft-404, 503, 300 на archive.is и т. д. Это сложно и трудно писать и поддерживать. -- Green C 13:18, 13 июля 2016 (UTC) [ ответить ]{{wayback}}{{dead}}
  • Только длинные , но не принудительное исполнение в отношении лиц, использующих короткие. Единственным средством против коротких URL-адресов должно быть либо автоматическое изменение ботом (настоятельно рекомендуется), либо изменение редактором, который их находит и возражает против них, или и то, и другое. Независимо от того, включает ли отдельный редактор короткие URL-адреса только один раз или делает это регулярно, даже после того, как ему сообщили, что требуются длинные, это не должно подвергать его/ее санкциям. Это очень незначительное правило, применимое только к нескольким источникам, и если мы собираемся ввести правило, оно должно быть без драмы. Единственный случай, когда должно быть задействовано принудительное исполнение, это если кто-то из -за этого воюет за редактирование (и абсолютно не должно быть исключения из правила 3RR для изменения или возврата коротких URL-адресов) или короткий URL-адрес явно используется в нечестивых или неэнциклопедических целях. С уважением, TransporterMan ( TALK ) 18:19, 12 июля 2016 (UTC) [ ответить ]
  • Long, Second TransporterMan . Long лучше, и, возможно, есть шаблон, чтобы упоминать его людям. Возможно, даже не это. Мне все равно, сколько раз кто-то «нарушает» это, это смешно, чтобы наказывать людей за это. Это своего рода нарушение правил, на которое жалуются люди, потому что это отпугивает новых редакторов. Простое исправление этого — это просто поддержание стандартов. Это то, с чем бот может легко справиться, так что давайте не будем тратить на это время людей. Tamwin ( обсуждение ) 06:48, 13 июля 2016 (UTC) [ ответить ]
    • @ TransporterMan и Tamwin : Никто не предлагал наказывать людей за это (если, конечно, они не используют это, чтобы обойти черный список). Обратите внимание, как Special:AbuseLog гласит вверху: " Записи в этом списке могут быть конструктивными или сделанными добросовестно и не обязательно являются признаком неправомерных действий со стороны пользователя. ". – nyuszika7h ( talk ) 08:21, 13 июля 2016 (UTC) [ ответить ]
    • @ TransporterMan и Tamwin : Я хочу поддержать это, за исключением преднамеренного нарушения (например, преднамеренного обхода черного списка) не будет/не должно быть никакого наказания. Даже сейчас, если вы добавляете ссылку из черного списка, вас не наказывают, вы просто блокируете, чтобы сохранить редактирование. Никто не будет/не должен преследовать вас, когда вы добросовестно заблокированы черным списком спама. Это не изменится/не должно измениться. Проблема с разрешением коротких ссылок заключается в том, что a) люди могут добросовестно добавлять ссылки из черного списка, которые могут нуждаться в удалении, b) люди будут использовать короткие ссылки, чтобы обойти черный список (они делают это с обычными сокращателями URL на регулярной основе), c) каждое добавление короткой ссылки должно сопровождаться другим редактированием ботом (и, возможно, даже проверять, всегда ли бот был верным) - всего этого можно избежать. В конечном итоге ситуация не будет отличаться от ситуации, когда редакторы непреднамеренно используют сервис сокращения URL-адресов (или аналогичные «плохие» ссылки), что регулярно случается из-за онлайн-сервисов, которые стандартно сокращают определенные ссылки, и которые теперь не смогут сохранить свои правки, им придется вернуться и «удлинить» свои текущие URL-адреса. -- Дирк Битстра T C 08:59, 13 июля 2016 (UTC) [ ответить ]
  • Длинная форма, преобразуйте короткую , как предлагает User:CFCF . Используйте автоматическое преобразование в длинную форму. Короткая форма скрывает архивированную страницу, в то время как длинная форма предоставляет важную информацию об архивированных данных с первого взгляда, а именно дату и исходный адрес. Пользователи могут вставлять как длинную, так и короткую формы, но бот или скрипт автоматически преобразуют короткую форму в длинную (без каких-либо предупреждающих сообщений или подобных мер предосторожности). На соответствующих страницах WP следует упомянуть, что длинная форма предпочтительнее. — Hexafluoride Напишите мне, если вам нужна помощь, или опубликуйте в моем докладе 13:46, 14 июля 2016 (UTC) [ ответить ]
  • Длинный, не дай бог короткий, никакого наказания, никакого шаблона страницы обсуждения для первого нарушения. В отличие от чего-то вроде подписания (за которое SineBot выдает предупреждение на странице обсуждения всего за 3 в течение 24 часов, в дополнение к шаблону позора «неподписанный комментарий» в самом сообщении), совершение этой ошибки и принуждение бота ее исправить на самом деле не является разрушительным, это просто добавляет дополнительную разницу в историю. Я подозреваю, что это будет решено при одобрении бота, но они в любом случае прочтут этот RFC, и я думаю, что любой разумный редактор поймет суть, когда прочтет сводку правок бота из своего списка наблюдения, и ему не понадобится страница обсуждения WP:BITE . Любые предупреждения на странице обсуждения должны иметь высокий предел, чтобы получить пощечину, например, 10 плохих ссылок в течение как минимум 3 дней. Это небольшая проблема, но маленькие проблемы — большие проблемы, когда дело касается удержания новых редакторов. Jhugh95 ( обсуждение ) 17:56, 25 июля 2016 (UTC) [ ответить ]
  • Длинную форму преобразуйте в короткую, чтобы сохранить адрес в исходном содержании. — Адам в MO Talk 20:00, 26 июля 2016 (UTC) [ ответить ]
  • Длинный формат — Принимайте короткий формат от редакторов, но пусть бот преобразует его в длинный формат. — JFG talk 09:44, 28 июля 2016 (UTC) [ ответить ]
  • Информация из dewiki:
    • для archive.is используйте только длинный формат . Для длинного формата есть много веских причин. В dewiki мы преобразовали все ссылки с коротким форматом в длинные для этого архива.
    • mixed-fromat для webcitation.org этот архив гораздо надежнее. Короткие ссылки более стабильны, и в них меньше сбоев. С помощью шаблонов мы можем извлечь точную дату из webciteID. Обратите внимание на Template_talk:WebCite#Date из webcite-ID. С помощью шаблонов вы можете добавить исходный URL в короткий URL, например: http://www.webcitation.org/5kbAUIXb6?url=http://www.geocities.com/los_angeles_coast/public_transportation.html Этот вариант очень стабилен, и нет риска сбоя, такого как неэкранированный ID или параметры даты. Часть запроса URL, которую мы используем для spezial:Linksearch и WP:spamm black list Boshomi ( talk ) 20:35, 27 июля 2016 (UTC) [ ответить ]
      • Кажется, это хорошая идея, хотя для этих URL-адресов WebCite, вероятно, единственным решением будет заставить бота конвертировать их, поскольку сам WebCite предлагает пользователям только короткую и длинную форму, а не смешанную. nyuszika7h ( обсуждение ) 09:14, 28 июля 2016 (UTC) [ ответить ]
  • Долго по SMcCandlish и здравому смыслу. Я предлагаю закрыть снег. Лучшее, FoCuS contribs ; поговорите со мной! 13:49, 28 июля 2016 (UTC) [ ответить ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.

archive.is в HTTPS

Перемещено из Talk:Archive.is

@93.185.30.56: Я вижу, что вы из России, где archive.is заблокирован в HTTPS. Однако ситуация меняется. Например, Китай блокирует HTTP, но не HTTPS. archive.is теперь по умолчанию использует HTTPS. Нет политики относительно того, как ссылаться на archive.is. И учитывая, что большая часть мира может получить к нему доступ через HTTPS, ссылка на него в зашифрованном виде лучше, чем подвергать трафик незащищенной ссылке. Пользователи в странах, где заблокирована одна из форм, должны приложить дополнительные усилия для изменения ссылки (HTTP/HTTPS) при попытке доступа к ней. — Hexafluoride Напишите мне , если вам нужна помощь, или опубликуйте в моем докладе 13:33, 14 июля 2016 (UTC) [ ответить ]

Также обратите внимание, что сама Википедия доступна только по протоколу HTTPS, так что этот вопрос в значительной степени спорный (и не имеет значения). nyuszika7h ( обсуждение ) 13:49, 14 июля 2016 (UTC) [ ответить ]
Hexafluoride , также обратите внимание, что пингование IP-адресов не работает, попробуйте вместо этого оставить сообщение на их странице обсуждения, если вы хотите привлечь их внимание. nyuszika7h ( обсуждение ) 13:50, 14 июля 2016 (UTC) [ ответ ]
@Nyuszika7H: Я по ошибке поместил это в archive.is talk, вместо Wikipedia:Using archive.is . Я перенесу это туда. Я также отправил Tb IP пользователя. — Hexafluoride Напишите мне , если вам нужна помощь, или опубликуйте в моем talk 14:00, 14 июля 2016 (UTC) [ ответить ]

Был RfC, который решил использовать https для archive.org .. Я не понимаю, почему archive.is даст другой результат, если будет другой RfC. Аргумент о том, что некоторые страны блокируют https, можно ли решить с помощью Wikipedia:Protocol-relative URL ? — Предыдущий неподписанный комментарий добавлен Green Cardamom ( обсуждение • вклад ) 15:13, 14 июля 2016 (UTC) [ ответить ]

@ Green Cardamom : Как я уже сказал, сама Википедия доступна только по HTTPS, так что это бессмысленно. nyuszika7h ( обсуждение ) 15:17, 14 июля 2016 (UTC) [ ответить ]
Вы неправильно поняли суть. Страны не блокируют https в целом, они блокируют отдельные домены. https://archive.is заблокирован в России, а https://archive.li — нет. Что касается Китая, то другой способ блокировки там (https доступен, а http заблокирован) здесь не актуален, поскольку в Китае заблокирована Википедия, поэтому бессмысленно оптимизировать страницы Википедии, ориентированные на Китай. https://archive.is — единственная комбинация протокол-домен (из 10: {http:archive.is, http:archive.today, http:archive.li, http:archive.ec, http:archive.fo, https:archive.is, https:archive.today, https:archive.li, https:archive.ec, https:archive.fo}) с гео-проблемами. Нажатие таких ссылок из России (где Википедия пока не заблокирована) приводит к сетевой ошибке, даже не к сообщению «страница заблокирована», поэтому ссылки https://archive.is выглядят как мертвые ссылки. Если вы настаиваете на использовании https, рассмотрите возможность ссылки на другой домен (archive.li, .today, .fo или .ec — все они хорошо работают с https) 93.185.28.66 (обсуждение) 15:29, 14 июля 2016 (UTC) [ ответить ]
Если они заблокируют archive.is, я не думаю, что стоит играть с ними в «бей крота», они в конечном итоге заблокируют и другие домены, если те получат широкое распространение. nyuszika7h ( обсуждение ) 15:32, 14 июля 2016 (UTC) [ ответить ]
Проблема в другом (вы можете прочитать об этом в русской Википедии и на новых сайтах). «Они» не «хотят» блокировать archive.is. Им нужно цензурировать несколько страниц, которые являются незаконными в России. С http — поскольку он не зашифрован — блокируются только те страницы и заменяются сообщением, объясняющим причину блокировки. С https — поскольку он зашифрован — невозможно заблокировать конкретную страницу, только целый домен. Таким образом, использование другого домена можно считать «ударь крота», в то время как использование http — это честная игра со старшим братом: он видит ваш незашифрованный трафик и старается быть как можно менее беспокоящим. 93.185.28.66 (обсуждение) 15:38, 14 июля 2016 (UTC) [ ответить ]
* Кстати, https://archive.today/any-path-here перенаправляет на http://archive.is/any-path-here в России и на https://archive.is/any-path-here за ее пределами и не предоставляет никакого контента, только перенаправляет, чтобы иметь наименьший шанс быть заблокированным. Это может быть хорошим компромиссом в качестве формы ссылки на archive.is по умолчанию из Википедии. Это должно сделать всех счастливыми: редакторов, которые хотят видеть https-ссылки в Википедии, посетителей из России, которые хотят видеть контент вместо сетевых ошибок, и российское правительство, которое любит устанавливать тонкую цензуру. 93.185.28.66 (обсуждение) 16:00, 14 июля 2016 (UTC) [ ответить ]
Настоящий вопрос в том, что лучше для проекта Wikipedia, а не что лучше для пользователей в России. У нас уже был RFC по этому поводу. Западный мир постепенно переходит на https. То, что другие правительства решают цензурировать, изолируют ли они свое население или нет, на самом деле не является проблемой для проекта Wikipedia. Российскому правительству было бы несложно посоветовать всем попробовать http вместо https, если что-то не работает. Я не вижу убедительных причин делать http протоколом по умолчанию, когда защищенные соединения всегда являются лучшим вариантом для подавляющего большинства пользователей за пределами России. ~ Amatulić ( talk ) 22:31, 14 июля 2016 (UTC) [ ответить ]
Я не думаю, что вы в состоянии представлять тенденции западного мира. Например, Reddit использует http-ссылки на archive.is. Шифрование передачи архивного контента, который доступен всем, просто смешно. 93.185.28.66 (обсуждение) 23:50, 14 июля 2016 (UTC) [ ответить ]
То, что делает Reddit, не имеет отношения к Википедии. А шифрование передачи архивного контента полезно, чтобы избежать отслеживания чьих-либо интересов неизвестными сторонами и правительствами. Если это «смешно», как вы говорите, то убедите свое правительство прекратить блокировать https на archive.is. Вы не предложили убедительного аргумента, чтобы заставить Википедию пойти против собственного консенсуса и использовать https, на самом деле, есть лучший аргумент, чтобы заставить российское правительство разрешить https. Вы можете начать еще один RFC, если вы считаете, что можете изменить консенсус сообщества. ~ Amatulić ( обсуждение ) 07:41, 18 июля 2016 (UTC) [ ответить ]

Хорошо, похоже, archive.is теперь начал перенаправлять HTTPS-запросы к архивным копиям (не к главной странице) на HTTP, с раздражающей задержкой в ​​10 секунд. nyuszika7h ( обсуждение ) 16:24, 25 июля 2016 (UTC) [ ответить ]

Привет. Я думаю, нам следует придерживаться MOS:WEBADDR тогда. С наилучшими пожеланиями, Кодовое имя Лиза ( обсуждение ) 07:30, 26 июля 2016 (UTC) [ ответить ]
в dewiki мы используем только https. мы преобразовали все http URL Boshomi ( обсуждение ) 20:38, 27 июля 2016 (UTC) [ ответить ]
По словам владельца сайта, в будущем они могут полностью прекратить предлагать HTTPS на archive.is, но он продолжит работать на других доменах, таких как archive.fo. [1] [2] – nyuszika7h ( обсуждение ) 22:10, 4 августа 2016 (UTC) [ ответить ]
Если я правильно понял, похоже, что они установили перенаправления на некоторые IP-адреса в качестве попытки защиты от ботов. Я не вижу смысла в полной остановке HTTPS, хотя я мог это пропустить. PaleAqua ( talk ) 00:01, 5 августа 2016 (UTC) [ ответить ]

По данному разделу:

Не существует никаких правовых прецедентов, подтверждающих, что такое размещение материалов, защищенных авторским правом США, без разрешения является нарушением Закона США об авторском праве в цифровую эпоху (DMCA), и нет правдоподобной правовой теории, согласно которой обычное использование ссылок archive.is в цитатах может привести к нарушению Википедией законов об авторском праве или вызвать запросы на удаление в соответствии с DMCA, но в других случаях редакторы могут использовать ссылки archive.is с некоторой осторожностью в отношении контента, защищенного авторским правом США.

Недавно измененный вариант оригинала:

Повторное размещение материалов, защищенных авторским правом в США, без разрешения может являться нарушением Закона США об авторском праве в цифровую эпоху (DMCA). По этой причине, чтобы избежать обвинений Википедии в нарушении законов об авторском праве и не получить запросы на удаление в соответствии с DMCA, следует с осторожностью использовать Archive.is в отношении контента, защищенного авторским правом в США.

Ни один из них не является источником, и они дают несколько противоречивые точки зрения. Думаем ли мы, что это хорошая идея, чтобы дать юридические заключения в этом эссе? -- Green C 18:26, 17 ноября 2016 (UTC) [ ответить ]

@ Green Cardamom : Здесь журналисты Vice спросили юристов Electronic Frontier Foundation о последствиях использования archive.today на сайтах сообщества, таких как Reddit, для авторских прав. Вы можете перефразировать их ответы для статьи или лучше спросить тех же людей о правовых аспектах использования archive.today на Wikipedia. 93.185.28.131 (обсуждение) 15:02, 18 декабря 2016 (UTC) [ ответить ]

«Удаляет страницы по запросам DMCA» — плохой источник

Сегодня, пример, указанный как источник для этого утверждения, показывает, что страница была заархивирована нормально, а не удалена из-за запроса DMCA. Можно найти другие примеры с помощью поиска Google, но случай для них тот же. Я не смог найти лучший источник для этого, но я думаю, что что-то может быть в блоге автора.Saturnalia0 (обсуждение) 01:25, 24 января 2017 (UTC) [ ответить ]

какой TLD использовать?

Привет!
Недавно archive.is объявил: "Пожалуйста, не используйте зеркало http://archive.IS для ссылок, используйте другие зеркала [.TODAY .FO .LI .VN .MD .PH]. .IS может скоро перестать работать." [3][4] (спасибо за информацию @ user:KurtR )
Все их TLD, похоже, нестабильны. Так какое же хорошее решение для wikipedia? (ping user:GreenC ) -- seth ( talk ) 11:10, 5 января 2019 (UTC) [ ответить ]

@ Lustiger seth : Предположительно вебмастер позаботится о том, чтобы сайт оставался активным хотя бы в одном месте. В случае, если ссылки перестанут работать (или раньше, в качестве упреждающей меры), бот GreenC или другой бот, скорее всего, сможет справиться с изменением всех ссылок на archive.today или archive.fo. Jc86035 ( talk ) 13:54, 5 января 2019 (UTC) [ ответить ]
@ KurtR , Lustiger seth и Jc86035 : Да, я знаю об этом, вчера я связался с владельцем archive.is. Он пока не уверен на 100%, что archive.is упадет. Работаем над немедленным изменением всех ссылок в базе данных IABot, чтобы IABot прекратил распространять .is, поскольку что бы мы ни делали в вики, не будет иметь значения, если IABot все еще будет публиковать ссылки .is.
Новый домен будет .today — это своего рода CNAME или псевдоним, а остальные — своего рода имена серверов, и по мере изменения или снижения имени сервера псевдоним может быть перенаправлен в другое место. Или представьте его как частный bit.ly для Archive Today. Мы также должны рассмотреть возможность переименования сервиса «Archive Today» во всей документации, по сути, отказаться от схемы именования Archive IS. — Green C 14:44, 5 января 2019 (UTC) [ ответить ]
Ничего не происходит. GreenC, у тебя есть какая-нибудь новая информация? Archive.is часто был лучше archive.org, потому что они не принимали скрипты. -- Дитрих ( обсуждение ) 03:27, 4 апреля 2019 (UTC) [ ответить ]
@ GreenC : Сегодня User:InternetArchiveBot заархивировал ссылку на паромной пристани Birchgrove на [5], но она не работает. Похоже, что ни одна ссылка на https://archive.fo или ранее использовавшийся https://archive.is не работает. Должны ли сайты по-прежнему архивировать данные по этим адресам? Fleet Lists ( обсуждение ) 01:27, 10 июня 2019 (UTC) [ ответить ]

Изменить archive.is на archive.today

Поскольку теперь он называется archive.today, следует ли изменить название и содержание статьи? Yaakovaryeh ( обсуждение ) 04:10, 9 января 2020 (UTC) [ ответить ]

Невозможно добавить новые архивы

Каждый раз, когда я пытаюсь архивировать страницу, она застревает на странице отправки, экран останавливается и бесконечно вращается на "загрузке". Что делать? Kailash29792 (обсуждение) 06:41, 2 сентября 2021 (UTC) [ ответить ]

Свяжитесь с archive.today через блог, на который они обычно отвечают. -- Green C 06:53, 2 сентября 2021 (UTC) [ ответить ]

Для ссылок на архивы, содержащих китайские или любые иностранные символы, похоже, что использование длинного формата URL с ".today" не будет перенаправлять правильно при вставке в Википедию по некоторым причинам (если вы нажмете на него напрямую). Например: [1] ; единственный способ сделать так, чтобы это работало, — скопировать ссылку на архив и вставить ее прямо в строку ссылок браузера. Но когда я меняю ее на ".ph", она отображается правильно при нажатии на нее. Например: [2]

С коротким форматом URL проблем нет. Так вот, вопрос: я знаю, что Википедия предпочитает использовать длинный формат URL, а также доменное имя ".today" (поскольку .ph — это только имя сервера). Но для этих конкретных ссылок, какой формат мне следует использовать, чтобы у редакторов не возникало проблем при нажатии на них?

PS: Я проверил ссылку на пост Wordpress, нажав на длинный формат URL, я смог правильно перенаправить ссылку. Ссылка Так это проблема Википедии? Пожалуйста, помогите!

Спасибо.-- TerryAlex ( обсуждение ) 19:43, 18 октября 2021 (UTC) [ ответить ]

Вы вообще можете создавать новые архивы с помощью archive.today? Kailash29792 (обсуждение) 03:58, 19 октября 2021 (UTC) [ ответить ]
После проверки ссылки на Wordpress я не думаю, что это проблема archive.today, но что-то идет не так, когда она вставляется в Wikipedia. Он просто не может правильно перенаправить ссылку по каким-то причинам.-- TerryAlex ( talk ) 04:19, 19 октября 2021 (UTC) [ ответить ]

Ссылки

  1. ^ "Noble Truth by Gigi Yim on Apple Music". Apple Music . Гонконг. Архивировано из оригинала 30 сентября 2021 г. Получено 30 сентября 2021 г.
  2. ^ "Noble Truth by Gigi Yim on Apple Music". Apple Music . Гонконг. Архивировано из оригинала 30 сентября 2021 г. Получено 30 сентября 2021 г.

Расширения браузера

Упоминается, что расширения браузера доступны для Chrome, Edge и Firefox. Есть ли преимущества в загрузке расширений вместо того, чтобы иметь сайт на панелях закладок? Mcljlm ( talk ) 15:45, 31 декабря 2022 (UTC) [ ответить ]

Запрошенный переезд 25 июля 2023 г.

Ниже приведено закрытое обсуждение запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на странице обсуждения. Редакторы, желающие оспорить решение о закрытии, должны рассмотреть возможность пересмотра перемещения после обсуждения его на странице обсуждения закрывающего. Дальнейшие правки в это обсуждение вноситься не должны.

Результат запроса на перемещение: не перемещено. Быстро закрыто по запросу nom. ( неадминистративное закрытие ) WP scatter t / c 16:03, 26 июля 2023 (UTC) [ ответить ]

Help:Using archive.today → Help:Using Archive.ph – Название сайта изменено. В то время как Archive.today в настоящее время перенаправляет на Archive.ph, нет никакой гарантии, что это будет продолжаться вечно. Текст на странице, конечно, тоже нужно будет изменить, но это должна быть вполне поисково-заменительная операция.  —  SMcCandlish ☏ ¢  😼  22:11, 25 июля 2023 (UTC) [ ответить ]

  • Oppose: archive.today имеет несколько доменов, и archive.today перенаправлялся на множество разных доменов с течением времени. Название проекта по-прежнему archive.today (отображается без изменений на каждом домене), а заголовок его статьи остается archive.today . jlwoodwa ( talk ) 00:56, 26 июля 2023 (UTC) [ ответить ]
  • Oppose . Владелец archive.today потребовал, чтобы мы использовали .today по всей Википедии. Это сервер перенаправления, который отправляет запросы на другие домены (например, .ph) по мере их доступности. Таким образом, если сервер контента .ph становится недоступным, сервер перенаправления может просто изменить, куда он отправляет трафик, чтобы вместо этого указать .is. Это сделано потому, что у сайта были проблемы с перехватом домена и отменой из-за характера их обслуживания, что может быть спорным. Домен .today защищен(r) от этих проблем, поскольку он не размещает контент, и, возможно, по другим причинам, которые я не понимаю. -- Green C 03:44, 26 июля 2023 (UTC) [ ответить ]
    Ладно, я не знал об этом. Это может быть просто быстро закрыто.  —  SMcCandlish ☏ ¢  😼  09:43, 26 июля 2023 (UTC) [ ответить ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.

Конвертировать в archive.today

Special:Diff/1167250578/1169669968 : «Ссылки (в основном источники в статьях) на archive.is для меня недоступны (я получаю проверку безопасности, которую невозможно завершить). Стоит ли как-то отредактировать все существующие ссылки, чтобы использовать archive.today?». (сообщение пользователя:WhyNotHugo ).

На самом деле я начал работать над ботом, чтобы сделать это, а также расширить от краткой формы до длинной. На Enwiki и 200+ других вики. Мониторинг в реальном времени. Я продвинулся довольно далеко, а затем пришлось отпустить его для других проектов. Это намного сложнее, когда масштабируешь так и поддерживаешь его в актуальном состоянии, а не просто однократно проходишь. Это жизнеспособный проект, если я смогу найти время, чтобы завершить его, вероятно, около 75% сделано. -- Green C 15:59, 10 августа 2023 (UTC) [ ответить ]

Похоже, что все зеркала были недоступны около недели по состоянию на сегодняшний день (archive.is/.today/.ph). :-( Muzilon ( обсуждение ) 00:07, 12 августа 2023 (UTC) [ ответить ]
Он упал, сообщается, около недели, хотя я помню, что проверял вчера в ответ на пост выше, и он работал. Сейчас не работает. Блог все еще работает https://blog.archive.today/ -- Green C 00:57, 12 августа 2023 (UTC) [ ответить ]
Проблема связана с тем, какой DNS-резолвер вы используете. Если DNS-сервис использует CloudFlare, он не будет работать. Все остальное работает. Reddit. Также Archive.today#Cloudflare_DNS_availability . -- Green C 01:29, 12 августа 2023 (UTC) [ ответить ]
Я использую Quad9 (9.9.9.10) и он тоже не работает.
Firefox по умолчанию использует Cloudflare для DOH.
Я с уважением заявляю, что сайт, который активно препятствует доступу популярных DNS-резолверов и, следовательно, недоступен для многих пользователей, не подходит для архивных целей. Лучше направить усилия на преобразование этих ссылок в archive.org, который не саботирует доступ. Алекс О. (обсуждение) 04:37, 16 августа 2023 (UTC) [ ответить ]
Может быть. В своей работе я ссылаюсь на archive.today только в крайнем случае, когда нет других вариантов, а это бывает часто. Wayback не будет/не может архивировать все. Более того, в эпоху 2012-2015 годов archive,today архивировал почти все в Википедии того времени, и они справились с этой задачей гораздо лучше, чем Wayback, на многих сайтах с новыми функциями Web 2.0. И Wayback не архивировал все систематически до более позднего времени. Так что многие старые мертвые ссылки на самом деле доступны только на archive.today... с архивированием все не так просто -- Green C 05:09, 16 августа 2023 (UTC) [ ответить ]
В настоящее время я могу получить к нему доступ через Tor , но не через прямое соединение. :-/ Muzilon ( обсуждение ) 07:03, 20 августа 2023 (UTC) [ ответить ]
Каждый раз, когда я пытался им воспользоваться в последнее время, я сталкивался с повторяющейся капчей. Кажется, я не один такой.
@ GreenC : вам известен какой-либо способ связаться с владельцем archive.today, чтобы предупредить его об этой проблеме? Извините за пинг — я спрашиваю только потому, что не могу найти никаких способов связи с сайтом в сети, а в 2021 году вы вставили текст, ссылающийся на запрос от владельца сайта в Special:Diff/1060801802 . Best, A smart kitten ( talk ) 08:41, 3 сентября 2023 (UTC) [ ответить ]
Для блога сайта есть страница контактов. Muzilon ( обсуждение ) 10:06, 3 сентября 2023 (UTC) [ ответить ]
Спасибо @ Muzilon ! Не знаю, как я это пропустил. Умный котенок ( обсуждение ) 10:22, 3 сентября 2023 (UTC) [ ответить ]
Они знают. Они делают это намеренно.

Владелец archive.is объяснил, что он возвращает нам плохие результаты, потому что мы не передаем информацию о подсети EDNS. Эта информация приводит к утечке информации об IP-адресе запрашивающей стороны и, в свою очередь, жертвует конфиденциальностью пользователей. Это особенно проблематично, поскольку мы работаем над шифрованием большего количества трафика DNS, поскольку запрос от Resolver к Authoritative DNS обычно не зашифрован. Мы знаем о реальных примерах, когда субъекты национальных государств отслеживали информацию о подсети EDNS для отслеживания отдельных лиц, что было частью мотивации политик конфиденциальности и безопасности 1.1.1.1.

Кто-нибудь должен обновить главную страницу с этой информацией. Я бы это сделал, но не уверен, как это сформулировать. Алекс О. (обсуждение) 16:37, 3 сентября 2023 (UTC) [ ответить ]
См. также https://jarv.is/notes/cloudflare-dns-archive-is-blocked/ Алекс О. (обс.) 17:16, 3 сентября 2023 (UTC) [ ответить ]
Боже мой. Я определенно не хочу спешить с выводами, но я лично не был бы уверен, что Википедия сможет использовать (и, возможно, в некоторых случаях/статьях, полагаться ) на архивный сервис, который можно просто отключить по прихоти владельца. По моему мнению, архивы по своей природе должны быть надежными . Опять же, определенно не хочу спешить с выводами , но если это не будет решено, то я мог бы увидеть возможный путь вперед, когда домены archive.today окажутся в черном списке как ненадежный архивный сервис ( если сообщество посчитает это уместным и предпримет действия для этого — для ясности, я не рассматриваю это как угрозу любого рода).
Я только что проверил, вручную изменив свои DNS-серверы, и - конечно же - страница снова работает. Но я даже не знал , что я на Cloudflare DNS (и мои DNS-серверы тоже не показывали 1.1.1.1) - и я не замечал этого до недавнего времени (может быть, изменилось что-то еще, кто знает - но я не буду гадать). Но я думаю, что определенно нужно обсудить, можно ли доверять архиву, который намеренно блокирует доступ определенным людям на основе их DNS-резолвера, для использования в Википедии.
Best, Умный котенок ( обсуждение ) 18:21, 3 сентября 2023 (UTC) [ ответить ]
Я только что очень быстро просмотрел последний RfC , и мне сразу бросились в глаза слова, что его всегда можно снова внести в черный список, если возникнут будущие проблемы . Опять же, не желая бросать здесь никаких намеков , но это говорит о том, что в прошлом могли быть проблемы с этим сайтом. Однако позвольте мне уточнить то, что я сказал, сказав, что я совсем новичок (1) в WP и (2) в теме использования archive.is на WP. Поэтому я оставлю это обсуждение на данный момент, чтобы позволить редакторам, более опытным в одной или обеих областях, высказать свое мнение. Всего наилучшего, умный котенок ( обсуждение ) 18:27, 3 сентября 2023 (UTC) [ ответить ]
Ни один из поставщиков архивов не надежен. Ни один. WebCite не работал почти два года. Ни одна из ссылок не работала. Ответ сообщества был: «Давайте подождем и посмотрим, что будет». В среднем мы теряем 1 поставщика архивов в год. Поиск по «устаревшим» и «умершим» на WP:WEBARCHIVES . Даже старый верный archive.org постоянно меняется, и снимки архивов перестают работать. Есть только одно решение для надежного резервного копирования: избыточность. Насколько он надежен (99,99% или 99,999% и т. д.) определяется тем, насколько он избыточн. Кроме того, archive.today содержит страницы, которые никто другой не будет или не сможет — черный список создаст огромное количество гниющих ссылок как сейчас, так и в будущем. Что касается этой ссоры с CloudFlare, Archive.today на самом деле имеет веские причины нуждаться в информации, которую CF отказывается отправлять. Поскольку archive.today спроектирован для снижения затрат, им это нужно. Поэтому, если они не могут получить его, они блокируют запрос — их серверам нужно балансировать нагрузку в зависимости от местоположения. Месть им путем внесения Википедии в черный список ничего не решит, кроме как создаст кучу гниющих ссылок, что сделает Википедию менее надежной. -- Green C 18:48, 3 сентября 2023 (UTC) [ ответить ]

До сегодняшнего дня при доступе к archive.today отображалась страница «Добро пожаловать в nginx!». Сегодня я часто получаю ошибку тайм-аута соединения. На сайте iidrn.com (Is It Down Right Now?) нет подробностей о том, как долго он был недоступен. Fabrickator ( обсуждение ) 18:21, 14 октября 2023 (UTC) [ ответить ]

Как поддерживать гибридное архивирование?

По-видимому, есть проблема с архивированием веб-сайтов Ajax с помощью Internet Archive.[6] Другими словами, это не работает. Однако, это прекрасно работает с archive.today. Мой вопрос в том, как нам сохранить оба в одной статье, не заставляя IABot перезаписывать ссылку archive.today? Если уже существует защита, предотвращающая это, дайте мне знать. Другими словами, проверяет ли IABot наличие ссылок archive.today, и если да, игнорирует ли он их? Viriditas ( обсуждение ) 18:47, 2 ноября 2023 (UTC) [ ответ ]

IABot не должен перезаписывать ссылку archive.today. Есть ли пример этого? -- Green C 18:51, 2 ноября 2023 (UTC) [ ответить ]
Нет, но я сейчас это тестирую. Viriditas ( обсуждение ) 18:52, 2 ноября 2023 (UTC) [ ответить ]
Обновление: Он оставил его в покое, как вы и говорили. Я не был уверен, что так и будет, но теперь я знаю. Viriditas ( talk ) 19:03, 2 ноября 2023 (UTC) [ ответить ]
К вашему сведению, вы также можете настроить тестовые сценарии в пользовательском пространстве, например, в своей песочнице, и запустить бота на этой странице, чтобы увидеть, как бот реагирует на определенный ввод. -- Green C 21:23, 2 ноября 2023 (UTC) [ ответить ]
Спасибо. Мне просто повезло, что это включало в себя корректное редактирование и необходимый запуск бота. Viriditas ( обсуждение ) 23:26, 2 ноября 2023 (UTC) [ ответить ]
Вы правы, некоторые поставщики архивов IABot не распознают и удаляют URL-адрес архива, если доступна замена. В таких случаях используйте , чтобы IABot не редактировал ссылку. Это редкие случаи. -- Green C 23:38, 2 ноября 2023 (UTC) [ ответить ]{{cbignore}}
Приятно знать. Я узнал сегодня хотя бы одну вещь! Viriditas ( обсуждение ) 23:42, 2 ноября 2023 (UTC) [ ответить ]

Почему мы это используем?

В дополнение к вышеупомянутой проблеме с DNS-резолвером, которая загоняет людей в цикл CAPTCHA без объяснений, я не понимаю, почему мы предлагаем этот сервис в качестве выбора, когда он (насколько я могу судить) управляется одним частным лицом, о котором у нас нет никакой информации. Я не имею в виду это в коварном смысле, но просто кажется очевидным, что мы не должны полагаться на это, как на реальную инфраструктуру, как это делает IA, инфраструктура, которая может показаться сложной — у них, по крайней мере, есть офис и средство связи, помимо блога tumblr. Сколько будет сломано или потеряно, если это сломается еще больше (поскольку, по-видимому, одного крупного DNS-резолвера недостаточно для разрыва сделки) или полностью отключится от Интернета? Remsense诉13:22, 4 мая 2024 (UTC) [ ответить ]

Я использую его, когда нет другого выбора — у них есть все, а я больше всего на свете ненавижу мертвые ссылки. У Wayback нет и не может быть всего. В этом мире есть только один крупный провайдер, и это Wayback. Кстати, архив обвиняется в иске звукозаписывающей индустрией за экзистенциальный ущерб (вспомните Napster). Между тем, в среднем мы теряем около 1 провайдера архивов в год, в основном это учреждения, такие как университеты и правительства — они не более надежны. Поэтому я хотел бы знать, какое безопасное место существует, потому что я не знаю ни одного. AFAIK, archive.today не находится под угрозой уничтожения, и в некотором смысле его секретность и единоличный контроль являются своего рода преимуществом от закрытия. Владелец.оператор хорошо осведомлен об этих проблемах и предпринял чрезвычайные шаги по размещению нескольких доменов и серверов по всему миру, чтобы ни одна организация или страна не могла его закрыть (и они уже пытались). Проблема с CloudFlare и DNS в некоторой степени связана с этим. Другой фактор заключается в том, что они существуют уже более 10 лет, и статистически, чем дольше что-то существует, тем дольше оно, вероятно, будет существовать. Новые сайты, такие как ghostarchive, более склонны к провалу просто из-за своей новизны (также архив, управляемый одним человеком). -- Green C 17:22, 4 мая 2024 (UTC) [ ответить ]
Я согласен с аргументами GreenC. Я склонен использовать Archive.today для любой веб-страницы, на которой слишком много стороннего javascript, особенно когда на нее ссылаются самые печально известные трекеры, такие как googletagmanager. Не имеет смысла, что кто-то, кто думает, что он/она читает архивную страницу на надежном сайте, на самом деле также отправляет свои данные сторонним трекерам. Boud ( talk ) 20:02, 29 мая 2024 (UTC) [ ответить ]
Задайте вопрос, получите ответ! Спасибо за объяснения. Remsense诉20:05, 29 мая 2024 (UTC) [ ответить ]

Типичное время архивации устарело

В настоящее время у нас есть несколько утверждений о том, что время, необходимое для архивации веб-страницы, обычно составляет 5–15 секунд , а в одном случае — 15–30 секунд . Кажется, это древняя история, например, 5–10 лет назад, когда загрязнение сторонним JavaScript было менее распространено. У меня сложилось впечатление, что типичный временной масштаб составляет 30–300 секунд. Это может варьироваться в зависимости от того, какой тип веб-страниц архивируется: простой HTML, очевидно, будет намного быстрее. Мы могли бы указать больший диапазон, например, «от 5 до 300 секунд», хотя это выглядит немного странно. Поэтому я предлагаю «от нескольких секунд до нескольких минут» для замены всех текущих оценок времени. Boud ( talk ) 20:14, 29 мая 2024 (UTC) [ ответить ]

Взято с "https://en.wikipedia.org/w/index.php?title=Help_talk:Using_archive.today&oldid=1226305591"