Will I as a gadget author have access to the violation reports for svwiki?

In T28508#4212646, @Nirmos wrote:

Will I as a gadget author have access to the violation reports for svwiki?

Not currently (As it may contain private data). We will need to find some way to get that info to gadget authors. The initial rollout will just change sources but still allow unsafe-inline, so it shouldn't affect too much.

@Bawolff I'd like to get svwiki in report-only mode. Should I start a discussion with the community about this now, or is it way too early?

In T28508#4669270, @Nirmos wrote:

@Bawolff I'd like to get svwiki in report-only mode. Should I start a discussion with the community about this now, or is it way too early?

Awesome. Thank you for volunteering. Actually do to certain circumstances, we are planning to expediate rolling out test mode to logged in users, so it should be happening for svwiki very soon.

See also T207900

I can't edit a certain page in ruwiki (https://ru.wikipedia.org/wiki/%D0%A1%D0%B1%D0%BE%D1%80%D0%BD%D0%B0%D1%8F_%D0%AF%D0%BF%D0%BE%D0%BD%D0%B8%D0%B8_%D0%BF%D0%BE_%D1%80%D0%B5%D0%B3%D0%B1%D0%B8-7 ) because of tons of errors related to Content Security Policy/CORS policy in browser console

I updated Chrome to version 70.0.3538.102 and this doesn't happen now.

@Bawolff where you see dl.metabar.com on my screenshots? I want to know what of my userscripts accesses this URL.

In T28508#4749602, @MaxBioHazard wrote:

I updated Chrome to version 70.0.3538.102 and this doesn't happen now.

@Bawolff where you see dl.metabar.com on my screenshots? I want to know what of my userscripts accesses this URL.

We record CSP reports. (Part of the reason we have csp in report only mode is to discover what would break if we turn it on). That was listed for your user in our csp reports database. I think that domain is associated with a browser plugin [maybe a yandex plugin] (some poorly written browser plugins are subject to the websites CSP policy, which really doesnt make sense) and not with a user script.

I don't have any Yandex plugin. I have only 4 enabled browser extensions: Google Translate, uBlock Origin, View Image (a small ext for Google Pictures) and a bypass of Russian state Internet censorship (https://chrome.google.com/webstore/detail/%D0%BE%D0%B1%D1%85%D0%BE%D0%B4-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BE%D0%BA-%D1%80%D1%83%D0%BD%D0%B5%D1%82%D0%B0/npgcnondjocldhldegnakemclmfkngch). Wiki[pm]edia is whitelisted in uBlock settings.

API returns warnings about Unrecognized parameters at Wikimedia Commons.

{"warnings":{"main":{"*":"Unrecognized parameters: {\"csp-report\":{\"blocked-uri\":\"https://tools_wmflabs_org/convert/svg2png_php\",\"document-uri\":\"https://commons_wikimedia_org/w/index_php?title, withJS."}},"cspreport":"success"}

The warning message indicates the title and withJS parameters are unknown?

In T28508#5001266, @Rillke wrote:

API returns warnings about Unrecognized parameters at Wikimedia Commons.

{"warnings":{"main":{"*":"Unrecognized parameters: {\"csp-report\":{\"blocked-uri\":\"https://tools_wmflabs_org/convert/svg2png_php\",\"document-uri\":\"https://commons_wikimedia_org/w/index_php?title, withJS."}},"cspreport":"success"}

The warning message indicates the title and withJS parameters are unknown?

See T208191. Its a known issue with HHVM. It might be fixed automatically as we move to php7 or I might write a work around patch. Note, even with the warnings, the cspreport should have been recorded just fine.

Is there a planned "target" CSP to which we should be working? Something like:

content-security-policy:
    default-src commons.wikimedia.org incubator.wikimedia.org meta.wikimedia.org login.wikimedia.org species.wikimedia.org wikimania.wikimedia.org *.wikipedia.org *.wiktionary.org *.wikisource.org *.wikibooks.org *.wikiversity.org *.wikiquote.org *.wikinews.org www.mediawiki.org www.wikidata.org *.wikivoyage.org blob: 'self';
    script-src www.mediawiki.org meta.wikimedia.org 'nonce-1234567890ABCDEF' 'strict-dynamic' 'unsafe-inline' 'self';
    style-src *.wikimedia.org 'unsafe-inline' 'self' data:;
    img-src  upload.wikimedia.org data:;
    media-src  upload.wikimedia.org;
    object-src 'none';
    base-uri 'self'

This will torpedo my gadget development workflow as documented here: https://en.wikisource.org/wiki/User:Inductiveload/Script_development

Having to save every edit to user JS (or CSS) on-wiki before you can see it (and also having to convince the Wiki and the browser to clear the cache) is incredibly painful.

If CSP is going to happen, would it be possible to allow users to opt-in to localhost in the CSP on a specific port:

• If the user's localhost is serving malicious JS on a specific port, the user is already out of luck, because an untrusted program is running on their machine already
• If the user's localhost is serving accidentally exploitable JS from some other application, the user won't be able to start their server on that port and will change the port or find the misbehaving application
• The user still won't be able to load malicious JS from other domains (except by proxying though localhost, which will only affect themselves, because 1) they have to opt-in in their account and 2) they have to be browsing from localhost)
• No one will be able to load malicious or privacy-breaching (cross-domain) JS for anyone else, even if other people load that user's userscripts that attempt to.
• Having this opt-in seriously reduces the surface of users who could even run into such events in the first place (probably 1 in a million readers of WMF wikis will enable this)

I think T208188: RFC: Partial opt-out method for Content security policy is probably what you're looking for.

From T208188 it's only about CSP for accessing data APIs, not JS:

The allowance is only for sending and receiving data. Not for importing executable JavaScript code.

While enWS does have several gadgets that make use of external APIs (in particular the IA data API), these can be proxied via Toolforge, so as long as that works, then it is a hassle/barrier to entry to the gadgets to but ultimately fine.

The comment above is about allowing the use of executable JS via something like mw.loader.load( 'https://localhost:12345/script.js' ); to avoid having to save a wiki page on every singe iteration and make sure caches for that JS are flushed (because you can serve with no-cache set, so it only keeps the local JS out of the cache, not everything on the page).