Florian Heinemann

The relevance of DriveNow's electric cars for Hamburg's charging infrastructure

Wed, 14 Mar 2018 12:05:31 +0100

Casual observers of the public charging infrastructure in Hamburg will note that many of the spots are taken by car sharing companies – specifically by DriveNow and their i3s. But for how many charging transactions do they really account? In short: It’s about a third. This is based on 56 personal observations across the inner city of Hamburg.

Source: Personal data collection in early March 2018. Focus on inner city ranging from Eimsbüttel in the West, Winterhude in the North, Wandsbek in the East, and HafenCity in the South. (*): Includes leasing cars such as the ones of Yellow Strom

But how does that compare to the number of electric cars on the road? Turns out DriveNow’s i3s indeed have an outsized share of charging transactions compared to all other electric cars on the road. Based on some extrapolation from data of the city of Hamburg there are ~2,800 EVs¹ and PHEVs registered in Hamburg (this excludes electric cars that are not allowed on public roads). In comparison, there are only 200 electric DriveNows in Hamburg (as of Dec 2017).² Let’s assume that the number of non-local cars charging in Hamburg is roughly balanced by those that are registered in Hamburg but charge elsewhere. From that perspective car sharing vehicles use about 4.3x as many charging transactions as you’d expect.

Source: Personal data collection and data of the city of Hamburg¹

Surely, you’ll say that car sharing vehicles have – on average – higher mileage. And you’d be correct. The average car in Germany is driven ~14,000km each year.³ Statistics for car sharing vehicles are more difficult to come by. However, DriveNow claims their cars are utilized for 3-5h per day.⁴ Combine this with data from Berlin from 2015 that claims that the average trip takes 18min for 8km⁵ and you end up with 80-133km per day or 29,000-48,000km per year. On average, that’s about ~2.75x as many kilometers as private vehicles. Assuming that EVs/PHEVs drive as much as regular cars (maybe a bit optimistic?), we can now (hopefully) compare apples to apples:

Source: Personal data collection and data of the city of Hamburg¹

While already closer, there is still quite a gap between observation and expectations: Adjusted for kilometers, DriveNow vehicles still have 1.8x as many transactions at public charging stations than you’d expect. So, what’s left? Home charging, of course. DriveNow mostly relies on public charging stations with few exceptions where they recharge cars with mobile batteries in case of a deep discharge of a car. Regular owners, on the other hand, mostly charge at home. According to an US survey from 4 years ago 81% of all charging is done at home.⁶ Only 10% of all charging is done at public charging stations with the remains taking place mostly at the workplace. I strongly suspect that the share of home charging is lower in Germany, but I couldn’t find any data on this. Assuming that BMW’s i3 has a roughly equivalent range to the average EV/PHEV on the road, we can try to approximate how home charging would influence the expected shares of public charging. Multiplying number of cars with average kilometers and share of public charging, we learn that DriveNow’s expected share would be 66% of all transactions at public charging stations. Interestingly, that’s almost twice what we observed. It seems regular EV owners are using public charging to a much larger extent that you’d expect. I can see the following factors being at play here:

Surely, there are gaps in the data. My calculations are only based on 56 observations. Plus, we know little about the share of home charging in Germany. In many areas of Hamburg it is rare that people own a dedicated parking space
Hamburg offers free parking while charging publicly. That’s huge – especially in the crowded inner city. DriveNow cars, on the other hand, can park anywhere for free
DriveNow incentivizes people to park their cars at charging stations (30 free minutes). However, it takes quite a bit of time to find those stations and it’s not that easy to actually charge the car if you don’t do that regularly. So, how many people do really charge their car sharing vehicles?
Public charging stations in Hamburg are cheap in comparison to many private offerings. Again, I believe if you were to ask Germans where they charge their cars, you would see a different share than in the US

Source: Personal data collection and data of the city of Hamburg¹

Any implications for the future?

Yes! Thanks to an agreement between the city of Hamburg and the two big car sharing providers (DriveNow and car2go), it is planned that the number of electric car sharing vehicles will grow to 950 by the end of 2019. This is on top to any deployments by smaller providers. If we assume that growth of the regular EV/PHEV fleet will continue at the current pace of 38% p.a., we’ll see about 3,600 regular electric cars on the roads by Dec 2019. If that were the case, charging stations could be used to ~60% by DriveNow and the likes based on my actual observations. The share could be as high as 88% if you project based on home-charging ratios, etc.

What did we learn?

