Nexus and competition over mobile standards

In becoming a hardware merchant, Google will exert greater influence over the emergence of a number of aspects of mobile technology. The ‘Nexus’ phone announcement represents an acceleration of an ongoing mobile strategy – a stepped up effort to prevail in a series of disruptive technology trends in mobile ads, voip, and graphics. Which connection method will be used to get rich media ads to the phone. What runtime display format will be used for displaying ads on the handset. What options will exist for VOIP and for back door calls made over IP and not made on the carriers native networks for switched calls. These are examples of the kinds of things Google wants to be able to influence.

The leading smartphone vendors each push differing standards for the graphics engine that will control the display of rich media ads on phones. Adobe is pushing flex-lite. Apple has its own approach and has been reluctant to adopt anything Flash-like on the iphone. Microsoft’s Silverlight will soon support mobile so that Windows ME and Silverlight will be their closed solution for display.

Google is pushing 2 open standards, svg and HTML 5 in a way that will support the delivery of plain old html with tags for rich media ads handled as SVG. Unlike Silverlight and Flash, SVG does not require another IDE and a compile step to produce the actual media files. Mobile phones would not need anything more than a browser for ad display. No Flex-light plugin or microsoft silverlight plugin. Ad inventory ( rich media ads ) distributed by the major ad networks is currently all Flash . However, Google’s recent AdMob acquisition should allow them to introduce and drive conversion to a new ad format not in wide use today – (Html 5 + SVG). Any handset with an HTML 5 browser will render rich media ads. Google has been working on JavaScript libraries that will fill out the web ecosystem around http, html and svg. Google’s intent may be to more strongly support an open solution for mobile rich media advertising by selling hardware that requires only a browser.

Google’s support for VOIP adoption and for open standards (IP for call connection protocols) is far more disruptive to existing carriers. Consumers will now have the option to buy and use an unlocked phone without a 2 year carrier commitment. This move may serve to turn cell towers into a commodity type of infrastructure rather than a critical part of carriers competitive strategy. If 2 friends each get unlocked phones loaded with the proper software , a carrier contract is not needed in order to make phone calls. VOIP, Skype, SIP client software support a number of different connection scenarios where voice calls occur without going thru the main internals of a carrier network. Some of the Google voice features allow carrier networks to be integrated in a way that may permit outside callers from traditional networks to call a google voice number and to reach the handset via SIP interfaces connecting the last mile of the call via IP protocol. Without a carrier contract, outbound calls to traditional networks can be handled by connecting first to Google voice on IP then bridging to the traditional carrier network. There would no longer be carrier subsidies of the handset purchase. There would no longer be a compelling need for a carrier. An IP connection alone would be sufficient. Gizmo5 offers IP based calling features like forwarding , message handling, SIP binding. With enhancements built on these features, it would be possible for friends to call one another using email addresses, URLs in place of traditional phone numbers. Anything that SIP could bind to the handset IP would be sufficient for making a connection to the phone.

Contrasts between correlation and traditional search

Two very different web-based activities involve traditional content search ( google ) versus automatic delivery of a filtered version of the web, condensed and focused according to your personal interests and preferences – Search versus correlation. This article contrasts the automatic delivery model with search in order to provide an understanding why stream correlation and delivery of matched content is a viable alternative to search.

Automatic delivery of filtered streams of web content, greatly condensed through a process using correlation and matching, is a compelling technique for “bringing the web to you”. Whereas search is “pull”, correlation and matching done by Real Time Matrix is “push”. Like a newspaper thats delivered to your door, edited and reduced in order to retain only those articles that are relevant to your interests, correlation with push is convenient. There is no need for newsstands and generic versions of the paper when you have an alternative for delivery of a version of the same paper condensed in such a way that each item is likely to match your interests? Over the last 2 years RSS has provided a number of technical components that complement the process of web delivery of news. Under the covers, RSS is powered by streams, rivers of data more mobile and more flexible than the analogous web pages utilized by search engines.

