Webware’s favorite live blogging tool, CoveritLive, is getting a new tool for its authors: the capability to update a live blog via Twitter.

When setting up a live blog, producers can tell it to monitor Twitter accounts for updates.

It’s a simple, if slightly crude, implementation: when a live blog producer is setting up coverage, he or she can tell the system to monitor specific Twitter accounts and post the Tweets in the live blog window. As a Twitter and a CoveritLive user, I’d prefer a bit more control, such as the capability to tell CiL to take filtered Twitter feeds (using #hashtags, perhaps), but this is a good start.

What I like most about this feature is that it sets up CoveritLive as a conduit or platform, not a closed system. If you’re a Web producer and want to set up a live blog, but your authors are happy Twitter users and don’t want to learn a new tool, fine. Just tell them to cover an event from their Twitter account using their favorite Twitter app, like Twhirl or TwitterFon. (Twitter live bloggers will still be subject to the platform’s 120-character limit, of course.) You can mix up Twitter posts with text from the standard CoveritLive writer’s interface. It’s easy.

Just in case I wasn’t clear about this at the top: CoveritLive is a fantastic tool for covering live events. I am very happy to see it developing with new features and capabilities.

We are using CoveritLive today to live blog the Under the Radar: Mobility conference.

CoveritLive viewers see the Twitter updates inline with the other content.

More: continued here

If you’re new here, you may want to subscribe to my RSS feed. Thanks for visiting Web 2.0 Portals!

Social aggregator FriendFeed has just rolled out a new option for its users to post some or all of their FriendFeed activity over to Twitter.

Earlier on in the start-up’s life the functionality was introduced to send replies (via FriendFeed) to other people’s Twitter messages. This worked as long as you had plugged in your Twitter credentials to give the app permission to post as you.

This new system is similar to that model, although it can be set to do this for everything you publish to FriendFeed. Users can also select which specific services they’d like cross posted, keeping your Twitter subscribers from being inundated with your comments about threads they have no idea about.

You can now opt to have your FriendFeed entries posted to Twitter, complete with a selection of which services you want it tracked from.

(Credit: CNET Networks)

To avoid what could be considered an infinite feedback loop, FriendFeed ignores these Twitter messages, even if you’ve set up your Twitter account to go into your FriendFeed. If other Twitter users reply to you it will simply go into the original FriendFeed entry.

This could mark the start of export publishing to other services, which VentureBeat’s MG Siegler thinks could be a simple play to drive more traffic to FriendFeed through back linking. As it stands any message sent to Twitter from FriendFeed includes a link back to that conversation, which might be enough to hook people.

Personally I really don’t feel the need to use this feature–at least for Twitter. I think Twitter’s strong suit is that it’s text only, and while links are sometimes handy I don’t think my followers want as many as FriendFeed is likely to spit out. FriendFeed does a far better job integrating photos, videos and other media, which is something I doubt Twitter is likely to add; that is unless it develops a plug-in architecture (which the recently updated side-bar suggests). For the sake of my followers I won’t do this.

Where I can see some value in this is for something like Delicious. The tools for sorting through Delicious bookmarks are plentiful and powerful, but lately most of my link sharing has been to FriendFeed because I prefer it’s media-rich bookmarklet. Sure, I could keep adding bookmarks to Delicious, then have them get sucked up in FriendFeed, but I know for a fact that my FriendFeed subscribers would probably be more likely to check out that link, or like it if it had a picture and a snippet of text. With a system in place to push out FriendFeed bookmarks to Delicious, I could avoid this problem altogether, and still keep my Delicious library fresh.

I expect we’ll see other services for export publishing in the near future–the question is whether it’s more for the users or FriendFeed’s traffic.

More: continued here

Google on Thursday will begin expanding the instant-messaging feature built into Gmail so people can use it to send text messages to their contacts’ phones.

To use the feature, people can click on a chat window’s settings to send a text message with SMS or type a contact’s phone number in the chat contact search box, Gmail Product Manager Keith Coleman said in an interview. The feature is experimental, available only to those who opt to use it through the Gmail Labs settings, and Google will begin offering it Thursday.

Gmail Labs has let Google offer a wide variety of experimental features to those who want them–27 so far since the feature launched in June. None has graduated to full-fledged features or options, but Google clearly is eyeing candidates.

Among the most popular Gmail Labs features, according to Coleman: a reminder that makes sure you really have attached an attachment you promised; “Superstars” that let people flag messages not just with yellow stars but with a variety of other colors; pictures in chat to show the face of your instant-messaging contact; and QuickLinks that let people bookmark Gmail interactions such as a search for all unread messages from your mother.

Keith Coleman, Gmail product manager

(Credit: Stephen Shankland/CNET News)

However, Google still has interface refinement and testing work to do before any feature becomes part of the standard Gmail application, Coleman said. Gmail Labs is intended to be a proving ground where new features can be tried sooner rather than later, even if they’re still immature.

However, Gmail Labs is limited to Gmail. The Gmail text-messaging feature doesn’t work with Google’s other instant-messaging options, including the chat gadget that can run on iGoogle or the Google Talk software that can be downloaded and installed on a computer.

Behind the scenes, Gmail Chat sends text messages to people’s phones from a specific Google phone number–one of about 1,000 the company reserved for the purpose–and each pair of people communicating gets to keep that number for future use. That’s handy, Coleman said, because the person who receives the text message can store the Google phone number in his or her address book as a conduit to reach the sender’s computer-based Google chat.

The phone numbers are recycled, Coleman said; the system works because each person probably won’t need more than 1,000 text-message chat contacts.

Recommendation tools are a dime a dozen these days. That’s not necessarily a bad thing though–the more exposure you get to new content, the greater your chances of finding a new favorite. To aid in that search is newcomer Taste Kid, a search tool that provides simple recommendations for music, books, TV shows and movies.

The tool uses previous user searches to figure out how terms are related, which means as time goes by the results are honed, and hopefully more accurate. While each of these results is missing links to purchasing pages and audio samples, each one has a YouTube video which you can view right from the results.

What makes the site particularly useful are the unrelated items which get stuck on the bottom of each exploration page. The site tacks on the most recently added and popular bands, books, TV shows and movies, which turns each result into its own browsing experience. In just a few minutes you can peruse about a dozen videos to find something you like–and of not, a simple click on something you do takes you to another recommendation page to start the process over again.

Where the tool loses some of its luster is the lack of a breadcrumb trail to get you back to your original search, or any sense that it’s getting to know you better. Mufin, a music recommendation tool I took a look at a few weeks back does this, and it makes it a far more engaging experience. Ideally future iterations of the tool will keep track of this with a cookie.

[via TheNextWeb]

Start a deep dive into music, movies and TV show recommendations with Taste Kid, a simple recommendation tool.

(Credit: CNET Networks)

More: continued here

Receipt-scanning service Shoeboxed just launched a new feature that automatically files scanned receipts into one of 15 expense categories. These include groceries, gas, and travel expenses, which you can view simply by clicking on them. Users can also create their own expense categories, although there’s currently no way to have the service auto-tag expenses by keyword.

In addition to new receipts, users will find a good number of their old receipts categorized. Dan Englander, Shoeboxed’s VP of Communications says some may not get the tagging treatment if the system can’t find a match, but that a “large majority” have.

Users of Mint.com and other online banking services have been enjoying auto-categorization for some time now, but keep in mind these places are getting the information digitally. Shoeboxed must first scan your receipts then run them through optical character recognition. The categorization is not just for the scanned receipts though; any online receipts you “CC” Shoeboxed with will get tagged too.

If an item fits into a category it’s now automatically tagged with it for easy sorting later on.

(Credit: Shoeboxed / CNET Networks)

More: continued here

Here we go again. A new company, Reframe It, is launching its Web markup product on Wednesday. Like ThirdVoice and Stickis before it, Reframe It lets you highlight a piece of a Web page, comment on it, and discuss those comments with other visitors to the site.

I found using the service a good community experience, although I believe the concept is dated. For one, nearly all sites now have their own communities and discussion threads, and adding another discussion system could actually splinter a community instead of drawing it together. Furthermore, Reframe It currently works primarily through a browser plug-in (on Firefox and Internet Explorer). Betting on software to carry community is a long shot.

On this New Yorker article, the user highlighted text (in yellow, left) and then commented on that clip in the Reframe It sidebar at right.

The company, though, is actually oriented around making that software dependency into a strength. CEO Bobby Fishkin wrote to me, “Within mass communities we can let members discuss the news as a community, filter for only comments by members, improve fund-raising by helping improve engagement, and drive traffic for these nonprofits with free branded groups.” By which I think he means that he envisions Reframe It being used sort of like a tour bus for the Web, in which groups can see everything out there, but stick together nonetheless.

The service also integrates with other social networks, Fishkin says, so when you’re trolling the Web with Reframe It active you can easily filter out comments from people outside your circle.

All well and good, but I stand by my assertion that the technology has no hope for widespread adoption as a standalone browser extension. To be fair, the company has a widgetized version of the product that publishers can add to their sites. This lets visitors to the site flag items on pages and chat about them. They can’t, though, just go to any site on the Web and have the same experience, as they can if they have the extension. But the tool for publishers is Reframe It’s best avenue for success, even though it competes with other native comment systems (the ones you get on any blogging platform) as well as third-party comment products like Disqus. Alternatively, I could see this concept getting necessary traction, even as an extension, if it was very closely married to an existing social-network platform like Facebook. Reframe It needs a viral distribution push that I don’t think it will get otherwise.

See also: GooseGrade lets readers copyedit your blog.

More: continued here

How popular can a piece of software get before being in “beta” is no longer a legitimate excuse for known software flaws? Or, to put it another way, is it responsible to allow hundreds of thousands of people to install your product, when you know ahead of time that doing so opens them up to attack?

The software visionaries at the Mozilla Corporation, which makes the popular Firefox web browser, have taken the approach that creativity and functionality is king–even if security has to take a backseat. Case in point: The widely praised “Ubiquity” software add-on, which brings an amazingly rich and extensible new form of interaction to the Firefox Web browser.

The technology press has showered praise upon the developers of this software tool. However, in prioritizing functionality over security, Mozilla Labs punted complex trust choices to end users–the vast majority of whom are ill-equipped to make such decisions. The end result is that the hundreds of thousands of users of Ubiquity face a significant risk of browser hijacking by attackers, which could result in the theft of e-mail and online banking account information.

Mozilla’s Ubiquity in Action

The Ubiquity add-on brings a new form of command-driven interaction to the Firefox Web browser. Using the tool, a user can perform actions based on the contents of a page–such as translating the foreign text on a page into English, or generating a Google map of a highlighted address. While this is certainly cool, it is the extreme extendability of Ubiquity that makes it a truly compelling tool.

One of the main design goals for Ubiquity was that it should be extremely easy for users to be able to create their own commands, which they could then share with others. As a result, a useful command can be whipped together in a couple lines of JavaScript–for example, allowing a user to send a Twitter message from within the browser. Aza Raskin, the head of User Experience at Mozilla Labs summed up the goals of Ubiquity in a blog post introducing the tool:

The fundamental problem is that extending the browser, and hence the Web, is too difficult. The closer new browser functionality can be packaged to look like standard HTML and (Javascript), the larger and more diverse a community will create it. The desktop paradigm for extension development, while powerful, has a high cost of adoption. Right now we have a short tail of browser functionality with thousands of add-ons. There should be millions. We can get to that long tail using a more Web-like model for functionality development–tools that are accessible to hobbyists and tinkerers, but that scales to professionals.

Mozilla Labs was hugely successful, and within a week of the first public beta release of Ubiquity, over 100,000 users downloaded and installed the tool. Even more telling, is the number of commands that have been created and shared by users. The Ubiquity Wiki lists 300-plus different commands, while Mozilla’s Raskin wrote in his blog that “thousands of commands (have been) written for Ubiquity” and that “in under a week, we have a roughly comparable number of Ubiquity commands as there are Firefox extensions.”

Mozilla does not release stats on the number of downloads, but given the rapid adoption of the browser add-on, it is quite reasonable to assume that by now it has been installed by at least 250,000 users, if not far more.

The Ubiquity command installation screen

No security, no problem

The success of Ubiquity has come at a high cost–the Mozilla Labs team completely punted on the issue of security, and made users responsible for judging the safety of downloadable Javascript, something that few of the hundreds of thousands of its users are likely able to do.

When a user wishes to install one of the thousands of publicly available Ubiquity commands, they are first taken to bright red warning screen. The user is clearly told the risks that they face should they accidentally install a malicious command, and then they are given the opportunity to read through the command’s JavaScript source code in order to see if it is good or evil.

The vast majority of the users on the Web are not able to read JavaScript. Even those skilled users that know enough to throw together a Ubiquity command or two are unlikely to be able to properly assess the security of someone else’s code. This point can be clearly driven home by looking at the success of the Underhanded C Programming Contest, in which users submit code that “looks” clean and safe, but which actually performs evil actions.

Furthermore, while Mozilla has been surprisingly frank with users about the risks they face when installing commands, this approach of education and disclaimers is simply not enough. It is totally unreasonable to offer a shiny, awesome and powerful new tool to the Internet at large if clicking on a wrong link could result in a user suffering identity theft or worse. Bruce Schneier has often said that humans are really bad at judging risk, and so of course, the vast majority of Ubiquity’s users are going to install foreign and unknown commands, simply because they offer awesome functionality.

Security Warnings in Ubiquity

In addition to the general problems of untrusted JavaScript, Ubiquity also suffers from significant security issues due to the ability to auto-update commands. By checking a box, a user can permit the browser to automatically upgrade commands whenever the author releases a new version. This option creates two major issues.

First, a developer could release a legitimately useful command, wait until thousands of users have subscribed to it, and then send out a malicious update to those users that have enabled auto-updates. Since users only get to see the JavaScript at the time of first install, they face significant risks from future malicious updates.

Second, command updates are currently served via non-encrypted HTTP connections, and the Ubiquity infrastructure lacks the code-signing functionality that is provided to Mozilla add-ons. This creates a significant potential for man-in-the-middle attacks against the Ubiquity update process, particularly when users are connected to the Internet via a public wireless network. Last year, I revealed that a number of toolbars for the Firefox 2.0 browser were vulnerable to this same type of attack. This flaw was eventually fixed by moving the distribution of commercial browser-addon updates to SSL-encrypted servers.

The Mozilla Labs team has recognized these risks, and has plans to fix them at some point in the future. However, for now, users of Ubquity remain vulnerable to attackers, particularly those who have opted to allow automatic updates of commands.

In releasing Ubiquity, the Mozilla team also created a Web site it calls the Herd, which enables users to opt-in to reporting which commands they have installed. Thus, one assumes, if 20,000 other users have installed a command, it is probably safer than one that five other people are using. While better than nothing, Herd is still very new, and due to the pro-privacy opt-in model chosen for data reporting, it only captures a small slice of the Ubiquity user base.

When asked to comment on some of the security issues, Aza Raskin issued the following statement regarding security issues in Ubiquity:

Mozilla Labs is a shared space for exploration for future user experiences on the open Web. It’s a place where we, as a part of larger community, can experiment and iterate on new ways of interacting with the Web, having the Web fundamentally enhance the browsing experience. It’s also a place where we can safely explore new security and trust models among a technically savvy group, before bringing them to a wider audience.

The Herd is one way of trying to involve the community as a corner-stone of solving the security problem. It’s still in its infancy. We are working towards creating an open API so that everyone can pitch in to create a safe place for everyday users to get commands. Just like Ubiquity UI not being right yet, neither is the Herd.

Eventually, I expect there to be hybrid models. Mozilla, and other trusted sources (think folks like Bruce Schneier), will vet core and recommended commands. The Herd, enhanced by numerous metrics of “browser health,” will constantly be watching for bad actors. Clearly, we don’t expect end users to need to read code–and we do plan on adding manifests of some form to sandbox certain types of commands. Right now, however, the emphasis is on empowering verb authors to be generative.

Raskin did not answer specific questions posed by this blogger, and neither he nor Dan Veditz, Mozilla’s security lead, would confirm if the Ubiquity code base was audited by members of Mozilla’s security team before being released to hundreds of thousands of users. I’d be willing to bet a few beers that it hasn’t.

There is of course a legitimate reason to release beta software, even when it has known security flaws. Were Ubiquity available only to those Web programmers proficient in JavaScript, this wouldn’t be an issue. However, when hundreds of thousands of people are using your product, you can no longer reasonably hide behind the claim of “beta.”

More: continued here