As new G+’ers, I imagine many of us scurry about busily categorizing or tagging these people we know, or sort of know, or might know but can’t quite remember, or don’t know at all.  I find myself falling into a pattern of creating circles by workplace, school, or other “where I met them” sort of context.  Pretty soon you’re looking at a dozen different circles.

It’s all neat and tidy (sort of), but my realization now is: When am I going to use these carefully crafted circles? I’m having difficulty imagining a situation where I’d post something only to my Borland colleagues and have reason not to post it to my Microsoft colleagues or for that matter to the general public.

Am I going to become my own Amazon Turk and presort my outgoing posts, sending them only to the people I think would be interested?  Not likely. I know they don’t really read my posts anyway.

On a different level, there is the argument that people who post are desiring to be heard.  So why restrict the scope of your audience by only posting to a circle of contacts?

One communication vector G+ Circles could easily replace is topic oriented or regional mailing lists.  We have a few of these here in the Santa Cruz Mountains to share information p2p about wildfires, road closures, storm damage, local merchants and events.  It wouldn’t be a stretch to imagine a publicly listed circle that people could attach themselves to (inverse of the current Circles paradigm) that provides a service similar to the email mailing list, but without all the subscribe/unsubscribe headaches.

One tidbit that new G+’ers seem to get excited about is the potential to use these Circles to limit distribution of some of their posts, in the sense of having private conversations. This really bugs me, because this is how we lull ourselves into using good tools for the wrong job.  It’s a bad idea to approach Google+ with privacy in mind.  It’s a microblogging publishing platform.  It may have some new knobs to publish to a group slightly smaller than 7 billion people, but don’t kid yourself into thinking limited distribution is privacy.

There is certainly a noble case for being able to post certain personal or sensitive items only to immediate family, (and for posting something *not* to immediate family!).  I can appreciate that argument.  Really, I can – it would be nice to be able to post vacation updates to a select group of family and friends  without telling the whole world that our home is empty and ready to be burgled. I get that.

As appealing as that scenario is, it still makes me uneasy. It’s tempting, but it does not silence the little voice in my head reminding me of the online mantra I learned firsthand at an early age:

If it’s sensitive enough that you wouldn’t want some individual or group to find out about what you said, don’t post it.  Anywhere. Period.

The Google Circles technology may be flawless – or not.  There are plenty of ways for technology to “leak” the wrong bits in the wrong direction, but technology isn’t our greatest or most common mode of failure.  That honor goes to the lump at the organic side of the human/machine interface who is still perfectly capable of screwing things up big time by posting the wrong thing to the wrong group.  Sometimes that lump is me.  Sometimes it’s a friend with whom I’ve shared or entrusted a little bit too much detail. And sometimes the lump posting the wrong stuff to the wrong place is just a congressman from New York.

Having streams of public and private conversations in the same place definitely does not help. We’ve all seen the email follow-up snarky remark that went to “Reply All” instead of “Reply to Sender” and cringed. Or pasted that rude (but hilarious) URL into the wrong IM window. (yikes)

Google Circles is no better and no worse.  Google Circles makes it easy for you to select which subgroup you want to post to, but everyone in that subgroup has the ability to share your post further, outside your control.  Google+ even reminds you of this with a little popup text to be respectful of the original poster’s intent when you share someone else’s limited distribution post.  Yes, you can disable resharing of your posts on G+, but that doesn’t prevent copy & paste or screenshots from helping your post jump the privacy fence.

If you believe there is some truth to the notion that information is hard to keep contained, then you have to accept that anything you post has the potential to “get out” and be visible to a much larger audience than you intended. The simplest way to deal with that reality is to treat everything you post as eventually becoming public information.

Thus far, my work to carefully sort and tag my contacts into their soothing blue pigeonholes is turning out to be all for naught. The blue circles float there largely unused because just about anything I would post anywhere I would post as public, not to any particular circle. Maybe I should start a mailing list…

Share/Bookmark

I have no opinion on whether hash-bang URLs are the new root of all evil, but I do have a few observations about hash-bangs that weren’t mentioned by Davies.

As Davies mentioned, a hash-bang URL is a URL that contains a URL fragment, set off from the rest of the URL by the # character, such as a Twitter profile URL: http://twitter.com/#!/danny_thorpe.  Davies delves into the Google origins of the hash-bang pattern intended as a means to help search engines index dynamically loaded AJAX web sites and how changing from a “normal” URL to a hash-bang URL impacts search engine web crawlers and page indexing.

