Topic on Talk:Requests for comment/Content-Security-Policy

In fawiki we have many gadgets which use wmflabs.org as a service and for all of these gadgets browser shows similar to this error. how can i solve it in our codes (javascript/python)?

load.php?lang=fa&modules=startup&only=scripts&raw=1&skin=vector:11 [Report Only] Refused to load the script 'https://labels.wmflabs.org/gadget/loader.js' because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self' meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikivoyage.org *.mediawiki.org 'unsafe-inline'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

for example this gadget

You should file a bug with the ORES people (If its an officially supported api, it probably is not supposed to be run on toolforge cloud VPS). There's not much you can do yourself at this time.

So far this error is just a warning. We will have a better system in place prior to this warning becoming an error. (e.g. a way for specific gadgets to opt out. Ideally the labels service would be moved into production). This may take a while, so for now you can just ignore the warning.

@Halfak (WMF) potentially interesting discussion for you to join here. Both @Yamaha5 and @Bawolff have confused labels.wmflabs.org for tools.wmflabs.org, but I believe the intent of the RFC is the same for either: eventually blocking js loading from Cloud VPS projects by on-wiki scripts.

Yes indeed. My apologies for conflating the two.

Ideally JS would never be loaded from something off production. The last plan I heard, Other data loads from non-production sources would be ok if the user opt-ed in to it - but nonetheless ideally that would not be used for anything maintained "officially" by WMF (not sure how "official" labels is supposed to be).

p.s. I should note, I no longer work for WMF and aren't working on this. This is just where things stood at the time I left.

@BDavis (WMF) Most of these gadgets worked for years and trusted. We should have a local whitelist to make a decision locally.

@Yamaha5 That is a fair argument to make to the folks in Wikimedia Security Team or whomever is currently working on this RFC's implementation. I believe that the intent of phab:T208188 is to allow such exceptions on a case by case basis.

Hey folks. We stopped recommend people load our JS from labels.wmflabs.org in mediawiki a while back. But we never disabled that functionality. I think it would be a fine idea to replace that Javascript with something that would direct people to do their labeling work on https://labels.wmflabs.org/ui/

@Halfak (WMF): That bot's concept is completely different from Lables.wmflabs. it checks miss-spelling or typos and some other problems in an article like this tool. Also we have other tools which are run based on the tools.wmflabs like move a list of cats and edit all their pages or adding category to articles based on the en.wiki's categories.

Oh yeah. I was only commenting WRT the use of labels.wmflabs.org JS as cross-site inclusion.

This is definitely a good idea, and even coming too late imo. But, carrying this thread on, I'd like to see *.toolforge.org and *.wmflabs.org added to the CSP directive on WMF wikis - having this as an option would be a huge plus for tools like mine (RedWarn) which use libraries not included in MediaWiki itself through toolforge CDN proxies.