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 communitydecided to blacklist it in 2013. In 2016, the decisionwas overturned, and archive.today was removed from the spam blacklist. Over 400,000 pages currently containover 695,000 links to Archive.today
In January 2026, the maintainers of Archive.todayinserted malicious code in order to perform adistributed 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. As of 12:31, 9 February 2026 (UTC), the malicious code remains active. 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 toarchive.today are currently allowed. If the site were to be blacklisted, any edit incorporating a new URL that starts withhttps://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 andremove the blocked link (shown below), and then save. ...
The following link has triggered a protection filter:archive.today
If you came here because someone asked you to, or you read a message on another website, please note that this isnot a majority vote, but instead adiscussion among Wikipedia contributors. Wikipedia haspolicies and guidelines regarding the encyclopedia's content, andconsensus (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 toassume good faith on the part of others and tosign your posts on this page by adding ~~~~ at the end.
B, then A: Deprecate nowarchive.today andarchive.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 ofWP: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'tWP:IAR around multiple expansive policies and guidelines just because you deem a random website "useful".SilverserenC19:05, 7 February 2026 (UTC)[reply]
A (orB first, A later). Wikipedia's need for verifiable citations is absolutelynot 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 isnot 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 atWP: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 toAnna's Archive orThe Pirate Bay even though doing so would also make verification moreconvenient. 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 wouldstill be available evenafter 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 haveany 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 donetoday by hiding the links in the variety of templates to which they have been added, but adding to the blacklist may takea lot longer barring a bot removal. I support doing the part ofoption 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 thatCS1 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 atthis 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. --LCUActivelyDisinterested«@» °∆t°21:44, 7 February 2026 (UTC)[reply]
This is significantly premature. PerNatGertler andAmigao 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]
As it's been a few days now and more information is available than it was when I made my above comment, I feel the need to update my view toOppose A andOppose rushing anything. As indicated by pretty much everyone making a considered point, we need to balance the needs of ensuring continued verifiability of the information in the encyclopaedia (our primary mission after all) with the competing goal of respecting our ethics and I do not regard option A as compatible with maintaining that balance. I support efforts to migrate away from archive.today where that is possible, but oppose removing the links where an alternative is not available.Thryduulf (talk)12:13, 12 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 thatthere 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]
Weabsolutely 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]
Just in case we get the kind of closer who counts the words in bold, I want to make it explicit that this reduces toOption A: promptly stop using the site.—S MarshallT/C12:05, 12 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 forA. 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 usedInternet 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 donot 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 retireWP: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) – Afterlearning more about the nature of archive.today from Jani Patokallio's blog, I changed my vote toOption 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 availableand 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 whatharm 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 thatInternet Archive cannot. It is also immune torobots.txt, because I spent over a year archivingKalki 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 usingarchive.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 forAnna's Archive orSci-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, havenever 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 beingfar more convenient than books, papers, or print sources.)GreenLipstickLesbian💌🧸05:18, 8 February 2026 (UTC)[reply]
I'm anOption 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.ChaoticEnby (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 forWP: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 ofWP: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, theAmerican Red Cross receives funding fromPhilip Morris USA, and the survival of the Ukrainian state in 2022 would not have been possible without companies such asDJI. 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 anyonereally 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]
YeahAdamstom.97, I mentioned above that I increased my usage of archive.today as it is immune torobots.txt which Wayback isn't. Because I spent a year archivingKalki 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, hopeyou 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, althoughB 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 siteStuff 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 thenA 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 whenany 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 frommalware. — 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 ofdialog 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 toWP: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 abotnet. 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 suspiciousever 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]
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.SamWalton (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 ahost; hosts do not require reliability in theWP: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 areputation 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 itthemselves. 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 hascryptominers 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 wouldnever 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.ChaoticEnby (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 archiveswhen 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 createAI 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 arenot 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.SamWalton (talk)15:28, 9 February 2026 (UTC)[reply]
Confirmed. But I'm quite sure I saw that piece of Javascript mentioned atgyrovague.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]
The scenario being discussed here is very unclear to me. If they wanted to just be an idiot, it would be trivial to develop code to randomly pick a page and mess around with it in some defined way. If they wanted to specifically mess with Wikipedia, it would be relatively easy to develop code to find dead link references currently relying on links to archive.is and mess around with a small random subset of them.Nil Einne (talk)14:29, 12 February 2026 (UTC)[reply]
Option C, open to B if clarified:Option B now, reluctantly.Changing primarily on evidence that users are also being roped into running the DDOS, not just editors generating links.Still feel STRONGLY that we should be warning users/editors ASAP, especially if taking any other action, A/B/Etc, is going to have to wait until this RFC has run its course. OptionA feels nuclear given current evidence weighed against the immense disruption removal would cause. OptionB 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 "sketchy people" 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 ofFranck_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 actualcontents 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'sown 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 thepopular "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 isnot 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 orHowever, 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 isnot 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 aboutWP: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 visitingan archive page fromthis revision ofFair 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 justreally 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]
I trust that it's true for you. I just cannot replicate this behaviour even under aggressive usage of the archive search function or by multiple direct clicks on the archive links. Even then the question is, how much of a real difference would it make for the botnet effectiveness if Wikipedia users were prevented from adding it or users couldn't see the links. My hunch is that it wouldn't make a big dent because most traffic is not related to Wikipedia.Szmenderowiecki (talk ·contribs)08:34, 11 February 2026 (UTC)[reply]
I don't think that's the right question. I think the right question is, do we want to send readers to run malware? If someone sent me link, knowing full well that clicking on the link has a good chance of running malware on my computer, I would be mad. I would be even more mad if the person defended their behavior on the grounds that it wasn't a 100% guarantee I would run the malware, they didn't want to be inconvenienced by finding a link without malware, or they couldn't find a link without malware. The point is not to decrease botnet effectiveness. The point is to avoid harming the reader by running malware on their computer. Best,HouseBlaster (talk • he/they)22:52, 11 February 2026 (UTC)[reply]
I don't think your framing of the question is right, either. It is only "malware" in the literal sense of the word, but not practically so. It is a malicious script (WP:ELNO no. 3 makes that distinction), but if you ask a random person what malware is, it's going to be something actually doing something bad to your device. Soransomware, corrupting your PC, sending spam without your knowledge etc. It isn't going to be a something that loads a third-party obscure page, unless it has a mechanism to infect your computer and send it to people who don't visit archive.today. I mean, no, I would definitely not recommend this behaviour (and it's illegal), but stuff of ultimately very low risk to the end user, where ISP action would be a pure hypothetical, is not something that I think whoever wroteWP:ELNO meant by "malware". Archive.is does not have the same traffic as Wikipedia. If WMF decided to pull off that stunt whenever somebody went on the Main Page, that would be very disruptive. At the scale of archive.is, it's a mild annoyance.Szmenderowiecki (talk ·contribs)03:55, 14 February 2026 (UTC)[reply]
@Szmenderowiecki Malware comes in different shapes and sizes and no amount of wordsmithing will make archive.is not one. To quote our page onmalware:Since 2003, the majority of widespread viruses and worms have been designed to take control of users' computers for illicit purposes. Infected "zombie computers" can be used to ...engage in distributed denial-of-service attacks as a form of extortion. (emphasis mine). archive.is is literally and figuratively malware in every sense of that word. We are effectively letting our reader's computers turn into "zombie computers" and in doing so with full knowledge of the operators ill intentions, becoming complicit in performing a illegal action at best and becoming distributors of the malware at worst. Whether that is ethically justifiable on the balance of losing some archived information that Wikipedia references is a judgement call that you and the community-at-large get to make.Sohom (talk)04:11, 14 February 2026 (UTC)[reply]
I don't think it's accurate to say whoever is behind archive.is doesn't care about Wikipedia. They've at least twice used bots to add links to Wikipedia. That said they probably don't care what we do about them since they continued to do it despite it leading to their site being blacklisted.Nil Einne (talk)11:19, 12 February 2026 (UTC)[reply]
They don't care about Wikipedia as a website or an encyclopedia, but they probably cared enough because they thought they could get more traffic, and only for that reason. And they do run some tracking/ad shit from mail.ru which probably covers part of their expenses. On the rest I agree.Szmenderowiecki (talk ·contribs)03:55, 14 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 nottechnically 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 byDr 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 sayingIn 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 amsupporting 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 whoopposed 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 isactively 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 (anddo!) maliciously co-opt the devices ofanyone 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 andactively happening threatPlaceholderer (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 ofA:
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 upholdingWP: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 optionB, 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 withA (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 favourB 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 optionA 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 onOption 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 (ignoringrobots.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 amassive 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). Butthe 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). Assomeone 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'spossible 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 atWP:ELNO number three. I know that options A or B will likely lead to the loss of some content. I don't like that. Butnot 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]
As a quick crash course in computer science,malware is likeWikipedia:Vandalism: malware is software whosepurpose is to cause harm. Google tracks people, ostensibly to better target ads. The goal isn't to harm you. Is Google's tracking technology bad? Yes. Is it malware? No. This DDOS attack, on the other hand, is designed to cause harm. It isobjectively malware, and our highest obligation is to the reader. Not giving them malware is a key part of that.
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 hereis 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 referenceswithout 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 A. It's running malware on people's computers, what more is there to say? I understand the value that the archive has on Wikipedia, and I originally wrote Option B on here before deleting the comment. But genuinely, it is running malicious Javascript on people's browsers to DDOS someone's blog for making a post. Add it to the blacklist, disable all the links, and put out some kind of PSA which is clearly written so readers can understand what's happening. I don't think we should remove the links from the wikitext of the article, because we don't want to brick references. I don't know how, but we need a bot to go through and change them to the Internet Archive or some kind of other site. It's amajor sacrifice, but it must be done.EatingCarBatteries(contribs |talk)07:45, 13 February 2026 (UTC)[reply]
Option A, probably better to bot-remove/disable the existing links (that is a 'B but with an expeditedA). 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 thearchive 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 abotnet 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 asafety 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 alsostrongly 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]
Additionally, if we are considering "safety", consider the impact on the perp. Wikipedia is one of the most popular sites in the world. If there is a sudden and visible change that attracts media attention, that's likely to bring more heat on the operator of archive.is. We hear that the FBI is already on his case, so if this somehow reinvigorates law enforcement attention, that's unlikely to be good forhis safety. Maybe you think he deserves it, or maybe you think the current FBI can be trusted to operate fairly, but I'd say there is risk of a low-probability high-impact outcome that has a greater bearing on the analysis of safety than anything that can be done in Javascript.Barnards.tar.gz (talk)13:35, 13 February 2026 (UTC)[reply]
A/B By allowing archive.today links to exist, we could be considered compliant in theDistributed 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 toWP:ELNO. We do not have workable standards for sufficiently minimal malware. We have previously decided to keepGoogle inTemplate:More citations needed over lesser usedsearch engines despite itsweb 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]
Fromwikt:distribute: "To deliver or pass out." Frommalware: "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 abotnet.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 wedon'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 tosci-hub would actually bemore ethical, since then, arguably the only harm would be toElsevier's profit margin.) Once we're no longermaking 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 adark 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 fromGhost Archive,PageFreezer andPerma.cc, which both seem limited in their accessibility. (I will also note thatArs 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 WMFhas 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: (1) display but de-link archive.is URLs, (2) provide an information page on why we are no longer linking to archive.is, and (3) 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]
Option A They have directly involved Wikipedia as an accomplice to their DDOS attack on a critic. Keeping these links gives them the power to use Wikipedia to attack their critics in the future. They have proven themselves to be unworthy of trust. It's unfortunate Wikipedia has such entrenched use of a malicious website, but that's no excuse to support a bad actor.—dgiestc01:21, 11 February 2026 (UTC)[reply]
Option B today, Option A in the near future per Tessaract2, nuking almost700k external links Right NowTM feels like a knee-jerk overreaction. Let's stop the bleeding and disallow additional links while working on migration. Then we can get rid of archive.today.mdm.bla01:36, 11 February 2026 (UTC)[reply]
I don't think there is anybody here arguing that we should do this in some kind of an attempt to stop the site owner doing what they're doing. This is about stopping Wikipedia from wronging it's own users, which is certainly detrimental to the encyclopaedia.Maltazarian (talk)00:57, 12 February 2026 (UTC)[reply]
I'm fully aware of that and the details of what's going on. That's why I didn't say "security risk" anywhere in my message, which I worded in a very deliberate way to not make that claim. I say we are wronging our own users not as a reference to posing a risk to their security but rather by making them an unknowing accessory to illicit actions. You can violate user integrity without posing a direct threat to user safety, and I consider this website to be doing just that. --Maltazarian (talk)01:28, 13 February 2026 (UTC)[reply]
Option B: Although this is the first time I'm hearing about this type of behaviour from archive.today, it's in our best interest to use a more stable archiving source when possible. Wikipedia should not so heavily link to a service that (albeit suddenly) involves the user's computer in a DDoS, but at the same time I think exploding all of the links immediately is too detrimental.LuciaBCD (talk)03:12, 11 February 2026 (UTC)[reply]
B: I recognise the importance ofarchive.today in being able to archive links withpaywalls and websites with complex elements so I feel a great compulsion against Option A. Option B is the least damaging to existing links and the only one that has any chance of getting consensus. Option B is the least harmful out of those proposed to existing and any future links, if those are truly necessary. I wish that theWayback Machine (web.archive.org) could archive more complex links but that is impossible given the technology they use, thoughGhostarchive may be a suitable replacement in most places archive.today is currently used. I hesitate to vote Option C because I don't want to reward the nasty behaviour of archive.today's ownership, in normal circumstances I would vote for Option C but that is not possible because all interactions on the internet must be conducted ingood faith and this obviously was not.Qwerty123M (talk)03:24, 11 February 2026 (UTC)[reply]
B and probably eventually A. I don't think any more links should be added. It appears the majority of the existing links can be replaced by other resources and that should be done as a first step. When we can see what that leaves we'll be in a better position to determine if there are any reasons not to go to A. I would not want to immediately hide all links to them because that would make it harder to replace them.Mike Christie (talk -contribs -library)04:41, 11 February 2026 (UTC)[reply]
Option B While the services that archive.is provides are highly valuable to Wikipedia, this attack is unacceptable and shows that the site can no longer be trusted. Also, I am not opposed to Option A.Opm581(talk|he/him)06:25, 11 February 2026 (UTC)[reply]
Prefer option A, otherwise option B. Oppose C using a CAPTCHA to DDoS another site is not acceptable. Given the number of links Wikipedia has from the site, by leaving them there we are part of enabling this behaviour to continue. While the DDoS may be taken down at a later stage, the trust that the site owner will not do this again has been broken. What if, instead of the CAPTCHA, it is built into each archived page but obsfucated?Therefore, I think we cannot delay in moving to adding the site to the spam backlist. While a mass removal of the archived links is not ideal from a replacement standpoint, the links would still be visible in a permalink version before the removal for an editor / bot who adds a new archive service link.DreamyJazztalk to me |my contributions09:33, 11 February 2026 (UTC)[reply]
Option A. It's hard and a lot of work to find replacements for content archived there, and often it will be impossible, but then we will have to live with this unfortunate situation. The site was fishy from the start, we should never have relied on it and instead should have looked for better alternatives, such as improving and supporting the Internet Archive, which is a transparent and trustworthy site. Also, I think the long-term future for archive.today looks rather bleak anyway, as it seems to be a project basically maintained by one person or very few persons, so the possibility that it will go offline in the near future is rather high, and then we're stuck with countless dead links anyway, so better come up with a plan to move away from this servicenow.Gestumblindi (talk)10:10, 11 February 2026 (UTC)[reply]
Part ofOption B. I think we should definitely discourage its use, but as noted, sometimes it's the only archive available. Perhaps some sort of "only use this if it is not archived elsewhere" policy that would prohibit it if the Internet Archive or other sources had a (functioning) copy elsewhere but allow it if it was genuinely the only way to access that information?Ceratarges-etc (talk)18:35, 11 February 2026 (UTC)[reply]
Option A. A site that turns its users into unwilling members of a botnet should never be linked. If they are willing to do this, who is to say that they are not willing to drop malware (not just an inline script) onto users' computers? What the archive.is operator(s) is doing is in fact a crime, and the fact that they are doing it should be more than enough to conclude that Archive.is as a website may not last as long as some may expect. --Xacaranda (talk)19:20, 11 February 2026 (UTC)[reply]
Option B+, the "plus' being that we should createatoday-url amdatoday-date parameters for cite templates, and have a bot go and switch in those parameter names for archive-url and archive-date on refs that cite the problematic archive. These parameters should have the sole effect of putting into the display item for references with a dead-like url-status parameter "The archive of this source is currently blocked for safety reasons", or somesuch. In that way, we are keeping a store of what the archive URL is, and should something happen where we did not assume that the site was a continuing problem (if, say, the site was sold), then we could restore the links easily. --Nat Gertler (talk)20:46, 11 February 2026 (UTC)[reply]
Option A (hide), otherwiseB as a temporary bare minimum,absolutely not C. I feel like a lot of people are focusing on the wrong things here. The original dispute is irrelevant, but so are technical considerations about what any given archival service can or is willing to do (I also want several transparent, capable, well-funded, and cruciallyredundant archives). I would even argue that the amount of links to archive.is should not be a factor here. The central point should be that the webmaster of archive.is has gone completely rogue (and possibly batshit apparently), and that therefore the service as a whole is thoroughly compromised. It would be absolutely unthinkable to willingly expose our readers to literal malware just because it would be inconvenient for us not to do so. That one might not think that unknowingly roping a device into abotnet is a big deal (though I think it is a massive one) is also besides the point, because we have no reason to expect that worse is not to come. The usefulness of a link for purposes of verifiability is only as high as its trustworthiness. The reality is that we cannot trust any link from archive.is any longer and have to adapt right now. Anyone still at the denial or bargaining stage needs to go straight to acceptance because this is a matter of large scale cybersecurity for editors and readers of this encyclopedia. Maybe an addendum: with this kind of behavior on display it is more than likely that archive.is is on borrowed time, so the earlier we rip the band-aid the better for everyone.Choucas0 🐦⬛21:08, 11 February 2026 (UTC)[reply]
Option B and thenA. The legitimate use of archive.is is very limited: in the cases in which it's legal to archive a website, then we can use the Internet archive. In the cases in which we use it to circumvent pay-walls, then it's obviously illegal. I think that we should take into account also an "ethical" POV: as Wikipedians we rely on reliable sources, and high-quality media are a huge part of them. Circumventing pay-walls means to contribute to their distruction, at least as independent media outlets, which is something that is already damaging ourselves. If I can understand why a Wikipedian would want to use it, a whole different thing is to publicly give the link to the illegal copy. If then this copy is on a site which doesn't give enough guarantees about the treatment of personal data, then I think that it's our responsibility to protect our readers, who may think that a website linked so extensively by Wikipedia doesn't expose them to any risk.--Friniate ✉21:35, 11 February 2026 (UTC)[reply]
B, and probably transition to A after replacing currently used links - Not much to add here, other than that relying on a site as opaque and frequently non-functional as archive.today was not a good ideaIostn (talk)23:04, 11 February 2026 (UTC)[reply]
Option C right now (possiblyOption B later), as noted by several others it is often the only archiving option available and it would be really concerning if archives were completly lost immediately.Totallynotarandomalt69 (talk)02:20, 12 February 2026 (UTC)[reply]
Option A ASAP, "hiding" the links (by modifying the cite templates or any other suitable method as discussed below) to ensure that users can't unwittingly participate in the current DoS or any comparable future attacks.Rosbif73 (talk)09:13, 12 February 2026 (UTC)[reply]
A is my first preference withB a close second. Strongly opposeC. Archive.is / Archive.today has a shady history from their early days when it was clear someone associated with the site very likely the owner was running an unapproved bot to try and add links to their site to Wikipedia. Archive bots are thing & what they were doing might very well have been okay if they'd gone through the approval process but they refused. I think there's good reason to suspect Rlink2 was operated by the same person although there is a slight possibility it was simply operated by someone inspired by Rotlink. Considering the risks that comes from running archival websites, especially ones that use account credentials to access websites where this is needed, the secrecy behind the website may not be so surprising but it does make it a lot harder to know whether to trust the person or group behind it. We now have definite evidence we cannot. Whatever people think about the original blog post, DDOSing it using visitors to your website is unacceptable. To be clear, it's perfectly possible to feel the blog post was unacceptable but recognise the great harms that come from doing what Archive.is is doing, two wrongs not making a right etc. There's no taking sides here except on the side against DDOSing using your visitors. Many people have great ethical concerns about being part of a DDOS so by definition the fact that some visitors were forced to participate in it means visitors have been harmed. And frankly, once a website has stooped so low, we really have to wonder what else they will do. Run a miner? Use visitors for credential stuffing to try and gain access to websites? Use Javascript exploits to try and gain access to stuff the shouldn't have access to? Attempt to deanonymise visitors to try and find more about people they don't like? Let's not wait and find out.Nil Einne (talk)11:48, 12 February 2026 (UTC)[reply]
As an author and an editor, I heartily dislike websites that steal content, and I strongly support Wikipedia's respect for copyright. Given what I read here, archive.today seems to be acting criminally; Wikimedia has a moral obligation not to support this, and also practically it is foolish to rely a site that is liable to be closed down or disappear for other reasons. SoB on the way toA. Perhaps one intermediate option is to get a bot to substitute each citation of an archive.today url with a link to a page that alerts the reader to the issue and provides the particular archive.today url as text; then readers can choose to copy and paste the address it into their browsers if they so wish, but must do more than merely unwittingly click.JMCHutchinson (talk)14:23, 12 February 2026 (UTC)[reply]
Can you clarify? There's limited difference between archive.is and the Internet Archive or really most archivers in the copyright / "steal content" regard & removing the Internet Archive isn't under consideration so I'm not convinced about that as a rationale. The only area which can perhaps said to be worse is archive.is use of credentials to archive some content and perhaps also or at least I think they're way more aggressive in circumventing blocks & bypassing paywalls.Nil Einne (talk)14:43, 12 February 2026 (UTC)[reply]
a >> b, oppose c. the legal and ethical issues outweigh the possible benefits of using archive.today. besides, we probably should not be using an archive that the creator admits isdoomed to die.ltbdl (love)14:54, 12 February 2026 (UTC)[reply]
Internet Archive is also doomed to die, as well as Wikipedia and Wikimedia projects in general. This doesn't mean we should stop existing right now.sapphaline (talk)15:19, 12 February 2026 (UTC)[reply]
I mean, sure, in the sense that everything will stop existing someday. I just wouldn't compare a website hosted by one guy violating copyright law and distributing malware who admits the site can't stay up forever to large non-profit-backed projects like Wikipedia or IA. Nobody is proposing that Wikipedia should shut down right now just because we might not exist forever.IsCat (talk)15:50, 12 February 2026 (UTC)[reply]
Option C - The security concerns mentioned in the RFC description are overblown and not accurate. The site is not "injecting" any code into anything. It's just loading a resource from a site, which is neither dangerous to the end user nor a very effective DDOS technique.Nosferattus (talk)17:46, 12 February 2026 (UTC)[reply]
Some sort ofOption B-2 — Some sites are already gone, some sites just disallow archive.org (robots.txt, or they literally block the IP ranges of archive.org to go to extreme way — I know of a site which do this albeit they are nowhere near reliable under our standards), some maybe just don't get archived properly. I sort of think we probably should leave existing archived stuff as is, but new insertion of the link should be prohibited — either via SBL or Abusefilter — I personally would prefer Abusefilter because we can give more detailed warning/disallow message. — regards,Revi18:09, 12 February 2026 (UTC)[reply]
Option C. Doing something just isn't feasible - we don't have the editor time. Also removing archive.today will lead to more link rot, which is already a massive problem. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester)19:30, 12 February 2026 (UTC)[reply]
B --> A, thenD (mirror and replace all archived pages). PerGreg Price, B quickly followed by A can be done so as to minimize disruption. But we should hide links soon and move existing ones away from this site ASAP.archive.today has always been problematic, and seen by some as an unreliable archive, for good reason. It is run by a random person with no other ties or commitments to archiving or public knowledge, with no oversight. It is under FBI investigation and has no long-term preservation plan for their website. The maintainer has repeatedly flouted the guidelines of WP, and is hosting malware on their site and to pursue personal disputes. They are blocking the entirety of Cyprus, the Condé Nast office, and anyone using Cloudflare DNS from visiting their sites.While we can not control where and how people use it for short-term personal use, we must assume that a) the site will one day go offline without notice, b) the site owner will continue to block readers by IP range, and c) the site owner may already be modifying any number of archived pages. As a result,
a) For long-term preservation, we must ensure that any important archives stored on archive.today are mirrored to a more reliable long-term archive that does not restrict who can access it. It is critical to do this while the service is still online, we should not delay.
b) For knowledge integrity, we should replace snapshots from archive.today with ones captured by a more reliable service; and should tag mirrors of their snapshots as "according to archive.today" so that future reusers can know to treat them with appropriate care.
c) To avoid exposing readers to malware hosted on their site, we should hide links to the site while replacing them. Tools for scripted replacement can work just as well with those links hidden.– SJ +20:25, 12 February 2026 (UTC)[reply]
Option C Archive.today often has archived links that are nowhere to be found on the internet archive. To deprecate the source would rid Wikipedia of numerous alternatives to seemingly permanently dead links. I have found numerous links tagged [permanent dead link] on this website. This removal would make matters needlessly complicated.JPHC2003 (talk)20:57, 12 February 2026 (UTC)[reply]
Option C per GreenC and Thryduulf. It's a valuable archive website. Provided they aren't actually stealing our readers' information, it's not our problem what the maintainers do with their spare time.Cremastra (talk·contribs)00:25, 13 February 2026 (UTC)[reply]
Option A with allreasonable haste. This archive is extremely useful, but it is not necessary to satisfy WP:V except in very rare edge cases, because verifiabilitydoes not require that all sources are immediately available online for free. Further, even if deprecated, anyone who wants to verify a source or compose article content using the archive can still do so simply by pasting the original source URL or following the link from a past revision. I am not of the view that there is a tolerable amount of malware our readers should be expected to cope with, nor can I accept that a malicious script is of no concern as long as it currently only targets someone who is alleged to deserve it. Regardless of how many articles link to archive.today, it is a convenience, not a load-bearing pillar of this project. —Rutebega (talk)00:30, 13 February 2026 (UTC)[reply]
C - One may reasonably concur with those above that it seems as though there is not enough reliable information to say with an exceptional level of confidence that the 'maligned' action towards the blog was by the hand of the website operator. However, it seems inconsequential either way. Websites redirect traffic, sell user data, etc. all the time. Existentially, large conglomerates use such methods to far worse ends in the grand scheme. Little, if any, micro-harm was done those unknowingly part of a seemingly ineffective attempt to redirect traffic maliciously. The benefit of this resource far outweighs the downside (no problem with allowing links in references to it but discouraging clickable hyperlinks). On a tangent, it would not seem wise for Wikipedia to become involved in hosting such content itself due to the likely legal headaches it would provoke (why operate in a grey area when others do the dirty work and host it elsewhere; if it really is a principle/practice we want to champion and bring in-house in some manner, then that's a large discussion to be had at another time).— Godsy (TALKCONT)00:44, 13 February 2026 (UTC)[reply]
C - The Internet Archive, which is the main alternative to archive.today, is much less reliable (in my experience); it's often painstakingly slow, or down/inaccessible, or gives some error or doesn't load the site properly half the time. I used to mainly rely on IA, until I discovered archive.today; having multiple archival options at our disposal is imporant to reduce our reliance on any one of them.We can satisfy both verifiability requirementsand security concerns simply by adding a notice before users click a link that warns them and recommends enabling uBlock Origin before visiting the link to block the DDoS code. That's highly recommendable for browsing the web anyway, and it's literally all that needs to be done to preserve the highly valuable function of the resourcewhile addressing security/complicity concerns.9ninety (talk)04:41, 13 February 2026 (UTC)[reply]
Those are external links, so caution is always advisable, and there's nothing wrong with a recommendation; it doesn't need to be an endorsement. But the main point is that we can let users know of the potential risk without removing the verifiability aspect and preserving information.9ninety (talk)07:57, 15 February 2026 (UTC)[reply]
Option C, as archive.today works well enough (not perfectly, but better that not having access to it) and serves a legitimate need that improves this encyclopaedia (perWP:1Q); The DDoS matter is beyond my scope here, but we clearly shouldn't condone such behaviour (allowing the use of a service that is independent from Wikipedia or WMF, and over which we have zero control does not, in my view, condone every action carried out by that platform); An optionD (i.e., "in-house" archive), as tabled in various points above would, of course, resolve this matter rather definitively. --Cl3phact0 (talk)12:28, 13 February 2026 (UTC)[reply]
Option B as obviously verifiability is important, so I don't think its a good idea to hide or remove all links. However, the site has clearly shown itself to be untrustworthy, potentially unsafe, and is ethically not doing something I can support. I think future use of the site should be discouraged and should be replaced with alternative archiving services where possible throughout the project.Golem08 (talk)12:42, 13 February 2026 (UTC)[reply]
B, then eventually A. Implementing option B immediately is really not going to negatively impact many readers today. Regardless of technical details of the DDOS threat, this archive has no ethical code whatsoever and can not be reccommended as a host.elchupacabra (talk)14:34, 13 February 2026 (UTC)[reply]
Option C If the attack is real it could be the case that was initiated by hacking of archive.is as it has very powerful enemies. We should first contact them to ask them about the issue. We all know that the alternative archive.org removes material if asked while removing material from archive.is is more difficult. Even if the attack was initiated by archive.is it has done no harm to the trivial blog as is still online. Why would WP risk losing such an important ally for a trivial blog?8ZeitundZeit8 (talk)17:08, 13 February 2026 (UTC)[reply]
The archive is Tumblr makes it clear the owners did it. But in any case it's a moot point. Whoever did it clearly has sufficient control over the site it cannot be trusted.Nil Einne (talk)18:55, 14 February 2026 (UTC)[reply]
Option A Considering that the link to the original doxx in theArchive.Today article is still present and its removal was not even included in the agenda (although it could have been simply because of “original research” and speculations like “there is some kind of criminal forum with the same John Smith-like name in whois”) - Wikimedia has already chosen an ally in this confrontation, and a break with the archives is inevitable. Well, this is not surprising, Jani-the doxxer-Patokallio worked at Wikimedia, right?Ahmad Zaibi (talk)07:01, 16 February 2026 (UTC)[reply]
Option A the cons of using this site, if I understand correctly, are that Archive.is is an incredibly dodgy website, run in an opaque manner by a really fishy character, that is now weaponizing uninvolved 3rd parties (including our editors andpotentially our users) todeploy malware in acriminal cyber-war against some individual they don’t like, and is likely just going to implode anyway within the foreseeable future. The pro is “it’s useful” with excuses being “what they’re doing isn’t that bad” or “what they’re doing is bad but what they do for us is more important”. That just sounds like thoughtless realpolitik to me. Wikipedia may not live up to its own ideals but that doesn’t mean we should just throw ethical and security concerns out the window. Even if you think the ethical/safety issues aren’t that big a deal this site is a ticking time bomb— how long before it dies anyway or does something even more egregious?Dronebogus (talk)23:55, 13 February 2026 (UTC)[reply]
Option C Archive.today is an invaluable resource and currently irreplacable in many cases where archive.org (Wayback Machine) doesn't function as well—orat all. Denying access to such an indispensable archival service, already employed in hundreds of thousands of archived source links in hundreds of thousands of articles across Wikipedia, due to an entirely unrelated alleged dispute between the site owner and some random blogger, seems like utter madness. At least until and unless there is a better alternative that can replicate the site's unique archiving abilities—i.e. the reason why Archive.today has heretofore been so widely used in the first place. The fact that Archive.today has been cited nearly 700k times on 400k pages by countless editors over the years attests to its inestimable worth to Wikipedia. If a better alternative existed, people would use it. But no such option exists at the present time. Hastening to blacklist such an obviously popular and useful service without a viable replacement lined up could have disastrous consequences, both foreseeable and unforeseeable. If and when a superior archiving service becomes available, then a transition would be reasonable, and would likely occur naturally.Inqvisitor (talk)03:48, 14 February 2026 (UTC)[reply]
We don't have the power to "deny access" to Archive.today even if that was what was being proposed here. Not linking to Archive.today does not prevent an editor or reader going to it on their own. I'm unsure what "disastrous consequences" you're envisioning. Could you clarify? It's just some URL links that either wouldn't be pasted into references anymore or would be hidden from readers though present (if A), or some new URLs that wouldn't be pasted in the future (if B). There's not exactly much scope for anything going horribly wrong. –Scyrme (talk)04:17, 14 February 2026 (UTC)[reply]
Option C as I worry that removing the links will make many archived sites inaccessible. I have used it many times myself because Wayback Machineis terrible at archiving Instagram and Twitter links. I understand the cons of using the site, bu I still feel it has usefulness here as the Internet Archive itself has been taken down by DDOS attacks, and sometimes cannot be used. I strongly disagree with depreciating or banning any links to archive.is on here. I also worry that not using it will lead to a LOT of link rot, which of course a big problem on here. I always try to use archive.org when I can, but sometimes the Wayback Machine doesn't work at all, as Inqvisitor. If the site does go belly up, we can discussion what to at that time, but until then, I say a blacklist would be big problem which will weaken many articles on here.Historyday01 (talk)17:54, 14 February 2026 (UTC)[reply]
B, with an edit filter to block new links or a bot to replace them with Wayback Machine pages. I wouldn't support deleting the links or hiding them indefinitely, butA is acceptable for the duration of the DDoS attack (this also gives archive.is an incentive to stop the attack).Somepinkdude (talk)22:08, 14 February 2026 (UTC)[reply]
Option C. There are simply too many types of websites that cannot be archived by similar services. Archive.today is an invaluable resource for documenting past happenings, especially on more niche topics that may be recorded on shorter-lived websites. Until the Wayback Machine and other archiving sites adopt AT's abilities to gather proper graphics design and have screenshot functions enabled by default, as well as access to softly loginwalled sites, AT should stay as a host for Wikipedia sources. —UndueMarmot (talk)08:04, 15 February 2026 (UTC)[reply]
Option C. We have to work with what we've got. We shouldn't just arbitrarily eliminate hundreds of thousands of archived links, and apparently (I'm not familiar with the details, but I'm sure those discussing it above know what they're talking about) archive.org can't archive certain sites or types of information, and so can't be used as a replacement in all cases, even just going forward. Ultimately, if archive.today is doing somethingillegal, then that's a problem for law enforcement to deal with, not Wikipedia.Joe (talk)14:39, 15 February 2026 (UTC)[reply]
Option C. Apart from the attack-against-gyrovague incident listed above doing some harm to one website, botharchive.today andarchive.org do some damage to people reading an archived web page:archive.today requires giving private data to an authoritarian organisation (Alphabet Inc./Google) for the captcha (for many, not all, users), but has the advantage of creating an html snapshot of the source page that greatly reduces the user's risks of executing dangerous code; whilearchive.org runs a copy of the original javascript from the original website, putting the user at a much higher risk compared to anarchive.today html snapshot. The (related) practical advantage ofarchive.today is that it's a lot more effective in terms of handling javascript and other non-html code (and storing the result as, I assume, plain html), and can archive many pages thatarchive.org cannot archive. In thelong term, working withInternet Archive, as an open, known, community-oriented organisation, could potentially get around the problem of live javascript storage and of handling difficult-to-archive pages. However, that's a hypothetical techno-social TODO task for the future which is not yet done. Archives arecrucially important forWP:VERIFIABILITY to greatly reducelink rot. Until Internet Archive tools become more powerful, best keep the status quo forarchive.today. Depending onarchive.today does remain a high risk in the long term (bus factor). The most likely long-term viable method would be to help/convince Internet Archive to (1) make static html archives available and (2) develop its abilities to handle tricky javascript.Boud (talk)16:24, 15 February 2026 (UTC)[reply]
Option C While I prefer the Archive.org for most archiving needs, Archive.today serves as a useful secondary alternative in cases where the Archive.org fails to preserve a webpage. Honestly, Option A feels too extreme—full deprecation would likely lead to the indiscriminate removal of links without proper replacements. How would those links be fixed afterward? As others have noted in previous comments, Archive.today remains a valuable archiving website.--TerryAlex (talk)17:57, 15 February 2026 (UTC)[reply]
@Samwalton9: It is not really a DDoS, that it is a DDoS is what Gyrovague likes you to believe. A DDoS has different characteristics. And no, the doxing is here very relevant. In the US our colleagues who contribute in good faith to DEI topics are under attack and threatened to be doxed/harassed/etc., because of the topics they contribute to.Romaine (talk)09:28, 16 February 2026 (UTC)[reply]
archive.today is using a large number of devices to send repeated network requests at another website, without the knowledge of the owners of those devices, and those requests are intentionally designed to avoid retrieving cached results. For all intents and purposes, that's a DDoS attempt. Doxing is bad, obviously, but it's irrelevant to the question of whether we should be sending readers to archive.today.SamWalton (talk)10:38, 16 February 2026 (UTC)[reply]
It is not a DDoS, that is something else. Framing it as a DDoS is highly problematic for a website where we say we try to base ourselves on facts instead of fiction. Sorry, it's not irrelevant. If the owner of archive.today was a Wikimedian, the community would have reacted a lot differently.Romaine (talk)11:21, 16 February 2026 (UTC)[reply]
Additionally, every single day we send our readers to thousands of websites which use Facebook pixels, Google captchas, and other "tools" that invade our visitors privacy and have a much higher vulnerability than this case. Also we have thousands of links to Facebook, a platform that on purpose doesn't remove malicious advertisements just for their own profit. And no, this is not irrelevant, this is hypocrisy.Romaine (talk)11:31, 16 February 2026 (UTC)[reply]
This RFC is framed as being a DDoS, while there isn't one. This RFC is framed as the users of archive.today are in danger ("safety concerns"), while they aren't. This RFC is framed when people say archive.today is injecting malicious code, while it isn't. This RFC is framed as being an attack, but it isn't. I think we can agree on that the captcha page contains code that makes the user visit a certain blog page, which we do not want. But if all these frames are used in this RFC, Wikipedia is violating its core values that we stand for facts.
It is certainly possible that Wikipedia takes a moral stand (and this RFC is only a moral stand because there is no danger to the users who use Archive.today). But taking a moral stand shouldalways be based on facts, and shouldalways be done in such way that it does not do harm to our core moral principles. If we base ourselves on fiction (the frames are fiction), we'll bite us in our own tail. If we violate our moral principles, it will hit us hard, as we'll then basically say to the world that they can't trust us.Romaine (talk)14:04, 16 February 2026 (UTC)[reply]
Option B and long-term option A. It's a bad situation, but this is a malicious site at this point. If this were any other site we'd have blocked them by now. I agree with all the comments about it being pretty important and this should spur further development to ensure we're not too reliant on any non-open/community-based archiving site.Legoktm (talk)18:30, 15 February 2026 (UTC)[reply]
Option B, later A I am a new editor and have limited experience writing articles from scratch (finding and citing sources, etc.), so take my opinion with a grain of salt. The (imo) best way to handle this i could come up with of over the last few days of thinking about this is a block for adding new archive.is links immediatly, adding a warning to existing ones, and migrating to archive.org or alternative sources. For any sources which can not be migrated this way, a Wikimedia controlled mirror of the archive.is pages could be established. In any case, i believe that linking to websites which could have harmful effects (e.g. potentially landing on an IP blocklist) on unsuspecting readers should be avoided.Aryezz (talk)18:55, 15 February 2026 (UTC)[reply]
As a sidenote, any archive carries risk of going offline for any number of reasons (bankruptcy, legal, technical, etc.), so even if my dream does come true and Wikimedia does end up creating an alternative archiving service, i would also still like to be able to embed multiple archives in a citation, to diversify the risk.Aryezz (talk)18:55, 15 February 2026 (UTC)[reply]
Option B for now, with A as a strong second choice Hiding the links vanishes a bunch of sources overnight that we then need to sort out, but relying on a website that is willing to DDOS critics leaves our readers and users open for use to a party that has demonstrated bad faith activity in the past. --Licks-rocks (talk)19:52, 15 February 2026 (UTC)[reply]
Option C - As others have noted, there is real no alternative in many cases. The Internet Archive sometimes errors out on sites that Archive Today can successfully archive. Until that is resolved, and all resources mirrored, it should not be deprecated or removed. --Joshua Issac (talk)21:06, 15 February 2026 (UTC)[reply]
Option A, with B second or short-term stop-gap. We cannot promote our readers being tricked into becoming part of a botnet, no matter what the benefit to our readers might be.WP:V is not the only pillar. I only support B at all if we need a short time to figure out more specifics, but long-term A is the way to go. We need to stop making things worse, with an eye towards pragmatic details and then make things better.DMacks (talk)01:03, 16 February 2026 (UTC)[reply]
Option C - As pointed out by others above, if we were confronted with the actions of the blogger, we would have immediately banned the blogger as NOTHERE for doxxing. I am not convinced we would have done the same for the counter attack in the heat of the moment by webmaster of archive.is who discovers attempts to dox them. We would have at least started with a warning. Since this RFC has now received press coverage, we can assume archive.is has become aware of this discussion. If the person values Wikipedia directing traffic to their website, I suspect these counter attacks will cease. If they continue despite our indirect warning, perhaps we can revisit this question. However, at this point in time, I do not see good cause to inflict such harm on Wikipedia as a project. Option A and even B would be premature severe measures at this point in time. --- C&C (Coffeeandcrumbs)03:44, 16 February 2026 (UTC)[reply]
@Coffeeandcrumbs, doxing (which is what the blogger did) is disallowed byour policy and is definitely a bannable offense, DDoSing by using botnets is straight-up illegal in that it is a federal crime. I see no reason to platform that either.Sohom (talk)03:54, 16 February 2026 (UTC)[reply]
Not just afederal crime. It's illegal in most countries (including Russia, where Archive.today is apparently based per the discussion atVillage pump (technical)). Regardless, the point shouldn't be who did the worse thing. The point should be whether Archive.today can be trusted to be safe and reliable if it doesn't respect user consent. –Scyrme (talk)04:00, 16 February 2026 (UTC)[reply]
I simply believe the counter attack, under the circumstances and by a resources perhaps just as important as this project, is more forgivable than an unjustified doxxing that seems to have resulted in the webmaster facing targetting by a fascist government. --- C&C (Coffeeandcrumbs)04:12, 16 February 2026 (UTC)[reply]
We're not here to pass moral judgement on the parties to the conflict or say when something is or isn't justified. Sure, it's a debate that can be had, but this is not the place to have it. The reasons the parties have for doing what they did are, to be blunt, irrelevant. The question we have to answer is what Wikipedia should do about external links that lead to sites known to run scripts that exploit site visitors for criminal/malicious purposes when those links also contain source material. Also the supposed harm has been quite overstated by many, the vast majority of archive.today links on Wikipedia are not required to upholdWP:V, as demonstrated in the analysis of links section. That is not to say there wouldn't be any consequences, but it wouldn't be the cataclysmic event some seem to believe it would be. ―Maltazarian(talkinvestigate)05:25, 16 February 2026 (UTC)[reply]
In this RFC there is no danger to the visitors of pages in Archive.today, and even using the archive function to add new pages to Archive.today does not do any harm to the user. The only thing that thus is discussed here is the "moral judgement".
Facebook is running massive advertisement campaigns that send users to scams, and Facebook has made the calculation how they have to pay in fines (which is lower) compared to the profit (which is higher) that they gain from those advertisements. We have thousands of links to Facebook and thus to their scams.
Referring to the links section is problematic, as already has been stated there, as it is an extremely limited sample. And even if the sample is accurate, which is questionable, this still means that thousands of archive links have no other alternative, leading to a large quality loss for WP:V.Romaine (talk)14:14, 16 February 2026 (UTC)[reply]
Option A: While this archiving site may have been relied on for some verification, I can't see that an "it's useful" position outweighs its deployment as a negative tool. Any archive is secondary - a snapshot indicating a resource that exists or has existed; if a reference is supporting anything controversial, multiple strong sources, such as a newspaper archive, are needed: that should be the direction for improving this site's verification. (Further, news sites such as The Guardian are assiduous in follow-up corrections, which are likely missed by an archive snapshot.) WP should not be directing traffic to external locations that are known to have been misused, so adjusting the displayed URL so that it can't be clicked directly seems the minimum prudent and responsible action at this point.AllyD (talk)09:15, 16 February 2026 (UTC)[reply]
Option C, per GreenC and Thryduulf. Editors have added references with the understanding that they would be available at the archived URL provided, and we have no way of checking that other versions of the same URL provide the same information, so it's not possible to remove the archived URLs or we'd lose verifiability. Discouraging the mention of archive.is would only induce violations ofWP:SAYWHERE. Meanwhile, it's not clear that the attempted DoS is achieving anything. The downsides of options A and B are clear, while the upsides are only hypothetical. Hence option C is the best course of action for now. If Automattic (the target of the DoS) comes to us complaining that our links are sending them a significant number of malicious requests, then we can discuss this again.Nemo09:47, 16 February 2026 (UTC)[reply]
@Nemo I'm not personally convinced that judging the efficacy of this attack should be relevant to this discussion. Do you think we should updateWP:ELNO #3 to state "Sites containing malware, malicious scripts, or trojan exploitswhich are achieving the attacker's goals"? In my opinion "Contains malware" is the simple line we should draw.SamWalton (talk)11:00, 16 February 2026 (UTC)[reply]
There isn't any "malware" by any common definition of the word. The visitor of the website is not hurt. The alleged DoS targetmight be. If "contains a script which makes unwanted HTTP requests" becomes our standard for malware, similar tothe FSF stance, then we should stop linking any website that doesn't work cleanly with LibreJS, and at any rate any website containing a proprietary captcha or AdTech tracker like theubiquitous and illegal IAB trackers.Nemo12:07, 16 February 2026 (UTC)[reply]
(edit conflict)Option B (and then eventuallyA). If C is the outcome I would strongly advocate a warning next to archived links at the very least. This isn't because I think the other party and their possible doxing is good or even acceptable; nor do I care much about whether archive.is's owner is-or-is-not doing something illegal (It seems likely to me butIANAL). No, the reason is that links to the site now use visitor resources to DDOS a site as part of some petty dispute. If a user goes to a site expecting one thing (presumably that their resources will be used for the functioning of the site and any code the site downloads would be for that purpose) but instead gets some entirely unrelated code (which uses their resources for the sysadmin's personal aims), that'smalware. That isn't something that a site build on thefree software/free culture movement should be tolerating.
Option B (and the hide parts of option A) then the spam blacklist of option A when we've removed all links. Using Wikipedia to attack websites is something I cannot ignore. I'm sure we can figure out how to handle all archives even without them. --Gonnym (talk)12:14, 16 February 2026 (UTC)[reply]
I'm sure we can figure out how to handle all archives even without them. Based on the research of other participants in this discussion, this is at minimum very much not a trivial task and in some cases may not be possible at all.Thryduulf (talk)13:52, 16 February 2026 (UTC)[reply]
B and then A, unless there is a way to sanitize the pages accessed - but I don't think it is possible. Readers of Wikipedia must trust that accessing the encyclopedia is not harmful. --.mau. ✉14:12, 16 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 ofCIA 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 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 beingonly 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 literallyonly verifiable via a single old dead webpage, is it really likely to be notable enough for inclusion anyway? If absolutelyno alternatives exist, how can we say it hassignificant coverage insecondary sources which areindependent of the subject? Maybe individual details don't requiresignificant 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 theydo 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 articlecontent is not notability anyways, it isWP: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 areno examples, then maybe it's even none. Just pointing to the raw total number assumes they'reall 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 theWikipedia 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]
Yes, that's why I referred to local libraries for editors (I didn't want to go into detail on how one obtains access, as that will depend on each individual library).isaacl (talk)03:23, 11 February 2026 (UTC)[reply]
I never figured out what the policy was at archive.org. I understand that they respond to take down notices. But it goes well beyond that. Just because something is on Wikipedia doesn't mean that they'll archive it. I have had discussions with the International Olympic Committee about archiving the Olympic web sites. After each games, the site is retired and the domain registration ends. The web sites since at least 2008 have been archived on tape at the IOC but what use is that? Archive.org does not archive them properly (the effort on 2012 was very poor). I was able to get the National Library to archive, but they only Australia-related material. Some sporting organisations were expecting Wikipedia to do the archiving for them.Hawkeye7(discuss)03:20, 11 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 isonly verifiable on asingle webpage that isn't even maintained anymore, it seems implausible to me to meetall 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 isonly 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'sWP: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 ofthis 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 atWikipedia: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 astransparent and the foreground color ("info-fc") set asvar(--color-base, #202122), both of which makeModule:Color contrast error out, andModule: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 thatModule:Userbox avoid adding the category if the contrast check errors out. That would involve changing theerror = 0 to something likeerror = 100 in three places inthis 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 forthis 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 theWikipedia 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 likeAnna's Archive orThe 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 starteda discussion based on this RfC on Meta Stack Exchange (the place for discussions about theStack 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 toarchive.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]
Floating the idea of a couple stopgaps we could implement while the malicious code is still live and/or this RFC is still running. I'd be very interested in particular to hear from option C !voters to see if any of these have a chance of achieving a consensus quickly:An edit filter set to warn whenever an editor adds a link to archive.today or a mirror. Can be clicked through, or the editor can take time to rereference.Explicitly state that editors are encouraged to replace archive.today references or mirrors thereof with other sources that verify the same facts.Place a "soft redirect" screen when a reader clicks an archive.today link that briefly summarizes the issue and whether they're likely to contribute to it, then offers them buttons to proceed or return to wikipedia.Tazerdadog (talk)05:47, 11 February 2026 (UTC)[reply]
You have three suggestions here. The first two are things we can do ourselves. I believe that the third idea would require dev support (either volunteer or WMF devs). On the first two:
I support adding aSpecial:AbuseFilter to 'warn' editors. The warning should provide a link to a short page explaining the situation (short enough that it's convenient to read, which means not this RFC).
Where do you expect to place this statement? General announcements (The Signpost, the admin newsletter, a watchlist notice, something else)? I suppose we could set up anWikipedia:Editnotice for affected articles. What else?
We can shelve the third until and unless someone technical comes along with a good idea for how it can be implemented.
On the first, of course, that makes sense. Should I go mock something up quickly?
On the second, signpost and admin newsletter are probably good ideas, but what I was really wanting was a formal statement so that volunteers can get to work on a verifyability-preserving cleanup. This could mean work pages, setting up bots, sorting by impact, topic, original source, or expected replacement difficulty, and having a good answer when someone asks "why are you shuffling references en masse" or "Where's the community consensus for your bot task" or "Dear WMF, what are you doing about these links to malware in your encyclopedia". The common way to do that is a RFC with a formal closure (hopefully expedited), but if you have an alternative way to get there I'm all ears.Tazerdadog (talk)02:55, 12 February 2026 (UTC)[reply]
I saw a good suggestion for how something similar to the third could be done somewhere else in this RfC: you could update all of the citation templates to check for links to archive.today and adjust them accordingly.MEN KISSING(she/they)T -C -Email me!03:15, 12 February 2026 (UTC)[reply]
We were talking about having the citation templates hide these links. The third idea is more like one of those "Now leaving ThisWebsite.com Click here if you are not automatically redirected to OtherWebsite.com in five seconds" (only with more of a "do you really want to click the unsafe link?" vibe).WhatamIdoing (talk)04:03, 12 February 2026 (UTC)[reply]
Hey now, there's no need to post disheartening comments in response to other people encouraging taking initiative to make Wikipedia better. If it's not damaging why not just leave it be? --Maltazarian (talk)05:58, 12 February 2026 (UTC)[reply]
Mockup availablehere. Please edit this mercilessly until it is fit for purpose. Current proposal is an edit filter that warns and perhaps logs, but does not disallow edits that add a link to archive.today or a mirror thereof. Text of the edit filter warning something like: "Warning - You have added a link to Archive.today, or one of it's mirrors. That website is currently running malicious code on the computers of people who visit it. For more information, seeour info page. If you can replace archive.today with an equivalent source, please do so. If you cannot, you can click "Save Changes" again to save your edit."
Regarding the formal statement, I just want to be 100% sure I actually have consensus first before I make a large volume of changes. Based on the RFC above I think it's likely I do, but I aminvolved as hell so I don't have the right to make that call.Tazerdadog (talk)05:35, 12 February 2026 (UTC)[reply]
It's looking like editing on the edit filter idea and landing page summary has slowed down. I still have not heard from anyone opposed to this, and quite a few people have seemed to be supportive either explicitly, or implicitly by contributing to building that landing page. At this point, unless someone objects basically now, can webe bold and add in this filter?Tazerdadog (talk)06:37, 13 February 2026 (UTC)[reply]
I think I would have preferred if GreenC had asked beforehand, but it's nothing I would squabble too much about. I'd be more worried if it was something like sending a notice of this RfC to the top 50 users of archive.today links on Wikipedia.
Speaking of, I do think there is a concern with adding an edit notice or an abuse filter link to this RfC while it's still going, as it would be more likely to attract editors who are more reliant on archive.today and could skew consensus results.MEN KISSING(she/they)T -C -Email me!03:11, 12 February 2026 (UTC)[reply]
I was slightly concerned about that too, but I would hope that the brave individual who takes it upon themselves to close this juggernaut of an RfC is wise enough to distinguish disgruntled archive.today afficionados voting C with little to no justification from people voting C with well-articulated arguments rooted in policy and good practice. That being said I hope it wouldn't be an issue even if it were to occur, and I actually appreciate the fact it has the potential to alert unaware editors who are using archive.today to the current situation.Maltazarian (talk)05:50, 12 February 2026 (UTC)[reply]
There is currently some bad blood between the blog and the archive site, ascan 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]
If this were any other concern, I would agree with your objection; but when it comes to user safety (ie. links that may be activelyunsafe) 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 theirreputation 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 arenot 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 thisparticular 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 areactually 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 somethingChildrenWillListen 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 isstill 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.SamWalton (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 sendHTTP requests to the gyrovague.com blog every 300 milliseconds. To see these HTTP requests in real time, open your browser'sweb 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 theGreat 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 hasasked 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 isnot 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 abotnet.? 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]
Would something like this be good?
Archive.today has been linked to a malicious attack.
Please exercise caution when using this site, and follow instructions at (add page here) before using the website.Last updated 03:25, 12 February 2026 (UTC)
"Has been linked to" is I think very soft to the point of being misleading. I would word the header as "Archive.today is currently conducting a malicious attack using the computers of people who access the site." Not sure if that can be shortened further or made simpler.Tazerdadog (talk)03:44, 12 February 2026 (UTC)[reply]
I agree I that "has been linked to" is too vague, but "malicious attack" is also very vague. Why not be specific? Something like:
Archive.today is conducting an ongoingDDoS attack via its users.
Exercise caution when using this site. For further information, see (LINK). (last updated)
The link could then provide whatever instructions we suggest regarding exercising caution, information about how this was verified, etc. That said, I doubt we'd get much agreement on any specific instructions. Some of us would prefer the instructions to simply be "do not link to archive.today or its mirrors", others would rather "only link to archive.today when strictly necessary after (...instructions on how to check for replacements...)" maybe including something about how to use content blockers like uBlock to block the script, and many arguing for C seem to want no instructions at all as they say they see no problem here at all. I suspect the closest we might get to an agreement on instructions is "exercise caution". –Scyrme (talk)01:26, 13 February 2026 (UTC)[reply]
Yes, being specific about the DDoS is useful because "malware" and "malicious attack" can mean a wide range of scary things. I'd still like to see something more specific than"Exercise caution when using this site." because the generic idea of "caution" isn't really actionable here for users. For example:"Consider alternatives to using this site."Dreamyshade (talk)07:00, 13 February 2026 (UTC)[reply]
Where exactly would this banner go? If it's on the main page that's going to be a lot of banners. If it's on the talk page no one will see it. If it's editors only then it doesn't really help readers at all. (I think this wording is fine.)Gnomingstuff (talk)16:58, 13 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 isat 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 isalready 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. AtList 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 thequote= 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 thequote= 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 atMexico#Political consolidation and one-party rule (1920–2000) the last source in the second paragraph (currently #80) includesquote=...specifically the Yaqui Valley in Sonora... is considered the birthplace of the Green Revolution. the relevant passage in thesource isMexico — 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 IAcannot 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]
@3family6 The comment right above yours, plus several other comments here, point out that "there really are no web archiving services that are not dubious copyright wise, even the IA". I doubt that the WMF would create a database containing massive copyright violations.David10244 (talk)09:37, 11 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]
@Katzrockso I just clicked on an archive.today link to read it, and I was presented with the CAPTCHA page. It may have been the first time I have visited archive.today from this computer. So, reading can definitely trigger the CAPTCHA.David10244 (talk)10:17, 11 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]
Today I restored a deadlink that was only available via archive.today by rearchiving with Megalodon. This got me curious: Wayback won't archive a.t links anymore...but will it archive a Megalodon archive of an a.t archive? Turns out,it willPickledCookies (talk)18:42, 13 February 2026 (UTC)[reply]
"unchecking some checkboxes in devtools" sounds like a step that would be taken on the user end to make these archives more viewable? This is a bit outside of my wheelhouse.
There's been some discussion of the WMF spinning up their own archival service. I hear the concerns about copyright violations raised byPARAKANYAA,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. TheArchive 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 anarticle discussing archiving considerations.isaacl (talk)22:54, 9 February 2026 (UTC)[reply]
This seems to keep coming up but I think it's incredibly unlikely websites will agree to allow their paywalled content to be publicly archived. For starters, while the Internet Archive may be controversial at times with stuff they do, they are also willing to talk to publishers & have a massive infrastructure behind them so it's unlikely that some random entity, even Wikimedia, will be able to convince them to do something the Internet Archive hasn't managed to.
More importantly, sites are starting to prevent access to the Internet Archive not because of dislike over what they're doing per se, not even directly because of concerns over bypassing paywalls. But instead because of concerns AI firms can use it to work around restrictions on scraping their content for AI use.[15][16]
Why would Wikimedia, or some other entity be able to convince these website AI firms won't do the same for their sites? Especially since again, whatever entity it'll be would lack the infrastructure and experience to even think of ways to try and limit it. Remember as noted in the articles it's not even that these sites don't want AI firms to use their content, rather it's that they want them to pay for it.
The AI problem is an even bigger issue that there NEEDS to be legislation about. As for the paywall issue, this is just my commentary, and someone would have to convince companies, but I think a good compromise would be only permanently dead content is available for full public access. Live paywall content would need to have a library card access.--3family6 (Talk to me|See what I have done)13:34, 12 February 2026 (UTC)[reply]
The Wikimedia Foundation can offer the usual enticements of money and publicity, plus it can limit access to specific sets of users (perhaps Wikipedia users with relatively high ongoing levels of activity). I agree that it would be a slow and challenging approach to attempt (the Wikipedia Library does demonstrate that some success is possible). I feel, nonetheless, that we should strive towards a convergence with the community consensus guidance onnot linking to sites contravening copyright law, without having to consider archives as a special case. This can also mean supporting archivists in pursuit of modifying global copyright conventions to support archiving.isaacl (talk)18:14, 12 February 2026 (UTC)[reply]
Limiting access could be enough and is something the internet archive probably won't do by themselves but everything else you've suggested is something the internet archive could do. Significantly in terms of money it would need to come close to what they expect to get from random AI firms or is unlikely to entice them.Nil Einne (talk)05:18, 13 February 2026 (UTC)[reply]
To assist with replacing archive links (and link rot in general), it may be a good idea to make it a requirement to provide a valid|date= or|accessdate= parameter whenever a|url= parameter is used by a citation template, so a warning message is displayed like when citing without a|title= parameter. Ideally, only one of them would have to be present to remove the warning, though if doing it that way would be difficult to code we could instead leave|date= as optional and make only|accessdate= a requirement. If the presence of a date in some form were required with a URL, it would be easier to find an appropriate snapshot for verifying what was on the page; simply start checking from the snapshot closest to the date/accessdate provided. At present it's never a requirement, even for{{cite web}} (where there's no alternative to using|url=). While it's not difficult to check through snapshots until you find one that's suitable, the process would be faster and more convenient if a date were always provided. It might also help with automating/semiautomating things, since a bot could then not only check if a snapshot exists on another archival site but also find the snapshot which is at the most suitable date. This is probably a change we could make before the RFC concludes. –Scyrme (talk)19:10, 15 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 thefourth 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.todaydirectly 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 doxxingothers, 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]
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]
@MEN KISSING, @Szmenderowiecki I also read the blog owner's blog, and it clearly states that he was curious about who runs this large archiving site. And curious why there was very little known about the person or people behind this large, critically important archive that a lot of the Web relies on. He (or she) did find some publicly available information, using a Web search engine, and not by using any deep sleuthing or hacking any databases or other sources. He put that name in a blog post.
Is that doxxing? Maybe so, but there did not seem to be any malicious intent. Was the owner of archive.today harmed by his name being published, after it was found in public sources?David10244 (talk)09:54, 11 February 2026 (UTC)[reply]
I don't want to get into too many details since as I said above it's largely irrelevant. It's perfectly possible to think what the blog owner did was quite wrong without supporting a DDoS using your visitors.
However I'd point out the claim we'd revdel all "doxing" is simply wrong. In fact there are plenty of "doxings" which are a prominent part of articles e.g.Libs of TikTok andMitt Romney#Social media, We had extensive discussion on how to handle the case of the name of the person behindSlate Star Codex before the blog author made it public IIRC we avoided mentioning the name but there was quite a lotof discussion over how easy it was to find.
Plenty of more examples I'm lazy to dig up. I'd note that theDoxing article itself includes a bunch of examples with names. From there I found that we have a whole sectionElena Ferrante#Anonymity. And that reminded me that bothThe Stig andBanksy have long had discussions over their identity.
Doxxing with respect tousers, at least those who prefer not to share their real-life information on-wiki. People who are prominent or who want to become prominent, or, in areas like the United States, criminals, have their personal info revealed by journalists non-stop. However, doxxing non-notable people on Wikipedia is also harassment, and it's in the rules. I wouldn't say that the sysadmin of archive.is wants to be or is a prominent person.Szmenderowiecki (talk ·contribs)04:07, 14 February 2026 (UTC)[reply]
I’m Eric Mill, I lead theProduct 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, from2013 to2016.
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 inanother 86K articles, archive.phin 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]
I think it would come down to several factors. If the legal team were to get involved, another shady activity got conducted by the site, and/or new information demonstrating a further significant risk to users emerged, they would likely take action or may have no choice but to do so.
Hi, I was wondering if WMF is planning on a follow-up RFC, possibly over on Meta Wiki, about updating global policy in the wake of this incident to ensure that similar situations can be more easily dealt with in the future? I'm guessing it is rather rare for a widely used source on Wikipedia to decide to conduct a DDoS attack, but when it does happen (or if the site transfers ownership or gets hacked etc.), there will be significant implications to consider, and risks to balance.Mitchsavl (talk)06:25, 12 February 2026 (UTC)[reply]
The WMF usually leaves decisions like this to us. I know it sounds pretty strange when you think about how many stupid people you encounter in real life, but the communities are actually pretty trustworthy. Everyone wants to do the right thing, as best we can.WhatamIdoing (talk)06:30, 12 February 2026 (UTC)[reply]
Even if WMF weren't to do it for global policy and instead as guidelines, it would at least give the communities a starting point to manage situations in the future.Mitchsavl (talk)08:06, 12 February 2026 (UTC)[reply]
There are other editors who think the WMF should just comply with whatever laws are created, and that it's none of the WMF's business to advocate for what Wikipedia needs. (Some of them think that individual editors should be doing this, so have you contacted your elected representatives, or whatever the most relevant people in your country/governmental setup is?)
More to the point, even if every country agreed to a "right to archive" as quickly as they can, that will not solve the problem that we have right now. That would address most of the problem for future decades. We need to address this problem approximately today.WhatamIdoing (talk)03:27, 14 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]
@WhatamIdoing No, I am talking about the Internet Archive Bot which suffers from severe server load and has many open tickets addressing this issue, none of which have gotten a response from the developer.Here's the ticket I opened in July 2025 and here's other bug reports submitted: [1][2][3][4][5][6]— Precedingunsigned comment added bySkarz (talk •contribs)15:24, 11 February 2026 (UTC)[reply]
On the one hand, we have you saying that it didn't work last July, and nobody replied to your complaint.
The evidence of multiple unacknowledged bug reports of a 48 hour+ backlog is significantly more relevant to me than evidence that it sometimes works. --skarz (talk)15:40, 12 February 2026 (UTC)[reply]
I've just confirmed that the bot works in every one of those tickets I just closed. I've been keeping busy with rewriting the bot, so I've been silently monitoring the tickets, and addressing load issues as they came in. IABot is running at it's limit, and I've been able to further optimize it on production to stabilize it. My intent is to close the tickets when I'm ready to deploy the new bot and decommission IABot 2, and have confirmed the reported issues aren't issues anymore. —CYBERPOWER(Be my Valentine)15:52, 12 February 2026 (UTC)[reply]
I've been leaving those tickets open so I have test cases for the upcoming version of IABot. I've been able to optimize the bot in recent months which reduces load and reduces timeouts. —CYBERPOWER(Be my Valentine)15:40, 12 February 2026 (UTC)[reply]
I think it would be useful to compile a list of discussions in other languages. I know of a recently started discussion in German and will add the link here, maybe others could add links to more language versions where this is discussed?Gestumblindi (talk)10:04, 11 February 2026 (UTC)[reply]
RfCs are open for 30 days by default. Given the ongoing nature of the main issue here, how do we feel about closing early? Perhaps after one week, which would be the 14th. Then, if there's consensus for A, we can take a couple days to figure out how to replace archive links and/or document what must be replaced before removing everything (this is just to say closing early doesn't mean absolutely every detail needs to be worked out, but can move us from decidingwhether to decidinghow).
Alternatively, we could keep the discussion open and tentatively implement option B while discussion plays out. A blacklist is easy to just undo at the end if there's consensus for C, but it would, in the meantime, prevent some degree of further harm.
Regardless of the duration we choose, this needs a crisp close at the end (solid + timely). Skimming through the discussion so far suggests to me that the close is non-trivial, and the problem is urgent enough that this really shouldn't sit past the 30 days while we hope for a closure. A panel closure is potentially helpful. If you're eyeballing this discussion to potentially act as a closer, speaking up now so we can form that panel is probably good.
I also agree that this should be considered for an early close, or if we really want the full 30 days, a temporary stopgap should be put in place. Elsewhere in the thread, I proposed 3 options, an edit filter that warns if a new link is added, a statement that it is helpful to replace archive.today links with alternative and equivalent citations, and/or a soft redirect page between the citation click and the archive today page that explains the issue to our readers.Tazerdadog (talk)17:37, 11 February 2026 (UTC)[reply]
As a matter of ordinary RFC procedure, we try to keep an RFC open for at least a week. However, there areWikipedia:No firm rules. If we think that the outcome is unlikely to change with more discussion, then it could be summarized at any time.WhatamIdoing (talk)19:23, 11 February 2026 (UTC)[reply]
Given the potentially drastic impact this RFC could have, I don't think I'd be comfortable with an early close with any concrete outcome unless it were a clearWP:SNOW situation, which it obviously isn't - SNOWis the mechanism for situations where there's a clear-cut, unambiguous, uncontroversial emergency. There is (quite rightly) no mechanism to declarecontroversial emergency closures, outside of perhaps overriding an ongoing discussion with anWP:OFFICE action or an arbcom motion; I'd be completely opposed to the idea, which would set a terrible precedent. It'd result in people going "we need to do something about this immediately, now now nownow" and when that initial rush of panic produces a slight majority in an RFC or something, demanding it be closed immediately because it's an emergency. Part of the reason RFCs generally run longer isprecisely because of that risk; if someone believes an emergency is so compelling that it requires immediate action, they need to convince the community thoroughly enough to allow for aWP:SNOW closure, or escalate to the WMF or ArbCom, whose role in such decisions partially exists for emergency snap decisions. --Aquillion (talk)19:34, 11 February 2026 (UTC)[reply]
The arguments on both sides are quite clear and I don't think anything will change other than the numbers. Consensus can be evaluated based on the relative strength of arguments at any time.voorts (talk/contributions)19:38, 11 February 2026 (UTC)[reply]
I fully back a quicker close than usual for two reason.
First off, this is quite a unique situation in that one of the options in the RfC quite clearly would suggest that action should be taken immediately. If there is a consensus that a site should be blacklisted because it's actively harmful then it doesn't really make sense to think that consensus would also be for addressing it now rather than waiting a month while the harmful links remain active.
Second off, the first point obviously hinges on consensus being able to be established already, but I think it can be considering the amount of attention this RfC has gotten and the extensive discussions had. We have the 30-day period to try to not leave out useful discussion and/or arguments (not to allow for more people to "vote",WP:NOTAVOTE), but in this case, as voorts pointed out, I think the arguments for each option have already been developed into quite solid forms. I think a closer has more than enough material to weigh the arguments for each option and establish consensus. --Maltazarian (talk)01:19, 12 February 2026 (UTC)[reply]
It doesn't really look like there's any consensus at all, though? Let aloneWP:SNOW consensus. It's also an evolving situation -- it looks like the WMF is currently deciding whether to take hard action, for one -- and people's opinions may change. (Personally I've done almost a complete 180 on this.)Gnomingstuff (talk)04:24, 13 February 2026 (UTC)[reply]
Agree with @Gnomingstuff that it seems tough to pull consensus out of the discussion so far. I know it's not a vote, but just by numbers, I'm seeing a close to even split between A, B, and C. I haven't participated in many RFCs, but I'm wondering if we could reach consensus faster by proposing a revised set of options oriented around minimum viable near-term action, and asking people to give their input again. Something like this, with the assumption that in either case we would continue policy discussions, analysis, and tool-building:
Option Y: Hide archive.today links from reader view. (Display change only. No direct changes to article content; no changes to editor mode. Reversible.)
Option Z: Continue to show archive.today links in reader view. (Status quo.)
Actually, since a discussion about a new set of options is not likely to be feasible, I'll make this alternate suggestion: based on the arguments I'm seeing, "Hide archive.today links from reader view." seems like a potential reasonable compromise position. It would minimize our continued participation in the DDoS, without causing disruption for editors who rely on it to verify information. It would buy us time to build tools and campaigns to remove unnecessary archive.today links (lots of them are pre-emptive archives of live pages -WP:EARLYARCHIVE) and replace necessary ones.Dreamyshade (talk)05:20, 13 February 2026 (UTC)[reply]
Not only are Cloudflare DNS users unable to use the service, they are also blocked by having the completed CAPTCHA page take them straight-up back to the CAPTCHA page; they are ad infinitum stuck executing the DDoS code on the CAPTCHA page. I'm not sure if they're still blocked but that was how it was.Aaron Liu (talk)01:52, 12 February 2026 (UTC)[reply]
The situation is better summarised in our articles. Archive.today demands Cloudflare does something which is not required. Archive.today may have reasons for wanting this but Cloudflare has reasons for not wanting to do this. In the end, archive.today chose to block all users of Cloudflare because they refused to do something which is not required. Saying it's Cloudflare fault (implying it's predominant their fault) is just silly.Nil Einne (talk)12:00, 12 February 2026 (UTC)[reply]
While not directly related to Cloudflare, I might as well mention this here since don't think it's worth starting a new thread. Per this blog post[17] Archive.is blocks the Condé Nast office IP I think due to their republishing of the blog post that caused the DDoS. And also the entirety of Cyprus because the Tumblr writer, I assume the owner of archive.is doesn't like the large number of people with alleged questionable backgrounds allowed in to it. Are there more who are blocked who we don't know about? While the author of the Tumblr is right that various websites block various things, notably many US news websites started to block the EU due to the right to be forgotten or GDPR or other laws, this sort of weird ad-hoc blocking does IMO raise additional concerns about the utility of archive.is even if it pales in comparison to the DDoS issue.Nil Einne (talk)14:21, 12 February 2026 (UTC)[reply]
A trusted third party tool could serve as a middle man that fetches the content from archive.today, strips all JavaScript or other malware (neutralizing the DDoS and other threats), and serves a flat HTML version to the reader.
This would preserve the verifiability while eliminating the security risk. It would require concession from Archive.today (so the proxy is not blocked). It would provide Wikipedia agency and safety. --GreenC08:35, 12 February 2026 (UTC)[reply]
I doubt archive.today's owner would allow such a service, so can you bypass reCAPTCHA/do you have enough money to pay for residential proxies? Because apparently archive.today blocks known proxy IPs from visiting the site without completing the captcha.sapphaline (talk)09:06, 12 February 2026 (UTC)[reply]
This could work, but some thoughts:
This still requires some degree of trust from the archive.today operator, which we currently do not have.
Hosting the website might be a task better suited to the Wikimedia Foundation rather than a third party.
Echoing sapphaline's point about the fact that the problem is with the CAPTCHA page. It would either have to be sanitized carefully, so as to not leave it non-functional, or somehow automatically bypassed. Bypassing the CAPTCHA page feels like we would just be countering abuse with abuse to me.
I'd like to just caution against taking action that might be viewed as antagonistic by the site owners without really thinking it through first. These folks don't seem like the most level-headed people. --Maltazarian (talk)10:11, 12 February 2026 (UTC)[reply]
I think one of the reasons archive.today is used on Wikipedia is because it supports "Javascript heavy" websites, which I assume something which strips JavaScript may render those sources non-functional.Mitchsavl (talk)10:06, 12 February 2026 (UTC)[reply]
To respond to points: this could be hosted on Toolforge and operate as an open-source project on GitHub available to multiple maintainers with a corresponding project page on Enwiki or Metawiki to report issues/discussions etc.. a full "Wikipedia-way" open-source project based on consensus. The "Stripping JS" means "strip out the bad parts", which is perfectly doable without harming the page. If Archive.today agreed to it, there would be no captchas - they disable captcha for that proxy server IP or some secret key. There's actually very little trust required because Wikipedia has full control of the final render - mostly it would be AT trusting Wikipedia. As for Archive.today would they even do it? I think there is a good chance. I don't think they fully appreciated what they did and the consequences and they may seize on a technical solution. --GreenC17:29, 12 February 2026 (UTC)[reply]
However we deal with the current situation, what are the plans for the future so that we don't have to face a similar situation? I've also created aseperate discussion if this is not relevant here. What are the difficulties of using anIPFS (or some equivalent of it) based solution? Are there better solutions?Smlckz (talk)11:59, 12 February 2026 (UTC)[reply]
The RFC claims thatthe 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. This is basically echoing the claims of Gyrovague, which is a party to the dispute. First, Archive.today isn't "injecting" anything. "Injecting code" normally refers to 3rd party attacks such as SQL injection or Cross-Site Scripting (XSS). There is no 3rd party injecting code into Archive.today. The code was put there on purpose, not injected. Calling it "injected" makes it sound a lot scarier than it is and like it is a security risk for visitors, which it isn't. Second, this is probably not an effective strategy for an actual DDOS attack. Unless Gyrovague is running off a home server, or Archive.today becomes a lot more popular than it currently is, this is unlikely to ever take Gyrovague offline, and I haven't seen any claims that it actually has. The original description of the attack on Y Combinator called it "DDOS-like" which is much more accurate. From statements given by the Archive.today webmaster, it seems their intention was not to take Gyrovague offline, but to "make it a bit more expensive" for them to doxx him.[18] The wording in the RFC is overblown and not neutral, IMO. Yes Archive.today is attacking Gyrovague, but that attack isn't a security risk for our users, nor would I even call it a real DDOS attack. It may be moot at this point, but can we change the wording to be more accurate and less fear-mongering? It seems that a lot of folks votes are based on the incorrect assumption that this is an actual security risk for Wikipedia users, which it isn't.Nosferattus (talk)18:21, 12 February 2026 (UTC)[reply]
If a find/replace to change "inject" to "insert" (which function in everyday conversations as near synonyms) would address this biased wording, I disagree there's actually any problem here. But if we're being sticklers for jargon, yes, directing second party web traffic to a third party domain en masse in order to harm that site is a "real DDoS", even if it's not as effective as other approaches. Aiming to make hosting more costly has historically often been a goal of a DDoS, and it can be very effective when targeting an individual person's website. —Rhododendritestalk \\19:03, 12 February 2026 (UTC)[reply]
That's a fair point, but I stand by my opinion that using the term "inject" is misleading and makes it sound like a much more serious security concern than it actually is.Nosferattus (talk)19:15, 12 February 2026 (UTC)[reply]
Running malware on my computer is absolutely a security risk. I certainly don't want someone to use my resources to attack another person. Best,HouseBlaster (talk • he/they)20:48, 12 February 2026 (UTC)[reply]
DDoS attacks do not need to take the target offline. They just have to happen. Reliable sources like Ars agree with us that this is a DDoS attack.Aaron Liu (talk)23:35, 12 February 2026 (UTC)[reply]
If you think there is no security risk to Wikipedia readers, then you are free to raise that point in the survey. Some editors, however, disagree.
Per CWL: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 would argue that being made part of a malicious botnet is a breach of security, no matter who the target of the malice is.
The operator of archive.today has demonstrated they are willing to use their web service for malicious purposes. Having external links to a service which is untrustworthy like that is, potentially, a security risk.
I don't see anything in the RfC that states as a matter of fact that there is a security risk, only that there are concerns of a security risk. I personally find the assertion that these concerns have been raised to be factual and neutral.MEN KISSING(she/they)T -C -Email me!04:21, 13 February 2026 (UTC)[reply]
Yes. If the OP is fine being part of an attempted DDoS that's up to them. Many people are not though. And for many it's not even due to any fear of possible ramifications simply that they find it highly unethical or immoral to be part of something like that. As for the security issue, there's a much wider issue there in that someone willing to engage in such highly unethical conduct cannot be trusted and might very well so something worse in the future.Nil Einne (talk)11:29, 13 February 2026 (UTC)[reply]
A distributed denial-of-service attack occurs when multiple systems flood the bandwidth or resources of a targeted system [...] Most of the time, attackers operate from an endpoint that is not their intended target, for example using another user's machine to attack a server.
No, it isn't. The argumentation here is a fallacy, selective reasoning, reads almost like the sort "every dog is a mammal, let's turn it around: then every mammal is a dog". The text picked from the Wikipedia article is extremely selective and not a good representation of the topic. It's cherry picking, by (relatively) random scraping some text from the article, instead of using the definition. The definition fromthe article:
"to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to a network. Denial of service is typically accomplished by flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled."
The goal is not to make the blog unavailable, nor does it have such an effect. There is no disrupting of the service, and the blog is not overloaded.
Framing this situation as a DDoS violates our core principles that Wikipedia stands for the facts. We should not set aside the facts to support our opinion. (It is a bad thing that the blog is accessed, without the control of the users, but adjusting the facts makes Wikipedia untrustworthy.)Romaine (talk)14:35, 16 February 2026 (UTC)[reply]
I would trust the judgement of someone whom the WMF has vetted to lead its security department,Eric Mill.
As I understand, the attack targets one particular site. Wouldn't it be wise for the gyrovague.com's owner to add aDDoS protection to his site, like multiple sites do? In that case accessing Archive.is would be more ethically safe and the issue would be mitigated at minimum or resolved at maximum.Brandmeistertalk10:52, 14 February 2026 (UTC)[reply]
The main issue here is readers safety: what if archive.today decides to add a cryptominer tomorrow to their site and Wikipedia has half a million references pointing there?Oakchris1955 (talk)11:35, 14 February 2026 (UTC)[reply]
No, nobody is saying it's "fine". (Almost?) everybody agrees that there are benefits to using archive.today, (almost?) everybody also agrees that there are harms to using archive.today, there is just disagreement on whether the benefits outweigh the harms or vice versa.Thryduulf (talk)12:24, 14 February 2026 (UTC)[reply]
@Brandmeister, "fool me twice, shame on me" is an argument for dumping the person who fooled you the first time before they have an opportunity to fool you a second time. You seem to be arguing for a "fool me three times before I'll protect myself" position: They unethically spammed us years ago, and we forgave them. They unethically use their readers' web connections to attack a blog, and you want to forgive them again. You seem to be arguing that only after they show their willingness to behave unethically towards us and our readersthree times should we discourage use of the website. And I wonder: when that third time happens, will you be saying "But the first one was a long time ago, so let's forgive them again and wait for afourth problem before we believe that they are willing to repeatedly engage in unethical actions"?
Did they earlier? I wasn't aware of their spamming before this DDoS attack, perhaps this was noted somewhere outside my visiting areas, that's why I wrote about fooling once and taking steps about fooling twice. Having occasionally used Archive.today as alternative to WayBack Machine, I haven't spotted odd activity.Brandmeistertalk09:11, 15 February 2026 (UTC)[reply]
The attacked site wasn't affected much because its webhost does have DDoS protection. The problem is that Archive.today is willing to abuse user resources to attempt such attacks and execute malicious code without user knowledge (try metering the Archive.today CAPTCHA on cellular data), and they have absolutely refused to back down. They could target those that don't have DDoS protection. I don't like the implication that Archive.today should have the power and our assistance to DDoS whatever site it pleases.Aaron Liu (talk)16:52, 14 February 2026 (UTC)[reply]
PerWP:PAYWALL, which is part of [[WP:VERIFIABILITY] and is probably thus considered a Wikipedia policy:
Do not reject reliable sources just because they are difficult or costly to access
Paywalls probably don't make links more likely to die, they may even make it less likely if they reduce the chance a site will die by giving them more of an income. However they make archival more difficult especially for sites like the Internet Archive less willing to do things to enable them to access and archive paywalled content. So they make it more likely we won't have an archive of the link does die.Nil Einne (talk)15:15, 15 February 2026 (UTC)[reply]
I have noticed the discussion to phasing out archive.today links. If Wikipedia ever follows through in phasing out the usage of archive.today links, what other alternative archiving site should editors utilize in reference citations? I know that the Internet Archive is one major archive site, but it is more harder to cache news articles with paywalls, such as the New York Times or the Atlantic. Any alternative to archive.today must be freely accessible to all Wikipedia users that wish to cite news articles in wiki pages at their pleasure.CastleFort1 (talk)16:34, 14 February 2026 (UTC)[reply]
Also, whether or not we remove or discourage archive.today links embedded in Wikipedia articles (the scope of the RfC), nothing stops an editor or reader from copying a URL and pasting it into archive.today to bypass a paywall and read the information. That's their own business, outside the scope of Wikipedia guidelines.Dreamyshade (talk)20:15, 14 February 2026 (UTC)[reply]
I agree with WhatamIdoing here. My concern is not so much large, august news organisations which realistically are never going to be lost (the New York Times will have archives both physically and digitally, and in my own experience as an Aus editor, while it might be annoying that paywalled NewsCorp papers aren't easily accessible, they are archived at places like the State Library of Victoria), but rather smaller sites which are digital-only, difficult to archive through the Internet Archive, and which could realistically be lost because of link rot. I have tried to useGhostArchive as an alternative.LivelyRatification (talk)21:53, 14 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]
Looking at all archive.today (including archive.is) links in mainspace only -
Out of 689,090 links, basically all - 686,434 - have a visible URL in the address (ie they're not just using the short format links)
There are a total of around 123,000 sites (ie distinct domains+subdomains part of the URL, omitting 'www.')
The most common is factfinder.census.gov (18,389) then webcitation.org (10,916)
The top 10 sites account for 70,000 links (10% of the total), the top 50 for 136,000 (20%), and the top 100 for 178,000 (26%)
705 sites appear 100 or more times, and cover 313,000 links - 45% of the total.
Granted some of those will be the difficult-to-archive domains, but there may be some that will be easier than others to switch to web.archive.org - eg I would hope the ~1500 theguardian.com pages would be straightforward, as AIUI it neither imposes a paywall nor regularly deletes old material.
The dates in the URLs - I think these indicate the date on which they were archived? - peak in 2012-13, with over 50% of links apparently from those years (350k links). It falls off sharply to a low in 2016-19 with around 10k links per year, then from 2020 onwards it's between around 25-45k per year. (It may be relevant that the Rlink2 bot started operating in late 2021)
Finally, as noted above there are about 363,600 source pages, so averaging about two archive.today links each. 115 pages have 100x or more archive.today links, and 6,685 pages have 10x or more, but generally they're very widely spread out.Andrew Gray (talk)22:00, 12 February 2026 (UTC)[reply]
Thanks, this is interesting! Curious how many of the citations that include archive.today/archive.is URLs also include the URL status attribute, and among them, how many are listed as "live" vs "dead"? The URL status attribute is not entirely reliable, of course, but that might help estimate how many of our archive.today URLs are pre-emptive archives (WP:EARLYARCHIVE) that we could auto-hide or auto-remove with minimal impact on verifiability.Dreamyshade (talk)22:41, 12 February 2026 (UTC)[reply]
I think that is a bit beyond me, I'm afraid - I'm purely working from the database link tables here, so I can tell the link's on the page but not the context of the template. I think @GreenC might possibly have some sense of how many are currently live from their bot work, though?Andrew Gray (talk)22:59, 12 February 2026 (UTC)[reply]
factfinder.census.gov (18,389) is largely unavailable at Wayback - which mostly has soft-404 versions. The webcitation.org (10,916) are actually more secure at Archive.today then at WebCite itself, which recently had a 2-year (!) outage - this is another can of worms. You know the 80/20 rule - 80% are easy 20% are hard. The Archive.today archives are often in that 20% bucket because there were no better options, why they ended up there. Not all, but many. I know this because I did a lot of it myself via bot and saw it first hand. Archive.today continually came through where others were unable. Dreamyshade's solution (below) to find totally different source URLs is commendable but does not scale it's not practical for these numbers. --GreenC04:42, 13 February 2026 (UTC)[reply]
I checked three random articles that cite archive.today versions of factfinder.census.gov, and I believe we could automatically or semi-automatically replace most of those archive.today URLs with liveand much more useful links to the same information on data.census.gov. See details atUser:Dreamyshade/Archive links.
In general, I believe we could pull off mass-scale replacement by finding patterns using data analysis and small-scale hand-crafted archive replacement exercises, then implementing the patterns in automated replacement bots (supervised by people) and semi-automated tools for human editors (such as integrating suggestions intoVisualEditor Suggestion Mode). The main strategy would be writing regexes and other ordinary algorithms for straightforward patterns, but for the trickier patterns, I suspect that carefully prompting LLMs with human-observed patterns could speed up retrieving viable replacement links (live or on archive.org) for editor review/approval. Would be great to do that in a tool along the lines ofMontage - a pretty fun web app for judging Wiki Loves Monuments photos, designed to help jury members make thousands of photo quality decisions quickly. (Not suggesting adding this functionality to Montage, just using it as inspiration.)Dreamyshade (talk)22:00, 14 February 2026 (UTC)[reply]
Just for completeness, I've also pulled down and had a look at the 15.2m web.archive.org links - again, almost all seem to have an identifiable date. These dates refer to the timestamp presented by the web archive, not when they were added to articles, but of course it's reasonable to assume they are usually quite close together.
There is a brief period around 2012-13 where a significant fraction of archive links go to archive.today (21% in 2013) but it is not until 2024 that they again make up more than 5% of the archive links - 6.5% in 2024, 12.5% in 2025, and 27% in 2026 (of course that will be a bit of an anomaly given it's only part-way into the year, but on current form it would not be surprising for it to be above 2025 numbers).
My assumption is that the recent higher share is down to an increase in the number of sites that archive.org can't handle (as GreenC notes above), and it does seem to suggest that blocking it will be an increasing problem going forward. On the other hand, I was a bit surprised to see the very high share of 2012-13 sites, and I wonder if those might have a better chance of being replaced with archive.org links than the more recent ones.Andrew Gray (talk)13:51, 15 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[39]; 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 haverequested a bot to fix the remainderThryduulf (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 aboutFranck 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.[40] This out says pretty much exactly what the article says.[41] 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 doesnot 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:
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[42] 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 onQuentin 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[43], 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 ofB 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 toWikipedia: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 screamWP: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 forSamejima 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 findwith 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 optionB, 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 atotal 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 thecore 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 canfind a source. It does not mean that there is a source alreadyWP: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 andWP: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]
Hello, thought of chiming in more for some specific contexts, particularly for Singapore-related articles.
I personally use archive.today quite a lot, especially for sites where the Internet Archive failed to capture. We also have the Web Archive Singapore, but that also loads very slowly and there have been instances when even archived versions were taken down (a rather fragile archive, in short). ForEsplanade MRT station, here are a few examples:
The Straits Times, Singapore's major newspaper, seems to be blocking attempts at archiving by IA, especially forthis article whennewer archives failed to capture.
Personally I'm more concerned for the deprecation of archive.today for captured WAB sites. If we are to proceed with Option A or B (and there seems to be an inclination to these options in this RfC), I rather if we first have an in-house archiving site before we start deprecating archive.today.--ZKang123 (talk·contribs)01:39, 11 February 2026 (UTC)[reply]
The following analysis is not statistically significant because it's scoped to articles in my current area of interest, but sharing my notes atUser:Dreamyshade/Archive links in case helpful. Method:search for insource:"archive.today" privacy and work through the results in order. Summary of what I've found after removing 25 citations involving archive.today in 13 articles:
13 citations included a live original URL, so I removed the archive URL
12 citations - original URL was dead, or citation only included the archive URL (no original URL within the citation)
8 - replaced with a live link to the original article at a different URL, found by searching the web for the article title
2 - replaced with better citations because the citations were weak
2 - removed claim and citation because both were weak
The good news is that a lot of the archive links weren't necessary, and nothing was irreplaceable in this set. I was surprised to find a couple citations where theonly URL in the citation was an archive.today URL.Dreamyshade (talk)00:26, 12 February 2026 (UTC)[reply]
If I were you, I'd prefer article links always archived and included in articles. For one thing, this helps verifiability if the link goes dead. The other problem it avoids is that if the webpage changes for whatever reason, we cannot blame the editor for improper editing at the time of writing. It may be outdated info, but outdated info is better than having sources that supposedly "support" the text but in reality don't.
In an ideal world IABot or archive.today bot could run articles every month or so, unless the editing is very lively in the article, so that we never have to bother about link rot. (I hope that whoever would be behind the second bot wouldn't have the in-built DDoS functionality).Szmenderowiecki (talk ·contribs)16:16, 14 February 2026 (UTC)[reply]
Yes, I support the concept of pre-emptive archiving in general. Specifically for links that are currently live and pre-emptively archived to archive.today, I believe that it’s appropriate to remove those archive.today links, because the harm to verifiability is relatively small. Ideal would be to replace them with pre-emptive archive.org links automatically, but that may not be feasible.Dreamyshade (talk)17:28, 14 February 2026 (UTC)[reply]
Please do not remove archive URLs unless you replace them with other archive URLs. Your own numbers show that eventually the links will be dead, as per standardlink rot lifecycle.Nemo09:55, 16 February 2026 (UTC)[reply]
Done.Chess enjoyer (talk)05:14, 10 February 2026 (UTC)[reply]
MEN KISSING(she/they)T -C -Email me!02:05, 9 February 2026 (UTC)[reply]
