YouTube and US music publishers reach an agreement

In 2007, the US music publishers, together with other content owners, launched a class action against YouTube.  At the same period, Viacom launched its suit against Google.  The two cases were concurrently treated with obviously some interferences.  The case with Viacom is not yet settled, although the last round benefited to YouTube.  In August 2011, YouTube and the US music publishers (at least the ones affiliated to the National Music Publishers Association (NMPA)) reached an agreement.

Some details on the settlement are available on YouTube’s blog: “Creating new opportunities for publishers and songwriters“.  YouTube will share some part of the advertising revenues when the content uses one of the registered songs.  YouTube’s content identification technology (ContentID) should detect any occurrence of a song.  No financial details are publicly available.

This is another step of Google, YouTube’s parent company, towards the normalization of its relationship with content owners.  YouTube may become one major legal distribution platform in the future…  Will the free model win?  Or will we see a YouTube++ with paid content?  Your guess?

 

 

Android Movie Rental and rooted devices

In May 2011, Google launched its new service of Video rental market for Android phones.  Soon, people discovered that the service was not available for rooted devicesRooting an Android device means giving yourself root permissions on the device.  In other words having FULL control of your phone.  This is not often the case with phones provided by operators.  Rooting is  equivalent to jailbreaking a device.  As Android is an open source system, very attractive to homebrew lovers, it is often the first thing they do to be able to create new apps.

The video app checks if the device is rooted and then refuses to play the content.  Why does Google do such a limitation?   The Video Rental Market uses a DRM to enforce the rental conditions.  One of the strong assumptions of software based DRM is that it runs in a rather trusted environment.  It is obvious that a rooted device does not fit with the definition of a trusted environment.  For instance, the app has no way to be sure that its system calls are not hijacked, or even if the system calls will act as expected.  Thus, it was obvious that Google had to take this measure.

Nevertheless, this limitation does upset the users who believe that open source means full control of their device.  Unfortunately, Open source and DRM are antagonist concepts.

As we could expect, the cat and mouse race has started.  It seems that a patched version of the app is available.  This version may not check the rooted device and accept to play the movie.  The movie is still protected by the DRM and you need a proper license to access your rented movie.

 

 

An iPhone that may refuse to record illegal content?

Apple filed in 2009 an interesting patent called “Systems and methods for receiving infrared data with a camera designed to detect images based on visible light.”  In a nutshell, the camera captures a picture or a video, attempts to detect the presence of an infrared signal.  If present the camera decodes the payloads and acts correspondingly.  This is what claim 1 protects.

Claim 1. A method for using a camera, comprising: using the camera to detect an image based on at least visible light; determining whether the image includes an infrared signal with encoded data; in response to determining that the image includes an infrared signal with encoded data, routing at least a portion of the image to circuitry operative to decode the encoded data in the infrared signal; and in response to determining that the image does not include an infrared signal with encoded data, routing the image to a display operative to display the image.

The obvious application is to block the capture, or decrease the quality, in presence of such signal.  For instance, a movie theater (or a classified facility) could beam such infra-red signal.  The compliant camera/phone would then block the capture.    The claims 4-7 clearly highlight this feature.

4. The method of claim 1, further comprising: decoding the encoded data in the infrared signal; and modifying a device operation based at least on the decoded data.

5. The method of claim 4, wherein modifying a device operation comprises applying a watermark to a detected image.

6. The method of claim 4, wherein modifying a device operation comprises disabling a device function.

7. The method of claim 6, wherein the device function is a record function.

 

Another usage, which is not related to content protection, is that the payload is analysed by an application that may display specific information on the screen.  The typical example would be a museum which would provide an application.  Each room or specific item would beam a code, the application would use this code to ask a server contextual information to display.  Obviously, if you would combine captured video + contextual display, you have an augmented reality device :Happy:

8. The method of claim 1, further comprising: decoding the encoded data in the infrared signal; displaying information on the display based at least on the decoded data.

Potential applications are numerous as described in subsequent claims.

Is this the solution against camcorders in theaters?  I don’t think so.  According to me, there are at least two issues:

  • It requires the camera to be equipped with the system.  Unless all manufacturers of cameras would adopt it, which is highly unlikely, there will be models without this system.  Pirates will use these ones.
  • Infra-red can be filtered by correctly tuned IR filters.  Soon the pirates would find the frequency of IR, and use the corresponding filter.  This is why IR jamming in theater did not work.  Some companies tried to blast IR beams towards the audience to blind cameras.  It was not a success.

The patent is available at http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=”20110128384″.PGNR.&OS=DN/20110128384&RS=DN/20110128384

 

 

Guidelines on Security and Privacy in Public Cloud Computing

NIST provides some recommendations when using a public cloud.  This excellent document gives very practical guidelines.  Every IT manager who plans to use a public cloud infrastructure, and who cares about reliability, security and liability, should read it before making any decisions and selecting the right service provider.

In front of the economic benefits of public cloud, it is extremely difficult to resist to the songs of the mermaids.  This document rises some serious issues and may help to keep the things under control.  For instance:

  • Even if you are using a public cloud, your company is accountable for the overall security of your service, i.e. even that of the outsourced part.
  • As the cloud computing infrastructure is highly uniform, it should be in theory easier to harden the platforms and manage its security (which is a positive point for IaaS).  Unfortunately, the use of hypervisors (virtual machines) increases the surface of attack (although many people believe that virtual machines are more secure)
  • Sharing an infrastructure with unknown parties is a potential issue.  A strong assurance should be provided for the mechanism enforcing the logical separation.
  • Be ready to audit your service provider if security matters to you.

A must read paper if you are about to board on the cloud boat.  The paper is about public cloud.  Nevertheless, some parts are also useful in the context of private cloud.

Reference

W. Jansen and T. Grance, Guidelines on Security and Privacy in Public Cloud Computing, NIST, 2011 available at http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf.

Migrating

The blog of content protection is moving to both a new web hosting and blogging engine.  I will now use WordPress.  I will try to transfer the old posts under the new blogging engine.  Thus, there may be some slight hiccups.

I hope that the new web host will be more reliable than my previous one.  My site was too often down

Password re-use

We often suppose that some users re-use the same password on many Internet sites. Most probably, the same password will be used to log on their company network. This is an extremely valuable path for hackers, as sometimes some Internet sites are not protecting correctly the stored passwords (if they even protect them). thus, an attacker that get access to such a list of accounts and passwords with a little bit of social engineering may try to log on companies’ accounts.

Gaw and Felten (Princeton, 2006) and Florencio and Herley(Microsoft, 2007) published empirical studies which evaluate the re-use at less than 20%.

Some password accounts have been hacked since the beginning of this year. Joseph Bonneau from Cambridge used this opportunity to make a new empirical study. His conclusions are that the ratio of re-use is higher. With a conservative approach, he estimates that 30% of the people may reuse passwords.

This is worrying but understandable. For every users, the number of sites requiring a logging is exploding. I just checked how many passwords my Firefox password handles (not far from 200 :( and with several different identities!) How can we reasonably expect users to use for each site a different password.

Nevertheless, it may be mitigated by some observations. One of the important factor is what are the sources of comparisons, i.e. the leaking sites. I suppose (or hope) that many people have multi-level approach of passwords: using a weak re-used password for non important sites, and more robust and diversified ones for more important sites.

For the sites where I do not care to be impersonated, I use the same very simple password. For sites where I must not to be impersonated, I use diversified robust passwords. And of course, for Technicolor accounts, passwords radically different from the ones I use on Internet.

What policy do you use?

In any case, Bonneau’s post is ineteresting to read.