URL Cache Equivalence Ignores Fragments

The hash-bang URL pattern also has significant impact on the browser client side of the equation. The browser does not consider differences in URL fragments significant when comparing two URLs for cache equivalence.  The browser will consider “http://twitter.com/#!/danny_thorpe” to be URL equivalent to “http://twitter.com/#!/somebody_else” when deciding whether to fetch the URL content in the browser cache or start a new network request to fetch the HTML page from the server.

This can be used to improve page loading time.  Put all of your static content in the HTML page at the URL base address (eg http://twitter.com/) and let the URL fragment specify the dynamic content that needs to be loaded by JavaScript code to fill in the content areas of the static HTML.  In this scheme, hopping around between different twitter profile pages should only need to download the static HTML content once and only download the actual dynamic content for each user.  After the first profile page loads the static HTML content into the browser’s local page cache, visits to other profile pages should all load from the cache.

When your static HTML content makes up the bulk of your page and the dynamic content is an accessory or minor component, this scheme should make for pages that load faster in the browser because the static HTML content is usually already in your local cache.  If each twitter profile were on a “normal” URL with no URL fragments, the browser would have to load the static HTML content for every profile page, and each of those pages would be stored separately in the browser cache.

Fragments Leave No Footprints

Another side effect of using URL fragments is that the fragments don’t appear in the browser history.  As a result of the URL equivalence rules ignoring URL fragments, multiple URLs that differ only in fragment will only appear as one entry in the browser history.  This makes sense if you are using URL fragments as they were originally intended – to reference specific subsections of the same base page.

We used this artifact to our advantage when implementing secure cross-domain communication via URL fragments – we could pass data in the URL fragment multiple times without polluting the browser history.

When URL fragments are used to specify different content this browser history “singularity” becomes a problem – hopping between URLs with the same base but different fragments (to see different twitter profile pages, for example) leaves only one URL in the browser history.  URL fragments leave no footprints.

If you try this in the Twitter web UI, you’ll find that visiting multiple profiles actually does create entries in your browser history.  I’m pretty sure that happens only because the Twitter pages are injecting entries into the browser history using JavaScript.

While I’m not sure I agree with all of Davies rants against LifeHacker, I will agree that building an entire content system solely on the hash-bang URL pattern with no appreciable static HTML content independent of JavaScript is probably not the best use of the hash-bang URL pattern.

Share/Bookmark

This is often called elastic computing, referring to cloud computing’s ability to increase or decrease the number of nodes in use more or less on the fly, usually in response to fluxuations in demand.  Pay for the cloud services when you really need them, then turn them off and pay nothing when you don’t need them. 

There are two small problems with the plan as described by Maarten: 

1. Getting your data into the cloud. If your web app doesn’t require enormous data on the server, you can probably get by with copying data up to the cloud as part of the transition script and copying it back when returning the service to running in your own data center after the peak load has passed.  The problem here is, copying all that data will take time, and lengthen the time to transfer execution of your service to the Azure cloud.
   Another option would be to give your cloud app access to your internal databases using IPSec secured back-links into your private network datacenter (codenamed Sydney).  In this mode, you’re using the cloud as your web front-end to handle the brunt of your peak load.  You’ll need to verify that your backend is not the bottleneck in peak load conditions for this to work.
2. Azure takes WAY too long to spin up a new hosted service for on-demand elastic computing to really work. Azure take 15 to 20 minutes to spin up a new hosted service, regardless of its size or complexity.  Large or complex deployments will take longer to spin up. 

When your internal server monitors start to notice your internal servers are having trouble keeping up with inbound web requests, can you really survive for 30 minutes until you can start shunting traffic to a newly deployed Azure service? Doubtful.  Many a website has been brought down in 10 minutes by a mention on Slashdot or MSN.

What might work better for dynamic peak load shaving is to keep one instance of your web app running in Azure – a hot standby – and ramp up the number of available nodes by issuing an update to the service config when you need more compute power.  Azure can update the configuration of an existing service much faster than it can deploy a completely new service.

There are other elastic computing scenarios that work much better with Azure.  If your service is only used during certain well-known periods of the day (live stock market analysis 9am-4pm ET, for example) you can automate shutting down the service during periods of non-use and starting it back up again before the workday begins, and reduce your hosting costs by nearly 50% compared to running the service all day and all night. 

If you can anticipate peak load periods, you can spin up your Azure cloud service before the wave hits.  For example, Amazon.com has observed surges in web activity on their retail site that correspond directly to lunch time in the Eastern, Central, and Pacific time zones, and again right around end of the workday in each timezone.  It would be pretty straightforward to scale up your nodes in anticipation of these well known, predictable peak load periods, and scale them back afterwards. 

The key point is that this type of scaling happens on a schedule, completely independent of actual real-time load analysis, so Azure’s long boot up time is not an issue.

Share/Bookmark

Web Of Trust enables individuals to obtain personal digital certificates without having to go through costly corporate or government paperwork. The idea is that if several trusted WoT members (notaries) assert that they have met the person and verified their government issued identity documents (passport, drivers license) match their WoT identity claims, then the person is probably legitimate and can be issued a trusted WoT digital certificate containing their actual name and email address.  The main purpose of WoT is to enable people to create trustworthy online identities by eliminating fake accounts (“sock puppets”) and impersonators.

WoT personal digital certificates can be used to to cryptographically sign or encrypt email text using S/MIME standards. Encrypted emails cannot be read except by the person the message is addressed to. Cryptographically signed emails are sent as clear text, but the recipients can verify that the message was sent by you and has not been modified in transit.

I joined WebOfTrust at its inception in the summer of 1999.  My WoT identity was essentially signed by ‘root’ – I met with a vice president of Thawte in San Francisco to verify my documents and chat briefly about the program. Thawte is based in South Africa (acquired by Verisign in 2000) and sent a small team on a coast to coast tour of the US to seed the WoT trust system with notaries. As I recall, San Francisco was also the first city in that tour.  WoT notaries make identity assertions to help others achieve trusted status with very little involvement (or expense) to Thawte.  You need trust assertions from at least 3 WoT notaries to achieve trusted status.

As a WoT notary, I’ve made quite a few identity assertions for folks in the Santa Cruz area over the years.  Nothing particularly interesting to report there.  What is interesting is the number of folks who would contact me to request a WoT identity assertion, but then vaporize as soon as they found out that they had to present photo id and meet me in person.

I guess I’m just continually amazed at how many people have enough interest and motivation to request that their identity be validated, but then back out because a) they don’t want to use their real name or b) they don’t have government issued photo ID documentation for the identity they’re trying to create.

