This time of year I do a lot of online shopping, and my bell rings with many deliveries. But today and tomorrow, not Saturday. The post office comes Saturday but has announced it wants to stop doing that to save money. They do need to save money, but this is the wrong approach. I think the time has come for Saturday and Sunday delivery to be the norm for UPS, Fedex and the rest.

I'm actually not a fan of login and sessions on the web, and in fact prefer a more stateless concept I call authenticated actions to the more common systems of login and "identity."

But I'm not going to win the day soon on that, and I face many web sites that think I should have a login session, and that session should in fact terminate if I don't click on the browser often enough. This frequently has really annoying results -- you can be working on a complex form or other activity, then switch off briefly to other web sites or email to come back and find that "your session has expired" and you have to start from scratch.

There are times when there is an underlying reason for this. For example, when booking things like tickets, the site needs to "hold" your pending reservation until you complete it, but if you're not going to complete it, they need to return that ticket or seat to the pool for somebody else to buy. But many times sessions expire without that reason. Commonly the idea is that for security, they don't want to leave you logged on in a way that might allow somebody to come to your computer after you leave it and take over your session to do bad stuff. That is a worthwhile concept, particularly for people who will do sessions at public terminals, but it's frustrating when it happens on the computer in your house when you're alone.

Many sites also overdo it. While airlines need to cancel your pending seat requests after a while, there is no reason for them to forget everything and make you start from scratch. That's just bad web design. Other sites are happy to let you stay "logged on" for a year.

To help, it would be nice if the browser had a way of communicating things it knows about your session with the computer to trusted web sites. The browser knows if you have just switched to other windows, or even to other applications where you are using your mouse and keyboard. Fancier tools have even gone so far as to use your webcam and microphone to figure if you are still at your desk or have left the computer. And you know whether your computer is in a public space, semi-public space or entirely private space. If a browser, or browser plug-in, has a standardized way to let a site query session status, or be informed of session changes and per-machine policy, sites could be smarter about logging you out. That doesn't mean your bank still should not be paranoid if you are logged in to a session where you can spend your money, but they can be more informed about it.

Today an op-ed by John Sununu and Harold Ford Jr. of "Broadband For America" (a group of cable companies and other ISPs which says it is really a grass-roots organization) declared that the net needs a better pricing model for what Netflix is doing. For a group of ISPs, they really seem to not understand how the internet works and how pricing works, so I felt it was worthwhile to describe how things work with a remarkably close analogy. (I have no association with Netflix, I am not even a customer, but I do stream video on the net.)

You can liken the internet to a package delivery service that works somewhat differently from traditional ones like the postal service or FedEx. The internet's pricing model is "I pay for my line to the middle, and you pay for your line to the middle and we don't account for the costs of individual traffic."

In the package model, imagine a big shipping depot. Shippers send packages to this depot, and it's the recipient's job to get the package from the depot to their house. The shippers pay for their end, you pay for your end, and both share the cost of creating the depot.

Because most people don't want to go directly to the depot to get their packages, a few "last mile" delivery companies have sprung up. For a monthly fee, they will deliver anything that shows up at the depot addressed to you directly to your house. They advertise in fact, that for the flat fee, they will deliver as many packages as show up, subject to a fairly high maximum rate per unit of time (called bandwidth in the internet world.) They promote and compete on this unlimited service.

To be efficient, the delivery companies don't run a private truck from the depot to your house all the time. Instead, they load up a truck with all the packages for your neighbourhood, and it does one delivery run. Some days you have a lot of packages and your neighbours have few. Other days you have few and they have a lot. The truck is sized to handle the high end of the total load for all the neighbours. However, it can't handle it if a large number of the neighbours all want to use a large fraction of their total load on the same day, they just didn't buy enough trucks for that, even though they advertised they were selling that.

This is not unreasonable. A majority of the businesses in the world that sell flat rate service work this way, not just internet companies. Though there are a few extra twists in this case:

• The last mile companies have a government granted franchise. Only a couple can get permission to operate. (In reality -- only a few companies have got permission to have wires strung on poles or under the street.)
• Some of the last mile companies also used to be your exclusive source for some goods (in this case phone service and TV) and are concerned that now there are competitors delivering those things to the customers.

The problem arises because new services like Netflix suddenly have created a lot more demand to ship packages. More than the last mile companies counted on. They're seeing the truck fill up and need to run more trucks. But they proudly advertised unlimited deliveries from the depot to their customers. So now, in the op-ed, they're asking that companies like Netflix, in addition to paying the cost of shipping to the depot, pay some of the cost for delivery from the depot to the customer. If they did this, companies would pass this cost on to the customer, even though the customer already paid for that last mile delivery.

ICANN is meeting in San Francisco this week. And they're getting closer to finally implementing a plan they have had in the works for some time to issue new TLDs, particularly generic top level domains.

In media today, it's common to talk about three screens: Desktop, mobile and TV. Many people watch TV on the first two now, and tools like Google TV and the old WebTV try to bring interactive, internet style content to the TV. People like to call the desktop the "lean forward" screen where you use a keyboard and have lots of interactivity, while the TV is the "lean back" couch-potato screen. The tablet is also distinguishing itself a bit from the small screen normally found in mobile.

More and more people also find great value in having an always-on screen where they can go to quickly ask questions or do tasks like E-mail.

I forecast we will soon see the development of a "fourth screen" which is a mostly-always-on wall panel meant to be used with almost no interaction at all. It's not a thing to stare at like the TV (though it could turn into one) nor a thing to do interactive web sessions on. The goal is to have minimal UI and be a little bit psychic about what to show.

One could start by showing stuff that's always of use. The current weather forecast, for example, and selected unusual headlines. Whether each member of the household has new mail, and if it makes sense from a privacy standpoint, possibly summaries of that mail. Likewise the most recent status from feeds on twitter or Facebook or other streams. One could easily fill a screen with these things so you need a particularly good filter to find what's relevant. Upcoming calendar events (with warnings) also make sense.

Some things would show only when important. For example, when getting ready to go out, I almost always want to see the traffic map. Or rather, I want to see it if it has traffic jams on it, no need to show it when it's green -- if it's not showing I know all is good. I may not need to see the weather if it's forecast sunny either. Or if it's raining right now. But if it's clear now and going to rain later I want to see that. Many city transit systems have a site that tracks when the next bus or train will come to my stop -- I want to see that, and perhaps at morning commute time even get an audio alert if something unusual is up or if I need to leave right now to catch the street car. A view from the security camera at the door should only show if somebody is at the door.

There are so many things I want to see that we will need some UI for the less popular ones. But it should be a simple UI, with no need to find a remote (though if I have a remote -- any remote -- it should be able to use it.) Speech commands would be good to temporarily see other screens and modes. A webcam (and eventually Kinect style sensor) for gestural UI would be nice, letting me swipe or wave to get other screens.

You may have heard of Bus Rapid Transit -- a system to give a bus line a private or semi-private right-of-way, along with bus stops that are more akin to stations than bus shelters (with ticket-taking machines and loading platforms for multiple doors.) The idea is to make bus transit competitive with light-rail (LRT) in terms of speed and convenience. Aside from getting caught in slow traffic, buses also are slow to board. BRT is hoped to be vastly less expensive than light rail -- which is not hard because LRT (which means light capacity rail, not lightweight rail) has gotten up to $80 to $100M per mile. When BRT runs down the middle of regular roads, it gets signal timing assistance to help it have fewer stops. It's the "hot new thing" in transit. Some cities even give it bits of underground or elevated ROW (the Boston Silver Line) and others just want to wall off the center of a road to make an express bus corridor. Sometimes BRT gets its own highway lane or shares a special carpool lane.