The remainder of the post describes stream processing for web content as it has been adopted by Real Time Matrix and in doing so, contrasts traditional search with matching and correlation performed on “live” data underlying the river of new web pages, as those pages are posted to the web. For the purpose of making a general comparison, without getting too involved in low-level technical details, the web can be represented by a freeway lined with a series of billboards. To use an example, the New York Times has a series of bill boards representing sections of the news. The NYT Sports Section can be percieived as a billboard represented by a deep stack of pages – a multi page billboard in which every sports article is represented by a billboard page, organized in LIFO order so that the “hot off the press” articles float to the top of the page stack. In will be of particular interest to examine search and correlation techniques as theyrelate to a single, new page as it is “posted” to the web.

Search builds an Index for the new page

The existence of an entry for the new page of content within a search index is a prerequisite. Before the new articles page is indexed, before that new index gets added back to existing indices for NYT Sports, noone can see the new page via search. Index building and pre-processing is not religious about “fresh content” and whats sits at the top of the page stack in the billboard. In building and refreshing its indices, Google employs crawlers on 10s of thousands of servers. The Crawlers act as robots that know the location of every billboard and how to schedule re-visits in order to pick up changes posted to each billboard. Reoccurring visits follow their own schedule, determined by Google algorythms that may miss by weeks the exact time of posting of freshest page. When they visit a site like NYT Sports,

Crawlers focus on the HTML formats of data in a page ( more on HTML data formats and RSS data formats below). Any new page that has appeared since the last visit gets processed by the indexer, links to and from other web pages get analyzed, meta information on the page is read, the page is scanned for key words to be included in an index entry for a new page. Before this new entry can update the main Google search indexes, before the new page can begin showing up among results presented as “hits” pages for web queries, the new index entry needs to be shipped along the freeway to the nearest Google data center where it can be included with other new index entry’s and scheduled for a process that will eventually update the main search indices. After all these pre-processing steps are complete, a sports search could include the new page within the list of search “hits.”

RSS Sample Data , Streaming Data

To understand the streaming data approach, look more closely at the example of a new Sports page article as it is posted to the NYTimes web site. As described above, there are two different data formats that can be used (  html or rss ) to represent the sample page from NYT sports. This html link is the data used by the crawlers described above. Besides this format, there is another data format of the same page that is more mobile, more easily distributed, and more easily exchanged with other cooperating computer systems. The , also from the NYTimes, contains the same articles as the html links, but these articles are organized in a very different data format – see the sample of RSS format data below :

<div> <pre> http://www.nytimes.com/2007/01/31/sports/basketball/31suspended.html?ex=1327899600&en=7ccd90d2e67129e2&ei=5088&partner=rssnyt&emc=rss The N.B.A. has shown little tolerance this season for any action that is illegal and overtly ugly. LIZ ROBBINS http://www.nytimes.com/2007/01/31/sports/basketball/31suspended.html Wed, 31 Jan 2007 01:33:30 EDT</pre></div>

Visualize the data above, drawn from an rss sample with itunes type NameSpace additions, as a stream. Scan each data line starting with <itms:artist> placed in one, long line. Next, animate that one big data line like a ticker-tape so the data scrolls across a given place. A ticker tape is a data stream containing words or items that can be correlated to other patterns. Look closely at the animated version of the sample data above – at some point , you would see the words Jack Johnson. If you were interested in music works by Jack, these 2 words could be found among the ticker stream, “matched” by correlation process on your behalf.

RSS Capabilities , Advantages

In contrast to the static html form of the page used by traditional crawlers, the RSS version of a page is fast and flexible. For the purpose of this example, the stream of rss data mentioned above “flows between” arbitrary source and destination points on the freeway. What does that mean? Mobile stream data, Rss friendly, leverages “Feed-enabled” software from any number of 3rd parties compatible with even more 3rd party device types. Equipped with a “reader” that consumes Rss, my phone can locate itself at a suitable off ramp, “subscribing” to just the data that has been correlated and matched to me, streaming past the off-ramp among a much larger “firehose” of generic data. Infrastructure supporting rss distribution is built into the phone and it just works.

