Ironick

Twitter and I Both Own My Content

I just took a look at twitter’s revised terms of service. I posted the my feedback using the feedback link, but I’d thought I’d also post it in my blog for all to see (and respond to):

We both own my content

Given your legal language below, twitter effectively jointly "owns" my content. In other words, anything I can do with my content, twitter can too. You might want to change your "tip" to reflect this.

Currently the tip says: "This license is you authorizing us to make your Tweets available to the rest of the world and to let others do the same. But what’s yours is yours – you own your content." When told they own something, most non-lawyers assume that have EXCLUSIVE rights of ownership. That is NOT the case with twitter content. Twitter effectively has ALL the ownership rights to my content that I have. Twitter can use or sell (license) my content any way I can.

I think your "tip" should make that clearer. How about: "This license is you authorizing us to have all the same rights to the content that you have. Your content is twitter's content -- we both effectively own it."

LEGAL LANGUAGE:
You retain your rights to any Content you submit, post or display on or through the Services. By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).

Carbonite: I’ll check back in a couple of years

I finally decided to systematically back up my home computer – the one I have for family/personal use. I’ve been using one sort of PC or another since the Compaq Portable in the mid-1980s. In all that time, I’ve only done sporadic backups of various directories when paranoia kicked in. Despite this utter lack of care, I’ve pretty much never lost an important file due to a failure or accident. I have had two hard drives fail on me, but in both cases a data recovery service was able to recover all the files.

But I figure that after 20 years, I may be pushing my luck a wee bit too far. So I decided to check out Carbonite, based on David Pogue’s review of the leading web (oops, now cloud) based backup services: Carbonite and Mozy.

I’m currently in the middle of a 15-day free trial of Carbonite and I’m loving it: simple to install, completely unobtrusive, continuously operating. There’s only one problem, but it’s a show-stopper for me: Carbonite will not backup external drives! In my case that means it won’t back up the USB drive that I use to store all my photographs and videos and music.

I was (and I still am) incredulous. I didn’t recall a single review mentioning this crippling feature. I was so incredulous that I searched the web to confirm it. My first confirmation was from this 2007 blog post comment (Carbonite: FAIL, Mozy: ON NOTICE) by the (then?) CEO of Carbonite:

David Friend wrote:

James: Hi, I’m the CEO of Carbonite and I noticed your comments about Carbonite on your blog. Backing up external hard drives is a feature that is available in our PLUS product which will be available shortly. Carbonite didn’t fail to back up your hard drive – we state clearly on the web site that the BASIC version does not back up external hard drives. Doing so would alter the economics of our business model and would require that we charge everyone a much higher price, or abandon our UNLIMITED backup policy which most of our customers really like.

Regards,
Dave Friend, CEO
Carbonite, Inc.
http://www.carbonite.com Carbonite Online Backup

Posted on 23-Oct-07 at 9:03 am | Permalink

When I read this I thought to myself, “Great! Let’s check out Carbonite Plus to see how much it costs. It’s been almost two years since this post, so I’m sure it’s available now.” So I go to the Carbonite site and search for “carbonite plus”. Unfortunately, this is what I found:

1074 : [General] External, Network, and USB Drives

Article Viewed 3

Reviewed 6/11/2009

The current version of Carbonite backs up only the files that reside on permanent hard drives on your PC.

Check back soon for a Carbonite service plan that will allow you to back up your external drives.

So I guess I’ll check back around mid-2011. In the meantime, I’m off to check out Mozy…

Related articles by Zemanta

• Online Backup Company Carbonite Loses Customers' Data, Blames And Sues Suppliers (Updated) (techcrunch.com)

Zemanta

I'm trying our Zemanta, an add on to Windows Live Writer. Zemanta is supposedly a semantic web application that automagically enriches your blog posts with suggested links, tags, related articles, pictures, etc.

For example, if I type the phrase mars lander, Zemanta will automatically do wonderful things. Well it's supposed to do amazing things, but I don't see anything happening. Would the concept of Gartner make a difference. Or the happenings in Iran. Nada. The movie, The Watchmen seems pretty cool.

It’s working now as you can see. The problem was that I was running an old version of Windows Live Writer. Now let’s see if it can handle more obscure terms like meiosis, or stigmergy, or tsallis entropy. Wow, it did all of them except for stigmergy, even though stigmergy is in Wikipedia.

Hmmn… It looks as if pictures is not working. I’d love to see a picture of Dolphins, or some Transformers, or maybe even Spider-Man.

