Tag: identity

Thinking about social logins and identity on the web

Posted on January 3, 2018January 3, 2018 by Doug Belshaw

Context

Yesterday was my first day as a Moodle employee. From this point onwards, I’m spending four days every week leading Project MoodleNet. This is described by Martin Dougiamas, founder and CEO as”a new open social media platform for educators, focused on professional development and open content.” As ever, I’ll be using this blog for my personal thoughts and musings, while there’s another blog for more official updates about the project.

Why I’m thinking about this

The following will be offered as core functionality through Project MoodleNet:

Identity and reputation
Messaging
News feed
Access to openly-licensed resources
Crowdfunding

The above is listed in the order in which I’d like to tackle them. As you can see, I’ve put identity and reputation first. That’s because I believe projects should begin by attempting the most challenging things, and also because I don’t want us to have to retro-fit something so fundamental after developing everything else.

The growth of social sign-in on the web

These days, it’s become normal for users to be offered a ‘social’ way to sign into almost every service on the web. Some sites, such as Airbnb, go so far as to offer those who use social sign-in for their site additional privileges compared to those who use the traditional username / password combination.

As outlined on this Wikipedia page, for those running web services there are many benefits to allowing users to sign-in using a social network account. These include targeting content, reducing the use of fake email addresses, and increasing the speed of the sign-up process.

For users, the main benefits are:

Not having to remember multiple usernames and passwords
Increasing the speed of sign-up and login to their accounts
Quick and easy sharing of content to social networks

Although it is straightforward to find data on the percentage of users choosing to use various social network accounts to login to web services, it can be difficult to ascertain their wider practices around security. For example, how many people use browser-based password managers? Does that change by demographic? What about password managers not based on the browser, such as the ones built into the iOS and Android mobile operating systems, cloud-based services such as LastPass and Dashlane, and deterministic password generators (such as the one I use)?

Do people actually use social sign-in?

A few years ago, social sharing buttons appeared all over the web. Website visitors were encouraged to click on the relevant button to share the content they were accessing with their network. It turns out that, despite the proliferation of buttons, most people actually don’t use them, instead doing it their own way.

We know that social sign-in is different. People do use it. In fact, some reports put the number at over 90% of users preferring social sign-in to the traditional username / password combination. The most popular of these by far is Facebook, followed by Google, Yahoo, Twitter, and LinkedIn.

The situation is similar to using contactless card payments in shops versus using cash. Using contactless every transaction you make can be tracked by your bank, just as every social login you make can be tracked by a social network. There are benefits and drawbacks to both options.

When I choose to use social sign-in

Personally, I don’t use Facebook and have written about the pernicious effect I believe it to have on society. As a consequence, I don’t (and can’t) use Facebook for social sign-in. There are some web services, though, where I do choose to sign in using a third-party account. While I wouldn’t base decisions about Project MoodleNet on my own habits, given the picture is quite complicated, it might be worth explaining the occasions when I sign-in via Google, Twitter, and LinkedIn:

When I have no other choice — I find Nuzzel an extremely useful tool for surfacing news from my networks. If I didn’t sign in using Twitter and LinkedIn, then I wouldn’t be able to access the service (and even if I did, it would have no value)
When my data is being shared anyway — unless you completely remove Google services from your Android device, it’s almost impossible not to share your contacts with them. As a result, I sign into Full Contact using my Google account.
When I want to buy something — I sign into The Guardian app on my Android device using my Google account as I bought a subscription through the Google Play store.

I also sign-in to my Moodle account using Google. Why? Because Moodle staff use Google Apps and it’s a professional, rather than personal, account.

The Moodle context

I asked David Mudrák if he’d be kind enough to generate a report on social sign-ins for moodle.org. He gave me data from 15th May 2017, which was the date that the ability to use OAuth2 to sign-in using a social account was added with Moodle 3.3. Since then, there have been five times more logins via Google than via Facebook. Those users creating new accounts since May show a preference towards the traditional username / password combination, with two-thirds of users choosing this option. Signing-in via social and traditional methods are not mutually exclusive, of course, and users can register using one option and subsequently switch to an alternative.

Project MoodleNet is separate from, but very closely connected to, moodle.org. As a result, it would complicate matters to have a separate login for Project MoodleNet, and provide little benefit to users. Instead, we should be aiming to bolster the value of having a Moodle account, which would no longer be used just for activity on moodle.org, but more widely across the Moodle ecosystem.

Learning from WordPress

Ideally, as someone who advocates for increased online privacy and security, I’d prefer it if most users signed into their Moodle account directly using a username and password combination. However, given that not using social sign-in could cause security issues for users who may otherwise re-use passwords across services, I suggest Project MoodleNet adopts the approach taken by WordPress.

Moodle and WordPress are similar projects in many ways. Both are open source and adhere to the GPL, allowing anyone to host their own version of the software without restriction or constraint. Just as anyone can use Moodle without having an account on moodle.org, so those using WordPress to power their blog or website don’t have to sign up for a wordpress.com account.