In addition, the Rss form of newly posted content does its own PR. As articles post to the NYTimes sports pages, the Rss format has the ability to inject itself into the syndication infrastructure with an announcement that simply says “I’ve arrived”. That simple statement triggers data flows and complementary filtering or “personalization” of the data in transit. The practical result is that relevant data arrives where it is supposed to go on an intelligent freeway. Again with the aid of ots of 3rd party software supporting announcement pings and the feedMesh, company’s like Technorati, syndic8 respond to the data that was just posted with all sorts of automated, “just arrived” type tools. The discovery method for newly posted Html is very different, involving higher cost and greater latency.

Compared to streaming Rss data, moving immediately out to the interested consumer from the billboard at the same time that the article is posted, traditional search indices can make you wait. You wait after the post while the crawlers are idle for a period of time determined by the algorythms at google. For example, if you have small traffic e-commerce site and you begin offering new categories of merchandise in your on-line catalog, it may be 30 days befor the new category gets picked up by crawlers and added to the indices for your site. NYtimes sports, although larger and of more interest to the dispatchers behind the crawlers, is still going to be affected by considerable latency between standard practice for CMS and newly posted Rss versions of articles calls for a notice of the post and a concurrent flow of data that mimics email. Registered parties and groups of people will be notified immediately after the Rss version of the article arrives on the web.

technorati tags:search, rss, crawler, robot, indexer, realtime

Blogged with Flock

Lotus Connections with Web20

As announced in BusinessWeek IBM’s recent enhancements to Lotus Connections validate some Web20 software approaches and may comprise a vanguard in corporate middleware employing  a new stack thats quicker and easier for software developers. Sites like TechCrunch have reported all the details of the Web20 fad among companies whose revenue is considerably smaller than IBM’s 95 billion. If the Elephant is ready to dance once again, there are  lessons for enterprise Software vendors under the covers of the Web20 culture in software development.

The salient points of the Lotus Connections press releases point out things like easier blogs, personal profiles, and autonomous communities as new features employing software practices now the main religion at lots of startups like Flickr and Delicious. Users of these newer web sites take no time at all to grow a new community of 25 or 2500 users (autonomous workgroups), whose members cooperate and interoperate, sharing data, applying tags to the data without assistance from System Administrators or programmers or application owners. Flickr and Delicious support the general proposition that, on the web, songs and pictures can “just find you” based on your interests and on your membership in a group. These “smart network” characteristics come to the enterprise with high value and very low cost.

The trend regarding some of this web20 plumbing is to increasing adoption by the enterprise; a logical consequence could be disruption in some of the technical aspects of the traditional Enterprise middleware stack. Compared to traditional corporate stacks,the Web20 software stacksare lean, present everywhere,  and very easy to deploy. Http and REST are software cornerstones supporting alot of functionality at startups that predates the lotus community announcements. For software developers at these firms,  there are no requirements for dealing with with WebServices Utiliitys,no UDDI, no complicated service endpoint xml schema abstracts. With REST, its  just URL’s, user interaction with those urls, and Httpprotocol. There are no extra libraries for programmers  to download ,no preliminary deployment utility steps to be run or library/repository entries to be maintained. The Web20 stack is better, faster, and way cheaper.

The following section provides business and technology details that support the notion of continued disruption as traditional business process software and work group software  adopts best practices and additional plumbing from web20 practices.

RSS & ATOM  present each worker with “their data”

In the same method that these 2 data formats are heavily used for syndication of web news and  weblogs,   business workgroup documents, selected database fragments can be wrapped or enclosed and then distributed to just the people that need to receive it. The snips of data in the <item>  below show 2 examples :

• RSS “encloses” a spreadsheet using enclosure
• RSS “encloses”  some data selected from a database in CDATA

