Blogging

Some of the tweaks that arrived with the launch of Gmail Labs are fairly silly (Mail Goggles and Old Snakey spring to mind), but a new option that arrived Thursday makes it increasingly apparent that Google is doing something right with the e-mail service.

The company launched Advanced IMAP Controls in Gmail Labs, a feature that lets users fine-tune the behavior of the IMAP (Internet Message Access Protocol) technology that outside e-mail services or software can use to access Gmail accounts. For example, you can limit which of your mail labels are exposed as folders to outside e-mail clients to improve performance. That’s useful, according to the Gmail blog posting, “if you find your mail client choking on a big [Gmail]/All Mail folder,” the often-overstuffed location where Gmail messages are archived so they’re still available but not in the way.

Of course, technically savvy folks might enjoy this option. But the bigger reason this is interesting is it shows how flexible an infrastructure Google has built under Gmail. That’s powerful because the company can monitor how often people use the options and how that affects Gmail’s performance and utility.

And because the Gmail Labs options are largely independent of each other, Google can test many improvements simultaneously. The overall approach lets the company gradually morph Gmail rather than release massive, disruptive overhauls. Perpetual flux aside, though, I still think it’s time to take Gmail out of beta.

(Via Google Operating System.)

Gmail Labs lets people fine-tune settings for IMAP, which is used to let other e-mail software access mail stored with Gmail.

(Credit: Google)

Read the original:
Google fine-tunes Gmail’s IMAP access options

“We are going to lose some good companies.” That’s the warning cry from investors in tech these days.

Some we won’t miss, of course: the lame, me-too, or single-featured “products” masquerading as businesses. But be prepared. Some Web 2.0 start-ups that are well-loved by many are in serious danger of falling off the cliff.

The problem is that being loved is no guarantee for success. Even being used isn’t enough. Remember Kozmo, the munchie messenger service from the last bubble? Not a person who used it didn’t love it. In the interest of building a user base, the company was OK with losing money on every transaction in its early days. But when the time came for it to become a real business, it was too late. It couldn’t transition to a viable company, and it folded. It was a tragedy.

Here, in no particular order, are 11 online services companies that could face a similar fate. Several of them are 2008 Webware 100 winners. Like I said, popularity isn’t enough.

Twitter

Although well-used by many and even relied upon by some (like me), Twitter has yet to turn on a revenue model. It’s not like the company would lose users, if it set up a minor advertising strategy as a test; people want to see the company make some money. Please, Twitter, turn on the revenue before it’s too late.

Meebo

This is one of the coolest online communication companies I’ve seen. I like its products and services. But the revenues for running branded chat rooms cannot be all that large. Meebo belongs under the wing of a larger company like Facebook or Microsoft, but with Meebo’s expensive valuation and the coming cutback in M&A, I fear that its exits may be blocked.

TripIt

A very useful service for organizing travel information. Wait, travel? Who’s going to be traveling more often during the economic storm we’re heading into? People are going to sit at home on their mattresses filled with cash, teleconference instead of go on business trips, and take vacations in their backyards. I fear for this company and other clever travel start-ups.

Zillow

The real-estate site’s revenue model is advertising. Real estate and bank advertising. Unless the real-estate research site starts charging for foreclosure listings, I don’t see it doing too well in a hunkered-down economy, in which people are trying to hold on to their homes for dear life, not upgrade.

Pandora

People love this product. It helps them find music they like. What’s wrong with that? Here’s what: unfavorable royalty rates could make it too expensive to run. Survival depends on ongoing negotiations with the music industrial complex. They appear to be going well, but the company is very exposed.

Second Life

The Web interface and social network of the future. Except that it’s expensive to run, hard to use, and suffers from empty-restaurant syndrome.

Skype

The revolutionary VoIP service was acquired by eBay, which someday may be seen as its downfall. A noncore service to the auction site, eBay may well want to spin off Skype to maintain focus. But who would buy it at the valuation that would make eBay stockholders comfortable?

Ask

Why isn’t it dead yet? It’s really a good search engine, and even a small piece of the search economy can generate significant revenues. But running fourth place in a three-horse race is not a good position to be in when the costs of competing are high, as they are in the search market.

DailyMotion

This popular mostly European video-sharing site isn’t under the protection of a major moneymaker like YouTube is, and it hasn’t yet found a way to offset its streaming costs with advertising revenue.

Netvibes

Here’s another product I have used and still like a great deal (occasional frustrating slowdowns notwithstanding), but that has a limited upside as a standalone business.

Netvibes’ much smaller competitor, Pageflakes, was acquired earlier this year, and that’s what needs to happen with Netvibes. But media companies–the natural acquirers for Netvibes–are about to get hammered by a retrenching advertising market, and that may spell the end of Netvibes’ survival plan. (The upcoming release of a Facebook product might help growth, but I don’t think that’s the real issue Netvibes is facing.)

