I've been contemplating doing a Firefox Extension as a personal enrichment technology project (obviously extensions aren't a potential revenue market), and have played around with the rudiments: Tremendously powerful, and very easy to take each step, and while there are specifics that I haven't nailed down, most of the enabling functionality for the following requirements seems to be there.

Before I waste the time I thought I'd put a general query to see if anyone has seen anything like this (searches yield nothing that looks similar).

• Record and report the time spent on all sites, or selected sites (e.g. defined by regex patterns, or groups of regex patterns), allowing for various reporting levels. e.g. domain, subdomain, folder, document, etc. Reporting could be facilitated via the new SVG or canvas functionality.
• Based upon the recorded time, allow the user to "ration" their own access. e.g. "Limit me to 20 minutes of Slashdot per day" or "Limit me to 60 minutes of Reddit, Digg, Slashdot, and JoelOnSoftware per week".

Like most software developers, I peruse the various technology sites during the day, and in the interest of good time management, not to mention that such a tool could be useful for billing purposes, I want to have an accurate grasp of exactly how much time I spend at specific sites, or a group of sites for that matter. Apart from status bar indicators of the time spent, and perhaps time "remaining", the product could be more interesting if it actively blocked further access to that site until you indicated moral weakness and selected the override feature.

Come across anything like this?

I've always wanted to mention Quake 2 on here, so here goes.

One of the big advantages .NET brought to desktop applications, at least in regards to official Microsoft dogma, was XCopy deployments: Instead of long, convoluted setups installing dozens of components into the system, shared libraries into system folders, and registry settings in the registry (and maybe some win.ini settings for real historical fun), XCopy allows you to build applications that can be "installed" by simply copying a folder.

Everything old is new again. Years back this was the DOS way, and in many cases it's still the UNIX way.

Some time back my favourite game on the Windows platform -- I did, and though the time is extraordinarily rare still do, play "shooter" games -- was Quake2, in particular with the ActionQuake mod. This game lived in my computing ecosystem for quite a while, not only because it was great fun, but also because the application existed as a directory "island" of sorts: John Carmack and crew had disregarded the Windows developer guidelines, ignoring centralized libraries, components, and registry settings, and stored settings in little config files in the application directory, with mods, extensions and libraries appeared in that directory or subdirectories.

I could "install" the application on a new machine, including all of my settings and extensions, just by copying the Quake2 directory to the new PC. Similarly, if I installed a new harddrive I could move it there and it was fully functional immediately. No complaints about missing libraries, or ridiculous dependencies upon fixed drive letters or fixed paths.

It just worked, and happily adapted to wherever it found itself.

This seemingly trivial "feature" made this application live on my hard drive far longer than it would have otherwise. Without the hassle of reinstalling the app everytime I upgraded machines or reinstalled the OS --  a nuisance that led to many apps getting left behind -- which would also have meant reinstalling all of the patches and mods, and then laborious reconfiguring the settings to a close proximity of my tastes, it just migrated with me. It was always there waiting to provide a quick diversion during a time of thought.

With XCopy deployment, Microsoft has shown that they've seen the light, and have realized that the whole "tentacles throughout the system" approach has been a terrible mistake.