Car sharing providers are already an important customer of the public charging infrastructure and will become even more important in the future
However, on average, current utilization of the public infrastructure is still very low as I’ve shown in a separate post
Hence, car sharing will be an important factor to make charging stations more profitable in the future
In some inner-city areas we may witness some shortage of chargers which can be compensated by more chargers (already in the works) or higher prices (e.g., removing the free parking inventive)

The raw data of my personal collection can be found here.

Drucksache 21/10349, Buergerschaft der Freien und Hansestadt Hamburg, 12. Sep 2017 ↩ ↩² ↩³ ↩⁴
Automobilwoche, data from 2017 ↩
KBA, data from 2016 ↩
Süddeutsche Zeitung, data from 2017 ↩
Tagesspiegel, data from 2015 ↩
InsideEVs, data from 2014 ↩

Hamburg investiert in mehr Ladepunkte. Die Nutzung bleibt aber weiterhin auf niedrigem Niveau

Sat, 10 Mar 2018 12:05:32 +0100

Hamburg hat sich in den letzten Jahren als Vorreiter in Sachen Elektromobilität in Deutschland positioniert. Dies ist unter Anderem dem Masterplan Ladeinfrastruktur zu verdanken der zur Installation von mehr als 600 öffentlichen Ladepunkten an 300 Standorten bis Ende 2017 geführt hat. Weitere 400 Ladepunkte sind bereits bis 2019 eingeplant. Damit soll auch das Henne-Ei Problem gelöst werden, dass potentielle Käufer von Elektroautos weiterhin vom Kauf zurückschrecken wegen mangelnder Infrastruktur.¹

Dank einer öffentlichen Präsentation von Stromnetz Hamburg, der Betreiber der öffentlichen Ladeinfrastruktur, haben wir jetzt auch ein deutlich besseres Bild davon wie intensiv die Ladepunkte denn wirklich genutzt werden (siehe unten). Wie auf der Grafik sichtbar hat sich die Anzahl der öffentlichen Ladepunkte in der Tat drastisch erhöht. Allein zwischen Mitte 2016 und Mitte 2017 ist die Anzahl um mehr als 50% gewachsen und damit sogar schneller als die Anzahl an Elektroautos in Hamburg (36%).²

Nicht überraschend bei diesen Zahlen ist die Anzahl der Ladevorgänge pro Station relativ flach geblieben, wenn man von den Saisoneffekten absieht (höhere Nutzung der Car Sharing Fahrzeuge im Winter, höherer Batterieverbrauch im Winter, etc.) Auch die durchschnittliche Lademenge ist mit 9-12 kWh recht konstant geblieben.

Überraschend ist wie gering die absoluten Zahlen sind. Mit rund einem Ladevorgang pro Tag bleiben die meisten Standorte weiterhin unterausgelastet. Es muss allerdings erwähnt werden, dass das Nutzungsverhalten über die Stationen hinweg sehr unterschiedlich zu sein scheint. Manche Stationen werden wohl bis zu 8 mal am Tag genutzt.²

Auch wenn man sich eine breitere Nutzung der Stationen wünschen würde, ist es doch erfreuend zu sehen, dass die Stadt Hamburg bereit ist langfristig zu investieren. Dass die Stadt sich auch auf weniger genutzte Standorte außerhalb des Zentrums konzentriert, wird sicherlich über die nächsten Jahre die Akzeptanz der Elektromobilität weiter erhöhen.

Quelle: Stromnetz Hamburg¹

Ladeinfrastruktur und Netzintegration, 5. Fachkonferenz Elektromobilität vor Ort, 27. Feb 2018 Leipzig ↩ ↩²
Drucksache 21/10349, Buergerschaft der Freien und Hansestadt Hamburg, 12. Sep 2017 ↩ ↩²

Hamburg is investing strongly into their charging infrastructure, but daily usage remains limited

Sat, 10 Mar 2018 12:05:31 +0100

Hamburg is very much at the forefront of e-Mobility in Germany – in parts thanks to an ambitious government-driven “masterplan” for charging stations. Until the end of 2017 Hamburg deployed more than 600 public charging points at 300 locations throughout the city. An additional 400 charging points are expected to be online until 2019. The goal is to break the catch-22 situation of people avoiding the purchase of electric cars due to the limited charging infrastructure.¹