It’s a shame to see WoT go.  I started using WoT certificates to sign all my personal and business mail after learning folks were receiving email with my return address that I didn’t write. Signed mail was a nice techorati touch, even if most of the folks I corresponded with didn’t know what that S/MIME attachment was for.  It was also a bit viral – folks would ask me about the attachment, I’d explain digital signatures, and they’d get interested enough to get their own certs and join the fray.  Once someone had sent you a signed email, you could store their public key and use it to send them encrypted email.  I’ve never sent anything through email that required encryption, but it’s fun to encrypt a few now and then just for fun.  Stick it to the man, so to speak.

My use of signed email came to an abrupt end when I found GMail.  I loved the gmail feature set, “net nomad” availability, and spam abatement, but gmail did not (and still does not) support cryptographically signing outgoing emails with digital certificates.  To a degree, I understand why this has never been a priority for gmail – in order for gmail, running on the web server, to sign your outgoing mail, the private key of your digital certificate would need to be stored on the web server.  That’s a security risk – or at least, more opportunity for risk than storing the cert on a local hard disk.  But I also feel that excuse is a cop-out.  It can be dealt with, but GMail never tried.

Personal digital certificates are handy in another way:  If you’re working on code to handle X509 certificate chains (as I have been lately – more on that eventually), it’s always nice to have a few valid X509 certificates to test with.  Sure, you can create fake self-signed certs with makecert, but fake certs don’t exercise all the code paths and don’t work on other machines.  WoT personal digital certificates are a quick and easy way to get an X509 certificate that is signed by a real root CA that is recognized by every modern Windows system.  As an extra bonus for code testing, WoT certificate chains have a depth of three:  leaf, intermediate CA, and root CA.

Alas, WoT is no more.  So long Web Of Trust.  It’s been a great run.

Share/Bookmark

Share/Bookmark