At the same time just about anybody who has looked at transit and the internet has noticed that as the buses go down the street, they travel with tons of cars carrying only one person and lots of empty seats. Many have wondered, "how could we use those empty private car seats to carry the transit load?" There are a number of ride-sharing and carpooling apps on web sites and on smartphones, but success has been modest. Drivers tend to not want to take the time to declare their route, and if money is offered, it's usually not enough to counter the inconvenience. Some apps are based on social networks so friends can give rides to friends -- great when it works but not something you can easily do on demand.

But one place I've seen a lot of success at this is the casual carpooling system found in a number of cities. Here it's very popular to cross the Oakland-SF Bay Bridge, which has a $6 toll to cross into SF. It used to be free for 3-person carpools, now it's $2.50, but the carpools also get a faster lane for access to the highly congested bridge both going in and out of SF.

Almost all the casual carpool pickup spots coming in are at BART (subway) stations, which are both easy for everybody to get to, and which allow those who can't get a carpool to just take the train. There is some irony that it means that the carpools mostly take people who would have ridden BART trains, not people who would have driven, the official purpose of carpool subsidies. In the reverse direction the carpools are far fewer with no toll to be saved, but you do get a better onramp.

People drive the casual carpools because they get something big for for it -- saving over $1,000/year, and hopefully a shorter line to the bridge. This is the key factor to success in ride share. The riders are saving a similar amount of money in BART tickets, even more if they skipped driving.

Let's consider what would happen if you put in the dedicated lane for BRT, but instead of buses created an internet mediated carpooling system. Drivers could enter the dedicated lane only if:

• They declared their exit in advance to the app on their phone, and it's far enough away to be useful to riders.
• They agree to pick up riders that their phone commands them to.
• They optionally get a background check that they pay for so they can be bonded in some way to do this. (Only the score of the background check is recorded, not the details.)

Riders would declare their own need for a ride, and to what location, on their own phones, or on screens mounted at "stops" (or possibly in nearby businesses like coffee shops.) When a rider is matched to a car, the rider will be informed and get to see the approach of their ride on the map, as well as a picture of the car and plate number. The driver will be signaled and told by voice command where to go and who to pick up. I suggest calling this Carpool-Rapid-Transit or CRT.

Passwords are in the news thanks to Gawker media, who had their database of userids, emails and passwords hacked and published on the web. A big part of the fault is Gawker's, who was saving user passwords (so it could email them) and thus was vulnerable. As I have written before, you should be very critical of any site that is able to email you your password if you forget it.

Some of the advice in the wake of this to users has been to not use the same password on multiple sites, and that's not at all practical in today's world. I have passwords for many hundreds of sites. Most of them are like gawker -- accounts I was forced to create just to leave a comment on a message board. I use the same password for these "junk accounts." It's just not a big issue if somebody is able to leave a comment on a blog with my name, since my name was never verified in the first place. A different password for each site just isn't something people can manage. There are password managers that try to solve this, creating different passwords for each site and remembering them, but these systems often have problems when roaming from computer to computer, or trying out new web browsers, or when sites change their login pages.

The long term solution is not passwords at all, it's digital signature (though that has all the problems listed above) and it's not to even have logins at all, but instead use authenticated actions so we are neither creating accounts to do simple actions nor using a federated identity monopoly (like Facebook Connect). This is better than OpenID too.

Yesterday we had a meeting using some videoconferencing. In a situation I find fairly common, the setup was a meeting room with many people, and then a small number of people calling in remotely. In spite of this being a fairly common situation, I have had trouble finding conferencing systems that do this particular task very well. I have not been looking in the high-priced end but I believe the more modestly priced tools should be able to focus on this and make it work. Yesterday we used Oovoo, one of the few multi-part conference systems to support PC and Mac, with some good but many bad results.

The common answer, namely a speakerphone on the meeting room table and a conference bridge system, is pretty unsatisfactory, though the technology is stable enough that it is easy to get going. The remote people are never really part of the meeting. It's harder for them to engage in random banter, and the call fidelity is usually low and never better than PSTN phone quality. They usually have trouble hearing some of the people in the meeting room, though fancier systems with remote microphones help a bit with that.