<item>
 <title>The Overnightscape #143 (3/14/05)</title>
 <pubDate>Mon, 14 Mar 2005 09:51:43 GMT</pubDate>
 <enclosure url=”http://xyzcorp.intranet.com/xls/billing/Overnightscape_receipts0143.xls”
    length=”10802740″ type=”application/x-excel”/>

 <category>payable</category>

 <category>unapproved</category>

</item>

<item>
 <title>The Overnightscape #143 (3/14/05)</title>
 <pubDate>Mon, 14 Mar 2005 09:51:43 GMT</pubDate>

 <content:encoded><![CDATA[
      <parameters applicable-location="point1">
         <temperature type='maximum' units="Fahrenheit" time-layout="k-p24h-n7-1">
            <name>Daily Maximum Temperature</name>
            <value>34</value>
            <value>43</value>
            <value>39</value>
            <value>39</value>
            <value>47</value>
            <value>48</value>
            <value>41</value>
         </temperature>
         <temperature type='minimum' units="Fahrenheit" time-layout="k-p24h-n6-2">
            <name>Daily Minimum Temperature</name>
            <value>16</value>
            <value>31</value>
            <value>26</value>
            <value>26</value>
            <value>32</value>
            <value>31</value>
         </temperature>
      </parameters>
   ] ]></content:encoded>

</item>

Enclosed in RSS ,  business data now gets a free ride for a better, faster, cheaper experience. The enclosing RSS stream of data can be routed anywhere using only http and a  network – there is an assumption that the enclosed documents are URL-accessible on a web-server or intranet. Any phone, PDA laptop can get access to the data as easily as these devices access the web. Http plumbing is everywhere and imposes very low admin costs. Atom and RSS are universally recognized formats which means that the only system requirement is to deliver data to the target application. Absolutely no requirement exists to write a UI or to develop user applications to manipulate the data because all kinds of software already exists that processes RSS/Atom and that manuipulates the enclosed data objects according to their mime type. In summary, things i dont need todo:

• No messaging layer or MOM needed
• No ESB needed
• No PUB/SUB framework needed
• No SOAP  Web/services infrastructure needed
• No presentation layer or application needed

Document Flow and Notification

Now that i’ve completed my work or updates to the documents that are of interest to my workgroup, i need to signal that im done and that subsequent work by others in the group may commence. Millions of dollars of complex software with functionality mentioned at the above link above has been sold to customers needing to cover this somewhat complex functional requirement. At the risk of oversimplifying things, the Web20 stack is a growing presence with decent capabilities for “eventing and notification” so that when your task is complete, i get an alert and can begin my task. Workflow/document related functions such as Creates, Reads, Updates, and Deletes are covered by REST , and as in the data excerpt above you may update the metadata in the <category> tag to indicate status changes. Those status changes can be picked up by observing or polling the data stream that encloses the document. Although not quite ready for prime, dojo’s comet is utilized in web20 contexts and purports to support http push in an environment where pieces of distributed software components communicate at a low level and with alot of intelligence using nothing more than http.

technorati tags:lotus, lotusworld, web20

Blogged with Flock

Net Neutrality – rolling new revenue without K-Street

Recent developments related to the ATT / SBC merger and the details in the consent decree that was part of FCC approval for the merger shows some movement away from the pipe owners like ATT back in favor of content providers like Google in the Net Neutrality  debate. A single abstention on the 5 member FCC board altered the neutrality dynamic in favor of the grass roots despite the counter argument by the pipe owners that necessary capital improvements make it imperative that they charge content providers like google and apple for all the new videos moving accross the net. Absent the changes that alter the web in the direction of cable TV, the pipe owners predict  capital improvement deficits and rising broadband congestion as bittorrent and itunes tv shows and netflix movies clog the network.