I think I’ll try it for a while…

Related articles by Zemanta

• Zemanta is a good social media tool (zemanta.com)

Two Timely T-Shirts

Is Google Chrome Taking Off?

I got a lot of hits on my post My 2¢ on Google Wave.... When I looked at the browser share stats (which I rarely do), I was surprised to find Google Chrome had more than a 12% share for the day:

Contrast this with Chrome's under 5% share since the beginning of the year:

Does this mean Chrome is taking off with the technorati? Or was the sample skewed by the fact that my popular post was about Google Wave?

I guess we'll have to wait and see...

Epiphany: Replace HATEOAS With "Hypermedia Describes Protocols"

As a few of my friends know, I live for epiphanies. I love to connect concepts. So I'm really happy to be having one now (it's been a while as regular readers of my blog -- if any remain -- can tell).

For a LONG time, I've been talking about how all interfaces can be defined in terms of IFaPs (Identifiers, Formats, and Protocols). My canonical example of an interface composed of IFaPs is of course the Web: URL (I), HTML (F), and HTTP (P). All three intersect in a particular instance of HTML, say my blog's home page. The HTML for my blog's home page is filled with URLs, HTML tags, and even HTTP "verbs" (though these are quite rare, mostly in an HTML form or embedded JavaScript).

Then along came REST and with it the concept of HATEOAS: Hypermedia As The Engine of Application State. And everyone, myself included, spent a lot of time trying to grok it and explain it to others. We're still trying. One way I try to explain it is by highlighting that HATEOAS requires that each server response must contain not only the requested data -- but also control information (in the forms of specially tagged URLs) describing the next set of permitted interactions with the server. It is this additional control information (at a bare minimum just some links to more data) that turns mere media into hypermedia.

Now along comes Jim Webber with a much better (dare I say brilliant) way of explaining HATEOAS and hypermedia: "Hypermedia Describes Protocols!" (See slide 26.) At first this might seem counterintuitive, since I said that HTTP is the Protocol and HTML is the Format in the WWW. But URLs, HTML, and HTTP are just generic description languages for describing domain-specific identifiers, formats, and protocols. Thus, think of a web of specific HTML pages as a domain-specific protocol. Jim Webber uses the example of ordering a Starbuck's coffee. (What's important is that each hypermedia DSL is composed using the generic languages of URL, HTML, and HTTP.)

This notion of bringing together identifiers, formats and verbs to describe a protocol is not new. One of the best descriptions of this was in the WS-BPEL 1.1 spec:

In thinking about the data handling aspects of business protocols it is instructive to consider the analogy with network communication protocols. Network protocols define the shape and content of the protocol envelopes that flow on the wire, and the protocol behavior they describe is driven solely by the data in these envelopes. In other words, there is a clear physical separation between protocol-relevant data and "payload" data. The separation is far less clear cut in business protocols because the protocol-relevant data tends to be embedded in other application data.

So if WS-BPEL was already thinking about mixing protocol data with "payload" data, what's so new about HATEOAS? The fundamental difference is that WS-BPEL is based on the concept of providing an entire static protocol description up front once and for all -- and providing it out of band. But HATEOAS is based on the notion of progressive description (don't bother Googling the term, I coined it; and not to be confused with progressive disclosure). More and more of the description of the protocol is provided to the client (in band in the protocol itself) as the client executes its part of the protocol. I guess another good term might be JIT Protocol Description (Just In Time). Another good term might be "self-describing protocol". So now when explaining HATEOAS, instead of saying "each server response must contain control information" (huh?), I can say "each server response progressively self-describes the current protocol."

Now there are pros and cons to static/complete vs dynamic/progressive protocol descriptions. How can I program a client to execute its part of a protocol if I don't have a full description of it up front? But if I encode the complete static description of the protocol into my client up front, how can I change the protocol dynamically?

Love to hear others' thoughts. I'm going to think about this some more. That's why I love epiphanies -- they make you think about things in new ways.

My 2¢ on Google Wave: WWW is a Unidirectional Web of Published Documents -- Wave is a bidirectional Web of Instant Messages

I viewed the Google Wave demo over the past several days:

I'm already convinced that Wave represents a Web paradigm shift on par with Ajax/Web 2.0. Just as Google Maps was the killer app that opened the Ajax floodgates (even though the component technologies/standards were already in place) Wave will be the killer app that opens the HTML5/XMPP floodgates. The Wave protocol is arguably the first advance worthy of the title Web 3.0 (though I'm not encouraging anyone to use the term).