The audio level

The next step up is a higher quality audio call. For this Skype is an excellent and free solution. The additional audio quality offers a closer sense of being in the room, and better hearing in both directions. It comes with a downside in that tools like Skype often pick up ambient noise in the room (mostly with remote callers) including clacking of keyboards, random background noises and bleeps and bloops of software using the speakers of the computer. While Skype has very good echo cancellation for those who wish to use it in speakerphone mode, I still strongly recommend the use of headsets by those calling in remotely, and even the judicious use of muting. There's a lot more Skype and others could do in this department, but a headset is a real winner, and they are cheap.

Most of these notes also apply to video calling which of course includes audio.

Today an interesting paper (written with the assistance of the EFF) was released. The authors have found evidence that governments are compromising trusted "certificate authorities" by issuing warrants to them, compelling them to create a false certificate for a site whose encrypted traffic they want to snoop on.

I'm at DLD in Munich, and going to Davos tomorrow. While at DLD I made a brief mention during a panel on identity and tracking of my concept of the privacy dangers of the AIs of the future, which are able to extract things from recorded data (like faces) that we can't do today.

I mentioned a new idea, however, which is a search engine which focuses on the negative, because though advanced algorithms it can tell the difference between positive and negative content.

These days it is getting very common to make videos of presentations, and even to do live streams of them. And most of these presentations have slides in Powerpoint or Keynote or whatever. But this always sucks, because the camera operator -- if there is one -- never moves between the speaker and the slide the way I want. You can't please everybody of course.

There's a phenomenon we're seeing more and more often. A company screws over a customer, but this customer now has a means to reach a large audience through the internet, and as a result it becomes a PR disaster for the company. The most famous case recently was United Breaks Guitars where Nova Scotia musician David Carroll had his luggage mistreated and didn't get good service, so he wrote a funny song and music video about it.

I think URL shorteners are are a curse, but thanks to Twitter they are growing vastly in use. If you don't know, URL shorteners are sites that will generate a compact encoded URL for you to turn a very long link into a short one that's easier to cut and paste, and in particular these days, one that fits in the 140 character constraint on Twitter.

(Update: I had a formatting error in the original posting, this has been fixed.)

A few weeks ago when I wrote about the non deployment of SSL I touched on an old idea I had to make web transactions vastly more efficient. I recently read about Google's proposed SPDY protocol which goes in a completely opposite direction, attempting to solve the problem of large numbers of parallel requests to a web server by multiplexing them all in a single streaming protocol that works inside a TCP session.

While calling attention to that, let me outline what I think would be the fastest way to do very simple web transactions. It may be that such simple transactions are no longer common, but it's worth considering.

Consider a protocol where you want to fetch the contents of a URL like "www.example.com/page.html" and you have not been to that server recently (or ever.) You want only the plain page, you are not yet planning to fetch lots of images and stylesheets and javascript.

Today the way this works is pretty complex:

1. You do a DNS request for www.example.com via a UDP request to your DNS server. In the pure case this also means first asking where ".com" is but your DNS server almost surely knows that. Instead, a UDP request is sent to the ".com" master server.
2. The ".com" master server returns with the address of the server for example.com.
3. You send a DNS request to the example.com server, asking where "www.example.com is."
4. The example.com DNS server sends a UDP response back with the IP address of www.example.com
5. You open a TCP session to that address. First, you send a "SYN" packet.
6. The site responds with a SYN/ACK packet.
7. You respond to the SYN/ACK with an ACK packet. You also send the packet with your HTTP "GET" reqequest for "/page.html." This is a distinct packet but there is no roundtrip so this can be viewed as one step. You may also close off your sending with a FIN packet.
8. The site sends back data with the contents of the page. If the page is short it may come in one packet. If it is long, there may be several packets.
9. There will also be acknowledgement packets as the multiple data packets arrive in each direction. You will send at least one ACK. The other server will ACK your FIN.
10. The remote server will close the session with a FIN packet.
11. You will ACK the FIN packet.