Thanks to a recent public presentation of a representative of Stromnetz Hamburg, the company in charge of building the infrastructure, we now have a much better picture of the public uptake (see the chart below). As you can see, Hamburg has indeed been busy deploying new charging stations at a steady pace. From mid 2016 until mid 2017 the number of public stations grew by more than 50%. This compares to a 36% growth in electric cars in Hamburg within the same time frame.²

Not surprisingly considering these two figures, the number of daily transactions per station remained largely flat with some fluctuation that might be explained by seasonality effects (e.g., increased usage of electric DriveNow cars during winter, higher battery consumption in the cold, …). Similarly, kilowatt hours per transaction stayed roughly flat fluctuating between 9 and 12 kWh.

Striking are the low absolute numbers. At just ~1 daily transaction per station, most stations seem to be heavily underutilized. However, it is important to note that there seems to be a high variability across stations. As remarked in a recently published report of the local government², some locations see as many as 8 transactions per day.

While it would be nice to see a bigger uptake of the public charging infrastructure, it is great to see that the city of Hamburg is willing to invest for the long-term. More so, it is commendable that Hamburg decided to not just focus on the sweet spots in the city center but to also build locations outside the center. This should greatly help to make the case to the public that Hamburg is ready for the growth in e-Mobility.

Source: Stromnetz Hamburg¹

Ladeinfrastruktur und Netzintegration, 5. Fachkonferenz Elektromobilität vor Ort, 27. Feb 2018 Leipzig ↩ ↩²
Drucksache 21/10349, Buergerschaft der Freien und Hansestadt Hamburg, 12. Sep 2017 ↩ ↩²

Corporate Accelerators: A Study on Prevalence, Sponsorship, and Strategy

Mon, 10 Aug 2015 13:05:31 +0200

I just finished my Master’s thesis about Corporate Accelerators. It covers macro-level trends such as growth and prevalence among large corporation in addition to questions about the sponsorship and strategy of such programs. The thesis will be available through regular library access soon, but is also available as free download here.

Abstract

In recent years, corporate accelerators have emerged as a new method to foster collaboration between startups and established companies. This thesis presents, to my knowledge, the first comprehensive database of corporate accelerator programs across the globe. On the basis of this resource, I propose a definition for corporate accelerators and show that they follow the same basic principles as non-corporate accelerators. Further, I provide evidence that corporate accelerators have been growing considerably over the past few years and have reached a level of presence close to that of corporate venture capital funds. While growth has been slowing down recently, I argue that corporate accelerators are well-suited to becoming a permanent element in the startup ecosystem and that they are likely to capture market share from non-corporate accelerators. On the basis of a population of 847 largely capitalized corporations I show that corporate accelerators are more frequently sponsored by large, information-related firms that are also investing corporate venture capital. This study provides first indications that corporate accelerators are not likely to deliver direct operating profits to the sponsoring firms. However, I provide examples of significant strategic explorations, including companies that select portfolio firms to help them innovate along their supply chain and distribution channels or to provide them with strategic gains in the marketplace.

Cite

Heinemann, Florian. 2015. “Corporate Accelerators: A Study on Prevalence, Sponsorship, and Strategy.” Master’s Thesis, Cambridge: Massachusetts Institute of Technology.

Corporate Accelerator database launched

Wed, 17 Jun 2015 15:05:31 +0200

As part of my thesis on Corporate Accelerators I’ve published a first set of data on a separate website aimed to create a comprehensive list of Corporate Accelerators. Comments about additional programs are highly welcome and can be directly posted on GitHub.

Antifragility, Evolution, and Entrepreneurship

Fri, 21 Nov 2014 10:02:34 +0100

Noubar Afeyan, a Sloan professor and founder of Flagship Ventures, recently argued during Harvard’s Spark conference that we should better distinguish between the term entrepreneurship, where “ship” implies a certain constancy, and entrepreneuring, which describes in his words the process of building up an enterprise and has a much stronger connotation of fluency and evolution. The idea of understanding the process of founding companies as a profession on its own that can be taught, serially applied, and improved upon is in my view an almost inevitable conclusion of the evolution of strategic management over the last century. The last 100 years have seen a substantial transition from managers seeing the world as predictable and their companies as self-contained to a focus on surviving in a highly complex, evolving, and interdepended world.

Some of the earliest academic thoughts on what was at that time called Scientific Management were highly mechanistic; focusing not only almost exclusively on the internal side of the company but also assuming that the surrounding could be considered stable. Uncertainty was something that was not only avoided but seen as dangerous and unscientific as it becomes clear in this statement from 1912: “The theory of proper execution of work is that it should be planned completely before a single move is made.”¹