MySpace

Walking dead. Although it’s under the aegis of Rupert Murdoch, the notoriously ruthless businessman could easily cut loose this social network of yesterday. The momentum is certainly not with this one.

See also: The tech downturn: How long and how bad?

More here:
Today’s Kozmos?: 11 potentially doomed dot-coms

Social-network builder Ning has deployed its support for developer applications for OpenSocial, something that it has been planning to do since Google kick-started the open-source project nearly a year ago. (It is now an independent organization.)

A Ning profile with the OpenSocial 'BuddyPoke' app added.

(Credit: Ning)

As part of the launch, a directory of 30 applications will be available for Ning members to embed in their profiles, which they use for any of the hundreds of thousands of networks created with Ning. They’ll have variable “skins” to adopt the design of the profile around them and blend in, the company has said. Incorporation into the OpenSocial app directory on Ning will be selective, so it won’t be a developer free-for-all.

A few OpenSocial apps had gone live on Ning in beta over the past year, including one from social music service Last.fm (which is owned by CNET News publisher CBS Interactive).

You still can’t embed OpenSocial apps on Ning networks, just profiles–but that will change, CEO Gina Bianchini said to CNET News, when future versions of OpenSocial (the current one is 0.7) are developed. “In its first incarnation, it looks and feels a lot like what you’d be doing on a MySpace profile or on a Facebook profile in terms of adding apps,” she explained, “but what’s unique about us is that we have half a million social networks and they’ll want an app for their network as well.”

From the Future of Web Apps conference in London, Google engineer Kevin Marks praised the incorporation of Ning into OpenSocial, which he helped build. “The nice thing about Ning is that we’re going from about 100 social networks to about 500,000 social networks,” Marks said to CNET News.

The question still remains, though as to whether Ning would opt to support Facebook applications–still not compatible with OpenSocial–the way social network Friendster has.

“We’d love to support Facebook apps,” said Bianchini, who co-founded Ning with veteran entrepreneur Marc Andreessen. “Right now, Facebook hasn’t neccessarily set it up in a really clear, programmatic way…(Facebook) has talked about it, then came back from it, and it’s a little bit in limbo right now in terms of really what and how they would want other social networks to support Facebook apps.”

Read the original here:
Ning’s OpenSocial support goes live

AOL has begun notifying bloggers who’ve used its Journals site that they should move their content to Google’s Blogger or bid it adieu.

The company, which is winnowing down its properties to improve its financial performance, published a notice last week that it’s closing its AOL Journals blog site as well as its Hometown/FTP site for hosting Web pages on October 31. And now it’s begun sending users notices that it’s time to move.

AOL set up a partnership with Google’s Blogger.com so that people can migrate their blogs, and Jack Krupansky is one user who made the move successfully. “It was mostly painless since I already have a Google account and a number of Blogger blogs,” he said in a blog posting. He did have to manually republish all the old blogs, though.

Krupansky also quoted a reminder letter AOL sent him:

Dear AOL Journals user,

As we wrote in an e-mail on Sept. 30, AOL(R) Journals will permanently shut down on Oct. 31. It’s never an easy decision to shut down a feature, especially one like AOL Journals that some of our members have used for a long time. But with a decline in Journals usage, we have to look carefully at all of AOL’s features to make sure we’re providing as much value to our members as possible.

Though we know this might be an inconvenience, the good news is that we’ve partnered with Blogger.com to provide a smooth transition for your journal. Blogger is a free service from Google that makes it easy to share your thoughts with friends and the world. Blogger supports most of the features you’ve come to expect from AOL Journals, and it’s easy to get started. If you wish to transfer your journal to Blogger, they will move your posts, comments and photos to your new blog on their service. When you’re ready, go to this link to get started.

Remember, it’s very important to save your Journals content before Oct. 31. If you choose not to move to Blogger, you’ll need to save your information manually (for example, by copying and pasting its contents into a word processor).

Again, we appreciate your patience and understanding as we make this transition, and we hope you enjoy using Blogger.com.

Sincerely,

The AOL Journals Team

AOL didn’t arrange such a smooth transition for the Hometown service. “Unfortunately, we’re not able to offer a replacement Web hosting option at this time. If you go to AOL Search and search for “Web Hosting,” you will find reviews of different services and viable options,” the company said, and members need to manually download their files stored at the site.

Read the rest here:
AOL steers Journals bloggers to Google service

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 back-seat. 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 have 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 email 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+ 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 that 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 have recognized these risks, and have 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 website they call 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 5 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 it’s 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.”

Read more from the original source:
With ‘Ubiquity,’ Mozilla chooses functionality over security