Gmail, Googles new Web-based e-mail service, has sparked commentary, controversy and even calls for congressional action. eWEEKs Steve Gillmor explored the perils and possibilities of the free software-as-service in an exclusive conversation with Google co-founder Sergey Brin.
Obviously, there are privacy implications of Gmail that I do want to touch on, but Im just as interested in the opportunities for programmability of this technology. If you could establish an API for this, that would be something really spectacular.
Thats an interesting idea. I havent thought too much prior to your mentioning it now, but there are certainly a variety of processes that I have in the past done with Unix, because I can basically program it to do all kinds of things with my e-mail—forward certain messages automatically, erase other ones automatically, trigger programs—and it would be interesting to consider doing those here.
Much in the same way that youve established keyboard shortcuts, you could establish macros, etc.
Yeah, thats a very good point. One thing Ive been talking to the team about is to be able to save your searches and have easy access to them. For example, I have a search that I often use—show me the unread messages in my inbox that were sent to me directly rather than to a mailing list that Im on. I use that one pretty often, but it would be nice to have it to save and maybe have it attach to a label or something like that.
Could you give me a quick overview of the goals of this project?
It started as an experiment to see if our search could be used on e-mail. And in fact, it was originally applied to my e-mail. I get a lot of e-mail—I have many gigabytes of it, and its hard to manage. I have all the same challenges as everybody out there, and I found that having effective search, having large storage, having the kind of threading that weve done here—all those things make me more efficient with my e-mail. And thats what I then decided that we should make available to the entire world.
Threading—is that what you refer to as conversation in the software?
Exactly. Sorry, we rename things to make them clearer, but yeah, its the conversation.
Next page: Gmail joins the RSS conversation.
Conversation, Gmail
-Style”>
It was interesting to me that you did finally hit on the word conversation. It seems to me that theres a synergy between the elements of the conversation in the RSS space and what youre doing in the e-mail space.
I think thats very true. Part of the things weve seen why blogs and RSS feeds are such a success is that you can actually read it—you dont have to stop, click back and forth, collect bits and pieces here and there—but it is all presented to you as one.
And thats what weve aimed for in the conversations as well, because I dont want to have to hunt and peck around to get the different pieces of the same conversation. I want to be able to see it all at once.
Contrast the dynamics of e-mail, given that its a fire hose of not necessarily welcome information being filtered, whereas the RSS space is the opposite of that—a reputational relationship between authors.
I think thats true. There are a whole bunch of challenges getting e-mail all the way to that point, but one of the nice things that you can do with the conversations is that you know when youre in a conversation. As long as youre interested in one of the messages, then you should be interested in all.
Theres no spam that sneaks into the middle of a conversation. You know whats of interest to you, you know youre going to read the whole thing, and theres going to be nothing else uncontrolled in there.
Going back to the notion of an API, something like 90 percent of all collaboration applications are actually running on e-mail.
Yeah, I can definitely believe that.
And thats not necessarily such a good thing, of course …
Because it has lots of limitations …
Given some of the discussion about privacy and rights, if you could provide API access to those rights—who could read, write, etc. —give that to the user, they could then turn around and use that as a way of arranging relationships between themselves and others, essentially bartering their rights, access to their information, in return for information thats coming to them.
I think thats an interesting idea. We try to be as upfront as we can be, but obviously if their clients, or Web browsers and whatnot, could negotiate these things for them, then we could be even more upfront.
It would take the conversation, if you will, away from whether its the cloud thats making those decisions and put it in the hands of the user.
Thats true, but to be fair, even as it is, we try to make the decision as clear to the user as possible.
Next page: We cant guarantee an instantaneous deletion, Brin says.
Eventual Deletion
Is it possible to delete messages, or does everything continue to reside in AllMail?
Oh, no, no, that was just poor wording on our part. Its just that we make a variety of backups, and we cant guarantee instantaneous deletion. Stuff thats on tapes, and those are offline—we eventually delete it, but we cant guarantee an instantaneous deletion.
The question would be whether or not somebody could feel confident that if they wanted to delete something that it would eventually be deleted.
Yes, eventually it will be deleted.
With social networks, including your Orkut beta site, the idea that you can define a relationship with explicit metadata is somewhat brittle; its difficult to describe the subtleties of whos a friend, etc. Contrast that with what Dave Sifry and I are working on with attention.xml at Technorati and youre doing here: allowing the metadata that already exists in the blogosphere, or in your case, the e-mail space, to be derived from the actual data.
I think that makes a lot of sense. You can do a lot of interesting things if you can just process existing data. One of the examples, and perhaps this stirred up some of the controversy, but next to our messages, we put ads which are related to the message, but we also put related Web pages, which can be a really good service for the user—I find them to be helpful all the time.
I wondered about taking a mailing list I subscribe to and flowing the messages into the architecture. If you had an API, how would you develop it so that it would retain the characteristics of the ad displays as well?
Youre saying, how would we still be able to make money, because people would just take the ads out?
Yes, exactly.
No, I think thats an important question. And in fact, as were working on providing forwarding [and] POP3, thats an important consideration there as well. I dont have a great answer; were still brainstorming.
You could separate the streams but provide them both, because some of the target ads and certainly the related links are valuable information that is only going to come from you.
Thats right, so maybe as long as we provide them, people will find them valuable enough that they will enable them regardless.
Is free storage sufficient attraction for users to commit all of their information inside your service?
Its the storage as well as the search functionality and the other features that weve put in. It really does work well, compared to any other Web mail service that Ive tried.
Next page: Web mail for the enterprise?
Will Gmail Go Corporate
?”>
It also compares favorably to my corporate e-mail.
Well, thank you. There are some things that it is currently missing as compared to corporate e-mail—for example, disconnected operation—though we do plan to provide things like POP3 and IMAP support, which should help that.
But we initially wanted to make sure we have something that was definitely better than all Web mail services, and perhaps, just perhaps, it will also be good enough for a lot of people to use instead of a corporate mail service.
Or they can use both, because they could just forward their messages to Gmail from their corporate e-mail, or the other way around. That way when theyre traveling and dont have their computer with them, they can just use the Gmail version, and when they are at their desk, they can still use their corporate mail.
You mentioned disconnected access. Once youve enabled some sort of forwarding capability for storage, you could hook it up to Groove for access on a plane.
Thats an interesting idea. I hadnt considered Groove, but thats a good idea. I know those guys—I should talk to them.
Getting back to the privacy issue, Groove uses an encrypted XML store. One of the ways you could provide some clarity about the privacy issue would be to push this data through an encrypted store. You could keep the indexes unencrypted, but keep the rest of the data encrypted.
Weve discussed a lot of that—I dont know if youve seen what [Brad] Templeton [chairman of the Electronic Frontier Foundation] has said about encryption ideas—and were looking at a lot of those choices. There are significant technical challenges. I dont know yet how it will pan out.
How long do you think this beta feedback process is going to be?
I think itll take three to six months or so. Were getting a lot of good feedback; weve already made a number of changes. Probably the big ones are feature requests that we need to deal with, and there are some significant ones there. I dont know how many of those well be able to get in prior to making it more broadly available.
Those who are beta-testing it will continue to have access?
Oh yes, yes, Im not suggesting that we would shut it down.
When will we see forwarding and other interchange features?
Those are the big, important ones. The biggest feature requests have been forwarding both into e-mail and out of. Some people dont have a mail system currently that they can easily, automatically forward to Gmail, though there are some third-party solutions which help that as long as we provide the forwarding out. And thats something were working on.
Next page: Brin says Google will keep looking at privacy, encryption issues.
Privacy and Encryption
Are you continuing to discuss privacy and encryption issues with EFFs Brad Templeton?
Yeah, I know Brad quite well, so I am chatting with him. These kinds of things are very substantial things, and I dont think we are going to be able to get them in certainly before broader release. That would really be rearchitecting the whole back end, which might happen at some point, but I doubt well be able to do that within the three- to six-month period.
Are you using the same group of servers you use for your core service?
Theyre the same kind of servers, but theyre sort of in separate clusters.
Obviously, there are some concerns about cross-linking the ability to track searches according to a persons identity.
Right. So, those are run separately. Now, I do think it would be handy at some point to provide functionality like being able to know when you log in to Orkut that you have unread messages, and potentially even when you do a search on Google just being able to find out if you have unread messages or not.
So, I think were going to look very carefully at what kind of functionality we can provide that does not have any kind of privacy implications.
Attention.xml offers a way of tracking what is read and in what order its read at both the RSS feed and item levels. My thought is that we specifically scope this so that we do not have or care about an individuals private information but rather establish the dynamics of the self-forming groups that have similar characteristics.
Thats interesting. The kind of thing a lot of people do: Lets say people keep exchanging conversations, you could automatically suggest they join one of these groups and have some sort of an RSS feed associated with that, and you just give them that option or something like that.
Yes, and in the same way you can print a conversation, you could also print to RSS.
Yeah, thats a very interesting idea.