Where I think Moodle can learn from WordPress is in the powerful and intuitive way that individual sites can be linked to wordpress.com accounts to access the value-added services provided by JetPack. Enabling this allows users to sign-in to their blog or website using their wordpress.com account or with their username / password combination.

This is handy for users, who are given a choice. If they click on the ‘Log in with WordPress.com’ option, they then have further options in terms of authentication. They can enter their WordPress.com credentials (username / password), authenticate using their Google account, or be emailed a single-use login link.

This approach strikes a balance between choice and convenience, while highlighting the benefit of having a WordPress account and identity.

One way of thinking about Project MoodleNet is as JetPack for Moodle. It will provide different functionality, but the idea is the same.

Summary

So, to recap:

Most users on the web seem to prefer social sign-in options. Those with an account moodle.org tend to prefer username / password, but this might be skewed towards more technical users. More research and testing is necessary.
Social sign-in means user data is shared with third parties and potentially allows users to be tracked across the web. Therefore, social logins should not be the only option to sign-in to Project MoodleNet.
Project MoodleNet should bolster Moodle’s existing login system in a similar way to JetPack providing extra value for WordPress users.

Additional reading

This subject can be a fascinating rabbithole. While I didn’t link to the following articles in the above, they have informed my thinking:

Simple Social Login for Users and Attackers (Infosecurity magazine)
The Perpetual, Invisible Window Into Your Gmail Inbox (Waxy)
Microsoft tells users to stop using strong passwords everywhere (The Guardian)
Social Login Buttons Aren’t Worth It (MailChimp blog)
Ad targeters are pulling data from your browser’s password manager (The Verge)

Photo by WOCinTech Chat used under a Creative Commons Attribution license

Some thoughts on Keybase, online security, and verification of identity

Posted on May 12, 2017May 12, 2017 by Doug Belshaw

I’m going to stick my neck out a bit and say that, online, identity is the most important factor in any conversation or transaction. That’s not to say I’m a believer in tying these things to real-world, offline identities. Not at all.

Trust models change when verification is involved. For example, if I show up at your door claiming to be Doug Belshaw, how can I prove that’s the case? The easiest thing to do would be to use government-issued identification such as my passport or driving license. But what if I haven’t got any, or I’m unwilling to use it? (see the use case for CheapID) In those kinds of scenarios, you’re looking for multiple, lower-bar verification touchstones.

As human beings, we do this all of the time. When we meet someone new, we look for points of overlapping interest, often based around human relationships. This helps situate the ‘other’ in terms of our networks, and people can inherit trust based on existing relationships and interactions.

Online, it’s different. Sometimes we want to be anonymous, or at least pseudo-anonymous. There’s no reason, for example, why someone should be able to track all of my purchases just because I’m participating in a digital transaction. Hence Bitcoin and other cryptocurrencies.

When it comes to communication, we’ve got encrypted messengers, the best of which is widely regarded to be Signal from Open Whisper Systems. For years, we’ve tried (and failed) to use PGP/GPG to encrypt and verify email transactions, meaning that trusted interactions are increasingly taking place in locations other than your inbox.

On the one hand, we’ve got purist techies who constantly question whether a security/identity approach is the best way forward, while on the other end of the spectrum there’s people using the same password (without two-factor authentication) for every app or service. Sometimes, you need a pragmatic solution.

I remember being convinced to sign up for Keybase.io when it launched thanks to this Hacker News thread, and particularly this comment from sgentle:

Keybase asks: who are you on the internet if not the sum of your public identities? The fact that those identities all make a certain claim is a proof of trust. In fact, for someone who knows me only online, it’s likely the best kind of trust possible. If you meet me in person and I say “I’m sgentle”, that’s a weaker proof than if I post a comment from this account. Ratchet that up to include my Twitter, Facebook, GitHub, personal website and so forth, and you’re looking at a pretty solid claim.

And if you’re thinking “but A Scary Adversary could compromise all those services and Keybase itself”, consider that an adversary with that much power would also probably have the resources to compromise highly-connected nodes in the web of trust, compromise PKS servers, and falsify real-world identity documents.

I think absolutism in security is counterproductive. Keybase is definitionally less secure than, say, meeting in person and checking that the person has access to all the accounts you expect, which is itself less secure than all of the above and using several forms of biometric identification to rule out what is known as the Face/Off attack.

The fight isn’t “people use Keybase” vs “people go to key-signing parties”, the fight is “people use Keybase” vs “fuck it crypto is too hard”. Those who need the level of security provided by in-person key exchanges still have that option available to them. In fact, it would be nice to see PKS as one of the identity proof backends. But for practical purposes, anything that raises the crypto floor is going to do a lot more good than dickering with the ceiling.

Since the Trump inauguration, I’ve seen more notifications that people are using Keybase. My profile is here: https://keybase.io/dajbelshaw. Recently, cross-platform apps for desktop and mobile devices have been added, mearning not only can you verify your identity across the web, but you can chat and share files securely.

It’s a great solution. The only word of warning I’d give is don’t upload your private key. If you don’t know how public and private keys work, then please read this article. You should never share your private key with anyone. Keep it to yourself, even if Keybase claim it will make your life easier.