A first suggestion that the world is not as stable as the earliest theories suggested came up in the 1950s when strategic planning was introduced. The term planning implied that there was a future that could be planned against and that would look different to the context the company was in at the very moment. Advanced companies during the 1960s and 70s took this idea of transition and change a step further with more systematic tools to understand product life-cycles and learning curves-all methods to analytically get hold of an uncertain time ahead.

Even more interestingly, during this time managers and consultants developed the idea that sub-divisions of a company could be considered as part of a portfolio which could be adapted to counter risks faced by an uncertain future. By evolving the company’s product portfolio, future profits could be maximized following rigorous analysis. What makes this view so fascinating is that it gives a first hint of purposefully accepting losses in order to refocus the company’s efforts on other areas. More so, it implied that there was a central body of the corporation that would not only take those decisions but do this repeatedly and hence over time dynamically improve their company’s standing while learning new management lessons on the way.

All those models still had a strong passively reactive view on their environment. This changed in the 1980s when we saw a sudden spike of interest in understanding the world outside the firm. New concepts such as game theory came up which helped to better model future states of other actors and we also saw the emergence of Porter’s five-forces; a framework which provided a better view on a complex external world and allowed managers to more effectively position their firms in their respective environment.

While at that time the importance of an external perspective had already emerged and it was already widely accepted that the future was difficult to predict, it took the 1990s to bring these ideas full circle: The emergence of Dynamic Capabilities. Suddenly, people, interactions among them, shared knowledge, processes, and technical capabilities were not anymore seen as liabilities but as an asset that could be shaped and re-configured to answer new, to the managers beforehand unknown challenges. Managers were asked to actively look out for new opportunities that could be seized. I believe these insights were critical stepping stones in enabling today’s entrepreneurship culture: The consideration that the internal capabilities (incl. the product!) are important but not static. That they shall evolve with the company’s customers and more importantly with the visionary insights of the management.

The critical new element which today’s entrepreneurs bring to the table, is the insight of not only seeing their companies as evolving (or “pivoting”) but also considering their own abilities as limited and hence improving together with their companies. Increasingly failures are not anymore seen as a weakness but as a quintessential graduation to more challenging startup ideas.

The earlier insights, though, stayed: Agile process models, Minimum Viable Products, and Design Thinking are nowadays mainstays of the startup scene and are just the latest chapters in the collection of management tools that allow a company to survive in an uncertain world by testing their markets. Some of the proposed frameworks are even pushing the boundaries so far, that it is nowadays seen as acceptable to sell products into a market without having any certainty that there will be demand for it. Similarly, today’s entrepreneurs have not only learned the lessons of the past with respect of learning from the external world but further expanded on it. Most young companies will assert that they consider their customers at the very heart of their corporate strategy, as a bridge to the external world which helps to constantly shape and improve their company’s products. These are views which would have been unheard of 100 years ago. While it might be easy to dismiss these statements as corporate buzzwords, I believe they are mostly rooted in conviction. Stanford² and MIT³, arguably the leading universities nurturing entrepreneurship in the world, preach customer-centricity in their courses and less-than-perfect customer service is anecdotally seen by young people as a relic of the remaining old-world companies but certainly not something one would expect from the likes of Amazon, AirBnB, and Teespring.

The churn rate of today’s startups is also interesting to observe. Small enterprises are a substantial net contributor to job growth⁴ but this comes at the cost of individual stability. Young companies incorporate, start employing people, but more often than not fail.⁵ But should we consider this as a failure? Nassim Taleb would argue that we shouldn’t. In his book Antifragile he emphasizes the importance of small failures to stabilize and evolve an overall system.⁶ At the example of restaurants he makes the point that we would likely have a very unsatisfactory dining experience without the failure of some entrepreneurs. With every restaurant that fails, the collective knowledge grows. Business models are proven or disproven and creative ideas get new space with the failures of others. Over time, we experience countless local failures, but at the same time we see the emergence of a new, much more stable restaurant ecosystem that is collectively not only delivering more value to its customers but also positively embracing future changes. He calls this attribute the antifragility of the system.