Google exemplifies the enormous valuations attached to content providers who can shake the money tree of sponsored advertising as they deliver applications and content thru the pipes owned by the likes of ATT. The number of page views served directly by Google and also by partners involved in affiliate programs where ad money flows back to google is money tree. The last i saw is that the front-end revenue for google sponsored ads was averaging $1.44 per click. Google disrupted the advertising market by evolving the AdWords marketplace and by extending the equation with web browsers, adding sponsored links to the search results pages served up by google to users trying to find stuff on the web.

Rather than paying K-street lobbys and using leverage in neutrality regulations to come up with rules allowing them to loot the pockets of Google, the pipe owners like ATT ought to be surveying the web advertising markets looking for an innovation of their own in order to print money like google does. For example, instead of looking on in envy at Googles 120 billion market cap and the growth of AdSense, the Pipe owners could be saying “hey i have a money tree of my own because I own the user IP and Im positioned to add the holy grail to that IP – individual user demographics.” Good demographics, added to the activities currently incorporated into Google’s ad words market would probably double the value to advertisors. Was that search on “mortgage insurance” submitted by a 36 year old in Greenwich with income of 450K or was it submitted by an 18 year old finance student at the state university? There is a difference.

When i do a search on a google sponsored site that is using AdSense, the relative value of the Ads that i will see along with my search results is determined by an auction whose market places a value on keywords without knowing anything about my demographic. User at IP 192.0.0.1 submitted a query on “mortgage insurance”. The IP is naked. There is very little in terms of marketing demographic or segmented audience based on age, address, and income associated with that IP address.

For the sake of argument, lets just say that im that 36 year old looking for mortgage products. I have  2 teenagers who are iTunes addicted. ATT is my ISP and they have offered me an opt-in program where i divulge some sensitive personal information that i can control and that allows me or my children  access to a new kind of cookie jar built on the $$$ associated with my demographic data. With the demographic, my click on a sponsored link accompanying the mortgage search is worth $3.50 not $1.44. That is because the DNA of marketers is in demographics and if they know just a little more about the person they are reaching thru AdSense rather than just the IP, they will pay.

Going with the future scenario, say that a partnership among ATT, Google , and iTunes works like this: ATT says that this month , in return for access to my demographic, they will credit my account $15 for free iTunes downloads for my kids. ATT has told Google that AdSense activity placing ads in front of me will be augmented by my demographic and as a result, Googles monthly revenue resulting from my “click” will double. Some of that delta revenue is charged back from Google by ATT. Everybody makes more. iTunes get more action that is subsidized by ATT’s bonus offer to me. So ATT is subsidizing my kids use of iTunes. ATT is collecting some piece of the AdSense money by allowing Google access to the demographic associated with my IP. Google is paying ATT a portion of the delta AdSense revenue.

references:

at&t consent decree

see “net neutrality” pg 9

NetNeutrality by lessig

technorati tags:net-neutrality, google, att, web, premiumcontent

Blogged with Flock

Reading Lists with state

Although easy to store on the web , and easy to use to  share your feed list,  OPML Reading Lists need new features including server-side, stored, state information and access to a networked valueHolder object type version of readingList state. A reading list user would then be able to seamlessly use any instance of any feedReading client to pick up the feeds encapsulated by specific list exactly where that specific user last left the list.  Lets say that there are 50 new feed items belonging to 10 of my ReadingList’s URLs in the morning. On my laptop at home, i manage to read 10 . Then, in my car on the way to work, via a Reader equipped satellite radio, i listen to 5 more podcaste items before arriving at work where i scan the remaining 35 feed items. This scenario involves 3 clients and 3 separate feedReaders that in today’s world are each capable of subscribing to and downloading all 50 feeds in triplicate. Today, there is no way for these readers to share state, to share the data that progressively updates as i wade through the 50 feeds. What i want is a seamless handoff off an updated awareness of both read and  unread items as my presence shifts among the devices on the way to work. The rest of the post is a discussion what and how for one possible solution that extends reading lists and that adds an app server that can update and hold values of these networked list objects.