To my mind, all of this fits into my wider work around Open Badges. Showing who you are and what you can do on the web is a multi-faceted affair, and I like the fact that I can choose to verify who I am. What I opt to keep separate from this profile (e.g. my gamertag, other identities) is entirely my choice. But verification of identity on the internet is kind of a big deal. We should all spend longer thinking about it, I reckon.

Main image: Blondinrikard Fröberg

3 things we need for the next big frontier in Open Badges and digital credentials

Posted on October 10, 2016October 10, 2016 by Doug Belshaw

Just less than a year ago, I wrote a post entitled Why the future remains bright for Open Badges. There had been some turmoil in the ecosystem, and the ‘horses’ looked like they were getting spooked. I used Gartner’s hype cycle as a ‘convenient hypocrisy’ to explain that, at that point in time, the badges community was on the downwards slope towards the Trough of Disillusionment.

Right now, I think we’re coming out of that trough. We’re beginning to see people and organisations looking beyond individual badges towards connected credentials. There’s also renewed interest in badges as creating local ecosystems of value. Not only is LRNG continuing to expand, but the RSA is actively exploring ways in which badges could connect learning experiences across towns and cities.

For me, the key thing about the web is identity-at-a-distance. When I’m in front of you, in person, then the ‘three-dimensionality’ of my existence isn’t in question. There’s something about the bandwidth of in-person communication that is reassuring. We don’t get that when projecting a digital image of ourselves.

As an educator, I think the great thing about Open Badges is that they are packaged-up ‘chunks’ of identity that can be put together like Lego bricks to tell the story of who a person is, and what they can do. The trouble is that we’re used to thinking in silos, so people’s (understandable) immediate reaction is “can I put my badges on LinkedIn/Facebook/somewhere else I already have an account”. While the short answer is, of course, “YES!” there’s a longer, more nuanced answer.

This longer answer pertains to a problem, which like invasive advertising as a business model, seems almost intractable on the web. How do we demonstrate the holistic, yet multi-faceted nature of our identities in online spaces?

I helped set up, but then withdrew from, a group of people looking at ways in which we could use blockchain technology with badges. The trouble is, as Audrey Watters so eloquently pointed out in The ideology of the blockchain, that the prevailing logic when both technologies are used together is be to double-down on high-stakes testing. I’d rather find a way that recognises and fits human flourishing, rather than reductively retro-fitting our experiences to suit The Machine.

3 things we need to move forward

As I often mention during my presentations, the problem with linking to a particular venture-capital backed social profile (even if it’s LinkedIn) is that it shows a very two-dimensional version of who you are.

1. Progression pathways

What we need is a platform (ideally, decentralised and built upon interoperable standards) that allows individuals to display the badges they have, the ones they want, and — through an online dashboard — a constellation map of paths they can follow to employment or levelling-up their skills.

I’m not mentioning particular vendors in this post, but I feel that there are several platforms that are moving towards this model.

2. Granular permissions

Something else which would help on the identity front is the separation of badge display from badge evidence store. In the same way that YouTube allows you granular permissions over who has access to your videos, so platforms should allow you to make your badges public, but, if required, restrict access to linked evidence.

The only examples of this I’ve seen are people taking this into their own hands, by ensuring that the web address for the evidence going into the badge is under their own control. For example, if you put evidence in Google Docs, you can make that URL be entirely private, shared with specific people, publicly accessible, or fully searchable.

3. Long-term storage

We’re at the stage now where there are large enough vendors within the badges ecosystem to be ensure the long-term survival of digital credentials based on an open metadata standard. However, individual vendors come and go, and some ‘pivot’ towards and away from particular platforms.

For individuals, organisations, and institutions to be confident of establishing their long-term identity through badges, it’s important that the demise or pivot of a particular vendor does not unduly effect them.

The best way to do this that I’ve come up with is for there to be a non-profit explicitly focused on ‘deep-freeze’ storage of digital credentials, based on a sustainable business model. I know that there were conversations with the Internet Archive when I was at Mozilla, and there’s definitely a business opportunity using Amazon Glacier or similar.

Next steps

I often talk about solutions that ‘raise all of the ships in the harbour’. It’s relatively straightforward to build a platform that extracts the most amount of money out of customers. That’s a very short-term play. Open Badges is an open metadata standard that connects everyone together.

These three suggestions will allow the Open Badges ecosystem become an even more flourishing marketplace of digital credentials. For employers, it means they are not forced to use chunky ‘proxies’ such as degrees or high school diplomas when they’re looking for a particular combination of skillsets/mindsets. Educational institutions can return to being places of learning rather than examination factories. And, perhaps most importantly, individuals can show what they know and can do, in a flexible, holistic, market-responsive way.

New to Open Badges? Bryan Mathers and I put together this community course to help you get up-to-speed with the basics.

I consult on identifying, developing, and credentialing digital skills as Dynamic Skillset, which is a part of We Are Open co-op. I’m looking to partner with organisations looking to use Open Badges as the ‘glue’ to build learner identity on the web. With my We Are Open colleagues, we’ve already got one City Council exploring this, and we’d like to talk to more forward-thinking people.

Get in touch: [email protected] / [email protected]