My only MAJOR concern is the Wave protocol's impact on the core standards of the Web. Clearly, Wave embraces HTML5. What is not clear is how Wave uses URLs and HTTP? A key question for me is "Can I create a bookmark to a wave or a wavelet?" I'm less concerned with HTTP, though maximizing "backward" compatibility between HTTP actions and XMPP actions would be good evolutionary design. The reason I'm less concerned about HTTP is that URLs are the foundation of the "shared information space" that is the Web. SMTP coexists with HTTP and both use HTML and URLs in the content they transfer. Even Roy Fielding is eager to replace HTTP, e.g., with Waka. It raises the interesting question of whether the Wave protocol is roughly what Roy was proposing with Waka.

Here are a couple of my major take aways:

1. The Wave client is a major proof of concept (or pilot project) for HTML5. If the wave client becomes a killer app, it will have a major (negative) impact on other RIA architectures.
2. The Wave protocol is a major proof of concept for the extended use of XMPP. It transforms it from a IM/Presence protocol to a general purpose bidirectional streaming protocol.
3. Whether or not the Wave client succeeds, Wave is undoubtedly going to have a major impact on how application designers approach web applications. The analogy would be that even if Google Maps had "failed" to become the dominant map site/service, it still had major impact on web app design.

Last but not least -- an observation from left field:

Wave is far closer in approach and capability to Ted Nelson's Xanadu vision than it is to Tim Berners-Lee WWW vision. Both had visions of a READ/WRITE web of linked information. One of the major design decisions TBL made was to drop the then-canonical-requirement of bidirectional links because of the scalability/complexity issue of the required "link servers" (or "link intermediaries"). Wave is fundamentally based on Wave servers. The Google tech talk on the design of the wave protocol explicitly mentions that Google rejected the approach of enabling P2P Wave interactions.

One major accidental design "decision" was when the NCSA Mosaic team decided to only implement rendering in their browser -- not editing. TBL and many others have observed that the last decade or so has been a series of attempts to return to the original vision of a read/write web, eg wikis, blogs, micro-blogging. Wave seems to me to be one of the best approaches ever put forward to redesigning the WWW to be read/write (real time read/write in fact).

We don't actually do what we propose -- we just propose it

It's a Small World #3897:

I was recently in Manhattan on business and took the opportunity to have dinner with our dear friends Allison Tolman and her beau Peter Cohen. In the course of our conversation, I was explaining what an IT industry analyst does for a living by referring to the now-famous (at least in the worlds of analysts and consultants) UPS commercial about the two consultants that first aired, I believe, during the 2000 Olympics in Sydney.

As I described the ad, Peter's smile kept getting bigger and bigger. I paused and said, "What's so funny?" Peter replied, "That's my ad." My jaw dropped to the floor. I've know Peter for years and I never knew he'd been involved with one of my all-time favorite ads. Mostly, we would talk about his creative work for Sun Microsystems, but that's a topic for another post...؟

Check out Peter's other work as well.

A great article on modeling risk

I finally got around to reading Risk Management in the New York Times Magazine. It is one of the best articles on

• Wall Street
• Modeling
• Risk
• How people game models
• How all models eventually fail

that I have ever read. It is must reading.

All risk management systems, all (complex) models for that matter, are examples of robust yet fragile systems: robust in the face of expected events, yet extremely fragile in the face of unexpected events. Of course we will "fix" our models and rebuild. But remember Hawkins Law:

Progress does not involve replacing one theory that is wrong with one that is right, rather it involves replacing one theory that is wrong with one that is more subtly wrong.

And that more subtle error will one day cause the edifice built upon it to come crashing down. And so it shall always be, since there's no such thing as a free lunch.

Would you drop 10 friends for a hamburger?

Has social software really led us to this? According to the NY Times Bits blog, nearly 234,000 facebookers were defriended by their so-called friends looking to score a free hamburger. Burger King ran a promotion on Facebook that gave someone a coupon for a free hamburger if they would drop 10 friends. Harsh but hilarious.

Facebook called a halt to the promotion because the promotion actually told the dropped friends they had been dropped...for a hamburger. Ouch! Something about privacy issues. How about just plain human cruelty issues? Can you top this one?

I would really like to me the person would came up with such a wickedly perverse marketing campaign. I think we would really hit it off.

PS I would never drop 10 Facebook friends for a mere hamburger. I'd need at least a Triple Whopper with Cheese. uhhhHHHhhrghhhuuuuHHHggrruhhhHHhh