Introduction to Electronic Signatures

I was asked to deliver a presentation to the Scientific Archivists Group conference in Nice on “Electronic Signatures”. This group tends to focus on the needs of regulated industries but also covers other areas.

It was an interesting talk… I realised I needed to give a high-level overview avoiding the deeply technical stuff, but as I wrote it I realised it was the human dimension that mattered most. Which is where I ended up.

Free ELNs are an accident waiting to happen

Every now and then we see “Free” ELNs pop up, make a bit of a splash on the forums and then quietly disappear from view.

I’ve always wondered what the business plan for these systems is; there seems to be a lot of optimism and little long-term thinking. I think some of it comes from looking at the numerous Internet-based services which are around with “Free” or “Freemium” models. A few people in their spare time use one of the amazing array of tools to quickly build a SaaS ELN, launch it, and see what happens.

Which is really great; we use a lot of those tools ourselves, and we have taken the Free approach when launching other products – but not an ELN.

Some of the reasons why I think free/freemium is not a viable platform for an ELN offering are:

  • Long term viability is important. Google Reader, Delicious and others are reminders of how this story can end, which is nicely summed up in this post on the Pinboard Blog.
  • The market is too niche to generate the user numbers which would allow anything other than direct monetization to work. There wouldn’t be the traffic for advertising etc.
  • Most “free” business models involve selling or re-using the data in some way or another (“If you are not paying for it, you’re not the customer; you’re the product being sold”). Which is a huge problem for information which should often be confidential.
  • There’s a lot of boring infrastructure stuff that goes into running an ELN safely which is too easy to “save” on. Paying means the vendor is accountable for backups etc.
  • The cheap way to do infrastructure is generally outsourcing to a “cloud” provider. Not knowing which country your data in is just the first of the problems that this brings.
  • Users need support, both in use but also in the decision making processes. I don’t know what revenue number you need to provide a decent support operation, but it has to be over $500/user/year.

I just don’t see how free ELNs will work out as a viable long term offering. I can see the attraction of Open Source ELNs and created one myself; but if you take a look around, most Open Source ELNs have fallen into inactivity (including mine!).

I’m not saying all ELNs should be charged for; we provide our PatentSafe ELN for free to teachers, and strongly discounted to startups and individuals. But those offerings are our way of getting smaller companies started, or “giving back” to education – underpinned by a strong and profitable business.

There’s a couple of interesting effects as well:

  • When people pay, they increase their expectations and feed them back to the author – who is motivated to make the product better.
  • Asking for money requires the supplier to align themselves with the market and pay attention to what’s really needed rather than what they think – and then to be able communicate the value back to the market. That’s hard, but very important for long term viability.

Broadly, Free ELNs are a disaster waiting to happen, and I’d strongly encourage people to avoid them. If your budget is genuinely too tight to be able to pay for an ELN, I’d suggest using Microsoft Office (or even OpenOffice!), or Evernote, or WordPress, or something. All of those solutions combine useful functionality with a viable business model.

iPad Dictation in the Lab & Cloud Computing

CultOfMac bring up a really interesting problem with Siri/Dictation… what you say is sent back to Apple and could be retained.

I can see why Apple do it; in reality it is the only way to get Dictation working with any kind of useful real-world accuracy. Not only does the recognition require a lot more data and potentially CPU than you have on your iDevice, but by gathering lots and lots of samples into one place, they can continually improve the performance in the real world.

However, this is probably a technical violation of some confidentiality clauses, government regulations, and potentially prior-art disclosure.

There’s a general point here about Cloud Computing. Yes, there’s a lot of Corporate-level discussion about “The Cloud” and people are starting to wake up to the privacy and legal implications of having your data on other people’s servers. But in parallel with that, and largely unremarked, as our phones get more capable they are also splattering our information all over the Cloud in various ways – some obvious, some declared but invisible (as with Siri), and some rather less honourable (the recent Path/Address Book issue as an example).

I don’t think this is going to stop adoption of iPads and other devices in the Lab; the trend is too powerful to resist. And I don’t think we’re going to see the emergence of a class of devices which “Do things properly” from an Enterprise perspective – Apple’s consumer focus has clearly shown where the market traction is, and anything focused on the Enterprise is never going to get a critical mass.

But I do think this is something to keep in mind; paranoia isn’t going to work, but Inter-company NDAs and Patent Law are going to have to start wrangling with Consumer-focused Cloud services. Those two worlds haven’t really interacted much, it is going to be interesting to watch it play out.

A sensible observation on Passwords

Finally some common sense on Passwords:

XKCD on passwords

So true, it isn’t funny.

This is why in PatentSafe we encourage the use of a phrase for signing documents. We can’t change organisation’s password policies (and most large companies use LDAP anyhow) but we can try to enforce sanity in signing pass phrases.

Maybe we needed short but hard to guess passwords years ago when memory was tight and CPUs weren’t able to chew through all possible combinations as fast as they do today. Nowadays having a 255 character string for a password shouldn’t be a problem – and it needs to be long to slow down brute-force attacks.

(there’s clearly features in PatentSafe to detect and/or defend against brute-force attacks but the first line of security should be sensible passwords).