It's as though they think that people won't be able to use a proxy, circumvent the Cleanfeed block, or simply use a search engine to find another torrent site.

Build Your Own Pirate Bay?

Proxying is a very simple concept.

• Alice is forbidden from speaking to Bob.
• Alice can speak to Eve.
• Eve can speak to Bob.
• Alice, therefore, can use Eve to communicate with Bob.

So, a user who wishes to access The Pirate Bay would have to do something quite complex to use a proxy? No, this is all there is to it:

SELECT * FROM html
WHERE url="https://thepiratebay.se/search/ubuntu/0/7/0"
AND xpath='//tr'

This uses YQL and xpath to extract all the information from a Pirate Bay search (in this case, for Ubuntu - which is legally distributed through Bit Torrent).

Simply, this asks Yahoo (an American site) to contact The Pirate Bay (a Swedish site) to deliver information to a user in Britain.

You can play with the results yourself in the Yahoo Console.

This returns a JSON string which can then be easily parsed (e.g. using jQuery). Simple.

Aha! But What About Downloading A Torrent?

In the olden days (well, last year) there was a fly in the ointment. You had to download a .torrent file from the website. That meant that you needed a way to connect to, in this case, The Pirate Bay or find a proxy which was willing to transfer files.

Nowadays, people use the magnet protocol. Here's what a magnet link looks like:

magnet:?xt=urn:btih:fa692da0488aee23e5eb605a87be934ad7cec106

Short enough to fit into a text message and, handily, can be embedded in an HTML document with no need to download an extra file. Paste those 60 characters into your torrent client, and it will connect to the cloud and start downloading the file you requested.

So, a single web request to Yahoo and a line of JavaScript code is all it takes to circumvent this blockade.

Next Move

So, do the UK courts need to order ISPs to block Yahoo as well? Or play whack-a-mole with all the new torrent sites springing up? Let's not forget, in 2004 the huge Bit Torrent search engine Suprnova was sued out of existence. Just like with the Hyrda, a decapitation lead to multiple sites springing up.

Piracy is a problem of convenience. A pirated copy is

• Faster to download.
• Quicker to watch (no unskipable trailers).
• More convenient to transfer to different devices.
• Global availability (no artificial regional restrictions).
• Immense back-catalogue (Star Wars, for example).
• Cheaper.

The only downsides are that they are often of dubious legality, and occasionally of poor quality.

The entertainment industries have to compete on all these points. I'll admit, that they will almost certainly not be able to compete with "free" - although monthly unlimited subscriptions come close.

The rest are problems of their own making. I described how I downloaded The Phantom Menace back in 1999. 13 long years later and the movie industry still isn't even close to where it needs to be.

Amazon have done pretty well from selling raw MP3s - a simple web interface, pay a small bit of money, instant high-quality download which is DRM free. Where's the equivalent for films? Or for TV? Or radio?

The pernicious restrictions around geography also must end. I want to watch Veep just as much as the Americans do. Why do I have to wait even an hour, let alone a week?

Finally, Star Wars still isn't available to (legally) download. If I have a hankering for Jar Jar Binks at 3AM, I have to order a DVD and wait while it is physically transported from a warehouse. That's such a 19th Century way of thinking that it hurts my brain.

Get all that right and maybe - just maybe - the "piracy problem" will solve itself.

Of course, alternatively, it may be too late. For 13 years people have been used to downloading without paying. That's a long period of learned behaviour. How content providers can convince people to change the habit of a lifetime is beyond my knowledge.

By which I mean - how do you make your content serve the user's time-bound constraints?

What I'm trying to say is - serendipitous discovery must be restricted based on temporal imperatives.

Or, to break it down further, a user may only have a specific amount of time to dedicate to your app; how do you deal with that?

In a mobile game, the interface may present the user a choice of "Quick Play" for when the user is waiting for a bus, "Medium Play" for when the user is on the bus, "Long Play" for when the user is stuck in a traffic jam.

James Whatley blogged about this subject recently. In a mobile video app - such as the BBC iPlayer - the length of time the user can spend on the app is (probably) more important than any other discovery method.

Demo

So, I spent the weekend building a demonstration mobile service which starts with the amount of time a user is expecting to use the app.

LooTube!

As far as I could see, iPlayer doesn't have any public APIs, the videos don't work on all phones, and the content isn't available outside the UK. So I have used YouTube as the basis.

The "User Story"?

As a user, when I am sat on the toilet, I want to be able to view a range of interesting videos suitable to the length of my visit.

Point your phone at http://LooTu.be and this is what you'll see:

YouTube's API only gives us three lengths of video - short, medium, and long - so there's not quite as much granularity as I would have liked.

Clicking one of the buttons, retrieves a list of videos based on time. The "Quick" button will show the users videos which are less than 4 minutes long.

