Good suggestion... But: there are 700-800 projects. If the WMF would register this domain, then they probably should do the same for dewikipedia.org, frwikipedia.org etc. I'm not sure we could ask that from them...

Per the point that @Trijnstel has pointed out, it's not a wise thing going for because of all the projects and language variants we have.

In additional there is also the costs of the security certificates to consider as well since they won't be covered by the current one.

I know from the other domains that have been inherited or trademark recoveries (Squatters) that @Dzahn has preferred to mark them as "parked" compared to actually routing though to the project.

This task is about registering nlwikipedia.org, not about 700 other projects. That's a slippery slope argument and incorrect. Because we register nlwikipedia.org, that doesn't mean we have to register any other domains. No causality here.

If the other domains are not registered, why should nlwikipedia.org be?

There's no direct causality, but we should at least strive to do whatever we do for rational, consistent reasons. If the reasons for registering nlwikipedia.org are the same reasons for doing the same for all the other languages, then we can't rationally and consistently say yes to this one and then say no to the next one. The pattern just goes on until we've processed 700-800 such phab tickets and registered them all.

You could make the argument that we should do the first few and not adopt a defensive strategy until/unless a lot more such requests roll in and the problem of the scale of relatively-junk domains becomes an actual problem. But what's perhaps missing in the discussion on this particular ticket is that it already *is* such a problem. We've already started looking at that problem, too. Back in mid-2015, I filed T101048 about trying to sort out the mess of the ~150+ or so domainnames (most of which are very low traffic / junk names for squat/typo/etc) which are actually configured in our DNS servers. Later @Dzahn carried this further and found that the volume of junk domainnames we have registered at registrars (but not necessarily configured in our DNS servers) is actually much higher.

We have over 600 domainnames already registered to us, and we're actively going through a slow and painful process now of sorting through them and making policy decisions about them all. Some we may keep the registration but not put in DNS at all, some may stay in DNS but not resolve to an IP for browser traffic, some may resolve to an IP that's just a parking/deadend HTTP service, and some very few may actually get to be redirects to the relevant canonical, real project domainnames.

The latter category (functional redirects) is what most people want for whichever of all of these junk domainnames is important to them personally, but we simply can't do that for all of them, or even anywhere near most of them. The reasons why tie back to HTTPS (insecure redirects are holes, secure redirects require certs/SANs), IP address allocation, SNI support, and/or other general techops maintenance-burden / tech-debt. It's in the light of all of the above that you're going to tend to find resistance to redirecting, and in some cases even registering, all of these junk domainnames.

The reality of typo-squatting concerns today, IMHO, is that few users actually type domainnames in URL bars anymore to begin with. Most traffic comes from search engines (including embedded in address bars) and links posted by others in social media which came from search engines. Search engines do a decent job of demoting typosquats over our legit domains. When you balance that against the Sisyphean task of trying to allocate or fight every potentially-confusing or typo-squatting domainname that could ever exist which might remotely be related to anything to do with our projects, it's just not worth the effort (again, especially in terms of ops' long-term implicit burden).

We could do this, but minus the redirect. That would mean nlwikipedia.org would simply be not found, like for example http://www.wikipedia.es/ but it would still be owned by WMF to protect it from getting squatted.

But to find out if we want to buy it for that reason only, please contact the legal team directly, since they have the budget for domains and usually decide what we register for these purposes like trademark protection.

Any news from legal?

Offtopic a little perhaps, but is anything being done wrt trademark violation of enwikipedia.org ? If wmf legal cant / wont take that domain to tribunals / courts, then this request for nlwp is very reasonable.

The slippery slope problem can be easily avoided in this case with rational criteria, like

• preventative registeration for projects based on number of pageviews , as a rough guide for the potential value for a squatter

• preventative registration when registrar or legal framework would make reclaiming squatted domain unduely difficult

Also locals should be able to act independently to protect the brand, without fear of wmf hitting them with trademark violation.

• create a process for locals to gift a domain to wmf, with a process in place to allow locals to continue to pay any fees if wmf doesnt feel it has ongoing value for trademark protection reasons, or return to domain to the gifter.

In T128968#2216661, @jayvdb wrote:

Offtopic a little perhaps, but is anything being done wrt trademark violation of enwikipedia.org ? If wmf legal cant / wont take that domain to tribunals / courts, then this request for nlwp is very reasonable.
…

That is offtopic for this task, Please file a seperate task

In T128968#2216663, @Peachey88 wrote:

That is offtopic for this task, Please file a seperate task

This has been opened before as T93523 . It was then closed as Invalid with reason "tracked on our internal trademark question queue.". How's that queue?

Note: the domain seems to be registered already. But all I get is MacKeeper shit...

Yep, looks like it's already gone. , registered to a Mr. Gerbert in London.

I cant see T93523. It is private? Can it be made public, or should we recreate a new task about that problem.

Yes, it has a custom policy. It has been created by @Glaisher. I modified the custom policies by adding your user manually. Try again now?

Ok. Can someone please update the list of squatted domain list and close this task? We failed.

Which list of squatted domains are you referring to?

http://internal.wikimedia.org/wiki/Squatted_Wikimedia_domains ? (I have no idea if it is still there, but that is where it used to be)

Oh, internal.wikimedia.org , i don't think i have access to that. But i asked on the staff channel if somebody can check it.

Correction, i do have access, just had to find it. The page is still there, but the last edit was in May 2013. So it's not really used (by legal ?) anymore it looks.

Added nevertheless : https://internal.wikimedia.org/w/index.php?title=Domain_names%2FSquatted_Wikimedia_domains&type=revision&diff=17196&oldid=17106

but as i said, first edit in about 3 years, so that is _really_ fwiw and you'd have to ask legal about current tracking.

Thanks for flagging this domain. We have internal tracking documents on the legal team, and I'll make sure nlwikipedia.org is on them. Since it seems that it's currently being used maliciously, it'll be at the top of our list for domain enforcement. If you encounter other domains that are misusing Wikimedia trademarks, please email legal-tm-vio@wikimedia.org.

As for preventative registration, there are too many potential domains for us to register them all, or even usefully define a high-risk and manageable subset. We can't even register all the variations on "Wikipedia" itself, let alone all the ways it can be combined with language codes. And with the ever-increasing number of gTLDs, the number of domains we'd have to register to get ahead of squatters is effectively infinite.