Entrepreneurs are certainly not the rational actors as earlier management theory imagined managers to be. They are overconfident when they believe in their personal success no matter the odds they face. But as Taleb suggests: Selected overconfidence on a small scale is much preferable to a global overconfidence, as we’ve seen it during the great recession.⁷ And the overconfidence is confined not only to the individual entrepreneurs and their companies, but also it is limited to the financial sphere. What gets unshackled, though, is the learning experience the entrepreneurs go through. It will help them to be more successful the next time and it will support any other entrepreneur who is looking for lessons learnt. Today’s entrepreneurs are unprecedented in the amount of knowledge that they pass on to their peers. Books are written as open source documents, business templates shared freely online, and countless blogs about startup learnings are being published.

Communities such as WeWork⁸ also show another prospective of today’s management culture: Companies share their resources, build mutually beneficial networks between each other, and lend each other a hand when there are times of hardship. It’s not that competition has disappeared, but that the world has reached such a level of complexity and rate of change, that it is rarer and rarer to have two entrepreneurs in a room that compete with each other in the same niche but more and more likely that they either build on top of each other’s services, or offer complementary products.

While the world I have described above is not yet the reality for most of us, I strongly believe that we can learn a lot from those working at the edge of management practice. The past has shown that it is usually the practitioners who dare first to take the next steps and advance our understanding of the world. At times where large corporations and banks collapse with disastrous effects, I believe strategic management theory and large corporations alike can learn a lot by more strongly embracing the approach of startups of staying closer to their customers and partners and of accepting uncertainty by failing small and fast. This might not only be a path towards more stability and value generation in today’s world, but also an almost logical next stepping stone building on top of 100 years of management theory.

Addresses and Discussions at the Conference on Scientific Management Held October 12-14, 1911. Hanover, N.H.: Amos Tuck school of administration and finance, Dartmouth college, 1912. ↩
http://startupclass.samaltman.com/ ↩
http://disciplinedentrepreneurship.com/ ↩
Stangler, Dane, and Robert E. Litan. http://ded.mo.gov/Content/Kauffman,%20where_will_the_jobs_come_from,%202009.pdf, November 2009. ↩
Gage, Deborah. “The Venture Capital Secret: 3 Out of 4 Start-Ups Fail.” Wall Street Journal, September 20, 2012, sec. Small Business. ↩
Kindle p. 1340. Taleb, Nassim Nicholas. Antifragile: Things That Gain from Disorder. Reprint edition. New York: Random House Trade Paperbacks, 2014. ↩
Taleb, 2014, Kindle p. 1515 ↩
https://www.wework.com/mission/ ↩

Hosting static pages on Dokku

Mon, 17 Nov 2014 12:05:31 +0100

Surprisingly, Dokku (and also Heroku) doesn’t offer you a straightforward option to deploy static websites. Sure, a lot of websites are anyway dynamic nowadays, but there is still plenty of need for static pages such as blogs created by the likes of Wintersmith.

The following steps will show you how to make it anyway happen with the help of a custom buildpack that I’ve been working on. What it does is to compile and deploy a lightweight NGINX instance that serves all the files.

All you have to do are the following three steps:

Add a file called .env to the root of your website directory. The file should have the following content: export BUILDPACK_URL=https://github.com/florianheinemann/buildpack-nginx.git
Add second, empty file called .static to the same directory
Push your project to Dokku: git push [your server] master

The static files that you want to host should be similarly in the root directory together with the .env and .static file. Don’t worry, those two files will not be served.

The first push will take a bit longer as the buildpack is downloading all the relevant source codes and compiling the packages, but every new push will reuse the already pre-compiled files making it a lot faster the second time round.

This buildpack has been successfully run on Digital Ocean instances of Ubuntu 14.04 and I assume that other configurations might work as well. Let me know if you successfully used the buildpack in different configurations.

Passwordless authentication: Secure, simple, and fast to deploy

Thu, 06 Nov 2014 12:20:43 +0100

Passwordless is an authentication middleware for Node.js that improves security for your users while being fast and easy to deploy.

The last months were very exciting for everyone interested in web security and privacy: Fantastic articles, discussions, and talks but also plenty of incidents that raised awareness.

Most websites are, however, still stuck with the same authentication mechanism as from the earliest days of the web: username and password.

While username and password have their place, we should be much more challenging if they are the right solution for our projects. We know that most people use the same password on all the sites they visit. For projects without dedicated security experts, should we really open up our users to the risk that a breach of our site also compromises their Amazon account? Also, the classic mechanism has by default at least two attack vectors: the login page and the password recovery page. Especially the latter is often implemented hurried and hence inherently more risky.

