Why is "Instant Commons" disabled?

[valerio-bozzolan]

It would be amazing to enable this option in LocalSettings.php as default:

$wgUseInstantCommons = true;

In this way you can embed images from Wikimedia Commons, without uploading them on your wiki. Usually this configuration is safe for production and it's enabled as default in lot of public wikis (for example Wikipedia).

More info:

https://www.mediawiki.org/wiki/InstantCommons

For example, with this option, then in the wiki you can simply write:

[[File:Temppeliaukio Church.jpg]]

To immediately see this image without manually uploading it:

(Image of Temppeliaukio_Church from Matthew Duncan, CC BY-SA 3.0 https://creativecommons.org/licenses/by-sa/3.0, attraverso Wikimedia Commons)

That's nice! Isn't it? What do you think about this feature?

Thank you so much!

[ocdtrekkie]

So on Sandstorm, this simply won't work out of the box, we endeavor to block all outside server calls by default. For a server-side request, the app would need to code a Powerbox request, which wasn't possible when this app was originally ported, and we're moving towards blocking client-side loading of external resources without the user's authorization as well.

So blocking this on Sandstorm is an intentional choice, though it could be revisited in an updated package because more tooling around external resources is available now.

[valerio-bozzolan]

O.o

Ouch. Deadlock.

Thank you for this clarification.

[valerio-bozzolan]

I wonder if a quick and dirty solution could be introduced in Sandstorm as a simple allow-list.

Let's say, allow:

^https://commons.wikimedia.org/.+\.(jpe?g|png|svg|pdf)$

[ocdtrekkie]

So, the short answer is not really: Sandstorm doesn't actually allow apps to talk out to anything over HTTP/S. It's actually not that network traffic is so much blocked as it is all Cap'n Proto, and an app must request the ability to talk through Cap'n Proto to an outside resource through Sandstorm. That's on the server side.

On the client side, which may actually be what is used here, it might actually load currently, but will stop soon, as we are implementing a Content-Security-Policy that blocks remote content. However, when this goes in, we'll have a "allow remote images" setting, like many email clients present today.

Once that's implemented, it may be safe to permit this app to load content from Wikimedia, since it will be blocked until a user chooses otherwise. But the default should always be to block remote content unless the user chooses otherwise, as remote content loading can be a privacy leak. So the choice the app packager made here at the time was correct, and still is for the moment.

I think it's still probably preferable to avoid remote loading though, even once we can control it, because the cost of uploading content locally is trivial, and the risk of privacy abuse by bad actors is high.

[ocdtrekkie]

I am going to cc @zenhack here, in case he doesn't get notifications on this repo, as he may want to see this and/or correct me.

[valerio-bozzolan]

Question. Is this really a server-side call? From the DOM I just see an hotlink to Wikimedia Commons.

[ocdtrekkie]

This would be client-side loading. We don't block it at present for images, but we intend to block it in the future. The problem is that when you load data from an outside source, you reveal information about yourself to that other server. Sandstorm prefers a model where you only reveal yourself to Sandstorm, and then Sandstorm enables certain communications beyond that only when explicitly authorized by the user.

[zenhack]

...and to be more explicit, apps could use this to phone home, by e.g. leaking user data via parts of the URL they chose to refer to.

As @ocdtrekkie mentions, I have half a patch sitting around that's waiting for me to finish it that does some nonsense with CSP reporting to generate an email-client-like "show images" button. But the use case we have in mind is really for stuff like TTRSS where the images are truly loaded dynamically; for something where the user has to pick an image interactively anyway it's less obvious that it makes much sense.

But whether to enable this, with that in place, is a judgement call that I would ultimately be inclined to leave up to the app package maintainer.

...Which right now is no-one, since this package is currently unmaintained...