Server side flickr review
Open, LowPublic

Description

Verification of files should be on sever side and not client side (client side flick'r review can be faked).

(Blocker: This is needed to enable Flickr Upload for all users)

Steinsplitter updated the task description. (Show Details)
Steinsplitter raised the priority of this task from to Normal.
Steinsplitter added a project: UploadWizard.
Restricted Application added a project: Multimedia. · View Herald TranscriptFeb 10 2015, 1:55 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Tgr added a subscriber: Tgr.Feb 15 2015, 10:08 AM

(Blocker: This is needed to enable Flickr Upload for all users)

Why? UploadWizard does not do anything a user could not do manually. I can upload a hundred Flickr images manually right now, and probably forget to add the flickrreview template to them or do it wrong, and then a volunteer has to clean up after me. UploadWizard does the same thing, except it adds the right templates - why would that require more scrutiny?

Generally, the client side is better for logic that is closely connected with user workflow, because the client side is easier to customize. Other wikis might have different verification requirements, different workflows, different templates, even different image sharing sites for which they want similar support. With a modular, extensible JS code and bot-based verification, they can provide that for themselves; after pushing everything to the server-side, they would effectively be blocked.

Steinsplitter moved this task from Incoming to Uploading on the Commons board.
Tgr added a comment.May 25 2015, 6:41 PM

I still believe this is not the best way to go. Or rather, checking the license should happen on server side, but not necessarily on the MediaWiki servers - that will in effect exclude smaller communities from adding support for their own image sharing sites of choice, as adding a significant amount of code to a WMF-deployed extension is a huge barrier, especially if the functionality is not easily understandable to developers outside that community (imagine doing code review for the logic that verifies 163.com licenses). I proposed a "federated" approach in T55046#1310718.

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 15 2015, 11:57 AM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:25 PM
MarkTraceur lowered the priority of this task from Normal to Low.Dec 22 2015, 4:06 PM
MarkTraceur added a subscriber: MarkTraceur.
In T89131#1039912, @Tgr wrote:

(Blocker: This is needed to enable Flickr Upload for all users)

Why? UploadWizard does not do anything a user could not do manually. I can upload a hundred Flickr images manually right now, and probably forget to add the flickrreview template to them or do it wrong, and then a volunteer has to clean up after me. UploadWizard does the same thing, except it adds the right templates - why would that require more scrutiny?

Generally, the client side is better for logic that is closely connected with user workflow, because the client side is easier to customize. Other wikis might have different verification requirements, different workflows, different templates, even different image sharing sites for which they want similar support. With a modular, extensible JS code and bot-based verification, they can provide that for themselves; after pushing everything to the server-side, they would effectively be blocked.

Since it is causing issues (e. g. here) we should probably replace "{{FlickrVerifiedByUploadWizard.*}}" with "{{flickrreview}}" in the code. OR we simply add {{flickrreview}} for a additionally check (then we can remove the FlickrVerifiedByUploadWizard from AbuseFilter). I actually have no idea for a onwiki-only solution here. But both changes are trivial.

kaldari added a subscriber: kaldari.EditedThu, Dec 6, 10:59 PM

@Steinsplitter - I fixed the AbuseFilter filter. You forgot to exempt the extended-uploader user group when you added the {{FlickrVerifiedByUploadWizard.*}} template. To be added to the extended-uploader user group, you have to be vetted for knowledge of the licensing policies, and be trusted to import files from Flickr that aren't Flickrwashed, so those users are trusted should be exempted from the AbuseFilter.

AlexisJazz added subscribers: Slowking4, AlexisJazz.EditedFri, Dec 7, 12:23 AM

@kaldari @Steinsplitter

@Slowking4 is not actually in the extended uploaders group. I suspect he has the "Share images from Flickr" button because he is in the "GWToolset users" group.

@Tgr on T100062 "Granted, the Commons community might well decide to not widen access to the tool even if that happens, as they tend to be concerned with making uploading too easy."

I am quite confident the Commons community will be happy to enable it with a ratelimit for autopatrolled users. Commons has 5,955 autopatrolled users but only 67 extended uploaders. And 57 gwtoolset users. And 256 license reviewers. And 225 admins. And many, many, many users who aren't in any of those groups. I can't say if the community will be happy to enable it for everyone without limits.

Steinsplitter added a comment.EditedFri, Dec 7, 11:42 AM

@Steinsplitter - I fixed the AbuseFilter filter. You forgot to exempt the extended-uploader user group when you added the {{FlickrVerifiedByUploadWizard.*}} template. To be added to the extended-uploader user group, you have to be vetted for knowledge of the licensing policies, and be trusted to import files from Flickr that aren't Flickrwashed, so those users are trusted should be exempted from the AbuseFilter.

Thanks @kaldari for looking into this :-). I did not forgot that, after your change extended-uploaders can review images, which is not allowed by policy. The policy requires a short poll, then the right (license review) will be granted to the user. Additionally, the review is client side and therefore not legally secure. The policy also disallows reviewing own files. http://commons.wikimedia.org/wiki/COM:LR

I think we should change the bot review as for now, we had a JS hack for that which stopped working (i have no time at the moment to investigate that): https://commons.wikimedia.org/wiki/MediaWiki:Group-extended-uploader.js :)

Steinsplitter added a comment.EditedFri, Dec 7, 11:46 AM

@kaldari @Steinsplitter

@Slowking4 is not actually in the extended uploaders group. I suspect he has the "Share images from Flickr" button because he is in the "GWToolset users" group.

The GWT invokes the hack from MediaWiki:Group-extended-uploader.js (which no longer works).

@Tgr on T100062 "Granted, the Commons community might well decide to not widen access to the tool even if that happens, as they tend to be concerned with making uploading too easy."

I am quite confident the Commons community will be happy to enable it with a ratelimit for autopatrolled users. Commons has 5,955 autopatrolled users but only 67 extended uploaders. And 57 gwtoolset users. And 256 license reviewers. And 225 admins. And many, many, many users who aren't in any of those groups. I can't say if the community will be happy to enable it for everyone without limits.

I think so as well, there is also onwiki consensus (as far i remember) for that (somewhere i the VP/Proposals archive), the only *blocker* was the client side license review which is not secure.

kaldari added a comment.EditedSun, Dec 9, 8:05 AM

@Steinsplitter - Ah, I see. While extended-reviewers can technically review image licenses now, I think they can be trusted not to violate the review policy (or hack UploadWizard to do a false review). We don't have to enforce every policy with an AbuseFilter, especially for trusted users, in my opinion. I'm open to hearing other opinions though. Of course, the best solution is switching to server-side license review, but no telling when that will happen.

4nn1l2 added a subscriber: 4nn1l2.Sun, Dec 9, 11:36 AM