With IIS 7 we might finally see the same sort of benefit for web applications. As it is IIS is a bit of a mixed-up configuration mess, with many directory-specific settings being stored in the IIS metabase existing somewhere else (on Windows 2003 it's a convenient, well-documented XML file that you can find at %sysdir%\\inetsrv\\metabase.xml) -- mime types, directory and file security, where virtual directories/web apps start, cache settings, etc. With IIS you can't simply XCopy the app and have full configuration, but instead you have to have appropriate permissions (generally administratrive) to open the IIS administrative console and set, for instance, that your CSS files should be cacheable for a day but the frequently rewritten XML file shouldn't be cached all, which tells IIS to add the appropriate HTTP headers to each.

Compare this to Apache, which lets you configure the vast majority of directory and file specific settings via .htaccess files in each directory, saving the "system wide" httpd.conf for settings that are truly web server wide. Configuration is logical and single point, and an application can be migrated with virtually all related setup with tremendous ease. A remote developer with access to only his folder of the web app has the ability to configure things as they should be configured without ridiculously requiring administrative rights.

IIS 7 adds this sort of functionality, moving a lot of the virtual directory and folder/file settings into files that you put in your web app file structure (obviously it won't, or rather won't under ideal conditions, allow these files to be read by web users). No more hydra-setup where half the setup exists over there and half exists over here.

Everything old is new again.

Congratulations to the Canadian Olympic Team on a remarkable showing! Not only the amazing medal haul (24 medals), but the tremendous number of winners who placed 4th or 5th, and all of the great athletes who did their best in representing this country.

It has definitely been a huge turnaround from the "disappointment" of Olympics past, and foretells a great 2010 winter Olympics in Vancouver.

Most users rely upon a small number of passwords — often only one — that they use everywhere. 

For their corporate domain account, their blog, their photo site, their email, their banking and PayPal accounts, and their discussion groups, one key opens them all. Despite the incredible risks involved with this practice, it is more prevalent than ever.

Password reuse is often a learned habit of jaded users who've been bitten by the "lost password" bug a few too many times, especially against sites that they seldom visit. Automated password management systems, such as those built into just about every browser now, help lubricate the usage of more secure passwords, but their single–PC implementations and data loss potential has many shying from trusting them.

It's so much easier to remember one or two password derivatives than it is to remember dozens.

Of course, few will actually admit to recycling passwords like this, and instead it's the guy using unique 20 character random sequences that are most likely to speak out. Impromptu prodding of acquaintances, clients, and contacts, along with the results of several recent security surveys, has me convinced that these security best-practice aficionados are the exception, and a large number of users, perhaps even a majority, are dangerously reusing the same password prolifically. Look at the outrage and fear when a site like Reddit loses their user's plaintext passwords (it is hardly alone in having this happen). Of course the users could simply change their password, but the source of the outrage was because this was the one key for many of these users.

If someone discovers your password on site A, there's a very good probability they can use it to access site B, and C, and D, and E, and so on (especially when your username is your email address). The security of your online reality relies upon faith in a lot of people who you shouldn't have faith in. The weakest link can make it all unravel.

On sites that I've architected, I've tried to minimize the potential damage of a hypothetical exploit by eliminating the target surface area.

Following this philosophy, not only do I not want to store your password — of course I only store a hash and not your original password, which should be a universal practice even among "low value" sites — but I never want your probably-reused password ever hitting the site in the first place.

Instead of sending your password to be hashed on the server, I want it hashed on the client end, before it even gets sent down the wire.

This wouldn't be a possibility without JavaScript, however the functionality JavaScript has become pretty much mandatory, so in this case it's reasonable to require it for even the basic functionality of the site. As such, the account creation and logon system incorporates functionality that hashes a combination of your username, password, and the domain on the client end, passing through the hash to the server as your "password". As a secondary benefit, the server can generate single-use variants (salts of sorts) which it provides with the form. If such a variant is provided, after the client script has created the hash, it then hashes the first hash with the variant, which the server can do as well, offering basic line encryption as well presuming that the server is tracking the variants, and ensuring they are server provided and not reused (it doesn't replace SSL, and there are still avenues for man-in-the-middle attacks and untrusted remote servers masquerading as the official site if they overrode DNS, however it's a step in the right direction where SSL can't or won't be used, which is the case for the vast majority of sites out there).

The SHA1 algorithm is well known, and in this case I decided to go with the excellent SHA1 implementation by Paul Johnston. Implementing it was trivial, and a simple example demonstrating how to use it for this purpose follows.

<script language="JavaScript" src="sha1.js" type="text/javascript"></script>
...
<form name="loginForm" id="loginForm">
<input id="passwordHash" type="hidden" value="">
Email Address: <input id="emailAddress" type="text" size="20"><br/>
Password: <input id="password" type="password" size="20"><br/>
<input type=button onclick="DoLogon();" value="Logon" />
<input type=hidden id="variant" value="" />
</form>
<script language="JavaScript">

function DoLogon()
{
  var username = document.getElementById("emailAddress").value;
  var password = document.getElementById("password").value;

  var hashString = document.domain + "|" + username + "|" + password;
  var hash = hex_sha1(hashString);
 
  /* Variant - trivial "encryption" if the server has provided
     a tracked, single use pseudo-salt. */
  var variant = document.getElementById("variant").value;
  if (variant.length > 0)
  {
    hash = hex_sha1(hash + "|" + variant);
  }

  document.getElementById("passwordHash").value = hash;
 
  /* Remove the password element from the form before submitting */
  document.getElementById("loginForm").removeChild(document.getElementById("password"));
   
  /* Submit the form. */
  document.loginForm.submit();
}

Voila. Now I never know that you use the password 4muppet8 on every site, and instead I only ever see a unique hash specific for this domain. If you accidentally enter the login credentials for another site (this is a huge security risk that catches people frequently), my logs will never betray what it was. If someone mirrored this page on another site for spoofing purposes, and they weren't smart enough to modify the javascript, even if the user entered their credentials for my site they still wouldn't see it (because it is hashed against their domain. e.g. paypalspoof.com).

Of course this scheme still suffers a critical weakness: If, somehow, a nefarious agent could replace the server side scripts, and somehow my remote server validation scripts failed, they could simply alter it to pass through the original password. While that scenario is far more remote and unlikely than the already remote and unlikely database delving or line monitoring, it does demonstrate why the optimal situation would be intrinsic browser support: Instead of creating a site-specific custom script to secure and individualize the password for a specific domain, which allows users to reuse passwords without actually giving the password to any specific site, the browser should support this functionality directly, and it should be uniquely evident in the UI when such a secure password element is in use.

In addition to the password input type, there should be a secure password type (with obvious, non-spoofable graphical indicators that it is a secure pasword box) as a basic HTML element, automatically incorporating this sort of enhancement. HTTP already supports digest autentication, which is similar, but unfortunately it is incompatible with the form logon approach commonly used, not to mention that it has its own failings.

I have absolutely no association with SiteGround outside of being one of many customers, however I've had good success with their MediaWiki hosting so I thought it worth a mention: For a very competitive price, SiteGround will get you going with your MediaWiki in no time (I get no kickbacks or commissions for mentioning this, but propose it as an alternative to the previous entry regarding setting up MediaWiki on IIS). Their service is quick and the hosting is reliable, and they're somewhat of MediaWiki experts.

While in the spirit of giving shout-outs, http://www.isqsolutions.com/ is a fantastic host (again I get no benefit from recommending them). They host yafla, and have done so to a close-to-perfect degree of reliability. Their offerings are feature rich and their prices are competitive, and they're very responsive to support issues. They're located here in the Greater Toronto Area.

[I don't normally post entries about other people's blog entries, however this relates to a topic that I've meant to cover for some time.]

Caught an interesting blog entry about Web 2.0 hype via Reddit the other day, and thought it worth a mention. It's a rather cynical take on the current "Web 2.0" phenomenon, noting that many of the recent Web 2.0 sites and services have no rational current or future business model.

To recycle a rather dated joke--

1. Make a really cool AJAX-equipped, streaming-video website with das Blinkenlights
2. Get lots of visitors and users
3. ???
4. Profit!

This is happening to a scale not seen since the disastrous .COM bubble of 1999-2001, and many of the rising stars of the internet world seem to exist purely in the hope that Yahoo or Google or Microsoft will snatch them up for tens of millions in their quest for Internet dominance. Sometimes it really does happen.

Most of us would love to be on the cheque receiving end of such an acquisition.

Being a software developer, entrepreneur, and technology consultant, I've been in contact with a lot of people who dream of branching out on their own, making their own killer software application or hugely popular web application. They imagine how they'll be sitting on the pile of lucre when the Adsense revenue and subscription fees start pouring in, or when the huge buy-out cheque comes in the mail, all while enjoying a reputation as a technical genius (or, in common media parlance, as an "internet whiz").

I offer my support and encouragement for their plans, but temper it with a bit of skepticism. My doubt arises because 9 times out of 10, or more like 97 times out of 100, their plan involves--

• Making a killer web application for geeks to hang out. Maybe make subscription levels and members only areas for revenue
• -or- Making cool component libraries for software developers, maybe some cool AJAX-like components
• -or- Making tools for the software development community (bug tracking, process management, etc)
• -or- Making cool web development tools, like an aggregator to mash up all of the Google Maps and Flickr photos with Amazon ISBNs
• -or- Something else to cater to the technically adept geek community.

This is what they know, so naturally they want to spin their observations and experience directly into business success. Whether they're pro-bloggers, or elite software developers, they feel that they know the needs of the market -- they know the itches that need scratching -- not to mention their natural desire to earn some credibility among their peer group of geeks and developers.

There are a number of problems with this plan.

• Every other software developer/web app creator is thinking and doing exactly the same thing: A small market is being grossly oversupplied by for-profit ventures, not to mention a huge cadre selfless gratis/libre advocates.
• The target is, on average, a smarter crowd. Smarter not only in general intelligence, but more importantly in the specifics of the products and technologies that you're offering.
• This target market has been observed as being very thrifty (just ask how the tip-reliant in Las Vegas felt about Comdex).
• A sad reality is that some of the target market resents seeing peers financially succeed. If you make a commercial product or solution, expect your forums to be overloaded with the resentful pointing out every marginally related open source competitor or freeware. Expect users to claim their constitutional right to use your information and services free of advertisements and restraints.
• The target market is technically capable of circumventing ads, copy protection, and just about everything else you might throw up to earn or protect revenue.
• The market is being conditioned to believe that software and services should be free (as in beer), or at least the costs should be submarined into something else.

This isn't to say that revenue isn't possible -- there are quite a few solution providers and websites doing very well targeting the developer/geek audience -- but instead is just an observation that it's one of the most difficult markets to tap. While many other domains sit underserved with a client base open and willing to paying fair rates for solutions, most dreaming software developers still peg their dreams on building the next Slashdot or tech aggregator or AJAX component suite or SQL formatter.

Software developers wage war over their saturated marketplace, building marvels of technical excellence in hopes of getting a piece of the table scraps, all while ignoring the much larger market (one in which people are actually paying $0.99 a day for a service to SMS jokes to their cell phone. In the tech world you can expect a fight to the death if a site demanded a $5/year subscription fee). I marvel seeing many of the simplistic, technically-deficient solutions yielding huge returns in other domains -- earlier today I had to deal with a widely used "business group membership" product, and I was astounded to see the enormous fees that went along with a subpar, circa-1995 era solution.

A week or so I mentioned a desire to build a Firefox extension to perform site-specific time tracking and blocking. I also commented that "obviously extensions aren't a potential revenue market". Not ever project has to be a revenue project (there are greater rewards than monetary rewards in many quests), however not everyone agreed with my assessment.

[as an aside, a user comment noted that there is a recently released extension called TimeTracker, which displays your daily total browsing time. While that product is extremely basic right now, it does discourage me from continuing on my extension quest -- I don't want to interfere or seem to "rip off" the obvious growth path of TimeTracker]

My reasons for believing that the extension market isn't a viable revenue market are largely documented above. The only current revenue model for extensions, I believe, is by serving a master other than the user (e.g. Adware/spyware, or as a branch of a much greater service such as Google and their Google toolbar).

For yafla registered clients (which basically means professional consulting clients who need the online tools) I've implemented an "AJAX" style logon (evident on the home page. It was basically developed for the upcoming http://www.360notes.com, which is currently in super-ultra-amazing stealth mode). It's responsive and extremely lightweight, and works throughout the site without redirects.

Maybe I'll bundle it up and sell it as an AJAX-enabled ASP.NET logon security user control!