We’ve seen quite a bit of great ideas and I got particularly excited by one very straightforward and low-tech solution: One-time passwords. They are fast to implement, have a small attack surface, and require neither QR codes nor JavaScript. Whenever a user wants to login or has her session invalidated, she receives a short-lived one-time link with a token via email or text message. If you want to give it a spin, feel free to test the demo on passwordless.net.

Unfortunately—depending on your technology stack—there a few to none ready-made solutions out there. Passwordless changes this for Node.js.

Getting started on Node.js & Express

Getting started with Passwordless is straight-forward and you’ll be able to deploy a fully fledged and secure authentication solution for a small project within two hours:

$ npm install passwordless --save

gets you the basic framework. You’ll also want to install one of the existing storage interfaces such as MongoStore which store the tokens securely:

$ npm install passwordless-mongostore --save

To deliver the tokens to the users, email would be the most common option (but text message is also feasible) and you’re free to pick any of the existing email frameworks such as:

$ npm install emailjs --save

Setting up the basics

Let’s require all of the above mentioned modules in the same file that you use to initialise Express:

var passwordless = require('passwordless');
var MongoStore = require('passwordless-mongostore');
var email   = require("emailjs");

If you’ve chosen emailjs for delivery that would also be a great moment to connect it to your email account (e.g. a Gmail account):

var smtpServer  = email.server.connect({
   user:    yourEmail, 
   password: yourPwd, 
   host:    yourSmtp, 
   ssl:     true
});

The final preliminary step would be to tell Passwordless which storage interface you’ve chosen above and to initialise it:

// Your MongoDB TokenStore
var pathToMongoDb = 'mongodb://localhost/passwordless-simple-mail';
passwordless.init(new MongoStore(pathToMongoDb));

Delivering a token

passwordless.addDelivery(deliver) adds a new delivery mechanism. deliver is called whenever a token has to be sent. By default, the mechanism you choose should provide the user with a link in the following format:

http://www.example.com/token={TOKEN}&uid={UID}

deliver will be called with all the needed details. Hence, the delivery of the token (in this case with emailjs) can be as easy as:

passwordless.addDelivery(
	function(tokenToSend, uidToSend, recipient, callback) {
		var host = 'localhost:3000';
		smtpServer.send({
			text:    'Hello!\nAccess your account here: http://' 
			+ host + '?token=' + tokenToSend + '&uid=' 
			+ encodeURIComponent(uidToSend), 
			from:    yourEmail, 
			to:      recipient,
			subject: 'Token for ' + host
		}, function(err, message) { 
			if(err) {
				console.log(err);
			}
			callback(err);
		});
});

Initialising the Express middleware

app.use(passwordless.sessionSupport());
app.use(passwordless.acceptToken({ successRedirect: '/'}));

sessionSupport() makes the login persistent, so the user will stay logged in while browsing your site. Please make sure that you’ve already prepared your session middleware (such as express-session) beforehand.

acceptToken() will intercept any incoming tokens, authenticate users, and redirect them to the correct page. While the option successRedirect is not strictly needed, it is strongly recommended to use it to avoid leaking valid tokens via the referrer header of outgoing HTTP links on your site.

Routing & Authenticating

The following takes for granted that you’ve already setup your router var router = express.Router(); as explained in the express docs

You will need at least two URLs to:

Display a page asking for the user’s email
Accept the form details (via POST)

/* GET: login screen */
router.get('/login', function(req, res) {
   res.render('login');
});

/* POST: login details */
router.post('/sendtoken', 
	function(req, res, next) {
		// TODO: Input validation
	},
	// Turn the email address into a user ID
	passwordless.requestToken(
		function(user, delivery, callback) {
			// E.g. if you have a User model:
			User.findUser(email, function(error, user) {
				if(error) {
					callback(error.toString());
				} else if(user) {
					// return the user ID to Passwordless
					callback(null, user.id);
				} else {
					// If the user couldn’t be found: Create it!
					// You can also implement a dedicated route 
					// to e.g. capture more user details
					User.createUser(email, '', '', 
						function(error, user) {
							if(error) {
								callback(error.toString());
							} else {
								callback(null, user.id);
							}
					})
				}
		})
	}),
	function(req, res) {
		// Success! Tell your users that their token is on its way
		res.render('sent');
});

What happens here? passwordless.requestToken(getUserId) has two tasks: Making sure the email address exists and transforming it into a unique user ID that can be sent out via email and can be used for identifying users later on. Usually, you’ll already have a model that is taking care of storing your user details and you can simply interact with it as shown in the example above.

In some cases (think of a blog edited by just a couple of users) you can also skip the user model entirely and just hardwire valid email addresses with their respective IDs:

