gerritadmin wrote:

Change 171545 had a related patch set uploaded by Glaisher:
Set iw_local to 1 for tools.wmflabs.org

https://gerrit.wikimedia.org/r/171545

Change 171545 had a related patch set uploaded (by Glaisher):
Set iw_local to 1 for tools.wmflabs.org

https://gerrit.wikimedia.org/r/171545

Patch-For-Review

@csteipp, @LuisV_WMF: I've opposed the patch for the time being, pending confirmation from your sides about my concerns.

I don't think we can allow urls with a 'en.wikipedia.org' hostname (e.g. https://en.wikipedia.org/something...) to directly hit Tool Labs services (which have full access logs, readable by anyone in the world). That would pose privacy policy violations I believe.

It would also pose security hazards, or at least make other exploits significantly more dangerous as an attacker would be able to lead large amounts of traffic to it.

This concern doesn't apply to (existing) external links, as those have to be clicked on by the user. Which is a significant barrier. it also doesn't apply to wiki administrators being able to use javascript to do anything they want, as that's a restricted user group (whereas anyone in the world can become a Tool Labs author).

@coren should confirm, but my understanding is that Labs is behind a proxy so that this sort of logging is not possible.

@LuisV_WMF It is indeed behind a proxy, which strips (only) the requesting user's IP address. That's quite good. The User-Agent string and Referer url are still exposed, though (Contains wiki domain and page title that the user was viewing.) But I'm not worried about those, as long as its only via gadgets and external links.

Granting toollabs the iw_local flag would result cause https://en.wikipedia.org urls (e.g. https://en.wikipedia.org/wiki/toollabs:example) – without any user interaction – to redirect to a Tool Labs program. Which can generate a user interface that impersonates Wikipedia. In fact, without malicious intent, it's quite common for tool authors to mimic Wikipedia styles for a sense of familiarity. Aside from Tool Labs being open for registration, tools' program code are also not publicly visible for review. Unlike Gadgets and site scripts, which are publicly indexed and more visible in Recent changes and Watchlist feeds (malicious code wouldn't survive long, and besides, they require administrator access to insert).

It worries me that we could be hosting bad stuff this way from our trusted domains with no feasible way of even finding out (short of manually looking through Tool Labs server files). Having said that, it's not up to me. I'm raising a concern to ensure that, if we're going ahead, we know the angles.

Ah, I see what you mean! Yes, I agree that labs should not get iw_local for right now; possibly that's something to revisit in the future but for now, if anything, we'd talked about making it *more* clear that you were leaving the site, not less clear.

Change 171545 abandoned by Glaisher:
Set iw_local to 1 for tools.wmflabs.org

Reason:
per issues raised in the task

https://gerrit.wikimedia.org/r/171545

@Patrick87 wrote:

As an official Wikimedia project Tool Labs should be treated as a local Wiki, e.g. it should be flagged as "local" in the interwiki table.

I think it's more like Wikimedia Labs is the official Wikimedia project and Tool Labs is a subset of Wikimedia Labs.

iw_local is kind of a goofy flag. Looking at https://en.wikipedia.org/wiki/Special:Interwiki, iw_local = 1 is only used for Wikimedia wikis and other "trusted" domains.

A major reason for using wmflabs.org was to have a segregated namespace that would be treated as untrusted, as I understand it. (Perhaps iw_local is closer to iw_trusted.) Because wmflabs.org is untrusted, automatically redirecting user traffic to it via a trusted domain such as en.wikipedia.org probably isn't the best idea, as @Krinkle notes.

I agree; the contents served from Labs is entirely user-generated and the potential for confusion is too high for iw_local=1.