Page MenuHomePhabricator

Please set up a CNAME for videoserver.wikimedia.org to Video Editing Server
Closed, DeclinedPublic

Description

part of the "Videos for Wikipedia Article" project through 2014 / March 2015 the video editing server has been implemented, for the proposal / specification see

As we want to move the video editing server out of beta now and move on to real-world tests, we need a real URL. Currently it just uses a subdomain the developer has used under his own, private domain. In our February meeting we have concluded - together with Brion Vibber - that we want to ask for the URL videoserver.wikimedia.org.

The Internet Archive has committed to hosting this service given that we share all uploaded footage with the Internet Archive, which has been implemented in the meantime. The video editing service is an approved OAuth consumer and was specifically designed as a Wikimedia tool. It only accepts free licensed formats that can go to Wikimedia Commons, it only supports SUL users, it only publishes free file formats (WebM) and pushes the final results to Wikimedia Commons, similar to the Video Convert tool on Toollabs by Prolineserver.

Can someone please set up the following CNAME record to the wikimedia.org. zone:

videoserver.wikimedia.org CNAME researcher1907.fnf.archive.org.

The minutes of the February meeting with that decision can be found here: https://de.wikipedia.org/wiki/Wikipedia:WikiTV/Schnittserver/2015.02

Event Timeline

80686 raised the priority of this task from to Medium.
80686 updated the task description. (Show Details)
80686 added a project: Wikimedia-Video.
80686 added subscribers: 80686, Fuzheado, brion.

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

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?

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

jcrespo changed the task status from Open to Stalled.Sep 11 2015, 4:57 PM
jcrespo removed a project: Patch-For-Review.
jcrespo added a subscriber: jcrespo.

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?

jcrespo changed the task status from Open to Stalled.

What exactly is this task stalled on?

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

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.

Krinkle added a subscriber: Krinkle.

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

Declining per the most recent comments. Please reopen if any of this is not true and you still think this should be created.