MyTube

CVS Account Request: http://drupal.org/node/994286 (status RTBC)
Sandbox: http://drupal.org/sandbox/lava/1074760
Description:

I am applying for a GIT account to publish and maintain a new Drupal module written by the Electronic Frontier Foundation. I have been working with Tim Jones from the Electronic Frontier Foundation on a module called MyTube . MyTube was written in 2008 as a way of serving Flash content or other remote embeds without putting users' privacy at risk with things like Flash cookies or remote referrers . Unfortunately, the project had not been worked on since early 2008, was not very configurable, and only worked for Drupal 5 (what EFF uses). As a Drupal 6 administrator at opensource.osu.edu, who was interested in running it on our website, I picked up the project, fixed a few bugs, made some improvements, made it compatible with Drupal 6, and converted it from using nodeapi into an input filter for flexibility purposes. I then backported my changes to Drupal 5 and passed the code onto EFF . The current version is located at http://opensource.osu.edu/mytube and also in our git repository at https://opensource.cse.ohio-state.edu/git/swaneybr/mytube.git .

MyTube is an input filter (it used to use hook_nodeapi in original version) that replaces all embed, object, and iframe tags with locally-hosted thumbnails that, when clicked, run a JQuery script that swaps the thumbnail out with the original embed code. Effectively, until the user clicks play, no remote request is made to the remote site hosting the Flash (or whatever else) content, so the user cannot receive referrer headers or Flash cookies until opting in. Below each thumbnail is a (configurable) disclaimer warning users about the privacy risks in loading the content. The disclaimer includes a (configurable) link to a page about privacy concerns for Flash content, which by default goes to https://www.eff.org/deeplinks/2008/02/embedded-video-and-your-privacy and also has a link to the source of the video, with the link text being the top-level domain. This ensures visitors can know what they are clicking to load before they load it. In summary, MyTube can be thought of as a site-wide Flashblock . To alleviate the NoScript-esque inconvenience this may pose to some users, especially those who don't understand or care about the privacy implications of some video-hosting services, MyTube also automatically modifies embed code for a number of websites so it autoplays when loaded, and then locates and downloads the thumbnail for that embed, so the appearance and experience is roughly the same as if the embed code itself were pre-loaded with the page. See an example at http://opensource.osu.edu/node/299 . In this way, unlike with NoScript and the like, the user only needs to click ONCE to play the video for many video-sharing websites (I am continuing to add more as I find them). If the source is not supported, a default thumbnail is displayed instead, and all thumbnails (default or not) are overlayed with a play.png symbol. In such unsupported cases, users can also add a thumb= atttribute to the embed code to specify their own thumbnail. Wherever the thumbnail may be from, it will automatically be resized to the size of the embed, or (if so-configured) the embed resized to an administrator-set width and height. Currently, thumbnails and autoplay are supported for YouTube, Metacafe, and Vimeo, and autoplay alone is supported for a handful of other locations.

What I hope to accomplish by submitting this to drupal.org is 2 things: (1) I want MyTube to automatically find updates, especially if (god forbid) there were some security vulnerability in our code, and (2) more users will know about and feel comfortable deploying MyTube. If it's adopted on a large scale it will be highly beneficial to end users who are mostly unaware of the massive amounts of data user-profiling and marketing companies are collecting about them, but potentially also beneficial to some companies (such as security vendors) as a PR move to show they care about your privacy. While naïve visitors will not notice anything happening, the ones who know and care about online privacy will appreciate that visiting a page with a single YouTube embed will not be added to a central database somewhere. I have spoken with the technical staff at EFF about hosting it here, and Tim Jones has agreed to sign on as a co-maintainer for the project, while I plan on being the primary maintainer. MyTube is licensed under the GNU General Public License version 2 or 3 (currently a license file is included for both, but I can remove them if it's against your terms). If you would like to contact Tim, let me know; his primary e-mail address has changed since leaving EFF. If you wish to speak with someone at EFF about the project, their main contact is now Chris Contelini , but he has not contributed any code to MyTube.

I shamefully admit I am new to Drupal development, or web development in general, but to the best of my knowledge the code submitted complies with your security best practices and coding standards, and API calls are made in place of standard PHP libraries wherever possible. As far as I know, there is no other server-side protection that does what MyTube does, not just within Drupal, but anywhere. There are a couple of end-user tools in the form of add-ons for Firefox, including Flashblock and NoScript. While these are more secure for security-conscious users, and they work for all websites, MyTube will work for all** visitors of the website regardless of what security plugins they may or may not have.

For security issues, MyTube does not currently access the database in any way other than the variable_get function. The primary security concern is that it is an input filter, and should handle user input in a safe and careful manner. While the removal of unsafe or potentially unsafe content is normally handled by the HTML Filter, users must technically be allowed (either by disabling this filter or whitelisting the appropriate tags) to submit embed, object, param, or iframe tags. Therefore, I consider any instance where such tags can pass through and automatically load (in any fashion) a security vulnerability. There has been one such vulnerability in the original version, which I can describe in more detail on request, but calling the HTML Corrector before MyTube processes the code will mitigate the issue (MyTube therefore calls said filter before invoking its own methods). Relevant embed tags can be selectively allowed or disallowed, and MyTube will process only what the user is allowed to use. In the event of a security vulnerability, if a fix is not immediately available, it can be mitigated simply by removing embed/iframe/object/param tags from the HTML Filter whitelist, and MyTube will pose zero threat. Simply disabling MyTube without revoking this access will allow everything to pass through unfiltered, but disabling MyTube will not create any benefit (or problems for that matter) if the tags are also removed from the whitelist. The only other issue I am aware of, which is minor but I'm considering mitigating anyway, is that in rare isolated cases MyTube has failed to detect where a video source is located, and therefore not display a link in the disclaimer. I'm considering adding code to handle these embeds differently, warning users that the code appears malformed and may be malicious, but this would probably fall more in line with a new feature. MyTube was originally written by Tim with the intention that it would be run in a tightly-managed environment, where everyone posting content trusts one another (or a single-user blog), but I hope to make it safe enough so administrators can safely allow many relatively anonymous users to post embed content without it every automatically launching for anybody without their explicit per-case consent.