Closed
Bug 669714
Opened 14 years ago
Closed 14 years ago
Change $wgAllowExternalImage value to "true" on wiki.mo?
Categories
(Security Assurance :: General, task)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: deb, Unassigned)
Details
I've had a few requests from people that we enable external images on wiki.mo to simplify the process of adding images (mockups etc) to feature pages.
It turns out that this is a simple configuration change, and doesn't require any new add-ons or anything: http://www.mediawiki.org/wiki/Manual:$wgAllowImageTag
| Reporter | ||
Comment 1•14 years ago
|
||
I totally picked the wrong property to change, I mean this:
http://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages
Sorry!
| Reporter | ||
Updated•14 years ago
|
Summary: Change $wgAllowImageTag value to "true" on wiki.mo? → Change $wgAllowExternalImage value to "true" on wiki.mo?
Comment 2•14 years ago
|
||
Although it would definitely be handy, I am inclined not to change this for a number of reasons. Below is my reasoning, but before I WONTFIX this I'm going to reassign to cshields for any additional comment. I don't like to just say "no", so I'm seeking additional input. :)
The way we have it set now is the default MediaWiki setting. On reading that link, it seems there are good reasons for doing it this way.
In short, linking to external images means we give up some control of our site, and put it in the hands of whomever we link to. This could be fine most of the time, but it's ripe for abuse. Those 3rd parties could have very different security/tracking policies than us, or could resent the bandwidth we're "stealing" from them, or could otherwise affect the display of wiki.mozilla.org (accidentally or intentionally).
In long, here are some of the reasons for not allowing external images:
1) To prevent malicious gathering of browser data. If we link to external images, the remote site will more or less get a profile of all of the folks visiting our site. We don't know what their security policies are like, so this could be considered a violation of our own security policies.
2) Allowing external content means someone else has some measure of control over how wiki.mozilla.org is displayed. This could be used maliciously (link to virus-infected images) or "retributionally" (as in, "you guys hot link my image and run up my bandwidth bill, I change it to something horrific and obscene"). This could be used almost invisibly too, by simply uploading a 1-pixel tracking image or something. wiki.mozilla.org is public... anyone can make an account.
3) To prevent Mozilla from being accused of "Bandwidth Theft". If we link to an image on someone else's site, *they* end up footing the bill for the bandwidth used. I don't know about legal repercussions, but there are certainly ethical ones. :)
4) To prevent "link rot", where previously working images later stop working or get changed out from under us.
5) To eliminate problems where the 3rd party host is maybe very slow some days, or inconsistently available, or blocked for some people. If it's all locally-hosted, the performance can be more consistent.
6) wiki.mozilla.org is an SSL site. If we allow external images, those may not be served over SSL, which would result in "mixed mode" warnings on pages.
Assignee: server-ops → cshields
Comment 3•14 years ago
|
||
pulling in infrasec.. I know we don't need their approval on every change but this is one I would not want to do without their okay. But my own preference is right in line with Jake's reasoning above.
Comment 4•14 years ago
|
||
I understand the concerns and would welcome alternative solutions (if there are any) that don't have these shortcomings.
I was one of the people who requested this, so I can explain my motives. We're using wiki.mo to build out feature pages for upcoming work. "A picture is worth 1000 words", as they say, so I want to be able to incorporate plenty of ideas and mockups in picture form into these feature pages. If you try the workflow for uploading an image to mediawiki and then incorporating it into the page, you will find that it hurts, from both a speed and workflow perspective.
The change proposed here would allow me to upload images to, for example, people.mozilla.com and incorporate those into the feature pages. If we had a way to limit external images to that site (which from a quick googling doesn't seem to sound immediately possible), that would actually eliminate nearly all of the concerns cited in comment 1.
There's a moderately better workflow laid out here:
http://henrik.nyh.se/2007/09/mediawiki-image-upload-tip
but it's still going to be slow going. There is a MultiUpload extension:
http://www.mediawiki.org/wiki/Extension:MultiUpload
There's also a Flickr extension which might be better than allowing unfettered image access for the entire internet:
http://www.mediawiki.org/wiki/Extension:Flickr
My main point here is to make clear that the pain point is getting images into pages on wiki.mo.
Updated•14 years ago
|
Assignee: cshields → server-ops
Component: Server Operations → Server Operations: Security
QA Contact: mrz → mcoates
Comment 5•14 years ago
|
||
The security concerns laid out in comment 2 are spot on. We really can't move to a model with external images because of those concerns.
Unfortunately, there also isn't a good way to selectively allow external image locations short of designing our own upload form.
For the purpose of this specific bug request, I also agree on WONTFIX.
To address your overall difficulty:
Perhaps we can look at addressing this specific solution by doing some sort of bulk upload that we coordinate with IT. This is only possible if mediawiki allows images to be placed into a directory and does not require specific database changes during upload. If this works you could then directly link to the filenames right from your wiki articles since the images would already be present.
Comment 6•14 years ago
|
||
Marking this WONTFIX, based on comment #2, #3 and #5.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Comment 7•14 years ago
|
||
OK, I understand the concerns.
The MultiUpload extension may help somewhat, but it's not a huge win.
Updated•13 years ago
|
Component: Server Operations: Security → Security Assurance: Operations
Updated•10 years ago
|
Component: Operations Security (OpSec): General → General
Product: mozilla.org → Enterprise Information Security
You need to log in
before you can comment on or make changes to this bug.
Description
•