var users = [
	{ id: 1, email: 'marc@example.com' },
	{ id: 2, email: 'alice@example.com' }
];

/* POST: login details */
router.post('/sendtoken', 
	passwordless.requestToken(
		function(user, delivery, callback) {
			for (var i = users.length - 1; i >= 0; i--) {
				if(users[i].email === user.toLowerCase()) {
					return callback(null, users[i].id);
				}
			}
			callback(null, null);
		}),
		// Same as above…

HTML pages

All it needs is a simple HTML form capturing the user’s email address. By default, Passwordless will look for an input field called user:

<html>
	<body>
		<h1>Login</h1>
		<form action="/sendtoken" method="POST">
			Email:
			<br><input name="user" type="text">
			<br><input type="submit" value="Login">
		</form>
	</body>
</html>

Protecting your pages

Passwordless offers middleware to ensure only authenticated users get to see certain pages:

/* Protect a single page */
router.get('/restricted', passwordless.restricted(),
 function(req, res) {
  // render the secret page
});

/* Protect a path with all its children */
router.use('/admin', passwordless.restricted());

Who is logged in?

By default, Passwordless makes the user ID available through the request object: req.user. To display or reuse the ID it to pull further details from the database you can do the following:

router.get('/admin', passwordless.restricted(),
	function(req, res) {
		res.render('admin', { user: req.user });
});

Or, more generally, you can add another middleware that pulls the whole user record from your model and makes it available to any route on your site:

app.use(function(req, res, next) {
	if(req.user) {
		User.findById(req.user, function(error, user) {
			res.locals.user = user;
			next();
		});
	} else { 
		next();
	}
})

That’s it!

That’s all it takes to let your users authenticate securely and easily. For more details you should check out the deep dive which explains all the options and the example that will show you how to integrate all of the things above into a working solution.

Evaluation

As mentioned earlier, all authentication systems have their tradeoffs and you should pick the right system for your needs. Token-based channels share one risk with the majority of other solutions incl. the classic username/password scheme: If the user’s email account is compromised and/or the channel between your SMTP server and the user’s, their account on your site will be compromised as well. Two default options help mitigate (but not entirely eliminate!) this risk: Short-lived tokens and automatic invalidation of tokens after they’ve been used once.

For most sites token-based authentication represents a step up in security: users don’t have to think of new passwords (which are usually too simple) and there is no risk of them reusing passwords. For us as developers, Passwordless offers a solution that has only one (and simple!) path of authentication that is easier to understand and hence to protect. Also, we don’t have to touch any user passwords.

Another point is usability. We should consider both, the first time usage of your site and the following logons. For first-time users, token-based authentication couldn’t be more straight-forward: They will still have to validate their email address as they have to with classic login mechanisms, but in the best-case scenario there will be no additional details required. No creativity needed to come up with a password that fulfils all restrictions and nothing to memorise. If the user logins again, the experience depends on the specific use case. Most websites have relatively long session timeouts and logins are relatively rare. Or, people’s visits to the website are actually so infrequent that they will have difficulties recounting if they already had an account and if so what the password could have been. In those cases Passwordless presents a clear advantage in terms of usability. Also, there are few steps to take and those can be explained very clearly along the process. Websites that users visit frequently and/or that have conditioned people to login several times a week (think of Amazon) might however benefit from a classic (or even better: two-factor) approach as people will likely be aware of their passwords and there might be more opportunity to convince users about the importance of good passwords.

While Passwordless is considered stable, I would love your comments and contributions on GitHub or your questions on Twitter: @thesumofall.

This blog post has been published on Mozilla Hacks.

8 years of Enterprise 2.0

Mon, 17 Feb 2014 12:05:31 +0100

In preparation of my talk at the Portal and Social Collaboration Days 2014 in Berlin, I’d like to share my main talking points in advance.

It is roughly 8 years ago that Andrew McAfee coined the term Enterprise 2.0. Since then a lot has happened and many practitioners have years of experience under their belt. So where are we in the world of Enterprise 2.0 and what is ahead?

I believe it is fair to say that we are quite a bit away from the hype around social technology that we experienced several years ago. Knowing that Google Trend statistics are not the most scientific source of information, it is still interesting to see that after a lot of activity between 2006 and 2010 less and less people have been feeling the need to search for the term Enterprise 2.0.

In parallel, I’ve noticed that over the last one or two years the mood of conferences, consultants and bloggers has evolved to something much more careful and considerate. The recent Digital Workplace Trends report also paints a mixed picture of some successes but also a lot of work ahead for those who would like to implement social software at work.

Apart from many other things, I believe it is worth considering three things when assessing the status of Enterprise 2.0:

First, it is not only us as experts, implementers or consultants who have experienced the journey of social deployments throughout the last eight years. Employees and managers went through the same process but on the receiving end - making some good but also less positive experiences on the way. We should therefore not be surprised to face a more challenging deployment process than in the past. Rightly so, there is a much higher interest from the business to clearly understand the benefits, objectives and risks before any deployment.

Second, social media is ubiquitous outside work. Almost everyone, including C-level executives, are using social software at home. Be it as simple as browsing online boards for tips and tricks, maintaining a LinkedIn profile or going as far as tweeting about work or hobbies. The average age of those who are using social media has been growing steadily and some solutions such as LinkedIn are coming very close to the age distribution of even the most conservative companies. These people have a certain expectation when thinking of social technology. They have experienced the great parts of the internet such as the Wikipedia but have also seen behaviour where they might struggle to see the connection to the workplace. Being confronted with statements from employees that they fear enterprise social networks might turn into an “internal Facebook” is hence less a result of unknowingness but of real experiences made outside work. Again, this is not as much a hurdle as it is an opportunity to shift the discussion away from the underlying technology (which by now most people know about) and to talk instead about the impacts onto employees’ working live.

Third, thanks to the NSA disclosures and recent hacks, employees and managers alike are much more careful about the security impact of Enterprise 2.0 solutions. Also data privacy concerns are much more likely to come up as a concern than in the past. It is interesting to observe the backlash some companies experience when talking about Bring Your Own Device (BYOD) with a reported 70% of employees expressing privacy concerns.

I see all of that as very positive signs. As Gartner puts it: For many of the typical Enterprise 2.0 solutions we went through the phase of inflated expectations, dropped into a period of disappointment and are now slowly ascending towards the plateau of productivity.

This positive trend is in my opinion supported by three evolutions which are core to the process.

Let me digress for a second. Do you remember the time when everyone was concerned about Foursquare being squeezed out of business by an adapting Facebook? The conversation has suddenly shifted drastically with Facebook being suddenly confronted with highly specialised competitors such as Snapchat, WhatsApp and Instagram (bought by Facebook). And even though Facebook has reacted in some ways to all of them, it is interesting to see that users seem to care much less about unifying their whole social experience into one tool. Is it about privacy concerns? Or about ease of use? It doesn’t really matter what it is but it should challenge our believe that we do have to necessarily offer a highly integrated toolset to our employees.

I would even claim the opposite: There is a much higher chance of success by adapting the strategy of the above mentioned start-ups and focussing on one use case per time instead of rolling out a full social media suite (as for example SharePoint) which might easily end up confusing employees more than brining real benefits to the business. Even more, who really has the resources to accompany such a technical rollout with the massive change, training and communication campaign that would be needed to support such a breadth of features? I am almost certain we will see more and more specialised deployments in large enterprises instead of bulldozer rollouts. Social media suites can clearly be underpinning those use cases as foundation and most of them offer the flexibility to do so. However full out-of-the-box deployments will make way for smaller but more adapted use cases.

On a different note, I believe we have reached a level of maturity where it becomes the norm to integrate social software deployments deeply into offline processes and where the business will also actively ask for such integration when being approached by Enterprise 2.0 evangelists. Such integrations can range from as simple as linking online Communities of Practice with offline events, to making sure that crowdsourcing campaigns are accompanied by a process that ensures real-world implementations, to real business process reengineering efforts.

Lastly, with such a level of experience on all sides, we can slowly question one of the pinnacles of Enterprise 2.0 deployments: starting with the needs. Social software enables entirely new business models and it is worth asking the question what we could do differently with the means that are available to us today. Companies such as GitHub are going as far as basically designing their governance around the way social software works. I believe we can do the same also in more traditional companies by fundamentally reconsidering the way we are doing business knowing that we can today, for example, easily engage a whole company on a certain topic. Easy starting points would be project management processes: Why do we have to keep early prototypes restricted to a handful of users in times where it could be a matter of seconds to open up a space to involve a broader set of future users?

So overall I am very hopeful for Enterprise 2.0. Not because we have already fulfilled its promise, but because we have managed to cross the difficult passage of the early hype and experimentation and can now finally focus on applying the learnt best practices.