If you use reading lists and just 1 client to check for feeds there is no need for new features. That single client would be the only location needed for storage of important meta information regarding the feeds and the delivery of items on those feeds. For any given feed or url in the list, the client knows when it needs to poll,  requesting a pull of new feeds from that url.  As long as you always use the same client the reading list entries are handled correctly regarding last visited  state and with respect to dupes because a single client knows how to avoid duplicate feeds on the url. It can diff the meta data just received against data from older items. Now introduce a 2nd feedReader client by sharing the reading lists on your PC with the reader installed on your phone and see what happens. Everything gets pulled twice. Without access to the same internal state information  used by the first client, the phone has no visibility into what time each url in the list was last requested and no access to meta data like the most recent pubDate on items just pulled by the other client. Nor does it have any information on duplicates. On the phone, you can get your feeds but it will be just as if you are using an email account where you save all mail items on the server while using multiple mail clients. Each client downloads the entire list of mail in the inbox even thou you may have already read the mail.

A shared folder of MyFeeds as I last accessed them , stored server-side where it associates users (myself) and lists (mylist) with a 1 : 1 cardinality is one solultion to the problem. The virtual folder encapsulates client state information like the last time that i read a particular &LT;title> belonging to a feed URL, storing server-side attributes like "last_access_date" on the feed and "has_been_read" on each title in the feed. Any feedReading client on any device has access to the folder and to accurate context covering details on what i last read and when.  All that i have to do to use the reading list in a consistent fashion is get access to the web on a device with a reader capable of accessing this shared folder.

Assume that you have  http://code.google.com/apis/gdata/protocol.html providing "shared folder" features. Look at the Gdata link for "Inserting-a-new-entry". Its focused on the provider and not the consumers of feeds, but it is so close to being a compelling example that some speculation around the fringe of the supported functionality is merited. This is scalable and it supports a full Rest   interface. In the details of the "201 Created" section you can see the xml code excerpt below:

<id>1 </id>

<link rel="edit" xhref="http://example.com/myFeed/1/1/"/>

<updated>2006-01-23T16:26:03-08:00 </updated> 

The link and the id above are pretty close to what you would need to have a uuid on the association between the user (myself) and the <entry.title> where you want to store the attribute "read or unread". Once someone convinces google to extend this initial offering for rss in the GData api, support for the reading list with shared state is done. Any feedReader on any device marks a title to "has-been-read", generating a local event that delegates to a proxy to GData where a POST/UPDATE occurs on the URI and data entry representing the distributed object encapsulating the state of my interaction with the collection of titles that belong to a specific feed. I could switch devices and do a GET to access the shared folder in the state where i left off while i previously was accessing my reading list. 

The Box in the living Room versus Rss everywhere

Who benefits from the requirement for a set-top box in the living room that does double duty as a receiver gateway for any incoming digital media (netFlix via the web) and as a distribution hub for syncing media to other local devices (forward myRingTones to my cellphone, forward my podcast to the XM device)? With this type of network organization both network endpoints involved in media transfer are fixed so that transmission across the net of copyrighted material covers a safe, consistent, and defensible route. This is a boon to content owners with piracy concerns. Utilizing a hardware node that is always the transmission destination within the home, content owners exert maximum control over the implementation of DRM and over the codec processing required to render transmission data into playable media. Each network connection made for the purpose of updating my household media library, is made with the assurance that my account has been authenticated, that my subscription has been paid, and that i will have difficulty ripping and re-burning the media that is being received. Piracy risks that preoccupy content owners may be minimized – but it is not a strategy that comes close to providing optimal consumer choice.

The new linksys product is part of a partnership with Yahoo designed to ease the task of syncing media that has been downloaded with TV , Stereo and other gaming components located in the living room or brought there for the express purpose of local file sharing. Recent reports posit Google cube as a similar product. Microsoft’s media center PC product also sits in the living room although it handles many other functions besides DRM. New devices like the slingBox virtualize my content, allowing me to watch any show on my list even if i’m in a hotel across the country from my living room. Sony’s location free offers features similar to slingBox, funneling content first to the hardware device where its available to be forwarded to other devices. Every one of these hardware devices intended for the living room utilizes hardware encryption, hardware DRM for a consistent and predictable distribution of media files or streaming media from content providers to legitimate media subscribers.

