From simple experience this is something I have definitely seen to be true for Twitter. From a little over a year ago until today, my sharing has steadily increased and still does.

An interesting detail here is that at first sight his statement  doesn’t actually seem to be worth mentioning. If I share 1 item a day  this year and I share 2 next year. So what?

Fortunately, to illustrate, Mark explains that as humans we have trouble imagining exponential growth.

“If you took a piece of paper and folded it on itself 50 times, how  tall would it be?”, to answer it, “Most people would say a few feet.

Turns out it goes to the moon and back 10 times…

That is way more exciting. Of course, it depends on for how long this  can be said to be true.

But to Mark he sees this as the way forward and the way to think.

You wouldn’t write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection, that’s essentially what you’re doing.

There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. But if HTTPS is more secure, why doesn’t the entire web use it?

HTTPS has been around nearly as long as the web, but it’s primarily used by sites that handle money — your bank’s website or shopping carts that capture credit card data. Even many sites that do use HTTPS use it only for the portions of their websites that need it — like shopping carts or account pages.

Web security got a shot in the arm last year when the FireSheep network-sniffing tool made it easy for anyone to detect your login info over insecure networks — your local cafe’s hotspot or public Wi-Fi at the library. That prompted a number of large sites to begin offering encrypted versions of their services on HTTPS connections.

Even sites like Twitter (which has almost entirely public data anyway) are nevertheless offering HTTPS connections. You might not mind anyone sniffing and reading your Twitter messages en route to the server, but most people don’t want someone also reading their username and password info. That’s why Twitter recently announced a new option to force HTTPS connections (note that Twitter’s HTTPS option only works with a desktop browser, not the mobile site, which still requires manually entering the HTTPS address).

Google has even announced it will add HTTPS to many of the company’s APIs. Firefox users can go a step further and use the HTTPS Everywhere add-on to force HTTPS connections to several dozen websites that offer HTTPS, but don’t use it by default.

So, with the web clearly moving toward more HTTPS connections, why not just make everything HTTPS?

There are some practical issues most web developers are aware of, such as the cost of secure certificates, but obviously that’s not as much of an issue with large web services that have big budgets.

The real problem seems to be that with HTTPS you lose the ability to cache. Not really an issue when servers and clients are in the same continent), but people in Australia (for example) looking at UK content will have better experiences when something can be cached and served without a huge response time.

There’s another small performance hit when using HTTPS, since the SSL initial key exchange adds to the latency.

For sites that don’t have any reason to encrypt anything — in other words, you never log in, so there’s nothing to protect — the overhead and loss of caching that comes with HTTPS just doesn’t make sense. However, for big sites like Facebook, Google Apps or Twitter, many users might be willing to take the slight performance hit in exchange for a more-secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.

Another problem with running an HTTPS site is the cost of operations. Although servers are faster, and implementations of SSL more optimised, it still costs more than doing plain HTTP, while less of a concern for smaller sites with little traffic, HTTPS can add up, if your site suddenly becomes popular.

Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn’t work with virtual hosts. Virtual hosts, which are what the most common cheap web-hosting providers offer, allow the web host to serve multiple websites from the same physical server — hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn’t work at all with HTTPS.

There is a way to make virtual hosting and HTTPS work together — the TLS Extensions protocol — but it’s noted that, so far, it’s only partially implemented. Of course that’s not an issue for big sites, which often have entire server farms behind them. But until that spec — or something similar — is widely used, HTTPS isn’t going to work for small, virtually hosted websites.

In the end there is no real reason the whole web couldn’t use HTTPS. There are practical reasons why it isn’t happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, which will make caching less of a concern, and improved servers will be further optimized for secure connections.

In the future the main concern won’t just be how fast a site loads, as that’ll become an obsolete consideration, but moreover how well it safeguards and protects our data surely?

(cred’ to WebMonkey for the background detail)

The Cabinet Office has published an open source procurement toolkit for the public sector on its website.

It said the purpose is to ensure that there is a level playing field for open source and proprietary software and that some of the myths associated with open source are dispelled.

The options document contains details of different IT functions such as servers, databases, application development, networks and business applications.

The document on cost of ownership advises taking into account issues around acquisition – such as purchase price, licences and integration – operation and management – including migration, upgrades, support services, training and software scaling – and end of life management.

It also advises that the total cost of ownership is only concerned with the financial cost of any solution, and does not involve any other benefits.

The government has had an open source policy dating back to the Labour administration in 2004, although it was reiterated in 2009 and 2010. Before coming to government, the Conservative party called for an increased use of open source technology in government IT systems.

The Government ICT Strategy, published in March, says that open source solutions should be considered alongside proprietary ones in procurement, and that when there is no significant cost difference open source should be chosen on the basis of its flexibility.

• All about Open Source v1 (pdf, 490kb)
• All about Open Source v1 0 (odf, 121kb)
• ICT Advice Note – Procurement of Open Source (pdf, 169kb)
• ICT Advice Note – Procurement of Open Source (odf, 37kb)
• Open Source Options v1.0 (pdf, 581kb)
• Open Source Options v1.0 (odf, 125kb)
• Total Cost of Ownership – things to consider v1.0 (pdf, 124kb)
• Total Cost of Ownership – things to consider v1.0 (odf, 198kb)