The IA is a great group of people, and I love them...but they are still a third party group. I'm concerned that doing this would give them access to the GeoIP cookies, along with tricking visitors who think they are talking to WMF servers into exposing their IP address (Or other tracking data that can be gleamed from their browser) to a third party service.

We already do have third-party services on *.wikimedia.org fwiw.

After reading what our privacy policy actually says. I withdraw my previous comment. However, the video server probably needs to comply with the part of our privacy policy that says "These websites [Third party services], and others like them, will provide a link to their privacy policy (if it stands alone) or to an explanation of any differing provisions (if the site's policy is based on this Privacy Policy)."

good point about the privacy policy. My suggestion is that we point at the WMF privacy policy, as this is a service set up and run by Wikimedians and solely used by / in conjunction with Wikimedia services. The only user-related data stored on the server are:

• external username (Commons / Internet Archive)
• access token (from OAuth)
• user role (local user role used to manage privileges)
• language and description text published by the user on her/his user page
• uploads of the user account (public)

By the way the code is all open source and hosted on Github. I think in the long run it should go to WMF's Git but for starters it was just easier to start at Github:

https://github.com/ddennedy/wikimedia-video-editing-server

In T99216#1290616, @80686 wrote:

good point about the privacy policy. My suggestion is that we point at the WMF privacy policy, as this is a service set up and run by Wikimedians and solely used by / in conjunction with Wikimedia services. The only user-related data stored on the server are:

• external username (Commons / Internet Archive)
• access token (from OAuth)
• user role (local user role used to manage privileges)
• language and description text published by the user on her/his user page
• uploads of the user account (public)

This might be slightly off topic - but, apache is configured to not keep logs?

This sounds like a good plan to me - it's the least we can do to support our video creators on Commons...

Are there any remaining policy problems? Or can I bother some opsen about this?

In T99216#1304942, @MarkTraceur wrote:

Are there any remaining policy problems? Or can I bother some opsen about this?

@MarkTraceur: The silence probably means that you can go ahead...

Change 232669 had a related patch set uploaded (by Dzahn):
add CNAME videoserver.wm.org -> archive.org

https://gerrit.wikimedia.org/r/232669

Aside from @Dzahn proposing the patch above, I don't think any ops have even been on the CC for this ticket. It was probably overlooked because it was never really in the "Needs Triage" state? While I applaud the efforts to make video editing easier for Commons, I think there are some issues that need to be looked at before we just flip this on and walk away:

At the very least we've got TLS issues here. The server has TLS configured, but very poorly. A quick run through the ssllabs.com checker reveals:

• Self-signed (untrusted) cert for the CN wikimedia.meltvideo.com
• POODLE-vulnerable (SSLv3 is enabled)
• RC4 is enabled - https://tools.ietf.org/html/rfc7465
• Lacks Forward Secrecy with several common FS-capable browsers
• Lacks AEAD cipher choice with several common AEAD-capable browsers
• No HTTP->HTTPS redirect
• No HSTS
• No OCSP Stapling

I think the points about privacy concerns with an ostensibly Wikimedia service on 3rd party hosting mentioned above are valid as well. What's happening with the traffic logs here? What cookies does this leak? How does the OAuth integration play out (not really my area)? Who has access to root on this box? How is security managed in general?

Perhaps this is answered somewhere deeper in one of the earlier links, but given this is Open Source software, what was the reason for hosting it outside instead of inside our infrastructure? Storage space concerns?

GeoIP is set at the top-level wikimedia.org, so yes, IA would have that cookie, as well as the user's IP (which they can run through maxmind and get the location for anyway). Authentication cookie would not be sent, since we set those for explicit subdomains for *.wikimedia.org.

@80686, when you listed "external username", is that their wiki username? If so, that means the IA has username + IP, which we consider sensitive. So yes, it would be good to get more information about what logging they have setup, and make sure we're comfortable with their opsec in general.

this should be on a third party domain if it is a third party service. privacy issues.

Change 232669 abandoned by Dzahn:
add CNAME videoserver.wm.org -> archive.org

https://gerrit.wikimedia.org/r/232669

The fundamental approach here seems to be flawed. From reading this task, it seems like we broadly have two options:

• use a third-party domain to make it very clear that this is not part of Wikimedia (or the Wikimedia Foundation), eliminating the cookie concerns and underscoring that this service falls outside of the Wikimedia Foundation privacy policy; or

• have Wikimedia do its own transcoding service.

Either of those options seem to make this task moot. This task seems like a compromise option that isn't feasible.

Ok I suspect what we're going to end up doing is moving the user interface to MediaWiki-integrated code and just use a backend server for transcoding/rendering/source-media hosting at IA.

This should moot the cookie/session/privacy issues with the domain, since it could still live on a separate domain.

I'm going to catch up with the IA folks later and make some more detailed plans about what we can arrange on their end...

Since we said it's going to be external and i abandoned the change to add that CNAME on our side, i think Operations doesn't have much to do on this one. Am i wrong?

also see T124127

jcrespo changed the task status from Open to Stalled.

What exactly is this task stalled on?

@Aklapper an answer to T99216#2057570

Ah, thanks. But who exactly is supposed to answer that question?

In T99216#5689785, @Aklapper wrote:

Ah, thanks. But who exactly is supposed to answer that question?

The requestor, Brion and "the IA folks" per T99216#1718412.

Neither @brion nor IA folks have answered, and @80686 hasn't been active for two years here.
Proposing to decline this task for the time being, as there is no sense in keeping tasks stalled for many many years.

(Untagging ops until here is a current request, CC-ing SDE for their information and possible future interest. I support declining.)