The holy grail for personalized e-media – play what i want now, wherever i am, on the device in my hand – is getting a lot closer to reality. TV shows can download direct to itunes for playback. GoogleVideo distributes mpegs and avi type files. Companies like brightcove supply enabling infrastructure so that any content can be routed to any subscriber device. Fireant delivers your media to any of your devices. RSS allows you to virtualize the storage of your global "playlist" and to access your personal channels list from any device affording web access. "Search, Browse, Subscribe" techniques are used to subscribe to (update) content, adding the content to channels in a virtual playlist. Playlists are the "what", RSS is the glue for connectivity and transmission – the standard that any net-connected device can understand as it uses the playlist in order to retrieve and to play your content whenever you want it. Playlists simply exist on the net – its totally unnecessary for either the list or the retrieved media to be tethered to any hardware in any fixed location like your living room. Any device at any time can retrieve the list, using links there in order to access the actual e-media content. With a virtualized menu of "my personal channels" and with mobile devices all coming equipped with an Rss Reader, wherever you have a net connection your virtual list becomes the available channel directory on the device. You play whatever you like wherever you are without ever having to consider how to sync up a handheld device with the hardware hub in your living room.

An example using virtual channel e-media without being tethered to any hardware hub in the living room involves a commuter with a playlist including a traffic feed. The virtual playlist includes the url for the traffic feed. Via the playlist, the streaming audio for the traffic can be played on a web-radio before departing from the home for work. In the car, XM Playlists incorporating the same technical glue are being used to organize satellite radio content. Eventually, tuning practices for these radios may include the capability to "tune to" URL’s. Sony is now equipping its new devices with features that leverage RSS – using psp rss reader the PSP can access the same traffic reports. At work, the same virtual playlist can be used to connect to the traffic before going home. None of these media scenarios need to be funneled through a device in the living room. The only real requirement for anytime, anywhere access to the media is a net connection and access to the playlist that includes the traffic report.

In terms of the details of encryption and DRM, the "hardware in living room" solution contrasts with an alternative software implementation of DRM in ways too numerous and too complex to wade into. For the ambitious needing more, see pg 11 – 14 of this Cato Institute publication . For any mobile device with an open software applications stack – like a phone or a psp – encryption and DRM processing meeting just about any level of requisite security is a straightforward matter. Binary media in transit to the device can easily be protected. However, hollywood and and the RIAA believe that any networked, web connected node where subscriber authentication and DRM license mediation occurs, and where media transcoding occurs is also an occasion for piracy- this belief and distrust is behind the support of hardware DRM in the living room because hollywood controls it. Although technical practices provide "always-on" access by my phone, my psp, or my XM device to the latest and greatest version of my playlist or the playlists of any of my friends, giving me the ability to play any of that content anytime, anywhere, content owners prefer hardware implementations of piracy prevention schemes that restrict any conceivable opportunity for diversion of media outside the sandbox.

These new hardware products, intended only for the living room assume that delivery of all media is made to the living room first – they do a good job protecting the interests of content owners and anti-piracy advocates, but at a price to anyone with a preference for playing anything, anywhere, anytime. When i have to bring my phone into the house first in order to sync a new ringtone, or when i have to bring my psp into the living room first in order to pick up a new movie trailer because the psp does not have the requisite DRM features that only exist on the piece of hardware in the download device located at home, my options for playing anything, anytime, anywhere are all impacted. The hardware devices for the living room include lots of convenience and easy-to-use features. As evidenced by the maneuvering over the analog hole bill , the content industry, while not always up-front in declaring their real intent, is more into piracy control than consumer choice.

 

 

technorati tags: soho, podcast, rss, set top box, e-distribution, home video, youtube, video