You may not be familiar with all this, but the main thing to understand is that there are a lot of roundtrips going on. If the servers are far away and the time to transmit is long, it can take a long time for all these round trips.

It gets worse when you want to set up a secure, encrypted connection using TLS/SSL. On top of all the TCP, there are additional handshakes for the encryption. For full security, you must encrypt before you send the GET because the contents of the URL name should be kept encrypted.

A simple alternative

Consider a protocol for simple transactions where the DNS server plays a role, and short transactions use UDP. I am going to call this the "Web Transaction Protocol" or WTP. (There is a WAP variant called that but WAP is fading.)

1. You send, via a UDP packet, not just a DNS request but your full GET request to the DNS server you know about, either for .com or for example.com. You also include an IP and port to which responses to the request can be sent.
2. The DNS server, which knows where the target machine is (or next level DNS server) forwards the full GET request for you to that server. It also sends back the normal DNS answer to you via UDP, including a flag to say it forwarded the request for you (or that it refused to, which is the default for servers that don't even know about this.) It is important to note that quite commonly, the DNS server for example.com and the www.example.com web server will be on the same LAN, or even be the same machine, so there is no hop time involved.
3. The web server, receiving your request, considers the size and complexity of the response. If the response is short and simple, it sends it in one UDP packet, though possibly more than one, to your specified address. If no ACK is received in reasonable time, send it again a few times until you get one.
4. When you receive the response, you send an ACK back via UDP. You're done.

The above transaction would take place incredibly fast compared to the standard approach. If you know the DNS server for example.com, it will usually mean a single packet to that server, and a single packet coming back -- one round trip -- to get your answer. If you only know the server for .com, it would mean a single packet to the .com server which is forwarded to the example.com server for you. Since the master servers tend to be in the "center" of the network and are multiplied out so there is one near you, this is not much more than a single round trip.

I just returned from Jeff Pulver's "140 Characters" conference in L.A. which was about Twitter. I asked many people if they get Twitter -- not if they understand how it's useful, but why it is such a hot item, and whether it deserves to be, with billion dollar valuations and many talking about it as the most important platform.

Some suggested Twitter is not as big as it appears, with a larger churn than expected and some plateau appearing in new users. Others think it is still shooting for the moon.

It seems that with more and more of the online transactions I engage in -- and sometimes even when I don't buy anything -- I will get a request to participate in a customer satisfaction survey. Not just some of the time in some cases, but with every purchase. I'm also seeing it on web sites -- sometimes just for visiting a web site I will get a request to do a survey, either while reading, or upon clicking on a link away from the site.

Twenty years ago (Monday) on June 8th, 1989, I did the public launch of ClariNet.com, my electronic newspaper business, which would be delivered using USENET protocols (there was no HTTP yet) over the internet.

ClariNet was the first company created to use the internet as its platform for business, and as such this event has a claim at being the birth of the "dot-com" concept which so affected the world in the two intervening decades. There are other definitions and other contenders which I discuss in the article below.

As you may know, I allow anonymous comments on this blog. Generally, when a blog is small, you don't want to do too much to discourage participation. Making people sign up for an account (particularly with email verification) is too much of a barrier when your comment volume is small. You can't allow raw posting these days because of spammers -- you need some sort of captcha or other proof-of-humanity -- but in most cases moderate readership sites can allow fairly easy participation.

Ok, admit it, who likes blogging in to a vacuum. You want to know how many people are actually reading your blog.

I have created a simple Perl script that scans your blog's log file and attempts to calculate how many people read the blog and the RSS feeds.

You can download the feed reader script. I release it under GPL2.

Recently, while keynoting the Freedom 2 Connect conference in Washington, I spoke about some of my ideas for fiber networks being built from the ground up. For example, I hope for the day when cheap kits can be bought at local stores to fiber up your block by running fiber through the back yards, in some cases literally burying the fiber in the "grass roots."