At the moment, http://LooTu.be doesn't allow the user to search for anything. It only takes time as a search query. It does, however, randomly select between YouTubes standard "top" feeds - most viewed, top rated, most shared, top favourites, etc.

Technical Details

You can view the source of LooTu.be - it's fairly basic HTML5 and jQuery Mobile. Feel free to laugh at my code and offer suggestions.

Thanks

Big thanks to Whatley for the inspiration, Robbie Dale for the logo, and my wife for her patience this weekend!

Preamble

• Many people download BitTorrent files.
• There are no BitTorrent search engines which are mobile friendly.
• Users have to try to navigate non-mobile-optimised websites.
• This is slow, inefficient, and may cost the user money in bandwidth charges.
• People who run Bit Torrent sites are often sued.

The Problem

BitTorrent search engines have a nasty habit of being sued (not something I want to happen to me!)

Lawsuits arrive based, usually, on one of the following factors:

• The site is hosting material which infringes a complainant's copyright.
• The site operates a tracker which tells users how to access copyrighted material without permission.
• The site distributes .torrent files which tell users how to access trackers.
• The site operates a search engine for Bit Torrent files.

The Challenge

Is it possible to create a mobile friendly torrent search engine which neither hosts, distributes, nor searches for .torrent files?

This is how the usual client / server relationship works

     +------------+           +------------+          +------------+
     |Browser     |           |Site        |          |Server      |
     +-----+------+           +------+-----+          +------------+
           |                         |                      +
           | Request for HTML page   |                      |
           +------------------------>|                      |
           |                         |Search Request        |
           |                         +--------------------->|
           |                         |                      |
           |                         |                      |
           |                         |  Search Response     |
           | Generated page sent     |<--------------------+|
           |<-----------------------+|                      |

The browser asks the torrent site, the torrent site asks a search engine, the search engine responds to the site, and the site returns a page to the user's browser.

This opens the site owner up to all sorts of risks. She knows what her users are searching for and she knows what response the torrent provider is sending.

Is there a way around this? Well, using jQuery Mobile, I believe there is.

     +------------+           +------------+          +------------+
     |Browser     |           |Site        |          |Server      |
     +-----+------+           +------+-----+          +-----+------+
           |                         |                      |
           | Request for HTML page   |                      |
           +------------------------>|                      |
           |                         |                      |
           |                         |                      |
           | Generated page sent     |                      |
           |<------------------------+                      |
           |                                                |
           |                                                |
           | Search request direct to search engine         |
           +----------------------------------------------->|
           |                                                |
           |                                                |
           |      Response sent directly to phone browser   |
           |<-----------------------------------------------+

Here's what happens:

1. The user's mobile browser requests the search page.
2. The site delivers the search page to the browser.
3. User types "Ubuntu" into the search box and hits "search".
4. The text "Ubuntu" is not sent to the site!
5. jQuery Mobile "intercepts" the request.
6. The browser sends the search query directly to the search server.
7. The browser downloads the search results directly. (JSONP)
8. The JavaScript on the browser renders the results on the screen.
9. The user downloads the torrent directly from the source.

So, in this way, all the service does is send some HTML and JavaScript to the user's phone.

The majority of the logic is stored on the jQuery CDN.

It is the user's phone which then communicates with the search engine. The user's phone which receives the results. And the user's phone which renders them.

In this case, the server doesn't see any content - legal or otherwise - nor does it see any search requests.

Technical

The code itself is fairly simple.

There are no reliable Bit Torrent search APIs which respond via JSONP. However, Yahoo Pipes provides several "recipes" which query APIs and return correctly formatted data.

Here's the skeleton code:

var pipeURL = "http://pipes.yahoo.com/pipes/pipe.run?u="+
    searchTerm+
    "%26rows=10"+
    "%26sort="+
    sortBy+
    "&_render=json&_callback=?";

//  Get the JSONP and parse it
$.getJSON(pipeURL,
function(data)
{
    // An Array of list items to be added to the ul
    var listItems = [];
    //  Loop through the results
    $.each(data.value.items[0].items.list, function(i,item)
    {
        //  Get all the properties of each result
        var enclosure_url = item.enclosure_url;
        var title = item.title.replace(/(< ([^>]+)>)/ig,""); // Strip tags

        //  Create a set of 
 which can be added to the 

        listItems.push('
'+title+'
');
    });
});

To reiterate, all of this runs on the mobile phone. There is nothing happening on my server.

Now, I'm not sure that this is a cast iron legal defence - hence I am not making the site public - but it moves the action squarely on to the user.

In this case, the phone contacts Yahoo, Yahoo then contacts a Torrent search engine, the phone does all the sending, receiving, rendering, and downloading. The server doesn't even see the search request.

What Does It Look Like?

The initial page.

Searching

The results.

The user is then free to download the torrent. Of course, the only torrent client I know for mobile phones is SymTorrent - and that only runs on older Symbian phones. So this project is of no practical purpose.