If you came here because someone asked you to, or you read a message on another website, please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
However, you are invited to participate and your opinion is welcome. Remember to assume good faith on the part of others and to sign your posts on this page by adding ~~~~ at the end.
Archive.today, also known as archive.is, is an archiving service similar to sites like the Internet Archive. Archive.today uses advanced scraping methods, and is generally considered more reliable than the Internet Archive. Due to concerns about botnets, linkspamming, and how the site is run, the community decided to blacklist it in 2013. In 2016, the decision was overturned, and archive.today was removed from the spam blacklist. Over 400,000 pages currently contain over 695,000 links to Archive.today
On January 2026, the maintainers of Archive.today injected malicious code in order to perform a distributed denial of service attack against a person they were in dispute with. Every time a user encounters the CAPTCHA page, their internet connection is used to attack a certain individual's blog. This obviously raises significant concerns for readers' safety, as well as the long-term stability and integrity of the service. The Javascript code which causes this is still live on the website. However, a significant amount of people also think that mass-removing links to Archive.today may harm verifiability, and that the service is harder to censor than certain other archiving sites. UPDATE: The malicious code has been reactivated, and is active as of 12:31, 9 February 2026 (UTC). Please do not visit the archive without blocking network requests to gyrovague.com to avoid being part of the attack!
Article source links that refer to archive.today are currently allowed. If the site were to be blacklisted, any edit incorporating a new URL that starts with https://archive.today/ will result in the editor being returned to their draft changes (Edit view) with a warning notice which reads (in part)
Your edit was not saved because it contains a new external link to a site registered on Wikipedia's blacklist.
To save your changes now, you must go back and remove the blocked link (shown below), and then save.
...
The following link has triggered a protection filter: archive.today
B, then A: Deprecate now archive.today and archive.is, with the goal of replacing later. In many cases, this archive link was provided because there were no other realistic alternatives for an archive (e.g., if the original website shut down). However, it's also true that many of the archived sources aren't actually needed right now (i.e., the original source is live) or a different/better/newer/live source could be substituted. Processing all of this would take time, but eventually I think we should head in the direction of not using that site. WhatamIdoing (talk) 17:22, 7 February 2026 (UTC)[reply]
Option C Archive.today contains a vast amount of archives available nowhere else. Not on Wayback Machine, nowhere. It is the second largest archive provider across all Wikimedia sites. Removal/blockage of this site will be disruptive daily for thousands of editors and readers. It will result in a huge proliferation of {{dead link}} tags that will never be resolved. In theory, citations that can't be verified any other way should be completely deleted, along with the content they cite. This includes your own content. It will do nothing to help Wikipedia, and Archive.today will not care one bit anyway. They have done nothing to harm Wikipedia (other than one incident over a decade ago). Copyright concerns can be dealt with on a per-URL basis. Much of the content is old sites that have been dead for a decade or more and Archive.today is the only place that contains these historic archives. The previous block of Archive.today a decade ago was undone because the site is pragmatic and useful to most editors. -- GreenC18:41, 7 February 2026 (UTC)[reply]
B, definitely right now, and A eventually With the proper end goal being the WMF supporting some sort of archive system, whether their own original or directly supporting the Internet Archive's work so it can be done more systematically (and maybe allow specific tailored links for WP references). There is a two-fold problem with Archive.today. The first is a result of the discussion that led to this, they're untrustworthy. The DDOS embedding isn't the first time they've done nonsense like this, with one of the prior times being them also targeting Wikipedia itself for promotional purposes. Using them is basically using a random person's website that's archiving stuff and that very much runs afoul of WP:RS requirements. Secondly is obviously the copyright issue, which WP policy already disallows for references explicitly. So that's a non-starter in the first place. Sorry, GreenC, but you can't WP:IAR around multiple expansive policies and guidelines just because you deem a random website "useful". SilverserenC19:05, 7 February 2026 (UTC)[reply]
A (or B first, A later). Wikipedia's need for verifiable citations is absolutely not more important than the security of users. We need verifiable citations so that we can maintain readers' trust, however, in order to be trustworthy our references also have to be safe to access. Archive.today has demonstrably abused its users' trust (including Wikipedia's editors and readers) by weaponising their service and cannot be considered safe. If readers and editors cannot trust the links we use in our references because we knowingly continue to rely on untrustworthy third parties, it's not just Archive.today that cannot be trusted but Wikipedia too. It is not pragmatism to risk user safety and maintain a dependence on an unsafe third party.If we choose C and ignore not only the recent incident but also its history, our reliance on Archive.today will continue to grow; we would be making the problem worse rather than gradually working towards a solution. Implementing B ensures the problem doesn't grow. We can then move towards A as we work towards an alternative. We should have worked towards becoming more resilient and less reliant on third parties like Archive.today earlier when concerns were raised years ago, but the second best time to start is now.(Edit: the discussion at WP:Village pump (technical) mentioned an FBI case against Archive.today. Depending on the outcome, the links to it may end up dead anyway. If we choose C but that happens, we would end up with the consequences of A anyway except we would have made no progress towards an alternative, leaving us even worse off. Better to get ahead of it so we're prepared either way.) – Scyrme (talk) 20:16, 7 February 2026 (UTC)[reply]
Update: Neither B nor A make Archive.today or its snapshots unusable by editors. They would only stop the addition of links to Archive.today to Wikipedia, much as we don't allow links to Anna's Archive or The Pirate Bay even though doing so would also make verification more convenient. Most of the links to Archive.today are in-fact replaceable. Many aren't even used for permanently dead links, but rather to bypass paywalls (and it's not Wikipedia's job to make piracy more convenient).As for the ones which truly aren't replaceable, they would still be available even after implementing B or A. Anyone still comfortable with using Archive.today could still copy the original URL and use the service to check an old snapshot for verification, but they would be doing so at their own risk rather than with the encouragement and assistance of Wikipedia. We don't have the power to delete Archive.today from the internet entirely, even if we wanted to, so neither A or B have any effect on verifiability beyond making verification slightly less convenient in cases where Archive.today cannot be replaced.Safety and trust must be the priority, not convenience. Verifiability is not meaningfully affected regardless of A, B, or C. – Scyrme (talk) 00:20, 10 February 2026 (UTC)[reply]
RFC proposals should always separate options that may be exclusive of each other or time-phased. Sigh.
Option A can be partially done today by hiding the links in the variety of templates to which they have been added, but adding to the blacklist may take a lot longer barring a bot removal. I support doing the part of option A which can be done immediately (to whit, modifying templates), which I think is the majority of the intent of B's "deprecate".
Regarding other technical implementations, I am a bit agnostic as to bot-removal of these links should that be discussed but do think it's fundamentally the only practical way to deal with the issue; citations already take years to deal with for just the couple tens of thousands of errors and maintenance messages that CS1 emits. The suggestion earlier of a bot or filter to block new additions (rather than blacklisting per se) is I think implicated also in option A's technical effort, and I would support that as well in the immediate term.
The history of the website and its owner are long and sordid (and more recent than above, e.g. the user I still think is a sock of the originally blocked Rotlink at this AN discussion in 2022). I would rather have a half million dead links than another half million links which may compromise the owner's systems, or any of a variety of other technical abuse. Izno (talk) 20:42, 7 February 2026 (UTC)[reply]
Option B. No further archive.today links should be created after (date this RFC passes) and this should be enforceable via bot, with the bot going around requesting IA archiving of such links. While A is interesting, let's not leap to it - sometimes websites are dead and the IA can't back it up. Someone doing the slow process of migrating migratable archives to IA would be useful (ideally when the website content is substantially the same, or has only merely moved URLs), but even if everything migratable is migrated, there will still be some stranded links where archive.today is truly the only option. Option B should minimize the usage of archive.today, but allowing it to continue in a small way in the long-term is acceptable, so not in favor of option A. SnowFire (talk) 21:16, 7 February 2026 (UTC)[reply]
For what it is worth, IA simply cannot archive at all many websites which Archive.today can. They archive things completely differently. Many websites, actually. This would, in effect, make many sites completely unachievable for our purposes. Just to note. PARAKANYAA (talk) 00:22, 8 February 2026 (UTC)[reply]
And that is a shame, but we just can't continue to use their services barring a switch in ownership or attitude from their current maintainers. Better to rip the band-aid off sooner rather than later. SnowFire (talk) 00:46, 8 February 2026 (UTC)[reply]
Option B Their recent behaviour isn't excusable, but removing all instances of it's use would be counterproductive and disruptive. I don't believe blacklisting at this point is the correct choice. I belive it shouldn't be the first choice, but there could be circumstances where it's needed. It should be discouraged but not disallowed. -- LCU ActivelyDisinterested«@» °∆t°21:44, 7 February 2026 (UTC)[reply]
This is significantly premature. Per NatGertler and Amigao in the discussion section, we have no reliably sourced confirmation that the alleged bad behaviour actually happened, let alone happened in the way it is protrayed above, and there appears to be equal likelihood for both sides to be telling the truth and for both side to by lying. We should not be making any decisions about changing anything based on the information currently available. Thryduulf (talk) 22:17, 7 February 2026 (UTC)[reply]
@Thryduulf We may not have a traditional RS, but you know what we do have? (Apart from Pppery's investigation above[1], which I've been able to replicate) Emails between somebody affiliated with Archive.is and the blog post. Neither the blog writer and the archive.is person have disputed their authenticity (and, in fact, the archive.is person complained they were too censored and published even more on their blog - [2]) - and in the emails, when directly asked about the alleged DDOS and legal threats, the archive.is person said, and I quote, So now there is no other option but to escalate the matter in various ways.. That's.... that's as close to admitting as you're going to get. GreenLipstickLesbian💌🧸23:06, 7 February 2026 (UTC)[reply]
Actually, speaking of those emails, my eye is drawn to this line:[3]
And threatening me with Streisand... having such a noble and rare name, which in retaliation could be used for the name of a scam project or become a byword for a new category of AI porn... are you serious?
(This is only somewhat coherent, but both the Archive.is tumblr and the emails make a lot of references to the blog owner's name)
Am I the only one who is... deeply uncomfortable with the idea of encouraging editors to use a website where the owner apparently thinks spamming Wikipedia with links, using visitors to the site to launch attacks on other people's websites, and then... seemingly threaten to create some form of revenge porn against people they're having a dispute with is a reliable mirror? Because I don't. And, while I'm unsurprised to see that some people don't view that as harmful, it is? GreenLipstickLesbian💌🧸08:07, 8 February 2026 (UTC)[reply]
Option C both per Thryduulf but also because the site is a valuable resource that sometimes is the only option. Old websites that have only been archived on archive.today should remain available to us. If Option B gets consensus it would mean that there is a deadline until the end of this RfC for some content to be written and after that point it will be impossible to source it even though the information will still be available on the open web. Even worse, with option A, sourced information will have to be removed simply because we won't be able to use the source. That is certainly not a desirable outcome. Warudo (talk) 22:57, 7 February 2026 (UTC)[reply]
B then A - they've proven that they can't be trusted they won't do this again. We could first stop any new links from coming in and then clear out the existing links before adding it to the spam blacklist. I'm not sure how links can be migrated to IA, but anything saved in archive.today should be migrated there if possible. HurricaneZetaC23:17, 7 February 2026 (UTC)[reply]
We absolutely do have evidence that this DDOS attack happened. It doesn't take much coding knowledge to verify it for yourself, and if you don't have that coding knowledge, then please consider either trusting the people who do, or else not !voting here. I think that on ethical grounds we've got to stop using that site in early course.—S MarshallT/C23:51, 7 February 2026 (UTC)[reply]
A. Just get rid of the links now, no need to wait. And their responses to the whole ordeal (as can be read from their Tumblr blog) aren't very professional either. Some1 (talk) 23:55, 7 February 2026 (UTC)[reply]
B as we prepare for A. I say this as someone who will soon be busy removing the many archive.today links I've added (since archive.org doesn't reliably work for many Nordic news sites). However, we cannot prioritize verifiability over user safety. No one here should have to worry about becoming a pawn in random internet beef. Zzz plant (talk) 00:05, 8 February 2026 (UTC)[reply]
Option C This is honestly the first I've heard of this DDOS attack. However, with the amount of Wikipedia articles using archive.today links, I don't see removing them all and/or deprecate as being beneficial. I had in the past primarily/only used Internet Archive to archive existing website. At some point (don't remember when), I found archive.today, and have used both concurrently to archive website. I honestly tend to stick with using archive.today moreso with the amount of times I've had issues with Internet Archive saving website(s), whether it be the 'You're currently archiving too much right now and need to wait', or sites that just literally do not archive on there. (working on a lot of articles related to television, for example, The Futon Critic is excluded from the Wayback Machine, and I've had to use archive.today when archiving that website). I've also had numerous times where the Wayback Machine struggles to load archived pages for me, while archive.today snapshots very quickly load up (I imagine that would be something to do with IA/WM trying to have a more 'live' archived version, where as archive today saves moreso a screenshot of the saved page rather than loading all the background processes?...) Also per GreenC's response. Magitroopa (talk) 00:21, 8 February 2026 (UTC)[reply]
B then A: I agree with Scyrme's rationale that the security of wikipedia users comes first and there is no website archive worth exposing a single user or editor to malicious behavior. I am also concerned with the longevity of the website (for both these reasons and other legal concerns), and I think option C would probably just delay the inevitable. Deprecating the site and then finding an alternative I think is the best way forward. Geethree (talk) 01:15, 8 February 2026 (UTC)[reply]
Option C unless someone can come up with an alternative that isn't 1. convincing the WMF to abandon its free content mission 2. misunderstanding how the Internet Archive works or 3. ultimately deleting all information on hundreds of thousands or our pages from the many, many web sources the Internet Archive cannot archive. I could support it if we retire WP:V, I suppose. PARAKANYAA (talk) 01:28, 8 February 2026 (UTC)[reply]
Option C. There are many websites that do not permit archiving by archive.org or have only been archived by archive.today before becoming a dead link. Removing the ability of editors to access relevant sources that verify content will not improve the encyclopedia in any way.Katzrockso (talk) 02:01, 8 February 2026 (UTC)[reply]
Option C per GreenC and Thryduulf. And: was Wikipedia harmed? No. Was the harm serious? Hardly. -- Michael Bednarek (talk) 02:05, 8 February 2026 (UTC) – After learning more about the nature of archive.today from Jani Patokallio's blog, I changed my vote to Option B. There seems to be a good chance that archive.today might disappear some day anyway. -- Michael Bednarek (talk) 10:27, 8 February 2026 (UTC)[reply]
Option C: the significance of the archive is too important to make a reactionary decision that could undermine hundreds of thousands of articles and cause a substantial loss of information. The concern presented here relates to an internal cyber security incident that was quickly exposed and has a small scope. Primary concern should be placed on the veracity of the archive and its safety to visitors in ordinary circumstances; there is little evidence that the archive is undermined in a way that should warrant its removal, and the actual risks and damage are being overstated. ProtoKiwi (talk) 02:19, 8 February 2026 (UTC)[reply]
Option C: For the same reasons as the last five Option C votes. No harm was done to Wikipedia or wikipedia users by the alleged actions, and the negative consequences of Option B (let alone Option A) would be tremendous and would cause great harm. Instead, I suggest that we focus on a voluntary effort to slowly migrate all existing archive.today/archive.is links to instead use links to the internet archive in all cases where this is determined to be possible (ie when the internet archive has live captures of the same website at the same point in time available and the content of the capture from the internet archive has been determined to be 100% identical to the content of the capture from archive.today/archive.is, as determined by manual human review (or by a bot that is sophisticated enough to reliably distinguish between partial (e.g. paywalled) or failed (e.g. error page, changed content, etc) captures and actual full 1:1 captures – note that the existing archive bots seem to lack this capability, so they would not qualify)), but to continue to preserve existing links where a 1:1 alternative is not available. Garzfoth (talk) 02:56, 8 February 2026 (UTC)[reply]
@Garzfoth, how do you know that no harm was done to Wikipedia users? Or, are you using a definition of "no harm" that says if someone hijacks your computer system without your knowledge or consent, then that's okay with you, because taking over your computer isn't harming you? If so, give me a couple of days, and I'll have a contract for you to sign, just so there can't be any questions later about whether you authorized me to make your computer spew some spam, okay? WhatamIdoing (talk) 04:10, 8 February 2026 (UTC)[reply]
@WhatamIdoing: Misusing the user's browser to run a transient network attack against a single target website does not materially harm the end user that is accessing/using a archive.today/archive.is webpage. The misuse only occurs while the page is open, and ceases once the page is closed. This behavior is absolutely not acceptable, but it is also not directly harmful to the end user. No permanent harm takes place. Now if they were serving up forced malware downloads when you loaded a archive.today page, that would be something which materially harms end users, and would absolutely merit taking this kind of drastic action to swiftly remove these links. And if there was proof that they were using this network attack functionality against a range of arbitrary targets (e.g. to run a commercial DDoS-for-hire service), then I would also be in support of taking drastic action. But a single one-off case that has apparently already ceased and has not recurred since then? Not a major concern. Sure, it's enough to justify beginning efforts to voluntarily migrate away from using links to this archive wherever possible. But it's not enough to justify immediately deleting all existing links and prohibiting adding any new links by adding the domain to the spam filter, when this is a unique and irreplaceable resource that is extensively relied upon by a huge number of existing wikipedia articles, and cannot be replaced by other services in many cases. Garzfoth (talk) 07:21, 8 February 2026 (UTC)[reply]
I'm just saying that if you think that's not "harmful", then you don't have any grounds to complain if I, or anyone else, do the same thing with your web browser. All it would take is one quick little script in common.js, and we could set it so that it targets only you (and/or anyone else who thinks it's not a harmful thing to do). A few years back, one of the Wikipedias briefly had a crypto mining script running on all readers' computers – but, hey, that's "not directly harmful" and "does not materially harm the end user" and "No permanent harm takes place", so you certainly wouldn't mind if we did that to your account, right? If you think you would mind after all, well, maybe you'd like to re-think what harm means.
I agree with you that hasty reactions tend not to be the best responses, and I think that we should have a measured, thoughtful, proportionate response. But I don't agree that the website's behavior was harmless. WhatamIdoing (talk) 23:59, 8 February 2026 (UTC)[reply]
Option C: Archive.today had been blacklisted before, and that was NOT the best move. It is capable of archiving so much that Internet Archive cannot. It is also immune to robots.txt, because I spent over a year archiving Kalki Online links which became nought the moment they applied robots.txt. Thankfully I had archived those links using archive.today, and they are still working. Kailash29792(talk)04:31, 8 February 2026 (UTC)[reply]
Option A: Miserable with the fact I find myself here, but we cannot permit websites to rope our readers into being part of DDOS attacks. In truth, I plan to keep using archive.today but do not intend to link to it on-wiki. If readers or other editors want to verify information I add, they can access archive.today through their own websearches instead of clicking a little link. The fact is that most of the archive.today links on Wikipedia are not an attempt to save URLs that have now gone dead that the Internet Archive cannot handle, but efforts to bypass paywalls, which is convenient, but illegal. It's strange that we accept links to archive.today for this purpose but don't accept the same for Anna's Archive or Sci-Hub. Rollinginhisgrave (talk | edits) 05:08, 8 February 2026 (UTC)[reply]
I think this is a good point - there's many old blogs, google drives, and archive sites that we don't link to in main space, but for which I'd have no issue using, personally. (I mean, purely hypothetically - I, of course, have never used an old blogspot or other websites to access 1960s magazine articles and obituaries or paid sources) - it's not like it's unavailable completely. Just not as convenient to access (whilst still being far more convenient than books, papers, or print sources.) GreenLipstickLesbian💌🧸05:18, 8 February 2026 (UTC)[reply]
I'm an Option B kinda gal. Ethically, it would be very wrong of us to continue using an archival site that pulls this kind of nonsense. Pragmatically, we can't nuke every archive.is link that exists all at once without recourse or nuance; there's 700,000 of them, we don't know what's in there. I think option B combined with a concerted effort to replace existing archive.is links with alternatives is the cleanest way to go. This also gives wiggle room just in case there really is no other source for something; the information still exists even if it's only in the hands of an asshole. Tessaract2Hi!05:17, 8 February 2026 (UTC)[reply]
Option B > C > A: This seems like an appropriate measure for the time being, and I am unswayed by the claims that archive.today is so critical for verification.How many of these ~700k links to archive.today are actually truly irreplaceable? And if a webpage really is so obscure that only archive.today can touch it, then is it really so valuable for verification? And does the verifiability really outweigh the risk it puts on Wikipedia's users?I dislike A, however, because I think it's preferable to come up with a more thorough clean-up solution. I'd like to see links replaced if they can be replaced. In light of the malicious code being reactivated, I've updated my position, see below. MEN KISSING(she/they) T - C - Email me!05:30, 8 February 2026 (UTC)[reply]
Option B: (removed previous !vote, I changed my mind): This sucks! Extremely shady shit. Not sure the blast radius is large enough to completely deprecate it yet -- although I think it's fairly likely this isn't a one-off, given human nature and all that -- but shady enough that we probably shouldn't actively keep using it in mainspace. Obviously we can't police what people use to read articles by their own accord. Gnomingstuff (talk) 06:39, 8 February 2026 (UTC)[reply]
Option B for now. This is a difficult decision, as we must consider the impact on the readers above all. On the one hand, a website that injects malicious code to force its users to participate in a DDoS campaign should, quite obviously, not be trusted – especially as it opens the door to future malware that might more directly affect readers. On the other hand, breaking thousands of links will also harm our readers, as source verification is one of the essential services provided by Wikipedia, and the reason why we can be trusted to begin with. Most likely, the vast majority of the 700k links can be safely replaced by other archiving websites, and this should be done as soon as possible, without taking down all the links in the meantime. Chaotic Enby (talk · contribs) 09:55, 8 February 2026 (UTC)[reply]
A - largely per Scyrme's reasoning, even though we disagree on the priority action. We should immediately hide all the links (convert to a wikicode comment maybe unless there's a standard way to do it). Ultimately I'd rather have a statement made that is difficult for a reader to verify instead of a link to a website that is acting maliciously. We're complicit in that if we know about it and leave those links in. WP:V cares about verifiability being possible, with it being easy a nice to have. A commented link to the website buried in the wikicode so we know where the info came from does satisfy WP:V (albeit in a really suboptimal way). We can then replace an unhide those archives over time where possible, and if it's not possible, then we've done the best we can do. (Pragmatic note to closer - it's pretty obvious that the tea leaves have this as a 2 horse race between B and C, B is significantly superior, although still insufficient.) Tazerdadog (talk) 11:04, 8 February 2026 (UTC)[reply]
Option C - personally, and I stress again that this is my personal view, my biggest priority is ensuring for WP:V for the next 5, 10, 15, and 20 years to come. Yes, DDoS attacks are unethical. Yes, the webmaster should not have done that, and should be admonished for doing that. However, as an individual, I weigh the importance of WP:V on top of the ethical problems of the DDoS attack as a matter of pragmatism; in a perfect world, we should only reward good deeds and punish bad actions, but we live in the real world. Finland had to cooperate with the Axis powers in order to ensure its own survival, the American Red Cross receives funding from Philip Morris USA, and the survival of the Ukrainian state in 2022 would not have been possible without companies such as DJI. The Wayback Archive is extremely unreliable and is down due to some sort of outage 60% of the time I attempt to use it, webcitation.org is dead, and there are no better alternatives. Until better alternatives become available, I do not feel like it is beneficial for Wikipedia to shoot itself in the foot like this, even if linking archive.is is the objectively wrong and unethical thing to do. Sometimes, we have to do evil things in order to keep the world turning. --benlisquareT•C•E11:51, 8 February 2026 (UTC)[reply]
Option C, until at least some sort of analysis of what percentage of archive.today's archived links truly aren't replicable. Unilaterally removing every link seems terrible considering the amount of areas it's used across the wikipedia. If the website gets taken fair enough and we can make do, but for now I don't think it's a good idea to remove the website. When reading through this RfC it doesn't feel like anyone really knows how many dead links and references this'd cause us to permanently lose. RandomEditsForWhenIRemember (talk) 12:09, 8 February 2026 (UTC)[reply]
Option C: This is concerning news but I think more investigation and thought needs to be put into this, rather than jumping to not using the site anymore. I often use archive.today for sources that cannot be archived on Wayback Machine, so if we stopped using archive.today for those then we would be losing archives of many sources and risking the loss of so much historical data. In my opinion, that would be a fundamental failure for Wikipedia. - adamstom97 (talk) 13:05, 8 February 2026 (UTC)[reply]
Yeah Adamstom.97, I mentioned above that I increased my usage of archive.today as it is immune to robots.txt which Wayback isn't. Because I spent a year archiving Kalki Online links on Wayback which became moot after they induced robots.txt, but archive.today continued (and still does) to accept those links. I don't think anyone noticed my message, hope you do. Kailash29792(talk)13:12, 8 February 2026 (UTC)[reply]
Option C: it would greatly harm verifiability and per GreenC. Also, doxing by that other site's owner is terrible behavior and should not be tolerated or defended. Adding code to get the site DDOSd seems counterproductive in that it will only draw more attention to that site; maybe it wasn't added by the admin. In any case, we need these links to stay for now. If you'd like to do something, maybe that should be getting links currently only archived by that site also archived in its alternatives. A later RfC on the same or a similar question could then have a different outcome if such was done / available. --Prototyperspective (talk) 13:32, 8 February 2026 (UTC)[reply]
Aas a first choice, although B with a very short timeline for removing would be acceptable. We cannot become knowing accomplices to this kind of activity. Nor can we rely on someone who would engage in this sort of behavior to not continue spiraling and do something even worse. And we cannot rely on this website to stay around anyway. Switching now, when the site is still live and we can still access without major issues, is far easier. Edit: Given that this is an active attack, I now only support A. All links should be immediately commented. B is vastly better than C, although still far insufficient. LordCollaboration (talk) 13:56, 8 February 2026 (UTC)[reply]
C Archive.today is the only option for some web archives, particularly the site Stuff You Will Hate, which had itself excluded from Archive.org. It was an incredibly important music site with some of the only records of the 2010s progression of hardcore, metalcore, pop punk, soft grunge, screamo and easycore. Issan Sumisu (talk) 14:14, 8 February 2026 (UTC)[reply]
Option C, per Green C et al. Deleting many thousands of archived citations that are available nowhere else is not a positive for the encyclopedia. BeanieFan11 (talk) 15:07, 8 February 2026 (UTC)[reply]
If the reports of using the site in a DDOS attack are true then A is the only moral option. "But they didn't hurt Wikipedia" is a shockingly naive and immoral response to these accusations. ElKevbo (talk) 15:51, 8 February 2026 (UTC)[reply]
Option B. archive.today's addition of a malicious script that abuses its web traffic (including visits from Wikipedia users) to conduct a DDoS attack against another website, without the consent or knowledge of archive.today's users, is an obscene breach of trust and a security concern. I have no idea why archive.today's operator(s) would degrade the reputation of their service in this way, particularly as this attack was unlikely to suppress the information when the blog writer could have simply posted it somewhere else. This behavior is so irrational that I am wondering if archive.today has been compromised; whether this is the case or not, I can no longer support recommending archive.today as a web archiving service when any other option is available. Option B does not remove any existing links to archive.today, but does discourage future use of archive.today in favor of more trustworthy services that do not misappropriate their users in a manner indistinguishable from malware. — Newslingertalk16:13, 8 February 2026 (UTC)[reply]
Although I vote for Option C, I am okay with B as long as the existing archives are left alone (I know that's the point). Sometimes issues like these, which are detrimental to expanding articles, makes me want to quit Wiki. Kailash29792(talk)16:16, 8 February 2026 (UTC)[reply]
Option C. I find this to be a challenging quandary but ultimately I think archive.today is a net positive for Wikipedia. I cannot support removing or disallowing such a valuable resource for verification, even if it may be a questionable one. A compromise I would support if it is technically possible is to retain archive.today links, but present some sort of dialog box warning to Wikipedia readers when any archive links are clicked, something along the lines of, "this archival website is not affiliated with the original publishers of this source nor the Wikimedia Foundation, and Wikipedia cannot guarantee the security of this website. Do you wish to continue?" with an option to either access the archive link or go back. However, I do not know how difficult this would be to achieve, or if it would be considered important enough to be an exception to WP:NODISCLAIMERS. Any thoughts on this idea from those more technically versed in the software might be useful, assuming it is not deemed a complete nonstarter. silviaASH(inquire within)16:59, 8 February 2026 (UTC)[reply]
(edit conflict)B, then A: Wikipedia should not be directing its audience traffic to support a botnet. They may have removed the DDOS-ing code now, but I see no reason to believe they won't do it again. Aaron Liu (talk) 17:00, 8 February 2026 (UTC)[reply]
I can independently confirm that the malicious code is not just in the past but still ongoing. We cannot essentially infect our users into a botnet. Stopping the addition of new links, which is the only thing Option B does, should be the minimum. Aaron Liu (talk) 15:59, 9 February 2026 (UTC)[reply]
Option B The actions of the site owners/sysadmins are absolutely inexcusable and likely illegal. Any cites that also have backups at the Wayback Machine should be updated, but those that don't need to be kept until another archive is made. — Jkudlick ⚓ (talk)17:39, 8 February 2026 (UTC)[reply]
Option C I was burned by WebCite's demise, and with more than a half-million links in WP now, it's another catastrophe unless those links can somehow be preserved under Option B. Today often saves pages better (e.g., saves graphics more completely) than dot org. Are there better options to Today than dot org? —RCraig09 (talk)18:09, 8 February 2026 (UTC)[reply]
unless those links can somehow be preserved under Option B. If I'm reading it properly, option B would keep everything in place as it is currently, only disallowing new archive.today link additions. Tessaract2Hi!18:14, 8 February 2026 (UTC)[reply]
Some variant of Option B This website has been suspicious ever since it was first used on Wikipedia. It is not a nonprofit like IA which can fight legal battles; it is a pseudonymous botnet. Wikipedia bots and users should behave as if it will be sued out of existence tomorrow. Ideally, there should be more active attempts to ping IA for URLs in order to minimize archive.is usage and remove excessive usage of archive.is. I notice and accept the counterargument that archive.is currently performs the greyhat service of archiving URLs which robots.txt forbids to IA; this should not lessen our suspicion of it. NotBartEhrman (talk) 18:15, 8 February 2026 (UTC)[reply]
Somewhere between B and C. I would propose D, that Wikimedia needs it own archiving project; perhaps buy/take over the WebCite consortium? And if possible, migrate Archive.today content to the new project.--3family6 (Talk to me|See what I have done) 19:04, 8 February 2026 (UTC)[reply]
A lighter option B > Option C >>>> Option A I do agree that we should take steps to discourage archive.today usage if it is possible, but I am concerned that full deprecation will result in editors indiscriminately removing the links without replacement which would cause the loss of valuable content. For that reason I also strongly oppose Option A. Things such as an edit notice suggesting to use archive.org if possible is something I would support, but I would skip things such as the edit tag filter as that would cause undue attention to the edit. I could also be suppurative of changes in the cite templates to replace direct links with "archived on .today", which will indicate that the source is still available while not providing direct traffic to the site. JumpytooTalk19:28, 8 February 2026 (UTC)[reply]
Option A. When readers come to Wikipedia looking for reliable information, we want them to trust not just the content we provide but, more crucially, the sources we're citing. If we're including a URL in a reference, then readers should be able to trust that they're going to a reputable website, not one that might hijack their browser to DDOS someone. If archive.today was actively hosting malware, the choice would be obvious and we wouldn't be second guessing ourselves with "think of the content". We clearly cannot trust the owners of this website - might they do something in response to this RfC, targeting Wikipedia editors? As Rollinginhisgrave notes above, if you want to use archive.today to find a source, that's fine, no one is stopping you, you can take that risk, and then you can still cite the document you've found, you just won't be including a potentially malicious URL in the process. I find the analysis below convincing too; the impact is not as great as it first appears. Sam Walton (talk) 21:16, 8 February 2026 (UTC)[reply]
Option C for now but keep a close eye on archive.is going forwards and make some attempt to replace it when possible, in case we have to remove it in the future; and make sure we have a panic button that could conceal all links to it rapidly in the future if necessary. I hate having to make this choice (per my comments below, this is extremely serious) but ultimately, looking at what happened, I don't feel that it actually puts users who are linked to the site in actual danger, or suggests that visiting the site in the future will put them in danger. And with that in mind, the costs to our users from taking it out would, comparatively, be too high. This just isn't enough to justify such a dramatic step. EDIT: Since some editors are talking about reliability, I should emphasize that we are solely citing this as a host; hosts do not require reliability in the WP:RS sense, only that we trust that the material they host be accurate reflections of the original publications. We're clearly never going to be relying on them as a publisher, so they don't need to have a reputation for fact-checking and accuracy; we just have to be confident that they're not altering their archives. I think that we can still be confident of that, despite this. --Aquillion (talk) 21:24, 8 February 2026 (UTC)[reply]
Option C - this is a dispute apparently between two individuals. As a neutral encyclopedia it's not our job to take sides here, and typically there are two such sides. On a personal level we may have views about unleashing DDoS, and an individual editor may choose to steer clear of archive.today as a result. Collectively our bigger problem is link-rot undermining the project, and that has always been the case. But I don't think we should be activists in this dispute, at least on what we currently know. I do see a strong case for WMF to host/own our own archive service, this sort of case illustrates the logic. ChrysGalley (talk) 21:39, 8 February 2026 (UTC)[reply]
This stopped being just a dispute between two individuals after the users of Archive.today (including users of Wikipedia) were unknowingly roped in. This was never about picking a side, but about user safety. Maybe you don't agree that users were especially harmed by this or that future risks are likely, but don't misframe the situation as picking sides in an external dispute. – Scyrme (talk) 22:08, 8 February 2026 (UTC)[reply]
Option C. This is a slippery slope of considering other criteria than the ones we have in the policy when assessing sources. There is zero evidence that Wikipedia users were or would be harmed by this website. Alaexis¿question?21:49, 8 February 2026 (UTC)[reply]
@Alaexis, @ChrysGalley, et al.: People in the real world were harmed by this website, and the more links we have to archive.today, etc., the more harm we'll do to those people. I find it really sad that we care about Wikipedia itself more than the impact we have on the real world. The same way we don't go around spreading libel about living people, we shouldn't go around promoting websites that use illegal tactics to take down dissenters. And also no, this isn't indirect; the maintainers of archive.today aren't funding bad stuff, they're doing it themselves. In that way, it's different than most of the slippery-slope (ideological) divestments you may have seen on the news.
Also, malware risk is definitely somewhere in the process of assessing the reliability of sources. I'm fairly certain that the community would say no if a "reliable" source has cryptominers in it. Why can't we say no to websites that use your internet connection to DDoS other people?
I hold immense respect for the people and the technology that power Archive.today, but trust, once lost, cannot be easily regained. The only way we can fix this is if we get a statement from the maintainer(s) of this service that denounces this kind of behavior, and a promise that they would never engage in such behavior again. Without that, we would be directing our readers, the people we're building the encyclopedia for, into an active minefield. ChildrenWillListen (🐄 talk, 🫘 contribs) 00:34, 9 February 2026 (UTC)[reply]
@Polygnotus: Yes, it took two years for the community to reallow archive.today after their (supposed) botnet attack, and that wasn't without significant opposes. We now have credible evidence (that you can check yourself) that they have injected malicious code that attacks other websites into their archives. In an ideal world, malware and attacks on real world people should void all arguments regarding the utility of a source, for something much worse is at stake. ChildrenWillListen (🐄 talk, 🫘 contribs) 01:00, 9 February 2026 (UTC)[reply]
People in the real world have been harmed by the owners of many websites that we use (think of all state-owned and state-controlled media outlets we're using). Banning them now without any basis in our policies will make it likelier that someone else will try to ban something else.
I'd start with a policy that clearly articulates the criteria for banning the use of an online resource (e.g., cryptominers). I'd support such a policy if it were sufficiently focused. Alaexis¿question?08:02, 9 February 2026 (UTC)[reply]
As said above, there is a difference between linking to sites whose owners have committed harm in other contexts, and sites that are directly being used to commit harm. The latter category is much closer to malware than to media of questionable ownership. Chaotic Enby (talk · contribs) 08:55, 9 February 2026 (UTC)[reply]
B, then A. Per Thryduulf and Maltazarian's analyses below, the vast majority of the archive.is links we currently have aren't actually needed for verifiability. Most of them are archived by the IA too, and most of the remainder either (a) can be replaced easily with better sources, or (b) already don't actually verify the claim they're cited for. So there's really no excuse for us to be sending our readers to this service which is clearly untrustworthy. Greg Price (talk) 21:55, 8 February 2026 (UTC)[reply]
Option C by default, there are too many refs that only exist on archive.today. Option B, if, and only if, users are directed to search other archives for an equivalent source, and if none is available, snapshot the archive.today link on a more trustworthy archive. This currently does not work on the IA, but perhaps something could be arranged with them. If that works, then old archive.today refs can be converted via bot to the new 'archive archive'. If we cannot make it work, Option C is the only choice. Regardless, editors should be encouraged to use better archives when possible. UnlikelyEvent (talk) 22:33, 8 February 2026 (UTC)[reply]
B, then A - per my comments elsewhere on this page. Also, I believe that all comments saying "we can't get this information anywhere else" should be discarded as obviously untrue- at the end of the day, any editor who wishes to cite, and link, a website they can only find on archive.today/archive.is can open up an account on Blogspot, Flickr, Google drive, Substack, whatever, and host a screenshot there to link. If they aren't willing to do so, then they aren't required to, that's fine -- if you're worried about being sued for copyright infringement, then you probably shouldn't be linking to the material on Wikipedia anyways. GreenLipstickLesbian💌🧸22:36, 8 February 2026 (UTC)[reply]
Also, in case it's not obvious - I echo others A is looking like something we'll have to do eventually, anyways. and at least this way we have a chance to do it on our terms. I hate to break it to you, but even if the FBI thing goes nowhere, a website whose operator apparently threatens to create AI porn in retaliation against enemies, using their names, [4] isn't a trustworthy mirror, and isn't going to remain one. GreenLipstickLesbian💌🧸23:00, 8 February 2026 (UTC)[reply]
While I agree that anyone can theoretically archive any webpage by screenshotting it and hosting it on a blogspot/github/substack/etc page, I assume part of the reason why people choose to use archive.org, webcitation.org and archive.is is that everyone as a whole accepts these snapshots as undoctored and unmodified, and therefore, a reliable capture of what the webpage looked like at a certain point in time. There is implicit consensus by the community at large that the archived snapshots don't lie, otherwise we would not be using them. If someone were to screenshot a webpage and self-host it on their own page, it wouldn't be unreasonable for other editors to doubt the authenticity of the screenshot, even if the original author had zero ill intent. --benlisquareT•C•E23:41, 8 February 2026 (UTC)[reply]
@Benlisquare Implicit consensus is the weakest form - I see no reason why we should trust a website belonging one Wikipedia editor, when we know that website has been weaponized above, say, a screenshot given to me by, really, the vast majority of editors in this thread - as I would do if they were to provide me with a quote of an offline source, or how I would trust them if they cited an offline or non-English language source for a fact in an article. GreenLipstickLesbian💌🧸00:05, 9 February 2026 (UTC)[reply]
Per the analysis below, I think all this malarkey about taking a screenshot of the webpage and hosting the screenshot is missing something really simple.
The majority of the usages of archive.today on Wikipedia are not irreplaceable. Two thirds of them, at least, capture content that is also captured by archive.org. And of the ones which are not available at archive.org, most of them seem easy to replace regardless. MEN KISSING(she/they) T - C - Email me!02:09, 9 February 2026 (UTC)[reply]
None of these services are suitable for long-term (5+ years) storage.
This will fail verifiability, because there's no way to know the content of these screenshots haven't been changed to create hoaxes/fit one's narrative/etc.
Both of these arguments apply to Archive.is/Archive.today as well, though? You have no way of knowing if the content of the screenshots hasn't been doctored, and no evidence that it's suitable for long term storage. (Though.... yep, my old blogspot from when I was in elementary school is still active. Older than Archive, that thing) GreenLipstickLesbian💌🧸08:07, 9 February 2026 (UTC)[reply]
"You have no way of knowing if the content of the screenshots hasn't been doctored" - firstly, while I've personally seen some archived copies being replaced with a fake "Welcome to nginx!" page, these were not archives of websites usually linked on Wikipedia, and this is not really tampering, just excluding a URL, something Internet Archive does all the time, and secondly, there are approximately 100k webpages being saved on archive.today daily; this is not an amount of data any one person can process so the owner tampering with completely random pages is a very unlikely scenario. "no evidence that it's suitable for long term storage" - the first snapshot on archive.today was made on 22 May 2012. I don't know of any Google Drive files from this period which are still accessible, and all other services you mentioned were not designed to be someone's free file hosting. sapphaline (talk) 09:19, 9 February 2026 (UTC)[reply]
@sapphaline: The "Welcome to nginx!" thing apparently started happening after the attack, which is definitely interesting, yes.
the owner tampering with completely random pages is a very unlikely scenario: There are certainly ways one can tamper with a large set of pages.
there are approximately 100k webpages being saved on archive.today daily...: Where are you getting this information from? As far as I can tell, the website doesn't report any analytics at all.
I visited archive.today/archive.md and was not presented with a captcha. I then initiated a save which brought up a captcha. I inspected the source code, searching for 'gyrovague' and 'random', with no result. How did you find the offending Javascript? -- Michael Bednarek (talk) 14:01, 9 February 2026 (UTC)[reply]
@Michael Bednarek You need to inspect the correct file, it's not in the main page source, see the image in the blog post. I confirmed, looking at my Network tab, that I was sending repeated requests as the Javascript implies. Sam Walton (talk) 15:28, 9 February 2026 (UTC)[reply]
Confirmed. But I'm quite sure I saw that piece of Javascript mentioned at gyrovague.com in the HTML source before. But Firefox Web Developer Tools/Network shows those GET operations to gyrovague.com. Alarming. -- Michael Bednarek (talk) 15:40, 9 February 2026 (UTC)[reply]
I know that the owner of archive.today is watching this discussion so I'm not going to disclose the endpoint I used because they might close it. sapphaline (talk) 15:54, 9 February 2026 (UTC)[reply]
the owner tampering with completely random pages is a very unlikely scenario Yeah, well, so is using your website to DDOS an enemy. And look what we're dealing with. GreenLipstickLesbian💌🧸18:35, 9 February 2026 (UTC)[reply]
Analysing 100k webpages to decide the ones you will tamper with is way harder than writing malicious JavaScript and putting it into your CAPTCHA page. sapphaline (talk) 19:08, 9 February 2026 (UTC)[reply]
Option C, open to B if clarified: Option A feels nuclear given current evidence weighed against the immense disruption removal would cause. Option B could be reasonable, but I'd want more clarity on how migration would work, on what kind of timetable, etc. Like others, I wish I saw a better alternative here. But we are where we are, with imperfect solutions and digital rot only accelerating, now compounded by the proliferation of AI slop, making pre-slop web archives even more valuable. More broadly, the semi-legal (being generous) nature of web-archiving creates structural advantages for operating anonymously out of "sketchy countries". I suspect this pattern will recur no matter the fate of archive.today. Short term, redundancy seems like the best approach, which (unfortunately) suggests continued use of archive.today, as removing it would gut tens (hundreds?) of thousands of refs that don't exist elsewhere, and leave us with a single archiver of any significant scope and history (Wayback). PickledCookies (talk) 02:30, 9 February 2026 (UTC)[reply]
Option B involves no current action against the existing links, it only disallows future additions of the links. A large portion of the archive.today links on Wikipedia are hosting content that can also be found on archive.org, and switching the links out in those cases could be an automateable task. MEN KISSING(she/they) T - C - Email me!02:57, 9 February 2026 (UTC)[reply]
I doubt anyone here has significant opposition to changing archive.today links to archive.org links when that is possible, the question is the resolution when no such substitution exists. Katzrockso (talk) 03:53, 9 February 2026 (UTC)[reply]
A few examples from cases where archive.org was not an option from reading the below analysis (GreenC's sample did not include usages on Wikipedia, so I haven't looked at those.):
Adolph John Paschang: The archive.today link does not actually verify the claim, so it would either need to be removed, or sourced to the book that the archive.today link directs you to.
Professional Sports: The archive.today link is used to source a claim regarding the salary of Franck_Ribéry during one season. Some quick digging revealed a usable source.
Curtis Rouse: Used to source the death of a notable individual.
In short, it seems to me a lot of these usages either:
Are inappropriate or of little value anyways
Could be replaced with a different or more direct reference to the content.
Or are the sorts of claims that are simple to verify.
Of course, that's not going to be all of the citations. Some of these are real thinkers that require nontrivial digging, and I'm sure there's bound to be a portion that are genuinely irreplaceable. MEN KISSING(she/they) T - C - Email me!04:23, 9 February 2026 (UTC)[reply]
I interpreted your question as asking what to do if no substitution to archive.org exists, not what to do if no substitution exists in general. I wouldn't know what to do. MEN KISSING(she/they) T - C - Email me!05:39, 10 February 2026 (UTC)[reply]
Where I agree is with steering readers and editors towards archive.org links as default. Where I disagree is with removing old archive.today links, even when their content is available on archive.org. Where I waver but lean disagree is on forbidding new archive.today links. This comes back to redundancy and the lack of viable alternatives.
A compromise position:
1. Where available, update existing refs that link solely to archive.today so they also include archive.org links. If a diffing method can be devised, add and prefer an archive.org link for exact or near‑exact matches. If match confidence is weaker, add archive.org as an additional link but do not prefer it or remove the archive.today link.
2. When a reader is linked to archive.today, there should be a clear notice that archive.org is the preferred source for web archives and that the archive.today link should only be accessed as a last resort. Editors should likewise be cautioned when adding archive.today links that archive.org is preferred, and to only use it for a secondary link or when no alternative exists.
Ideally, pages exclusively available via archive.today could be re-archived via Wayback. Unfortunately, based on some quick experiments and a bit of googling, it appears this used to work, but doesn't anymore. PickledCookies (talk) 04:24, 9 February 2026 (UTC)[reply]
Option B as a very kind compromise. I really, really hope the community doesn't land on C, which at best reads as a lack of concern, and at worst an endorsement, of unambiguous malicious activity. If archive.today is willing to abuse their platform this way, what's stopping them from manipulating the actual contents of the sources they mirror? WindTemposthey(talk • contribs)09:40, 9 February 2026 (UTC)[reply]
Option B, steadily transitioning to Option A, per GreenLipstickLesbian; conducting a series of DDoS attacks against many individuals, one of which was a person who dug into your archiving practices, and then threatening said person with AI revenge porn is unacceptable behavior, and should most definitely bar them from being used as a source. EdiotRando (talk) 16:58, 9 February 2026 (UTC)[reply]
Option B, and A long-term, per Chaotic Enby and Sam Walton. Providing a link to verify content is not useful if a reader cannot safely click on that link. It's a pity that a service so important would do something so petty, but here we are. Vanamonde93 (talk) 17:18, 9 February 2026 (UTC)[reply]
I agree with those who have proposed forming a plan to migrate away from linking to an archiving site that runs code on user devices that has no role in providing services to the user. As stated by others, anyone would still be free to visit any archiving site they wished of their own accord, so the ability to visit snapshots of cited sites will still exist, albeit with additional steps.
On the general problem of linking to copyright infringement: perhaps the Wikimedia Foundation can work on ways to establish legally licensed archives of major paywalled sites, in partnership with archives such as the Internet Archive. It would be challenging given the business model of those sites, but maybe a workable compromise can be established that manages how many Wikipedia editors has access at a given time. isaacl (talk) 17:42, 9 February 2026 (UTC)[reply]
I'm not suggesting that the Wikimedia Foundation work on a comprehensive solution, but one that legally licenses content, so there is no issue with establishing legality. Theoretically it could use the Wikipedia Library as a front-end for access, but to decouple the archived content from the content owner's servers, I think it would be good to partner with someone like the Internet Archive for the actual storage. isaacl (talk) 18:58, 9 February 2026 (UTC)[reply]
Yes, that paragraph was specifically regarding the general problem of linking to copyright infringement. (The ultimate solution would be for countries to modify copyright law to accommodate archiving, as I discussed elsewhere.) Partnering with archives would enable the Wikimedia Foundation to influence their operations, including enhancing their resilience. isaacl (talk) 16:57, 10 February 2026 (UTC)[reply]
Option A: I initially read the options and thought B would be the best approach. However, despite the reasonable concerns over breaking links, we should swiftly act to protect readers and the public. If this website gets any traffic from Wikipedia, we are contributing indirectly towards a likely illegal action. We prohibit linking to items that are copyright violations, so I think we should prohibit links to things that do demonstrable harm. The people in favor of a phased Option B to Option A or even just an Option B are more in alignment with my perspective than Option C, which would result in Wikipedia becoming an unwitting accomplice for these malicious actors and those who would follow them. Best, (Edit conflict with someone referencing a similar issue to one I mentioned) ~ Pbritti (talk) 17:48, 9 February 2026 (UTC)[reply]
Option C per GreenC. At the moment the many benefits overwash the possible downsides. If this dispute goes on for a lot longer and it comes out that archive.today is severely in the wrong, I may reconsider, but right now as it stands it seems imprudent to block it. Chorchapu (talk | edits) 18:32, 9 February 2026 (UTC)[reply]
Option A over option B, strongly oppose option C. The malicious code has been reactivated, and the links need to disappear as soon as possible. They shouldn't be deleted, but they need to be hidden so that Wikipedia is not complicit in the ongoing DDOS. A cleanup effort to replace the links should take place. MEN KISSING(she/they) T - C - Email me!18:44, 9 February 2026 (UTC)[reply]
Option A. This is a terrible situation to be in. archive.today works wonderfully as an archive and preserves URLs that web.archive.org often fails to. But if the allegations are correct, which seems likely, the owner of archive.today has made a severe breach of ethics, user trust, and probably the law. Wikipedia keeping these links active would be negligent. Anne drew (talk · contribs) 20:03, 9 February 2026 (UTC)[reply]
Option C. So let's make the sequence of events clear. According to Gyrovague's own summary, Patokallio published a blog post that tried to dox the webmaster of archive.is (he calls it OSINT but the effort was clearly aimed at doxxing someone). He got nowhere after WHOIS searches returned clearly pseudonymous info, so he scraped more of the internet in search of the identity. When the webmaster discovered this info more than two years later (probably because the FBI got on their ass, and after weird cease-and-desist letters started to come to unrelated DNS providers), he decided it was time for retaliation and set up a botnet. The code is running as I write.On the one hand, the botnet is illegal in many jurisdictions. On the other hand, the original reporting is clearly unethical. There is no indication that the otherwise obscure blogger did much journalistic work before, so I can understand why whoever is behind archive.today was pissed. We would have indeffed such a user on sight. So, to take a term from the popular "Am I The Asshole" subreddit, ESH, big time, and it's not the webmaster of archive.today who started it.Now as to Wikipedia, archive.is simply works better. Archive.org tends to have more snapshots of the early internet but the quality is not so great and the website is slowo, while archive.is has less of them but they are of much higher quality (except YouTube, which neither website can archive properly). Resource Request would be more backlogged than it is now if it weren't for archive.today. And if you are running uBlock Origin - which I strongly recommend to anyone - filters got updated so that if you archive with archive.today, you are not going to be part of the botnet because that snippet of code will be blocked. So you can avoid disruption to the blog while using what is clearly a better service. Which is why I cannot support any other option. Szmenderowiecki (talk · contribs) 23:14, 9 February 2026 (UTC)[reply]
Why does it matter who started it? It's not our job to pick a side in this. Our focus is reader/editor safety and trust. It's also important to note that neither A or B block editors who are comfortable using it from doing so independently, it would only prevent inserting links here on Wikipedia. You could still use the service for verification if you're comfortable doing so with uBlock. We can't assume all readers and editors use uBlock though. – Scyrme (talk) 23:57, 9 February 2026 (UTC)[reply]
Our focus is reader/editor safety and trust. Our main focus as volunteers is to provide high-quality content to readers, and that's what any about page of Wikipedia will tell. Of course, directly linking to malware is obviously bad, that's vandalism and criminal. But this kind of code is very low on the scale of actual harm. It's annoying for the owner of the blog, but users' safety/trust is not impacted. If it were, you could file a credible report to WMF Trust and Safety, but there is little they could actually do. The code doesn't compromise users' devices. It doesn't spread to others' devices or servers. It doesn't try to steal money or your credentials. It is very unlikely that the ISP will throttle users' internet just because the server-side javascript of a webpage effectively tries to DDoS an obscure blog. What's more, blacklisting archive.today will not have the intended effect of stopping the botnet because I bet the vast majority of the archiving is not done by Wikipedia users - and if I just want to search for an existing archive and then paste it to Wikipedia, the script is not deployed. User:IABot uses the Internet Archive not archive.today, and I'm not aware of a Wikipedia bot that would use archive.today links. So I don't see the point.
"will not have the intended effect of stopping the botnet" - That is not the intended effect. Literally no one had framed this as an effort to apply pressure onto Archive.today until you just did. – Scyrme (talk) 02:08, 10 February 2026 (UTC)[reply]
Literally no one had framed this as an effort to apply pressure onto Archive.today and contrary to what you imply, neither did I. The admin of archive.is does not have particular interest in Wikipedia and I don't think they care.
However, several option A/B voters said that the blacklisting is necessary to avoid perpetuation of the DDoS: Miserable with the fact I find myself here, but we cannot permit websites to rope our readers into being part of DDOS attacks or However, the purpose of deprecating Archive.is is to prevent our userbase from inadvertently taking part in their DDOS attacks. WP:ELNO point 3 indeed bans links to sites with "malicious scripts", but the way I read it is "websites that load malicious scripts when clicked", not "websites that may have that script hosted somewhere on the domain but not necessarily on this exact page" (otherwise any links to files hosted on big cloud storage providers would be banned because a few files hosted on the cloud turn out to be malware - if some Google Drive files prove malicious, do we blacklist drive.google.com? Do we blacklist google.com just because it indexes malicious websites? Websites that have malicious content?)
As I mentioned in the discussion, the vast majority of likely reader interactions with archive.is should not trigger captcha, and so load the malicious script. I could not reproduce reports saying that captcha is triggered outside the page where you actively need to archive content - which is not the part of the page that readers will use unless they choose to. So I don't think the arguments that blacklisting would mitigate the DDoS attack are true. Most of the unwitting DDoSers will be people unaware of this discussion or of Wikipedia blacklist. A typical reader does not know about WP:RSP so will not know about deprecation or blacklisting. And even then we will be mostly blacklisting the wrong pages. The real blacklist target is the archive page but a) the URL does not change and b) no one will have the need to cite it.
Even then editors who will try to add archive.is links do not necessarily use the archive feature on archive.is, they often will just look into existing archives. And even those users who do use the archiving feature can avoid being part of the botnet with relative ease. Szmenderowiecki (talk · contribs) 05:49, 10 February 2026 (UTC)[reply]
@Szmenderowiecki: I've just screen recorded myself getting a CAPTCHA only from visiting an archive page from this revision of Fair use, and I am happy to email you that video proof. I don't believe it can be uploaded to Commons as it is not freely licensed. ELNO 3 (quite rightly) is a complete prohibition of malware—not just really bad malware, tricky-to-avoid malware, or malware which is activated 100% of the time. HouseBlaster (talk • he/they)20:58, 10 February 2026 (UTC)[reply]
Based on sampling my friends and acquaintances, the vast majority of our readers do not use µBlockOrigin or any content blocker (other than tracking prevention). Aaron Liu (talk) 03:15, 10 February 2026 (UTC)[reply]
As I read this discussion, I see that this is coming down to whether or not the harm that came from Archive.is DDOSing another blog (and the possible threat of it happening again) outweighs the benefits it has in citing inaccessible information. The later arguments to me are coming off as assesment of this website as a reliable source. Yes, this website is not technically a source in it of itself, as it merely contains snapshots of the webpage being linked to, but many editors are debating how to reconciling blacklisting this website when it comes to verifiability, so I feel that making my opinion based on that framework would be fair game. When considering other deprecated/blacklisted sources, I do think we have a precident here for blocking sources for reasons that go beyond whether or not they are reliable. A year ago (almost to the day), the RFC on The Heritage Foundation was closed by Dr vulpes (talk·contribs) as consensus for blacklisting. When commenting on whether or not blacklisting was applicable, vulpes commented that:
Although blacklisting is more often used to deal with spam or disruptive links it was noted that there is a possible risk to editors and the community by allowing such links to stay on the site. As reported such links could be used to track users and editors which raised the option of blacklisting the Heritage Foundation. Several participants argued that blacklisting is the only sure way to block the direct use of heritage.org links in citations, which would prevent anyone from inadvertently clicking them. Many editors pointed out that blacklisting is not just a reliability decision but a security measure that is similar in nature to blacklisting malicious domains that track or harm our users. — User:Dr vulpes
With Archive.is, we are dealing with a website that is agreed to be storing the snapshots of archived websites, with the verifiability therefore being dependent on the reliability of the source being mirrored, and this recent DDOS is one not directly targeting Wikipedia. However, the purpose of deprecating Archive.is is to prevent our userbase from inadvertently taking part in their DDOS attacks, and the above quote would demonstrate that a blacklist would be necessary from a security standpoint. Dr vulpes also recognized the same dilemma between the security harms in a source and the potential benifits of citing sources in their conclusion of their closure by saying In conclusion, this discussion revolved around balancing Wikipedia’s need for reliable sources against protecting editors from a group... willing to exploit links on Wikipedia...With that in mind, I am supporting option A, with B as a second choice. We have to ensure that we are not risking readers/editors from partaking in DDOS attacks from verifying a citation if at all possible, even if it hinders our ability to verify information in our articles, a concern I empathize with for those I disagree on how to address Archive.is and their DDOS attack. Gramix13 (talk) 23:30, 9 February 2026 (UTC)[reply]
As someone who was involved (I'd say too involved) in that Heritage Foundation RfC, and who opposed blacklisting Heritage, I think this case is in fact worse. With Heritage there was some investor presentation with a nebulous threat to dox specific Wikipedia editors (so admittedly more targeted at us), but there was in my view no real security reason to believe that links to their own website would be a threat. What we have here is a website that is actively and visibly weaponized for anyone that uses it.
The Heritage threat to dox specific editors (ostensibly, in the blacklisting discussion, through links to heritage.org) was unrealistic because you can't guarantee e.g tracking junk on links posted to Wikipedia would only be accessed by the intended target. What archive.today is demonstrating is that they will (and do!) maliciously co-opt the devices of anyone who uses their site. This isn't targeted at us specifically, but rather it's hitting everyone who uses archive.today, which includes us.
I do think that using Wikipedia editors' devices against their will to illegally attack people online is also an attack on Wikipedia editors (though I guess that's something people !voting C would disagree with). From there, if it makes sense to blacklist Heritage for a nebulous, unrealistic, and unrealized threat, it makes sense to blacklist archive.today for a specific and actively happening threat Placeholderer (talk) 01:29, 10 February 2026 (UTC)[reply]
Option C – Bummer for the blog operator, but the site is far too significant to deprecate. I don't see what Wikipedia has to do with this dispute, and we shouldn't be compromising our editors' and readers' access to information to intervene in a dispute between third parties, especially so when we don't know how long that dispute will last. 5225C (talk • contributions) 01:15, 10 February 2026 (UTC)[reply]
Even if we set aside the blogger's situation, this fundamentally calls into question the safety of using archive.today. The operator has demonstrated a willingness to use their visitors as a botnet - what's to stop them from escalating to malware or credential phishing next? Trust is earned in drops and lost in buckets. Anne drew (talk · contribs) 01:23, 10 February 2026 (UTC)[reply]
Option A (hide, not remove), with Option B and adding a warning as a second choice. Per my discussions with other editors, which can be seen in it's entirety below in the "Analysis of links" section, and the fact the malicious code is once again active.To summarize my reasoning for coming down in support of A:
First of all, I believe it is fundamentally wrong for us to subject readers to being unknowingly exploited as a tool for committing a crime or really any unethical action. If archive.today is doing this we absolutely should not be facilitating such behaviour by displaying links to archive.today without a warning.
I do not believe that archive.today is critical infrastructur for upholding WP:V. This was my main concern, but based off my own analysis and the arguments of other editors I have come to this conclusion. This means that for me it's not about user integrity versus verifiability, but rather user integrity versus avoiding inconveniences for editors, and user integrity wins that fight every day of the week.
I think there is value in the archive.today links being accessible for editors because the information in them can make it easier for editors to find replacement sources, hence I favour hiding them instead of removing them. This also leads me to the fact that:
I don't think doing nothing is a tenable strategy when it's clear this website cannot be trusted on a long-term basis. If we do nothing and the archive.today people do something down the line that forces us to remove all the links it would make it much harder to handle the consequences than it is if we act now and hide the links from readers while still editors use them to ease the finding of alternative sources.I was going to go with option B, reasoning that if it's a one off event we can do things behind the scenes but keep archive.today links visible as long as it's maintainers aren't using it for shenanigans, but considering they're now doing that again I don't see much choice but going with A (hide) simply because we can't trust them turn off the code again and actually keep it that way. As a back-up choice I favour B and add a warning to the links, a bare minimum solution, and to be honest I'm even inclined to say we should have some warning for editors on the hidden links if option A wins out. -- Maltazarian (talk) 01:27, 10 February 2026 (UTC)[reply]
I just want to add that while I was writing this comment Eric Mill of the WMF officially responded to this situation and I believe that really highlights just how serious of a breach of user trust it is to do nothing in a situation like this. A lot of people are shrugging their shoulders and going with C without fully evaluating this fact. I fully understand the immediate negative reaction one has to such an extensively used resource potentially being deprecated, and I certainly didn't come down on Option A without hesitation, but I urge everyone to really consider this from a reader's perspective. -- Maltazarian (talk) 01:36, 10 February 2026 (UTC)[reply]
Option C As of right now I am not aware of anything that can replace archive.today or anything that can be migrated to. If archive.today is gone, there would be no backup for archive.org as of right now. And archive.org is already on very unstable legal ground. And I don't think there will be one for the foreseeable future given that it seems like this kind of website can only be run out of countries that are enemies with the US so that they can keep running without being threatened by legal challenges, and you also need very comprehensive operational security. It is unfortunate to see copyright being abused to suppress history. Copyright violations can be dealt with on Wikipedia but the loss of history is permanent. If history is made inaccessible or inconvenient to access, or is not preserved so that it remains accessible, it's like it never happened.Pancho507 (talk) 01:31, 10 February 2026 (UTC)[reply]
Archive.today would not be "gone" in any meaningful sense. It just wouldn't be linked here anymore. You could still go and use it if you're comfortable doing so. – Scyrme (talk) 01:55, 10 February 2026 (UTC)[reply]
it seems like this kind of website can only be run out of countries that are enemies with the US so that they can keep running without being threatened by legal challenges Archive.org is primarily hosted in the United States. One could argue that the US is its own biggest enemy of course. Polygnotus (talk) 01:56, 10 February 2026 (UTC)[reply]
A (hide, not remove)promptly as response to using editors' devices against their will in breaking the law. Discussion on long-term reliability could proceed from there. More commentary here[5]Placeholderer (talk) 01:54, 10 February 2026 (UTC)[reply]
Option A - and consider keeping a list of removed links with diffs outside of articlespace to try to find substitutions. Archive.is is a valuable as a free knowledge tool, mainly because it is willing to employ adversarial tactics (ignoring robots.txt being one example) to archive sites that fund themselves via paywalls or otherwise do not want to be archived. I dare say everyone in this discussion, including me, has benefitted from this, and that it accounts for why many people choose it over the Internet Archive, which is more cautious. The problems begin here: ownership and operation is completely opaque and its funding model is unclear. We are talking about a massive enterprise, and we have no idea who or what is paying for it, or why. That should be perturbing for something we rely upon so extensively and point so many of our readers to. If it were just these unknowns, there would be a reasonable debate weighing the value of its archival function against the risks. We could talk about educational use of paywalled information, open knowledge, the business of journalism, etc. and it would probably go much the last RfC went (where the value was judged to outweigh the risks). But the DDoS is different. How many times in the past has the opaque nature of this project obscured its use for reasons other than archiving? We also learn that the operator, or someone who seems to be the operator, is threatening Gyrovague, indirectly saying they will e.g. (vibecode a gyrovague.gay dating app). As someone on Hacker News put it: "Only somebody with a some degree of lawlessness would operate such a project" and we should not be altogether surprised when their eccentric ethics result in users being unwittingly implicated in unethical behavior. It's possible it is the passion project of an independently wealthy archivist-activist who's cagey to avoid getting caught, and that this recent DDoS was a desperate move to try to keep their project alive at any cost. Lots of less appealing things are just as possible. At this point, to put a fine point on it: we are pointing our readers to a site that secretly forces its users to DDoS someone over a personal dispute, and which runs an expensive service with a mostly opaque funding model. I'd be curious, for those supporting C: where is your line? What I'm reading in many of the C !votes is basically "nothing else ignores robots.txt and circumvents paywalls, so we need it, and nothing else matters". Is that more or less it? I would hate to lose it for Wikipedia, too, but it's just too sketchy to rely on for such an infrastructural task as preserving our citations. If, at some point in the future, the operator acknowledges they did something messed up, outlines some principles/policies it will adhere to moving forward, etc. we can revisit. I feel conflicted about this, both acknowledging its value and having a lot of respect for ambitious archivers (all the more if they undertake some impressive and possibly grayhat technological feats in the public interest). The more I sit with this situation, however, the more I see this DDoS issue as an altogether different category of sketchiness. It's not doing what's necessary to serve the public interest; it's unethically instrumentalizing users in a personal dispute. I appreciate that this particular personal dispute may have implications for the longevity of the project, but it still feels like a bright line crossed. That's how I'm thinking about it, anyway. YMMV. — Rhododendritestalk \\ 02:33, 10 February 2026 (UTC)[reply]
B for one year I have carefully read all of the discussion. I think the C's main point is the value of archive.today. I see no one defending their actions. I agree with the C's on the value of archive.today. My question is how do we replace the value archive.today provides with a resource that will be a better neighbor? If we go with option B for one year my hope is that this will give sufficient time and incentive for an unrelated group to make a similarly valuable resource while being a better steward for all stakeholders.Czarking0 (talk) 02:43, 10 February 2026 (UTC)[reply]
Option A, with B as second preference and a strong opinion against C. I don't think Wikipedia should be feeding traffic to a DDoS service that appears to still be running. I am very reluctant to remove something that has had such utility on wiki, but the actions of the people behind it suggest that it is simply not a website we should be using to archive links. The utility Archive.today has for the wiki should not be a free pass for obviously bad and malicious behaviour. --LivelyRatification (talk) 02:48, 10 February 2026 (UTC)[reply]
Let's not mince words: archive.today runs malware on your computer. To state what should be obvious, we should never direct readers to sites with malware, which is part of policy at WP:ELNO number three. I know that options A or B will likely lead to the loss of some content. I don't like that. But not running malware on readers' computers is infinitely more important. Option A over option B, strongly oppose option C. HouseBlaster (talk • he/they)02:56, 10 February 2026 (UTC)[reply]
Option C: per Szmenderowiecki, 5225C. To be fully blunt, I am of the opinion that this is not an issue for us here at Wikipedia; yes, there are underlying issues between the archival site and the blogger, but we should, to the maximum we can, stay out of it, and use what we can whilst we can: the site remains too important to terminate usage immediately. In that respect, yes, we should absolutely transition, over the longer-term, to our own archival services, but I distrust the WMF to do it properly, and, more importantly, want it to comport with copyright law, as well. In a few words: it's not our problem, and, until and unless it affects our userbase directly, it shouldn't be. After all, WP:NOTSCANDAL, and we shouldn't be creating one, either. — Javert2113 (Siarad.|¤)04:40, 10 February 2026 (UTC)[reply]
Not linking to it here is staying out of it. Doing nothing means unwitting traffic from Wikipedia continues to aid the DDoS attack. That's not staying out of it. If you are comfortable using it despite these issues, you could continue to do so at your own risk. Though you don't agree there's much risk here, others feel differently and they should being to make that choice for themselves. Doing nothing means the links continue to be used in references without context, so many will not be able to make an informed choice. – Scyrme (talk) 04:52, 10 February 2026 (UTC)[reply]
One option would be to institute warning messages, both for users traveling out from Wikipedia to an archive.today link, and for editors attempting to add such links as sources. To me, this seems like something A, B, and C could all agree on that could be implemented in short order. PickledCookies (talk) 05:27, 10 February 2026 (UTC)[reply]
Could you clarify why you think the site is too important? Also I have to say that having anyone who clicks certain links on Wikipedia get their device temporarily hijacked to be used as a tool in a potentially criminal and certainly unethical act qualifies as directly affecting our userbase. -- Maltazarian (talk) 06:30, 10 February 2026 (UTC)[reply]
Option B, without prejudice against A: if the operator of the website is willing to weaponize it like this, what else are they willing to do with it? --Carnildo (talk) 06:21, 10 February 2026 (UTC)[reply]
None of A, B or C. Allow the use of links for verifications (by other editors) while hiding the links from displaying to readers. Discourage the addition of new links to the website, but don't prohibit them. ▶ I am Grorp ◀ 07:25, 10 February 2026 (UTC)[reply]
Option B, weakly Option A. For the sake of argument, I am going to assume that this was indeed a malicious DDOS attack. I'm not going to pretend like I'm knowledgable in templates, but would it be possible, while keeping the archive link in the wikitext, to point to a kind of soft redirect page? A sort of intermediary link, kind of like those notices that some websites have that let you know that you are going to an external page. For example, a new page could be created, say "Wikipedia:Archive.today abuses", that explains what's happening with a big red button to then bring you to where you were going. EatingCarBatteries(contribs | talk)07:32, 10 February 2026 (UTC).[reply]
People ought to know what Javascript their browsers are running (that's why we have {{Usurped}}), and they need to be strongly discouraged from visiting the page, but at the same time we can't underestimate the value in that archive.
Option A, probably better to bot-remove/disable the existing links (that is a 'B but with an expedited A). Archive.is/today arrived here in a very aggressive way, pure spamming, now they perform an action like this. I understand the argument that if material disappears that it is good to have a 'backup', but I do not follow the argument that material becomes unverifiable as soon as the archive link disappears. That simply argues that we cannot rely on ONLY ONE archive link, we need archives from multiple, even just in case one of them disappears for uncontrolled reasons. I do note that it appears that there is more going on with archive.is than only the initial spamming that landed them here, and this case, it may be wise to look for alternative solutions before decisions are taken for us. --Dirk BeetstraTC10:55, 10 February 2026 (UTC)[reply]
Option A, oppose C, There is longstanding consensus in our linking guidelines to not link to malware. archive.(today|ph|is) to put it simply is currently active malware, using random visitor's computers to actively mount a DDoS attack. At a ethical and technical level, this is no different from operating a botnet and we should not be exposing users to this level of malicious behavior. -- Sohom (talk) 11:21, 10 February 2026 (UTC)[reply]
Option C. There is undeniable shadiness going on here (definitely on the part of the attacking site, and possibly also on the part of the target site), but I'm not sure it constitutes a safety risk to our readers. Other websites frequently take liberties with readers' resources, running heavy Javascript for ad/tracking purposes for example. Wikipedia should not give the appearance of providing any kind of assurance of 3rd party websites; we cannot possibly vet everything, and if readers think we do, it could create a false sense of security. I think the benefit of including links to this archive is also undeniable. It is concerning that there is drama happening in and around our infrastructure, and while that could lead to an integrity concern, I don't see any evidence that this has occurred. I would suggest other archive sites with more transparent governance should be preferred, but if there is encyclopedic content that can be sourced only to archive.is, then I think using it as a reference is better than deleting the content or leaving it unsourced. I also strongly believe Wikipedia is exposed through overreliance on archiving sites (particularly the Internet Archive, which has faced its own recent existential threats) and the WMF should give serious consideration to funding an in-house alternative. Barnards.tar.gz (talk) 11:43, 10 February 2026 (UTC)[reply]
A/B By allowing archive.today links to exist, we could be considered compliant in the Distributed denial of service of Gyrovague. Wikipedia readers should not be able to participate in any kind of DDoS. Plus, it is illegal in many jurisdictions, so why are we trying to put ourselves at legal risk in exchange for being able to access pages that weren't archived by IA and supposed usefulness? Rhinocratt c15:27, 10 February 2026 (UTC)[reply]
Option A We cannot in good faith knowingly link users to malicious websites, even considering the value it provides. Dead links are preferable and users can seek mirrors of their own accord. ChromeGames (talk · contribs) 17:08, 10 February 2026 (UTC)[reply]
Option B per HouseBlaster's reference to WP:ELNO. We do not have workable standards for sufficiently minimal malware. We have previously decided to keep Google in Template:More citations needed over lesser used search engines despite its web tracking because those practices at least have functional relevance to Google being the top browser. Archive.today's utility over Internet Archive cannot justify turning a blind eye to hijacking of reader devices for immature harassment of a blogger. ViridianPenguin🐧 (💬) 17:37, 10 February 2026 (UTC)[reply]
Option A: .today and its mirrors are knowingly distributing malware in order to perpetuate a petty dispute with a blogger. It's a violation of ELNO to allow these links as HB pointed out. I support Option A, which will prohibit the addition of these links so we can work on replacing them where feasible (perhaps the goal should be "as many .today links as possible" instead of all links to it). I would not be opposed to Option B instead, since the addition of deprecated links is logged by the edit filter and can be dealt with there. Option C contradicts established guidelines and endorses malicious behavior, which is unacceptable. This is a weird case where none of the options are ideal but the operator of these sites has forced our hand. We need to deal with this sooner rather than later. IsCat (talk) 18:02, 10 February 2026 (UTC)[reply]
They are not distributing malware. They are/were (not sure of the current state) running a DDOS attack on one specific site. You may or may not think these actions are about equally bad (some in this discussion do, some do not), but they are very different actions. Thryduulf (talk) 19:30, 10 February 2026 (UTC)[reply]
From wikt:distribute: "To deliver or pass out." From malware: "Malware is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy." The website is delivering a Javascript file to all users of the website that intentionally causes disruption to a computer/server and attempts to deprive access to information via a DDOS attack. I don't see how that isn't distributing malware. IsCat (talk) 19:53, 10 February 2026 (UTC)[reply]
I'm inclined to disagree that they are different actions.
By the letter, a webpage that runs unwanted code on someone else's computer to perform an unwanted malicious act, no matter who is the target, is malware. Going to a website downloads the webpage so that you can see it, and if the webpage is malicious, then you are downloading malware.
By the spirit, the promise that is being broken when you click on the link and unwittingly contribute to the DDoS is the same promise that is being broken when you download a trojan virus. The issue is not in how severe the action is, the issue is in the trust being broken.
I'm also inclined to disagree that readers aren't being directly hurt here, per CWL below: It's not primarily for moral reasons; it's to protect our readers from becoming part of a DDoS campaign, which might potentially cause their IP addresses to be blacklisted or lead to hefty internet bills in certain regions.MEN KISSING(she/they) T - C - Email me!20:00, 10 February 2026 (UTC)[reply]
Archive.today isn't using its own resources to conduct the DDoS; they're distributing software (through the browser) that takes control of user hardware resources to. That's the definition of a botnet. Aaron Liu (talk) 21:42, 10 February 2026 (UTC)[reply]
Option A. We should never reward malicious actors, no matter if it's good for us or not. If we deliberately link to sites known to contain malicious code, we do a tremendous disservice to our readers. SeraphimbladeTalk to me19:39, 10 February 2026 (UTC)[reply]
Option A When someone shows you who they really are, believe them. The editors of this site have established that they think they can weaponize Wikipedia traffic for their own nefarious purposes. This is obviously a violation of WP:VANDAL. Why is that not enough? From my perspective, there is no need for a discussion, this is already not allowed. LrdDimwit (talk) 20:20, 10 February 2026 (UTC)[reply]
A, reluctantly. I have been grateful to have archive.is over the last few years, but this is an enormous breach of trust. The deciding factor for me is that, if we don't do this, we're funneling unsuspecting Wikipedia readers into a botnet. Otherwise I would support option B and a more structured retreat from reliance on archive.today. I also support what I've seen called "option D", that Wikimedia deploy large-scale web archival tools of its own, but that would be an enormous undertaking that would have to come well after the remedy for this particular problem. Moonreach (talk) 20:28, 10 February 2026 (UTC)[reply]
Option A by way of modifying citation templates not to generate links to archive.is and the other domains, at the very minimum, as a first step. We should not be complicit in distributing malware. We should not be feeding our readers into a botnet. (Having every DOI link point to sci-hub would actually be more ethical, since then, arguably the only harm would be to Elsevier's profit margin.) Once we're no longer making the problem worse, we can take further steps. For example, we could automate the process of checking to see how many archive.is links really don't have a counterpart in the IA, and thus get a better picture of why that is. One possibility we may need to consider down the line is a dark archive, a mirror of every webpage that Wikipedia cites that is stored away for safekeeping but not publicly viewable. Stepwise Continuous Dysfunction (talk) 20:41, 10 February 2026 (UTC)[reply]
Option A - if this is provable, then I think as the users above have said we need to dissociate from it. WP should not keep linking just because it's convenient to us. Perhaps this suggests the need for a reliable archive of information funded by the WMF, but this is perhaps out of scope of the RfC? - Master Of Ninja (talk) 21:20, 10 February 2026 (UTC)[reply]
Option C. archive.is is valuable to Wikipedia. I don't see an issue with the DDoS. It's a fair response to a doxx attack which is a lot more serious in real life. Joe vom Titan (talk) 21:22, 10 February 2026 (UTC)[reply]
As others have said, DDoS attacks are literally a criminal offence in most countries. Involving visitors and users of Archive.today (including those from Wikipedia) in a crime without their knowledge or consent isn't a "fair response". – Scyrme (talk) 21:51, 10 February 2026 (UTC)[reply]
Any of A, B or C, but: I would only be ok with option A in the context of hiding links, commenting them, or some other method that makes evidence of their existence at one point not completely gone. I think completely removing archive.today citations without any record would be catastrophic. There needs to be some way for editors to be able to confirm that a given citation was at one point verifiable somewhere, even if it is no longer linkable. Hiding instead of removing will also make it easier to replace the archives. Assuming this would be true, I feel roughly equal about all the proposals. Duckduckgoop (talk) 23:01, 10 February 2026 (UTC)[reply]
Option B (for now), then Option A: Archive.today is still widely used across Wikipedia to preserve websites, especially those behind paywalls not archived fully by Wayback. It would take a while to find alternative archives for each deprecated archive, and it is truly problematic that DDoS attacks are happening. Unfortunately, I have not found many good alternatives (should Wayback go down again), aside from Ghost Archive, PageFreezer and Perma.cc, which both seem limited in their accessibility. (I will also note that Ars Technica has an article covering this very RfC.) — Trailblazer101🔥 (discuss · contribs)23:55, 10 February 2026 (UTC)[reply]
Support A (soft-block links and inform readers as to why), oppose A (URL hiding or automated removal). As the WMF has noted, we cannot allow our readers to unsuspectingly navigate to archive.is pages containing live DDoS code. Disruptive as it might be to our internal processes, I think we ought to have blocked first and discussed later. As things stand, we should inform our readers, and enlist them to help, by modifying citation templates to display but de-link archive.is URLs, provide an information page on why we are no longer linking to archive.is, and ask readers to help by replacing the archive.is link with an (auto-generated) archive.org link, provided they can verify this is equivalent. In the unlikely event that the site operator backs down, I would support a re-evaluation of this response. Preimage (talk) 00:34, 11 February 2026 (UTC)[reply]
"is generally considered more reliable than the Internet Archive" – I'd say [citation needed] for this claim. What does "reliable" mean? And what about "general"? I always found archive.is a bit fishy, with the deliberate copyright violations etc. I think we should strike this claim, or at least make it clearer and more neutral. — Chrisahn (talk) 21:06, 7 February 2026 (UTC)[reply]
Hmm, that may not be the perfect word for it, but AIUI there are websites that (for various technical [or maybe other?] reasons) can't be usefully archived at archive.org, so one of these is used instead (i.e., instead of nothing, which is the realistic alternative). I think that's what's meant by "more reliable". I'm not sure what wording would be clearer. WhatamIdoing (talk) 21:16, 7 February 2026 (UTC)[reply]
Archive.today uses sophisticated methods to archive difficult websites, such as using headless browsers, residential IPs through botnets, and subscriptions for some of the most archived websites to bypass paywalls. The archiver also takes DOM snapshots after the javascript has run, instead of re-rendering the page all over again which may fail. Overall, this makes Archive.today more reliable than the Internet Archive in many cases. ChildrenWillListen (🐄 talk, 🫘 contribs) 03:32, 8 February 2026 (UTC)[reply]
Option C: Archive today is a vital source for information which would otherwise no longer be available, and it is particularly useful in the wake of the shutdown of CIA World Factbook, and deprecating or blocking it would block information from legitimate, trustworthy sources that have closed down. While the Internet Archive would be preferred, this may not always be an option, especially if their servers go down and some material is unable to be archived during that time (such as some emergency alerts), or it does not correctly display the information but archive.today does. Mitchsavl (talk) 04:16, 8 February 2026 (UTC)[reply]
Reading through the allegations, I think I was too hasty to make an informed judgement, however my point about the importance of archiving still stands. Mitchsavl (talk) 04:46, 8 February 2026 (UTC)[reply]
What's the plan for A? WP:V still exists, what would we be replacing them with? If the original link is still up I assume we can just use that, but I bet there's some where the original no longer exists. This isn't hand-wringing from myself, if we can get a workable action plan then I'm all in on kicking archive.is to the curb. Tessaract2Hi!02:08, 8 February 2026 (UTC)[reply]
With no replacement? That seems bad. If I'm to follow this path, I think we might need a [citation needed] that specifically says something like [non-archive.is source needed] so we at least know the information came from Somewhere and was verifiable at some point. Tessaract2Hi!02:16, 8 February 2026 (UTC)[reply]
It's not a solution admittedly, it's more of a stopgap. It'd be meant to push people to find a source once the archive.is one is gone, as opposed to removing the orphaned information wholesale. I really don't think removing every archive.is link without finding a clean replacement is a good idea, which is why I asked for a plan in the first place. Tessaract2Hi!02:27, 8 February 2026 (UTC)[reply]
I don't hate that. Two years is a long time to find a replacement for something if there's a group of people working through the queue. Tessaract2Hi!05:05, 8 February 2026 (UTC)[reply]
I think it'll take longer than two years, if we leave it to a group of people working through the queue. At five minutes per link (which is about what it took me the other day to look at a few of these), we're looking at 57K hours of work, or, say, 10 full-time equivalent employees for three years. And we don't have ten FTEs; if we're lucky, a Wikipedia backlog process might average two or three dedicated/stubborn people who add up to one FTE. But if we could flag these to a lot of editors, then many hands make light work. If 100% of this month's editors fixed one of these, then almost half of them would be done in a month. We'll never get all 100%, and we probably won't get 10%, but spreading the workload can make a big difference. WhatamIdoing (talk) 21:03, 8 February 2026 (UTC)[reply]
A lot of the arguments for doing nothing hinge on information being only verifiable via Archive.today. Even if I were to accept that this matters more than the safety of users and that verification through a sketchy website makes Wikipedia more trustworthy rather than less so, I question whether that information even belongs on Wikipedia in the first place. If something is literally only verifiable via a single old dead webpage, is it really likely to be notable enough for inclusion anyway? If absolutely no alternatives exist, how can we say it has significant coverage in secondary sources which are independent of the subject? Maybe individual details don't require significant coverage, but surely they require a plurality of independent secondary sources?This isn't a rhetorical question/argument, I'm actually asking. Maybe there are cases which I haven't considered where it would be appropriate, but I can't think of what they would be. Just because I can't think of any, doesn't mean they don't exist, but if they do exist I would appreciate if someone would explain what they are and provide some clear examples so that we have a better scope of the problem. – Scyrme (talk) 02:14, 8 February 2026 (UTC)[reply]
There's definitely situations where some sources don't get certain details that others do. That's not even an edge case, that's just a case. Besides, isn't the multiple sources thing more for notability than verifiability? Tessaract2Hi!02:21, 8 February 2026 (UTC)[reply]
Notability is my point. Even if it's verifiable (via Archive.today), if it's not notable it's not encyclopedic and doesn't belong on Wikipedia anyway. In those cases losing Archive.today is surely not a real loss? Or is there something I'm missing here? – Scyrme (talk) 02:27, 8 February 2026 (UTC)[reply]
Hundreds of thousands of sources? You're lumping together sources for different topics. All the Archive.today links aren't all references about the same one thing. – Scyrme (talk) 02:31, 8 February 2026 (UTC)[reply]
Okay? What does that matter, though? It's still a massive chunk of material we are citing to. Criteria for inclusion for article content is not notability anyways, it is WP:DUE. PARAKANYAA (talk) 02:50, 8 February 2026 (UTC)[reply]
Surely due weight also depends on a plurality of independent secondary sources? Details which don't have coverage in such sources don't warrant any weight. It being a massive chunk of material doesn't matter if it doesn't belong here. A lot of articles have large sections which cite unreliable sources or aren't cited at all or devote sections to quotes, etc. That there's a lot of material doesn't mean it's important. – Scyrme (talk) 02:54, 8 February 2026 (UTC)[reply]
Sure, but plenty of extremely reliable sources have been archived by archive.today. It is completely unrelated. Sure, this won't be an issue for a topic as notable as Abe Lincoln, but we have many, many topics on things that are notable, but not super notable, where one really good source being gone can be a huge problem. PARAKANYAA (talk) 02:58, 8 February 2026 (UTC)[reply]
This sounds very hypothetical. How many "really good" sources are reliable, independent, online-only, and also badly maintained or defunct? "One really good source" also doesn't sound like a plurality of reliable, independent secondary sources. If there are enough multiple reliable, independent, secondary sources for a topic to be notable overall, but only one of them covers that particular detail is that a detail that warrants inclusion in the article? Or would it be undue to include it?
Again, maybe I'm wrong, but if so I'd appreciate clear examples so this isn't just about whether hypothetically we could imagine that maybe some of those links are references which support details which are important to include in our articles. Like, sure, maybe such a thing is possible. But how many of the links are actually cases like that?
Without examples, it's hard to judge how many of the links affected are important. Maybe it's most of them. Maybe it's only a few. If there are no examples, then maybe it's even none. Just pointing to the raw total number assumes they're all important, when obviously they aren't. – Scyrme (talk) 03:29, 8 February 2026 (UTC)[reply]
Practically, the really good sources that can't be archived by Internet Archive are websites of major newspapers which don't want their old stories made available for free - and Wikipedians don't want to (or can't) pay for them.
Just saying the unspoken thing about what Archive.is is good for - it's always been about bypassing paywalls. So a lot of these sources that people are saying will never be available again are, in fact, available - for a cost. (Something they and the WMF absolutely could do something about - coorporations don't give you stuff for free but I imagine you could spin limited TWL access for archived news stories for editors as a good PR thing). GreenLipstickLesbian💌🧸03:48, 8 February 2026 (UTC)[reply]
If that's the case, then isn't that what the Wikipedia Library is for? Regardless, a paywall existing doesn't make a page unverifiable without an archive. It just makes it costly to verify if you do it privately. Even without the Wikipedia Library, you could always also do it the old fashioned way and go to a physical library an ask them to procure a copy for you. Doesn't have to cost you anything, with a bit of effort. – Scyrme (talk) 03:57, 8 February 2026 (UTC)[reply]
Note many local libraries now offer online access to newspaper archives for the residents they serve, so you don't even need to go to the library. isaacl (talk) 05:18, 8 February 2026 (UTC)[reply]
It depends on what was archived, I guess. Not everything archived with archive.is is a "random website"; across the close to 700,000 links on Wikipedia, some of them have got to be archives of important sources. Tessaract2Hi!02:30, 8 February 2026 (UTC)[reply]
That's what I'm asking. If something is only verifiable on a single webpage that isn't even maintained anymore, it seems implausible to me to meet all Wikipedia's criteria for inclusion including not only verifiability but also notability, due weight, etc. However, with so many links I don't want to assume. Maybe I'm wrong. Does anyone know any clear cases where actually it's indisputable that something which is only verifiable via Archive.today would meet all of Wikiepdia's criteria for inclusion, making the loss of Archive.today an actual problem? If so, how common are such cases? How many of those hundreds of thousands of links actually matter? – Scyrme (talk) 02:36, 8 February 2026 (UTC)[reply]
@Scyrme, "notability" means "qualifies for a separate, stand-alone article". A long-dead article confirming someone's WP:DOB or similar details has nothing to do with notability. It's not like someone is using these pages to argue that there should be a whole separate article on Chris Celebrity's birth date. Ordinary individual details (e.g., a birth date, where someone went to school, what the name of the CEO was, where the first store was located...) don't require multiple sources. WhatamIdoing (talk) 03:58, 8 February 2026 (UTC)[reply]
If we are to scrutinize Archive.is (et al.), should we also scrutinize other archival services such as GhostArchive or Megalodon.jp? ―Howard • 🌽3302:15, 8 February 2026 (UTC)[reply]
Maybe, but that's not within the scope of this RFC which was triggered by a specific recent incident which contributes to a long history covered by the previous 4 RFCs. – Scyrme (talk) 02:23, 8 February 2026 (UTC)[reply]
All these archives, including the Internet Archive, have the same problem where, well, the basic act of web archiving and reproducing content that is not already free or owned by your organization is copyright infringement unless the fair use rules apply (and since web archiving reproduces the whole work, this is not the case). Internet Archive has mostly preserved itself due to the fact it will take down basically anything anyone asks them to, but this is reactive rather than proactive and doesn't mean it isn't copyright infringement. GhostArchive and Megalodon.jp have niche advantages but are generally difficult to use. Archive.today is more robust in some ways than the others, has way more content than GA or Megalodon, and is very consistent but the issue is the guy who runs it is somewhat shady. PARAKANYAA (talk) 02:25, 8 February 2026 (UTC)[reply]
To those who argue that the incident in question did not harm end users: co-opting user devices to run malicious code breaches trust, which is harmful to collaboration, and makes use of computing and network resources. Unchecked, this can affect user experience, and can lead to a network provider taking action to limit network access. I appreciate why many wish to continue using links to archives that archive copyrighted work, as a special exception to the general guidance described at Wikipedia:Copyrights § Linking to copyrighted works. But we should not minimize the severity of running malicious code. isaacl (talk) 18:21, 8 February 2026 (UTC)[reply]
"Please consider joining the feedback request service." in the rfc tag is implemented as a user box and is emitting the category. Izno (talk) 01:14, 9 February 2026 (UTC)[reply]
And more specifically, that userbox has its background color ("info-c") set as transparent and the foreground color ("info-fc") set as var(--color-base, #202122), both of which make Module:Color contrast error out, and Module:Userbox is coded to add the category if the check errors out (and this page is not userspace, categoryspace, or a talk page, which skips the check all together). Anomie⚔01:41, 9 February 2026 (UTC)[reply]
Personally, I'd suggest instead that Module:Userbox avoid adding the category if the contrast check errors out. That would involve changing the error = 0 to something like error = 100 in three places in this bit, but people who're more active there may have better ideas. Anomie⚔02:33, 9 February 2026 (UTC)[reply]
Have just stumbled across this discussion and not entirely clear on the specifics but here's my two cents. I often use Archive.today when the Internet Archive fails, either to archive links that the Internet Archive cannot (because it is paywalled or simply because the Internet Archive can't, for some reason, which seems to have become more common as of late). The conduct of the people behind it is, by all accounts, pretty deplorable, and I think if at all possible we should avoid our readers being directed to a DDOS attack in any kind. My concern is mainly instances that exist where sources are solely available online and then get removed in some way or another. Sure, in some cases there might be physical newspapers, but there are often online sources that I've found that have no physical backups. Link rot is obviously a very common issue, but sometimes websites like The AV Club will simply take down old articles. I have no particular love for Archive.today and would be happy to never use it again on or off-wiki given the conduct of the people behind it, but I think it's untenable to have no way to archive links that the Internet Archive can't reach. On a recent article I wrote, I used an Archive.today capture for this Politico article -- still active, the original source is (to my knowledge) not paywalled, but there are no captures of it on the Internet Archive. What if this source goes down? How will we able to archive it and verify the information in it if it succumbs to link rot? Perhaps the answer is simply "we can't", but surely there should be some sort of solution here. I try to archive every URL I cite onwiki due to the issue of link rot, and it would be a shame if that became impossible. --LivelyRatification (talk) 13:15, 9 February 2026 (UTC)[reply]
I haven't read enough to make an informed decision but it's a shame that archive.today has fallen to this low. It's great for research by bypassing paywalls, otherwise sources such as CNN, BBC, et cetera are unavailable for research. Chorchapu (talk | edits) 15:02, 9 February 2026 (UTC)[reply]
@Chorchapu: Many paywalled journals and media outlets are available via the Wikipedia Library. Any active Wikipedia editor in good standing can access it for free.
Unfortunate. Could always try a VPN to get around geolocking. Regardless, a paywall doesn't make a source "unavailable". Even if there weren't any libraries to access such sources for free, a paywall on a digital reference that isn't actually a dead link is no different to a book you have to buy to look something up in a physical copy. It's inconvenient, sure, but not unavailable or unverifiable.
Additionally, as others have pointed out, not permitting Archive.today links in references would not stop editors accessing it themselves independently to verify a reference. None of these proposals would result in Archive.today being deleted from the internet, they would only prevent the addition of links to it here. It would be no different from an editor using something like Anna's Archive or The Pirate Bay to access a source. They can't link the download link here on Wikipedia, but we can't stop editors using them in private to access works. – Scyrme (talk) 22:11, 9 February 2026 (UTC)[reply]
"not permitting Archive.today links in references would not stop editors accessing it themselves independently to verify a reference" - something like 0.1% of readers actually check references; even less of them check for archived copies of a page when they encounter a dead link without an inbuilt archive URL. sapphaline (talk) 22:19, 9 February 2026 (UTC)[reply]
A paywall isn't a dead link. A hypothetical situation in which a reader clicks a link in a reference, sees a paywall, and decides not to bother is no different from them clicking a DOI or ISBN in a reference and finding a closed access journal or a book that is only available in print. If so few readers actually bother to check, then this is mostly for the benefit of editors either way. – Scyrme (talk) 22:24, 9 February 2026 (UTC)[reply]
Yes, verifiability is about the fact that readers can "do it", meaning that they can check reliable sources (including reliable sources of their own choosing/not cited in the article) to determine whether the Wikipedia article is making things up. WP:Glossary#uncited material can therefore be 100% WP:Glossary#verifiable, because readers "can" (e.g.,) go to the library and ask a reference librarian for help verifying the claims in the Wikipedia article. WhatamIdoing (talk) 01:52, 10 February 2026 (UTC)[reply]
I've started a discussion based on this RfC on Meta Stack Exchange (the place for discussions about the Stack Exchange network) seeking input/consensus on handling links to archive.today (and .is, .md, etc.) in SE posts as there may be over 1k links to archive.today|is|md|etc. from SE, hence the deseire to raise a discussion there for SE. (for transparency, while I've contributed a bit, I'm not a Wikipedia regular) Coconutmacaroon (talk) 22:32, 10 February 2026 (UTC)[reply]
There is currently some bad blood between the blog and the archive site, as can be seen on the archive site's own blog. So while we could see this as motivation for the archive site having actually done what is claimed, we could also see it as the blog for making a fake claim. I would definitely want better evidence before attempting to disable a site that has proven useful (even if I do raise my usual copyright concerns about using archive sites.) -- Nat Gertler (talk) 21:59, 7 February 2026 (UTC)[reply]
It was covered on reddit and HN at [7], [8], and [9]. The comments discuss the technical aspect of it and do seem to confirm there was an attempt at DDOSing here. Izno (talk) 22:49, 7 February 2026 (UTC)[reply]
If this were any other concern, I would agree with your objection; but when it comes to user safety (ie. links that may be actively unsafe) I think it's reasonable for us to determine this ourselves. We're not stating in an article that they're unsafe, and we're not assessing their reputation for fact-checking and accuracy (the things that require we use proper sourcing ourselves); we're trying to determine if a link is a danger to our users. That particular determination isn't constrained the way most of our other choices are; if all the sources uniformly get something wrong, we're ultimately required to reflect that because that's how an encyclopedia works, but we are not constrained to use actively harmful links. Even if every other source in the world said that a link was safe, if our own internal investigations showed it was dangerous, I believe we could and should blacklist it. (This is a separate question from "how dangerous is it, actually?" and "how should we respond", of course. But for this particular decision I don't think we're actually constrained by RSes the way we are elsewhere - we might look to them to make sure we're not screwing up or to get a second opinion, but this is different from other discussions, and our responsibilities are different as a result. Unlike other article content, our responsibility when it comes to avoiding dangerous links isn't "only link to sites everyone else says are safe", it is "only link to sites that are actually safe.") --Aquillion (talk) 21:07, 8 February 2026 (UTC)[reply]
Whether or not there is what we generally consider a reliable source exists for this, when dealing with security risks, malicious actors, or anything similar, it is best to be cautious, and wait for an “all clear”, than to do nothing and discover it is worse than we first thought. Various commenters have already validated it, and explained the process to recreate it. And I really wouldn’t trust someone who does one sketchy thing not to do any else malicious. Mitchsavl (talk) 04:29, 10 February 2026 (UTC)[reply]
DDoS code is still live - I just want to bring attention to something ChildrenWillListen has noted above, which is that this isn't some past issue that the site owner has since turned off, if you hit a CAPTCHA page on archive.is, the code is still live - your browser will start making random requests to the target website. The RfC makes it sound like this problem is something that happened in the past, I'll add a brief note there. Sam Walton (talk) 13:35, 9 February 2026 (UTC)[reply]
I can independently confirm (pictured). If you don't get the CAPTCHA page, try clicking on any link on the page, like "faq" on the top. Aaron Liu (talk) 15:56, 9 February 2026 (UTC)[reply]
I can also confirm this on my end. The malicious code on the archive.today CAPTCHA page instructs the web browser to send HTTP requests to the gyrovague.com blog every 300 milliseconds. To see these HTTP requests in real time, open your browser's web development tools when you are on the CAPTCHA page and go to the "Network" tab. What archive.today is doing here is like a rudimentary single-site version of the Great Cannon of China. — Newslingertalk16:57, 9 February 2026 (UTC)[reply]
This is quite a lot to take in. Can WMF help verify whether the allegations are true - I think the question to answer is the Archive using links to form a DDoS botnet? If the answer is yes, WP should stop funnelling users towards it. - Master Of Ninja (talk) 21:23, 10 February 2026 (UTC)[reply]
My comment below as WMF was based on this having happened, not strictly whether it was still ongoing.
However, I personally verified yesterday that the DDoS code, as originally described, was still in place and functional on the archive.today CAPTCHA page, shortly before posting my comment. EMill-WMF (talk) 21:30, 10 February 2026 (UTC)[reply]
@Master Of Ninja, we don't need the WMF to verify this. Multiple technically skilled volunteers have already done so. This is not a particularly difficult think to check (any comp sci student should be able to figure it out), and it's not a WMF-hosted website, so the WMF has no special ability to investigate it. They can only do you or anyone else could do themselves.
This been has asked and answered several times now. Do you think we need to have a boxed notice, so people can see it? Maybe something like this?
Multiple technically skilled people have independently confirmed that this website is still emitting malware. Last updated: 10 February 2026
I think the wording on this could be adjusted in the interest of neutrality, given that some editors might disagree with "emitting malware", and it could also address the common misconception that it is only when pages are archived when the CAPTCHA page is encountered. Maybe something more like:
Multiple technically skilled editors have independently confirmed that the code responsible for the DDoS attack is still present in the archive.today CAPTCHA page. This page can be encountered on any visit to archive.today and is not exclusively encountered when archiving websites.MEN KISSING(she/they) T - C - Email me!21:55, 10 February 2026 (UTC)[reply]
How about ... this website uses its open CAPTCHA tabs as part of a botnet.? Could also add "malevolent" in front of "botnet" and "takes control of" instead of "uses".No offense, but your version is simultaneously wordy and lacking in context (what DDoS attack?). Aaron Liu (talk) 22:11, 10 February 2026 (UTC)[reply]
Could make a separate subpage or make a new section that summarises the relevant information and context, and link to it in the message. That way we don't have to fit all the context about what's going on and how we know into the message box. – Scyrme (talk) 22:19, 10 February 2026 (UTC)[reply]
As a way to deprecate without losing verifiability, we could consider copying all the links to some centralized list, and then writing a script that goes through the list taking a screenshot of each page?—S MarshallT/C23:56, 7 February 2026 (UTC)[reply]
We'd ask the WMF to provide appropriate storage, initially in a space that's linked from Wikipedia but not indexed. Is archive.today breaching copyright, then?—S MarshallT/C00:49, 8 February 2026 (UTC)[reply]
That would be copyright infringement. Yes, and so is Internet Archive. None of the fair use exceptions apply. All Internet archiving is copyright infringement as it is reproducing the whole work invariably. If you search for legal opinions on the laws on web archiving, the most optimistic view is it is at best a gray area, or worse all infringement. A gray area which we, and the WMF, strictly do not involve ourselves in (free content!), leaving it to the legally troubled Internet Archive and archive.today. PARAKANYAA (talk) 01:08, 8 February 2026 (UTC)[reply]
I think that this is something worth raising with the Foundation, who has actual lawyers who could consider what is and isn't safe. That said, it's worth pointing out that the Internet Archive is a constant target, and Wikipedia is already a target for people who don't like some of the stuff we say; adding additional potential copyright infringement (even if it's potentially protected by fair use) would be adding an avenue for people to use to attack the project as a whole. --Aquillion (talk) 21:12, 8 February 2026 (UTC)[reply]
In many cases a properly-attributed snippet is probably sufficient, but in others you need a lot more context. For example I've been reading some late 19th/early 20th century rail accident investigation reports recently. Some of those I've been needing to read over a page worth of information to be able to verify even a very simple statement like "primary cause: driver error". If I was trying to verify something more complex then it's likely I would need to include a lot more context. At List of lakes of Yukon I cited one publication about 70 times, a snippet for each of them feels like it would be well above the threshold for fair use.
Agreed. A method that'll be effective in some cases, but not a panacea.It has another drawback as well, which is that a screenshot of a single paragraph from a website will be easy to fake. Trivial, in fact.As an alternative solution that works on the single-paragraph level, we could ask editors to use the quote= parameter of {{cite web}}. Then we could persuade or convince someone to code a bot that crawls the page, verifies that the cited text appears on it, and, on a fully-protected page somewhere in the encyclopaedia, logs that it's checked that the quoted text appeared on %_date. It still doesn't give us the full page in context, and that's a problem, but it seems more tenable than relying on an unethical site of unclear ownership and sustainability.—S MarshallT/C23:18, 8 February 2026 (UTC)[reply]
That would only work on machine-readable websites that don't block the relevant bot, and would have to cope with things like "Lorem ipsum [...] et dolore magna aliqua", " [sic]", "They are about {{convert|5-10|kg|disp=sqbr}} when fully grown" (which could be in the source as "about five to ten kilos") etc. There would need to be a categories/pages for "verified by bot", "verified by human", "bot unable to verify" and "failed verification by bot" (which would be checked by a human). If it's going to be useful it would have to be alongside other tools. Thryduulf (talk) 00:56, 9 February 2026 (UTC)[reply]
No, that's not right. Verbatim quotes from a website using the quote= parameter of {{cite web}} would not contain convert templates. Only the Wikipedia article would contain those. The bot literally just has to load the quoted text, ctrl+F and find it, and log whether it succeeded or failed at a given timestamp. Yes, other tools would also be needed, but it's the beginning of a workaround.—S MarshallT/C07:28, 9 February 2026 (UTC)[reply]
Yeah, it still could contain [...], […], [sic] and {{sic}} though. It's also not impossible for it to contain things like "his [Smith's] actions", Thryduulf (talk) 12:32, 9 February 2026 (UTC)[reply]
No, that's still not right. Quotes from other websites won't normally contain wikimarkup. Therefore, {{sic}} will not occur -- except on other wikis, which we shouldn't be using for verification anyway. [. . .], […], and [sic] could indeed occur on another non-wiki website, but they present no obstacle because ctrl+F will find them just fine.—S MarshallT/C13:54, 9 February 2026 (UTC)[reply]
No, those could be present in the quote= parameter so a simple ctrl+f will not find it on the source website. For example at Mexico#Political consolidation and one-party rule (1920–2000) the last source in the second paragraph (currently #80) includes quote=...specifically the Yaqui Valley in Sonora... is considered the birthplace of the Green Revolution. the relevant passage in the source is Mexico — and specifically the Yaqui Valley in Sonora where Borlaug introduced new wheat varieties in the middle of last century — is considered the birthplace of the Green Revolution. so a simple ctrl+f will fail despite the quote matching the source. Thryduulf (talk) 18:34, 9 February 2026 (UTC)[reply]
Overuse of quotes is also a copyright concern with our current system. It also doesn't solve the verifiability issue if it is from a website that is gone because you can simply lie. PARAKANYAA (talk) 10:43, 9 February 2026 (UTC)[reply]
If you cite a source 1 time, perhaps. If you cite a source 10+ times with different parts of it all being copied, no. And it certainly doesn't abide by the WMF's (far stricter!) rules on fair use. PARAKANYAA (talk) 10:43, 9 February 2026 (UTC)[reply]
Whichever way this turns out, there are many, many, many websites that Internet Archive cannot archive at all, but which archive.today can. Information cannot be migrated to the IA because their archive types are entirely different. That is the majority of the 600,000 usages of archive.today. The alternative is not having IA archive these sites but not having them at all. And the nature of web archiving is against the WMF and the project's mission due to the copyright issues inherent to it, so they will never have an alternative either - there really are no web archiving services that are not dubious copyright wise, even the IA. If we were being honest about COPYLINK we would honestly ban all web archiving sites.It may be the result here, that we delete information sourced to 600,000 links and be doomed every time a site goes down that IA cannot archive, and if so then fine, but we should not suggest the impossible or that there is a future solution that will never appear, because IA cannot replace them and neither can the WMF. PARAKANYAA (talk) 00:30, 8 February 2026 (UTC)[reply]
None of these options sound great. Tbh, perhaps Wikimedia needs to create its own web archiving project. Between the lawsuits and concerns of possible future earthquake damage with IA, and this issue with AT, might be best to have our own, parallel project.--3family6 (Talk to me|See what I have done) 18:59, 8 February 2026 (UTC)[reply]
While preserving knowledge would certainly fit within the Wikimedia Foundation's scope, the copyright issues of website archiving (at best a grey area, at worst flat out copyright violation) are not at all compatible. Sure we could archive public domain and at least some copyleft-licensed websites, that's only a minority of the sources we use and would be ripe for both good and bad faith breaches of that license requirement (machine-readable copyright statements are the exception rather than the rule). Thryduulf (talk) 19:09, 8 February 2026 (UTC)[reply]
If this RFC is going to pass, the WMF needs to arrange some deal with their operators to mass-archive all 695k links we have to archive.today. sapphaline (talk) 17:19, 9 February 2026 (UTC)[reply]
It's not an archive of the original so if we're going to be prohibiting their service for moral reasons, why would we let the service continue to be used by being laundered through another service? PARAKANYAA (talk) 20:13, 9 February 2026 (UTC)[reply]
@PARAKANYAA: It's not primarily for moral reasons; it's to protect our readers from becoming part of a DDoS campaign, which might potentially cause their IP addresses to be blacklisted or lead to hefty internet bills in certain regions. I don't see why people think I started this RfC solely because I feel people are being wronged. ChildrenWillListen (🐄 talk, 🫘 contribs) 20:16, 9 February 2026 (UTC)[reply]
There is no real risk of any damage to any individual reader happening, it is effective at scale only because so many people use the website. It is a deeply scummy move, but not actually dangerous to the viewer in any meaningful sense. For the website maintainer targeted, sure (though I also think doxxing people is bad) PARAKANYAA (talk) 20:20, 9 February 2026 (UTC)[reply]
not actually dangerous to the viewer in any meaningful sense – well, apparently not in any sense that is meaningful to you. But other people disagree. WhatamIdoing (talk) 21:56, 9 February 2026 (UTC)[reply]
From my understanding, the code is only executed when someone archives a new page and encounters a captcha. Given that the links on Wikipedia are to already archived pages, how will this impact any user/viewer of Wikipedia? Katzrockso (talk) 05:38, 10 February 2026 (UTC)[reply]
It would send the message that it is a safe source, being so widely used, and could affect them. And if we know they are doing something sketchy now, we could hopefully weed it out before future malice. Mitchsavl (talk) 06:49, 10 February 2026 (UTC)[reply]
There's been some discussion of the WMF spinning up their own archival service. I hear the concerns about copyright violations raised by PARAKANYAA, Thryduulf and others above, but what about this solution: The WMF takes on the role of archiving citation URLs, but only gives access to trusted Wikipedia editors on a limited, as-needed basis. That way we can continue using archive links for source checking but don't expose copyrighted material to the world publicly. Would that mitigate any of the copyright concerns? Anne drew (talk · contribs) 18:54, 9 February 2026 (UTC)[reply]
The following is not legal advice, but in my view, not from a legal perspective. Organizations are still infringing on copyright if they keep copies of copyrighted material for their own internal use. From a publicity perspective and thus as a way to mitigate risk of legal action actually taking place, perhaps. My personal preference would be to work out explicit agreements with major paywalled sources. isaacl (talk) 19:06, 9 February 2026 (UTC)[reply]
The vast majority of actually problematic for verifiability sites are going to be defunct services and more obscure websites not the current major commercial players. Current businesses have a vested interest in keeping their materials available in some form, even if for a price. PARAKANYAA (talk) 20:08, 9 February 2026 (UTC)[reply]
Content owned by defunct companies or otherwise unreachable owners is a general problem for re-use, as there's no one readily available to give permission. The Archive Team tries to just grab content before it disappears, but it's an ad hoc stop gap. The ultimate answer is for countries to agree to accommodate archiving needs into copyright law. The World Intellectual Property Organization published an article discussing archiving considerations. isaacl (talk) 22:54, 9 February 2026 (UTC)[reply]
I see a lot of participants in the survey have mentioned something of the owner of the gyrovague.com blog being DDoSsed only in retaliation for having doxxed the owner of archive.today. I personally think it's idle to try and take a moral stance on the issue here; it's less about whether the archive.today owner is 'right' and more about what the archive.today owner's actions suggest about how well we can trust them in light of the fourth RfC. However, it does seem to be factoring in to many people's !votes. Can we, perhaps, get some clarification on the actual dispute that seems to have occurred? MEN KISSING(she/they) T - C - Email me!22:28, 9 February 2026 (UTC)[reply]
In 2023, gyrovague publicly doxxes the archive.today admin(s).
edit: The article notes that the contact info used to register archive.today was also used to register some cybercrime-related sites (carding, etc). It's also worth noting that kiwi farms is cited as one of the sources for another claim.
In November 2025, feds subpoena the archive. Themedia notices, and, among other things, links to that doxx.
btw, the 404 media article is, uh, interesting? it links archive.today to GamerGate, which seems like a great way to stir up shit.
Jan 8th: One of the names from the original doxx sends a GDPR complaint to wordpress.com about said doxx. The author decides that a request to take down the article is "entirely lacking in actionable detail" (?), and gets Gemini to write some bullshit about how the doxx is in the public interest. Wordpress.com eats it up.
Jan 9th: webmaster@archive.today directly emails gyrovague with a request to take the doxx down "at least for 2-3 months".
[hard to tell exactly]: archive.today doesn't receive an answer, they start DDoSing the blog in question
Jan 15th: gyrovague notices the email in their spam folder, saying they "would be more inclined to cooperate if you were not simultaneously sending me legal cease and desist letters and attempting to DDOS my site." They ask what in particular should be deleted.
Jan 25th: gyrovague gets no answer. They decide that "taking the blog post down entirely is not an option" (without justification), and decide to double down. "if you don't cease the DDOS, I'll have to publish a follow up blog post, a copy of which is attached for your review."
Jan 26th: archive.today responds, saying that the only response from gyrovague they've received was the AI generated response to the GDPR complaint. "now there is no other option but to escalate the matter in various ways."
[...]
archive.today threatens to create a gay dating app (???) named after gyrovague's real last name, and to write an investigation on gyrovague's supposed Nazi grandfather
They do still really like doxxing others, so not only do they not remove the original post, they follow through with posting the article we're discussing right now
It seems like both parties just kept escalating this at every opportunity. I'm at a loss for words.
I'll be honest, I don't think the reason for DDoSing someone matters for this RFC. At least on an ethical level, I really don't think we should actively be linking readers and editors to be a part of a DDoS no matter who is being DDoSed and what they might've done. (And I also don't particularly trust the runners of archive.is not to do something worse if they're still running the code at this point...) Tessaract2Hi!02:05, 10 February 2026 (UTC)[reply]
The only time the code runs is if you actively try to archive something. Just using archive.is is not DDoSing the blog, at least not that I'm aware of. So links to individual archives, the ones that readers will interact with 99% of the time for the purpose of verifying info in otherwise dead links, do not by themselves DDoS gyrovague. Szmenderowiecki (talk · contribs) 02:21, 10 February 2026 (UTC)[reply]
That's interesting. I always had to do a captcha when archiving, but never when searching for existing archives or clicking on a link to a ready archive. Which is why I thought that "archiving a page" and "completing a captcha" was the same thing on that website. And I tried searching archives for a couple links and never needed to fill a captcha. (I can't speak about robots or infected devices). Szmenderowiecki (talk · contribs) 02:41, 10 February 2026 (UTC)[reply]
Yeah... I think I opened up a can of worms by asking this in the first place. I wouldn't be opposed to having it collapsed as an unnecessary tangent. MEN KISSING(she/they) T - C - Email me!03:01, 10 February 2026 (UTC)[reply]
Just because gyrovague could not post a scan of a photo ID of the admin in the Internet because he didn't get to it doesn't make the blog post not doxxing. Wikipedia would revdel doxxing attempts on sight and indef the posting user. Szmenderowiecki (talk · contribs) 02:21, 10 February 2026 (UTC)[reply]
I'm more concerned about the implication that there was malevolent intent with the blog owner's post. I skimmed through it, and although it does reveal a few names (mentioned as likely being aliases) of the archive.today admin(s), it seemed to be borne more out of curiosity rather than an intention to bring down the site's owner(s). Maybe the blog owner was being negligent and careless, but I don't see an intention that they meant anything ill, and certainly nothing that excuses the archive.today fellow's response.
I wanted to ask about all of that specifically, because I'm genuinely not sure what to make of it, because I know I can be naive from time to time.
At the same time, I really don't think it's worth splitting hairs over this aspect of the issue in the first place. A sysadmin who is willing to use website traffic for a DDoS attack on a blog owner's website is not a sysadmin who can be trusted to run online services that can supplement Wikipedia, regardless of why they did it. MEN KISSING(she/they) T - C - Email me!03:16, 10 February 2026 (UTC)[reply]
I’m Eric Mill, I lead the Product Safety and Integrity team here at WMF. Given the scale and severity of this issue, I wanted to ring in here with a note from WMF to explain our approach, as the English Wikipedia community considers what to do with archive.today and its mirrors.
To cover the facts first, the RFC summary and discussion do a good job of describing the problem: archive.today, a very useful and highly relied-upon archiving service that has helped Wikipedia content be more verifiable and understandable to readers, is using visitor browsers and network bandwidth to carry out a DDoS attack as part of a dispute with another website owner.
Despite the publicity their actions have stirred up, Archive.today’s owner has not been deterred from continuing the ongoing DDoS. Their official blog (a redirect from blog.archive.today) has only dug in further, acknowledging the reporting but neither denying nor apologizing for it. As discussed on this RFC, the site’s owner has previously displayed questionable behavior and violated Wikipedia policies; their use of sockpuppets led to archive.today being blacklisted on English Wikipedia for a time, from 2013 to 2016.
The RFC summary notes the impact of ~400K articles to archive.today, though that doesn’t include the mirrors. For example, archive.is is linked in another 86K articles, archive.ph in another 10K. And this is global and bigger than just English Wikipedia. For example, eswiki, dewiki, jawiki, ptwiki, frwiki are each in the 5 digits of article counts for archive.today (not even counting the other mirrors).
Our view is that the value to verifiability that the site provides must be weighed against the security risks and violation of the trust of the people who click these links. We (WMF) encourage the English Wikipedia community to carefully weigh the situation before making a decision on this unusual case. For readers to remain relaxed and trusting while using Wikipedia, they should be able to reasonably expect that links on Wikipedia to potentially dangerous websites are rare, and that those that do exist are dealt with quickly once spotted.
Further, the same actions that make archive.today unsafe may also reduce its usefulness for verifying content on Wikipedia. If the owners are willing to abuse their position to further their goals through malicious code, then it also raises questions about the integrity of the archive it hosts.
To be clear, our view here isn’t based on who the site owner is, where they’re located, or that they operate pseudonymously. Wikipedia links to both big public institutions and private individuals all the time, routinely extending them that trust as a good-faith participant on the web. For the web to work in that way, it also means reconsidering whether it’s necessary to withdraw trust when it is violated. In our judgment, using unsuspecting site visitors to carry out a DDoS is a violation of that trust.
We expect that when WMF comments on an RFC like this one expressing real concerns, community members will wonder whether we are saying we’re going to take our own actions. The candid answer to that is that we don’t know yet, and have not made that kind of a decision: given the scale of the issue across multiple wikis, we will learn from the result of this RFC and outreach to other communities that might be impacted. We know that WMF intervention is a big deal, but we also have not ruled it out, given the seriousness of the security concern for people who click the links that appear across many wikis.
Right now, we just want to get our view – that the utility of these links for verifiability must be weighed against the violation of the trust of people who click these links – out here for the record, and encourage the community to see this issue as seriously as we do.
Thanks for chiming in Eric; I just read this discussion and my first thought was "I wonder what Eric thinks about this," and was this delighted to see your two cents. I think you have hit the key issue on the head, and appreciate that you're leaving that weighting to the community. I want to point out something that you didn't say: whether linking to archived sources of perhaps dubious origin (i.e. scraped copyright material) is acceptable. I read the non-comment as not taking a stance, but also suggesting that the foundation doesn't consider that to be dispositive. You don't need to reply to me, although you (or legal) certainly could if you feel I've misread your silence :) If you were in the replying mood on any point, I'd like to see your thoughts on the feasibility of a WMF led archiving operation, as suggested by many folks above. AdmiralEekThar she edits!12:00, 10 February 2026 (UTC)[reply]
Thanks Eric. I agree with the WMF's serious concerns about decreasing user trust in Wikipedia and relying on the integrity of an archive whose operator has chosen to behave in deceptive ways. I'd be up for participating in a community campaign to manually replace archive.today/archive.ph/archive.is links that can't be auto-replaced with archive.org, including helping with finding alternate citations where needed. Dreamyshade (talk) 20:30, 10 February 2026 (UTC)[reply]
Perhaps this is a good time to raise awareness to the fact that Wikipedia's own Internet Archive bot is essentially dead/abandonware? I have archived and tagged thousands of pages with it previously, it's an incredibly powerful maintenance tool. But it's effectively dead now, which lead me to start using archive.today exclusively. Maybe this is a good time to revive that project. --skarz (talk) 14:16, 10 February 2026 (UTC)[reply]
@GreenC, thank you for this. (Wikipedia:Namespace 0 is articles, and namespace 6 is File: pages.) Can you tell me how many different articles have a link? One link each in 400K articles would be different from an average of ten links in 40K articles. WhatamIdoing (talk) 21:18, 7 February 2026 (UTC)[reply]
It's definitely more than I expected. For context, web.archive.org is ~15.25m links from ~3.1m pages (quarry). So archive.today is covering something like ~4% of our total web archiving (allowing for a few other small archives)?
On a per page basis, archive.today has an average of two links per page on 5% of all articles, versus web.archive.org with an average of five links per page on 43% of all articles. Andrew Gray (talk) 22:45, 9 February 2026 (UTC)[reply]
Can we do a spot check of a random sample of 20 or so of these archive.today links? Should be as simple as adding a few lines to the query, like I've seen an admin do recently for a separate issue. I'm curious how many of these are truly irreplaceable, vs how many of these could easily be replaced with other sources, like if they're hosting content that is already archived by the Wayback Machine. MEN KISSING(she/they) T - C - Email me!08:23, 8 February 2026 (UTC)[reply]
Where the article had multiple archive.today links I picked one at random, where there were multiple archive.org snapshots I picked the one closest in time to the archive.today snapshot. I have not attempted to analyse whether the links are reliable, whether they verify the content or whether the information is available elsewhere.
Assuming this sample is representative (I don't know a way to tell) then roughly 15% of archive links are available only via archive.today.
* One article was linking to archive.today incorrectly [31]; one archive.today archive used on multiple pages is of a 404 page, an earlier archive on archive.org has the content, I fixed two instances and have requested a bot to fix the remainder Thryduulf (talk) 14:01, 8 February 2026 (UTC)[reply]
I came across 2 links to archive.today/archive.md which were avaialable at archive.org under exactly the same time stamp, which is no surprise because that's where archive.today/archive.md got them:
I looked at the sources that failed and for the first one (Paschang) the archive isn't actually showing the information it's being used for in the article, but rather showing a page explaining it is available through in-library reading. This is also stated on the article it's used in. In other words, the archive.is link is not actually serving any verifying purpose here.
The professional sports source is used for a claim about Franck Ribéry's salary for a football season, and while such a thing might be hard to verify for lesser known players but not for someone of Ribéry's stature. I looked around a bit and found other sources that can be used for that claim. [32] This out says pretty much exactly what the article says. [33] This one doesn't says it indirectly as no Bundesliga player is ranked higher (although I wouldn't this in an article and I'm just including it here to make the point that the information is absolutely findable without the archive.is link).
The Animal Crossing one used the Nintendo website as a source for a simple claim about an easily verifiable fact about something found in the game. That archive.is link is hence not a necessity for maintaining verifiability of this article.
So in all three cases where there is an archive.is/archive.today link but no archive.org link and where the original link is dead the removal of the archive.is/archive.today links listed there does not affect the verifiability of the claims made in any of the articles. If this is the norm then the impact of deprecating archive.is/archive.today would have on verifiability is being quite overestimated. Make of it what you will, but to me it seems deprecation would be more of an inconvenience to editors than it would be a threat to verifiability, and after all we shouldn't be sacrificing reader safety/experience for our own convenience. - Maltazarian (talk) 15:10, 8 February 2026 (UTC)[reply]
Thryduulf: Thanks for that but not sure 20 samples that way will tell much. If you want a list of URLs that likely do not exist at Wayback, I can provide over 250,000. Why? Because my bot is programmed to only add archive.today when no other option exists. It's the last link in the chain. I keep logs going back 10 years. Here is a sample. I have not checked them manually just cut and paste. I can not guarantee if they exist at Wayback or not.
Out of this arbitrary selection, half could be replaced automatically, 3/10 could be manually rescued, and 2/10 have content on available on archive.today. JumpytooTalk20:09, 8 February 2026 (UTC)[reply]
I looked at all 20, but didn't attempt to find the content anywhere else:
In summary, 8 were available at Archive.org, 8 were not available, 1 was almost certainly available and 3 would need human checking. Thryduulf (talk) 20:18, 8 February 2026 (UTC)[reply]
To add onto previous comments by digging a bit into the dead links out of the last 10 of those posted:
uefa.com - The stats are from one game after the source on archive.today, and if the claim being made really happens to be about the stats right without that one extra game included you can account for that as it shows what his most recent game was (against Belgium), so you can get around this one fine.
turkishairlines.com - Dead, not on archive.org, but there is a version of this page [34] that can be used as a source for Turkish Airlines starting operations in Friedrichshafen, Germany on 2 May, 2013, which I presume is what the page would be used as a source for.
100.naver.com - It's in Korean but from what I can see with translation tools it's about the same subject, and the archive.org version is newer so in any case that should be used as a source over an old version of the page. If the source has changed it's statement/stance on an issue we shouldn't be using their old one.
sportsillustrated.com - Yeah this one might be dead and gone. However, I did find plenty of similar news reports stating that Quentin Coryatt retired, and this Sports Illustrated article isn't actually in use in the article on Quentin Coryatt, and I doubt some fine detail that only exists in this article is being used to verify something somewhere else when it's not important enough to be on his own article.
BBC.co.uk - I mean this is just a picture of a painting which can both be seen in real life and [35], so this is not an issue for verifiability.
sungazette.net - Didn't dig too deep into this one because there's a lot of similar reporting, as there is bound to be for American politics, but I'm not sure what the claim this would be used to support is. If this article is reporting on something that's only interesting for some small local audience that this paper is writing for then the other reporting might not cover it.
All in all I'd say that out of those dead links it's only for the last one that there seems to be a significant risk of causing issues for verifiability if we were to remove it. - Maltazarian (talk) 20:57, 8 February 2026 (UTC)[reply]
The "Maybe"s are the biggest issue. They require a human to look at and assess them. By extension, that also applies to the "Yes" category; they have to be checked manually to determine if they are replaceable or not. So we cannot just have a Bot do it. Hawkeye7(discuss)22:03, 8 February 2026 (UTC)[reply]
Sometimes bots fail to detect that an extant archive is of something other than the intended content page - soft 404s, redirects to home pages, "this website is for sale", etc. All the "yes"es in the second table are (if I've understood correctly) false negative's from Green C's tool, so the bot is fallible in both directions. Thryduulf (talk) 22:15, 8 February 2026 (UTC)[reply]
If you are arguing it's inconvenient I cannot overstate how much I agree with you, but then again if the site is a ticking timebomb waiting to go off and do something that forces immediate deprecation then doing nothing will only make the inconvenience greater, and it would be forced upon us once it happens rather than be something we have control over. I haven't made up my mind yet, but if the issue has to do mostly with the large amount of effort rather than constraints on what we are even able to do then I am inclined to favour some version of B just because it doesn't seem viable to do nothing while hoping for the best. Maltazarian (talk) 22:50, 8 February 2026 (UTC)[reply]
This feels like the kind of thing that we could make a tool for. Imagine a game that shows a bit from the Wikipedia article (similar to Wikipedia:Citation Hunt), and then the possible/probable archive.org page. I click "Yes, that's a match" or "No, that's wrong" or "I'm not sure – Skip". Based on my response, it updates (or doesn't) the archive link in the Wikipedia article. WhatamIdoing (talk) 23:52, 8 February 2026 (UTC)[reply]
@GreenC: I'm the one who asked for the random sample, and specifically I was looking not for 20 URLs that are possibly irreplaceable in general, I was hoping for a selection of 20 random instances of archive.today being used for referencing on Wikipedia, out of the given number of ~700k. The idea is to have a better number for how many citations on Wikipedia actually lose verifiability if archive.today were to be deprecated. A list of 20 random URLs that are possibly irreplaceable doesn't really mean much for this purpose if they aren't URLs being used on Wikipedia.
@Thryduulf: Just to make sure, was that a random sample that was sampled, well, randomly? It needs to be ordered by &sort=random and not something like relevance or creation date, because the sorting order needs to be statistically independent of the chance that the link is irreplaceable in order for the sample to be unbiased. MEN KISSING(she/they) T - C - Email me!21:58, 8 February 2026 (UTC)[reply]
@MEN KISSING my first table were the default sort order presented by the internal search engine (I didn't know &sort=random was a thing), my second table is the same order as GreenC's. Thryduulf (talk) 22:02, 8 February 2026 (UTC)[reply]
Ah, I'm pretty sure that would be sort by relevance. I'm not really sure what sorting by "relevance" even does? But if I had to guess it would either sort more popular articles first, or articles where archive.today is more relevant, either of which are not ideal. I did notice your sample skews heavily towards more popular articles, and equal representation for less popular articles is a must.
By the way, I think the correct way to account for articles that cite archive.today multiple times, is to examine all of the citations, instead of just picking one at random.
Alright I'll start going through these, just saying in case someone else will too (which happened with the last list) so we don't do excess work for no reason (do tell if you are also looking at them). Maltazarian (talk) 22:59, 8 February 2026 (UTC)[reply]
Thank you!
BTW, there isn't anything special about that specific random sample. Anyone may generate one of their own via the same search parameters that I posted, but it might not be necessary to do so. MEN KISSING(she/they) T - C - Email me!23:11, 8 February 2026 (UTC)[reply]
Alright here:
Black Forest clockmakers - Not on archive.org, but verifiable elsewhere as the archive.today page is an excerpt from a book, as the citation says it is, and I assume the book actually exists somewhere.
Moisturizer (album) - On archive.org. The link was broken on this page and it actually had a red text error message, but I was able to fix it all by finding where the page had been moved on that website. The page it had been moved to is on archive.org.
Kecskemét Air Base - On archive.org and has another source in the article that gives redundancy
Samejima Kazunori - Not on archive.org. The url has been excluded. It looks like a web version of a primary source so it should exist out there somewhere, right? I'm actually really confused as to what this source is and it certainly does not scream WP:RS to me. Very obscure guy though, and I'm out of my depth in this subject area.
Peter Lyssiotis - A strange case of the archive.today link not being in the article for reference purposes, but rather as a feature in the "External links" section. I checked anyways and yeah it's on archive.org.
University of Illinois Willard Airport - On archive.org. The archive.today link was causing an error so I replaced it with the archive.org link to fix it.
Choi Min-ho (badminton) - Not on archive.org. The website is still online but resists capture by archive.org.
Mendy Pellin - Another case of the archive.today link being in the "External links" section. Altough it also has a template saying perhaps some stuff there should be footnotes so I don't know what's really going on with that article. Checked and it's not on archive.org.
Curtis Rouse - Not on archive.org. The url has been excluded. The source is only used as a source for his death and some stuff that other sources in the article also support. Shouldn't be an issue to make do without this archive.today link as we are just dealing with getting a source for the death of a notable individual.
Out of the things I looked at the source that might pose a problem for verifiability if removed is the one for Samejima Kazunori, but honestly I'm not so sure that should even be used as a source in it's current state at all so make of that what you will. - Maltazarian (talk) 01:07, 9 February 2026 (UTC)[reply]
By your estimation, would the links that are both offline and not on the IA be easy to replace if you had no access to the contents? As in, if you only had the dead URL and contents of the article. Seems important to weigh regarding the decision to either remove all archive.today links now, or blacklist new additions and have a set period of time to get them replaced. UnlikelyEvent (talk) 01:16, 9 February 2026 (UTC)[reply]
For both the ones in this list:
Black Forest clockmakers is a bit complicated. The footnote tells you the name of the book so in that sense the link could be replaced easily, but not with another link. I think it's an obscure German book so while I think constructing a citation for it wouldn't be much of an issue, that footnote would be for an offline source that I don't personally have access to.
ANKRD26 would be easy as the footnote mentions EST profile and NIH, and I actually found the new location of the information by googling something about NIH EST and then just putting "ANKRD26" into the first search field I could see.
Samejima Kazunori I'm not even gonna attempt to find with access to contents. I'd think it would be very difficult.
Curtis Rouse should be easy to replace as it would be just be searching for a death notice.
Worth nothing is if the Choi Min-ho link were to die I think it might be rather difficult to replace, just for the sake of argument as if we do get rid of archive.today it's likely that would end up being an issue at some point down the line.
I also looked at examples in other comments and two of those are cases like the ones you asked for:
Professional sports would also be easy as it's clear from the text what the citation was used for.
So while the vast majority would be just fine, there would certainly be some tough nuts to crack, and I do think you will find cases where removing access to the archive.today links would interfere with the ability to find replacement links. To be clear, for this reason and others, as well as the general lack of urgency here, I don't support immediate deprecation of the links. Right now I'm leaning towards option B, in large part because I think this isn't a problem that will go away and I think we should get ahead of this thing before it blows up in our faces. - Maltazarian (talk) 02:36, 9 February 2026 (UTC)[reply]
I would point out that finding links manually on archive.org is a very different from automating with a bot. Many of those pages have a "Redirecting to.." and "Impatient?". Automating is tricky because frequently they go into loops that never get anywhere. Or, they end up at soft-404s. How do you determine it's a soft-404? You can't really. The other thing is many of those pages are not showing as available in the Availability API for the same reasons, they are too sketchy. So the only way to do it (safely) is manually. And the idea that the community will magically do this manually is laughable - it won't happen. When I started on this archive work in 2015, there were a total of about 800,00 archive links added to Enwiki manually from 2001 to 2015 .. by everyone taking nearly 15 years! Good luck with that. -- GreenC02:34, 9 February 2026 (UTC)[reply]
I mean we could simply do some sort of distance function between the results on archive.li and archive.org (with a bit of regex to exclude / conform things that differ between the two in the same way on all pages), and only automatically convert links where the distance is minimal. Maybe send some that are in a grey area to a list for manual review, and reject ones where the distance is huge. This wouldn't capture everything because there's all sorts of reasons the pages would differ, but it would find a lot of safe matches while excluding obvious 404s where the distance would be wildly out of range. --Aquillion (talk) 02:40, 9 February 2026 (UTC)[reply]
With a healthy dose of responsible automation, it sounds doable, actually. But it would be a lot more feasible if we were to go with option B in the meantime, which explicitly allows the existing links to persist until willing volunteers get around to dealing with them.
Yeah it's far from ideal. Doing this type of work is tedious and there will be a lot of material that bots will fail to deal with, but I'd rather we stop making the problem worse than it is and let the debt begin to be slowly paid off rather than keep going as if everything was fine and increasing our reliance on archive.today. If we do that, then we leave ourselves at the mercy of the owners of that who might pull some shenanigans without any warning that force us to deprecate it. Just hoping that it won't happen doesn't seem like a great strategy. -- Maltazarian (talk) 03:30, 9 February 2026 (UTC)[reply]
A few years ago there was a panic about the Internet Archive going belly up. Concerns have subsided somewhat now but it remains fragile with major outages as recently as last year. We were relying on archive.is as a fallback. Hawkeye7(discuss)05:04, 9 February 2026 (UTC)[reply]
Yeah, honestly this situation has gotten me thinking about Wikipedia's archive practices as a whole. It's a bit concerning that one of the core pillars practically has a single point of failure. Ideally we want our sources to be clearly published secondary sources, but in reality a large chunk of all citations on Wikipedia are online-only articles from small publishers. They need archiving to be stable sources, but the archives we de facto rely on are third-party and could in theory shut down today if they felt like it. It's not like there's some brilliant magical solution to this though. -- Maltazarian (talk) 05:41, 9 February 2026 (UTC)[reply]
WP:Glossary#verifiable means someone can find a source. It does not mean that there is a source already WP:Glossary#cited in the article. If www.example.com shuts down and nobody's archived it, then the information cited to www.example.com is still verifiable if any other reliable source (another web page, a book, a magazine, a news article...) supports the same content – even if that other source is presently unknown to Wikipedia's editors and readers (but findable by someone). Archive sites don't usually make the difference between verifiable and WP:Glossary#unverifiable; they usually make the difference between "That's good enough for now" and "Ugh, I'm going to have to spend some time looking for a different source". WhatamIdoing (talk) 05:59, 9 February 2026 (UTC)[reply]
I'm fully with you on that, in most cases it's just a matter of labour (which is why I'm fine with option B to the RfC), but I'm thinking that if the rug got pulled from underneath (archive.org dying) and left us with a backlog of "Ugh" would still mean a small part of it becoming genuinely unverifiable, or so hard to verify it will be deemed unverifiable in good faith, and a small part of the entirety of EnWiki would still be thousands of articles.
If it is on the web only, it is entirely possible information on many topics simply disappears for good outside of archives of the specific source. PARAKANYAA (talk) 10:34, 9 February 2026 (UTC)[reply]
If the case for the topic's notability is based on sources that can evaporate when one (or a few) websites go offline, then maybe that was a weak case for notability all along.
Also, WP:NRVE, and that means evidence is required "today", and "Trust me, those dead websites contained plenty of SIGCOV IRS when they were working a decade ago" isn't sufficient. WhatamIdoing (talk) 23:17, 9 February 2026 (UTC)[reply]
You've missed the point I was making so spectacularly that I'm at a loss how to respond in a way that doesn't sound utterly patronising (and you especially do not deserve that). Thryduulf (talk) 00:10, 10 February 2026 (UTC)[reply]
Probably worth pointing out that archive.is seems to have itself had a fair amount of downtime recently, and I trust a major organization like the Internet Archive to be stable more than Just Some Guy (who appears to also be Some Shady Guy). Gnomingstuff (talk) 07:11, 9 February 2026 (UTC)[reply]
I use it constantly and it hasn't been down at all. In contrast to Archive.org, which has had multiple outages in the past few months. I believe what you are experiencing is, sometimes if you use certain DNS it will go down for that because of complicated reasons which is a purposeful choice by the website maintainer, which I have always fixed by just changing my settings. But I haven't seen the actual website go down in years. PARAKANYAA (talk) 10:21, 9 February 2026 (UTC)[reply]
A couple of big ones that aren't grabbed by the spotchecks are Reuters and WaPo post-2025-ish, where when trying to archive them to the Internet Archive results in archives of JS errors. Similar occurs when trying to archive them in Ghost Archive. So Archive.today is currently to only one available that can archive two prominent RS that we use extensively for their more recent articles/articles that were not previously archived at the Internet Archive. -- Cdjp1 (talk) 10:28, 9 February 2026 (UTC)[reply]
WaPo keeps its own archive, so we don't need an external service to duplicate that. Reuters is a wire service, which means that their content is basically 'archived' in all the newspapers around the world that reprint their content. WhatamIdoing (talk) 17:40, 9 February 2026 (UTC)[reply]
Done. Chess enjoyer (talk) 05:14, 10 February 2026 (UTC)
MEN KISSING (she/they) T - C - Email me! 02:05, 9 February 2026 (UTC)
