Pages

Pages

Tuesday, March 08, 2011

Insistence on a single, real-name identity will kill Facebook - gives telcos a chance for differentiation

Note: This post was written before Google+ , Google's stance on pseudonyms, and the rise of #nymwars . Most of this article applies just as much to Google as Facebook.
 
There's been a fair amount of debate about online identity in recent days, partly spurred by Techcrunch's shift to using Facebook IDs for blog comments in an effort to reduce trolling and spamming. Various web luminaries have weighed in on one side of the debate or the other.

Mark Zuckerberg, founder of Facebook, has been quoted in David Kirkpatrick's The Facebook Effect: "You have one identity. The days of you having a different image for your work friends or co-workers and for the other people you know are probably coming to an end pretty quickly ... Having two identities for yourself is an example of a lack of integrity."

I think that's narrow-minded nonsense, and I also believe that this gives the telcos a chance to fight back against the all-conquering Facebook - if, and only if, they have the courage to stand up for some beliefs, and possibly even push back against political pressure in some cases. They will also need to consider de-coupling identity from network-access services.

Operators could easily enable people to have multiple IDs, disposable IDs, anonymity, tell lies, have pseudonyms or nicknames, allow your past history to "fade" and various other options.

In other words, they could offer "privacy as a service".

There are numerous reasons why people might wish to use a "fake" identity - segmenting work and personal lives, segmenting one social circle from another and so on. There are many real-world situations in which you want to participate online, but with a different name or identity: perhaps because you have a stage or performance name, perhaps you have a (legal) "guilty secret" of some sort, or maybe because you want to whistleblow against people in authority or those that you perceive as dangerous. It can even be because your name is just too common (JohnSmith16785141), or too unusual or difficult to spell (Bubley). It is also common for people to want to participate as part of a company, not an individual.

I know plenty of people who use pseudonyms on Facebook and other social media sites, and for *personal* things I'd say that's good for all sorts of reasons. In a business context, I agree with websites such as LinkedIn and Quora that enforce real names, because there is a strong "reputation" angle to their businesses. But on the other hand, if I had to deal with 300 LinkedIn requests a day from random people I haven't met, I'd probably change my mind.

There is another, important side to anonymity and multiple identities - obfuscating parts of your persona and contact details from advertisers and spammers. Being able to give a secondary (and ideally disposable) email address or mobile phone number to untrusted parties is important. I still use my fixed number for most online forms in the UK, because there's a legally-enforced telemarketing opt-out, while giving a mobile number risks spam SMS. The same is true of online identities - I want to be able to corral spammers and unwanted advertisers in a corner of my Internet world that I can safely nuke if I have to.

So, there is an opportunity for operators to offer - either individually or collectively - a more friendly set of identity options. This probably relates more to mobile operators than fixed operators, but not necessarily. A critical element here is that ID *cannot* be always tied to a SIM card or phone number, for most of these use cases. Users will not wish to be tied to a single access provider, not least because many times they will not be using a single, operator-issued device or that provider's access network. They will also not want to pay for an access account in perpetuity, just to make blog comments or something equally trivial. And, painful though it is to telcos, they *will* churn, and using identity as a lock-in will reduce trust and take-up of the services.

In other words, a telco-provided custom ID will need to be provided OTT-style - something like Orange's ON service , a cross-network app which enshrines principles from studies of psychology and anthropology - such as the right to lie. You need to be able to "take your privacy/idnetity profile with you" when you move to another operator. Unless we want to wait 10 years to force through "identity portability" laws, operators will fail to exploit this opportunity if they just try and see it as a churn-reduction tool.

This also means that interoperability between privacy providers is unncessary and even undesirable. Operators can - and should - go it alone to start with, which is why fixed operators have a chance as well as mobile. Living in the UK, would I use AT&T or Telenor as a privacy provider? Maybe, depends on whether I like a specific service and trust them, but I'd be more keen than going with one of the UK operators who'd try to link the capability into other services. Although that said, I'd probably use certain aspects of this broader idea from my current telecom providers - perhaps a second "fake" number I could use for advertisers and potential spammers.

(It goes without saying that most or all of this will need to be built outside rigid architectures such as IMS or RCS, which also have centralised repositories for subscriber information, unique personal identifiers attached to credentials such as SIMs, and an assumption of access/service coupling).

Now there is an open question here about full anonymity. A lot will come down to local attitudes and laws. Some countries already force users of previously-anonymous services such as Internet cafes or prepaid mobile phones to register with the authorities - for example Italy, Spain and India. Others like the UK and Portugal are still OK with off-the-shelf purchases of SIM cards, anonymous web access and so forth - luckily our new government binned the hideous UK ID card project when it came to power last year. As events in the Middle East have shown, anonymous and easy access to communications helps protesters against despotism - possibly a price worth paying for a minuscule rise in terrorism risk. Personally I have the luxury of democracy, and I tend to vote for libertarianism rather than nannying state intervention, but your opinion may vary.

(And yes, I understand that real, true anonymity is almost impossible - both online and in the real world. We are traceable via credit cards, mobile phone records, facial-recognition CCTV, and probably online semantics and other behaviours. But at the moment, it's difficult to join the dots unless you are Google or a government security agency).

Don't get me wrong, I'm a huge fan of Facebook and believe that in many ways it is going to eat the telcos' collective lunch. Friend lists are already usurping the notion of a phone "address book", and web-based approaches make social networks much more flexible than a telecoms infrastructure can be. It's tempting to believe that Facebook is now too big to fail - but don't underestimate the fickleness of social groups. I've had a few friends who have had pseudonym-based profiles deleted, and they are definitely no longer loyal users.


I strongly suspect this is not an area in which the telcos will move together, en masse. It is an opportunity for some of the more forward-thinking and perhaps renegade operators (or specific product teams) to move aggressively and across network boundaries. If ID gets mired in years of interop talks and nonsense about support of roaming, it will go the same way as other "coalitions of the losers". This needs to be done NOW and done aggressively by those brave enough to step up - perhaps in partnership with a web provider or two.

15 comments:

  1. The telcos could do this (we did some work for one on this subject) but they are not organised in such a way as to do it.

    As to Facebook's privacy decrees, the whole structure is about advertising, it is just odd that so many people don't see it.

    ReplyDelete
  2. Alberto10:09 am

    Hi Dean,

    I agree with most of your post but again you try to advertise your obsession against IMS/RCS in this post and it simply does not fit. I mean you can stop talking about RCS already since none else is talking about it anyway.

    But IMS you want it or not is a kind of reality already. Just to remember you, IMS is not just the crap you listen to in some conferences. IMS was designed with multiplicity of identities in mind. So by default you can have several IMPUs associated with an IMPI (so maybe you have several nicnknames: a real one a totally anonymous one etc.) and you can have several IMPIs associated with one IMS Subscription. So its a quite flexible schema and with the right Identity Management solution it can be exploited to fit what you propose in this post.

    Other topic is if the operators really want to support this...

    ReplyDelete
  3. "(It goes without saying that most or all of this will need to be built outside rigid architectures such as IMS or RCS, which also have centralised repositories for subscriber information, unique personal identifiers attached to credentials such as SIMs, and an assumption of access/service coupling)."

    Never miss an opportunity to get an IMS dig in eh?

    There's nothing in IMS that precludes anything you have suggested.

    ReplyDelete
  4. Alan - thanks & fair point.

    Alberto & John - Sure, I think the telecoms industry has wasted an enormous amount of time & money on IMS, so yes I will definitely mention it in cases such as this.

    I think it's absolutely critical for this type of service that identity is kept well-clear of the existing telco core network, although perhaps linked to subscriber data management systems.

    As I've said before, IMS will be used in some contexts, by some operators, for some services. It strikes me as strange that in a post in which I actually point out a way telcos could have an advantage over Facebook, you seize on the point that challenges the telco orthodoxy.

    The IMPU / IMPI stuff is new to me & interesting though. Is it useable over other operators' access networks without their permission? Could I get (say) an AT&T IMS subscription in the UK, so I could use an AT&T IMPU on a Vodafone handset, or via my BT home Broadband? Or indeed, via an anonymously-bought prepay SIM in the Philippines?

    Alberto - there has been a "twitching of the RCS corpse" in recent weeks following the MWC announcements. I have a briefing call on it tomorrow. Zombies sometimes need another stake in the heart to remind them they're dead.

    But more importantly, you used the term "IMS subscription" and the idea that a "user" is the same as a "subscriber". In some cases that is true, but one of the main bottlenecks for the telco industry is this ridiculous insistence on a subscription-based model for use cases that don't warrant it.

    So for example, I might want to get an AT&T temporary identity for a week to use while travelling, for example. How easy would that be to implement?

    Dean

    ReplyDelete
  5. "you seize on the point that challenges the telco orthodoxy."

    That's one possible view of things. I prefer "corrects the flawed assumptions." ;-)

    ReplyDelete
  6. John, Alberto

    Serious question here:

    I'm a big believer that operators need to work on web-style applications that go across telco borders. Think about a better-executed version of the VF360 vision.

    Whenever I have spoken to people developing "telco-OTT" services, they have viewed IMS as too heavy & generally unsuitable, not least because of the handset-app problem.

    What is your view of the role of IMS in that type of scenario? Is it realistic to expect to have Verizon offer some form VoLTE over T-Mobile US and AT&T networks, for example? Is there an advantage to IMS in that situation & how would it be used?

    Dean

    ReplyDelete
  7. Anonymous2:27 pm

    I am sure you know that OpenID offers many of the features you are describing in this post, including multiple personas. Even though people have faulted the UX of OpenID signin, the bigger problem is enticing the "Relying Parties", the third parties which would like to use the authentication service. In my opinion, Facebook Connect has become popular because the RPs can get access to the vistors' social graph. If telcos have to have similar traction, they need to offer something more than simple authentication service. I can think of ahandful of things if the users are within the telco's service area and am hard pressed to come with things if they are not.

    ReplyDelete
  8. Aswath - yes, I know about OpenID, but I suspect that the winner in this game is:

    a) The most convenient / low-friction approach (Facebook is good for this)
    b) The one which users sign up for without realising (eg it's a corollary function of a different & useful service). Facebook is again good - but potentially this could be linked with a telco's other OTT-style services.
    c) The one with the most useful & clever features.

    I think telcos could *potentially* have some differentiators. For example, they often have a pool of unused E164 numbers, which they could rent out on a temporary basis (eg "Get a new phone # for a week" )

    They are also developing some other useful services which could be used as hooks for their identity proposition - for example, O2 launching free WiFi apps for smartphones across networks. That client could become something else in future.

    While the RPs might not be able to get full social graph information from an operator ID client, they might get other data - device type, location etc. Clearly any operator here would need a decent understanding of what appeals to a given audience, and what their ID users would be prepared to divulge.

    Dean

    ReplyDelete
  9. "Whenever I have spoken to people developing "telco-OTT" services, they have viewed IMS as too heavy & generally unsuitable, not least because of the handset-app problem."

    Interesting point. If these people find IMS too heavy and generally unsuitable it begs the question - why are they not using some kind of abstraction to hide the complexity? (JSLEE, SIP servlets, Parlay-X (now OneAPI)

    I can imagine if a developer felt that they had to launch in and develop their own SIP-AS that they would be over-whelmed but this is not reality and operators will not generally want to expose their networks to this extent.

    ReplyDelete
  10. John

    A number of reasons:

    a) They are typically more "software people" rather than "telco people". If you want to "create the next Facebook", you probably want to hire people with similar software / UI skills to them, rather than JSLEE etc

    b) These activities are often intended to be free/freemium at first, and that may not work with the cost structure of the core network (for example, if the vendor licences are based on # of subscribers, # of transactions etc)

    c) Time-to-market and the "continuous beta" mentality - difficult to do when one touches the core infrastructure in some way

    d) It's easier to "do everything in the cloud", host on Amazon or similar, use a variety of third party APIs alongside telco APIs if avaialble

    e) Architectural or operational constraints which mean that the approaches you suggest cannot flex to meet the needs of new business models.

    A lot of future telecoms value is in HTTP interactions, not SIP sessions - for example, could you create the equivalent of a quick and easy facebook-style "like" or "vote up/down" function with telco architecture without a charging model involved?

    Dean

    ReplyDelete
  11. "for example, could you create the equivalent of a quick and easy facebook-style "like" or "vote up/down" function with telco architecture without a charging model involved?"

    I suppose that would be possible but why would you even consider implementing something that way? Horses for courses and all that. Do all your cool Web 2.0 stuff in the cloud (or wherever) and connect to the operators' services using published APIs as and when necessary.

    Orange's service is a good example of where we should be heading:. http://www.orangepartner.com/site/enuk/access_orange_apis/p_access.jsp

    Now this is not IMS based as far as I know but exposing such APIs is made much much simpler in an IMS environment where consideration for this kind of thing has been there from the beginning.

    ReplyDelete
  12. On topic:
    HSS could be part of the solution decribed by Dean, however the HSS datamodel is 'telephony' based (it assumes the presence of a SIM card). However, many HSS vendors are now developing HSS to be part of a true identity and privacy management system. (Note: all the other parts of IMS are not relevant in this discussion).

    Off topic (and on the IMS discussion):
    IMS is a reality (for right or wrong) today for Voice services; SIP Trunking, IP centrex and Residential VoIP and, next, Mobile Voice_over_4G and RCSe. I personally believe this is part due to a 'sunk cost syndrome' - since operators and vendors have invested so much in IMS no one (in the telco industry) will come out and say it can be done differenly, that you do not need the 3GPP/TISPAN IMS (btw I'm not even refering to the full blown architecture - but just what operators need to get going with beforementioned services).

    @John, IMS has nothing to do with APIs or web servies; however it claims to deliver 'IP Multimedia' services which increasingly are delivered through web services. The APIs you mention such as JSLEE, PARLAY(how great and beautifull they may seem to some)are Telco centric, and don't provide the same abstraction as REST, AJAX and JSON for example. Nor are these 'telco' APIs in anyway specific to IMS (often they pre-date IMS).
    Moreover, when it comes to APIs you either target a mass market or a vertical. Telco's are a vertical that tries to push their home-grown API to developers for mass-market services, but these do not 'understand' or want to 'understand' these APIs because they can effectively do the same with other APIs.

    ReplyDelete
  13. Anonymous8:35 am

    Just one comment on this part by Dean:

    "Could I get (say) an AT&T IMS subscription in the UK, so I could use an AT&T IMPU on a Vodafone handset, or via my BT home Broadband?"

    This is very much possible and is a pretty simple use case. For using an AT&T IMPU in Vodafone UK, both these operators should have an understanding between them. Its more of a business issue rather than a technical one.

    Technically, its striaghtforward. Suppose, AT&T wishes to launch service in the UK as a MVNO and with Vodafone as a partner. Then this situation will arise. The IMPU will be provisioned in the Vodafone HSS.

    On top of this, if you need roaming for an AT&T IMPU provisioned in Vodafone UK and the IMPU roams back to the US, then these operators will have a simple POI between them. The call flow will be very simple and straightforward - "Unprotected Initial IMS Registration procedures" as per TS 24.229.

    ReplyDelete
  14. @Colin,

    Good points all. What you illustrate is absolutely the reality of IMS - it's being implemented by telcos today, there's no realistic alternative and nobody is particularly keen to start setting off down a different track at this stage. It's certainly not perfect but then what is?

    Regarding APIs. I think we're in agreement. If your customers want a REST interface then that's what you should implement. If you're building a particular service with very high transaction rates or very low latency requirements then perhaps a JSLEE or OneAPI approach would be better. Horses for courses as always.

    The underlying architecture being IMS should be invisible and really is largely irrelevant to the end-user however my opinion is that exposing any API is made much much easier in an IMS environment (even without considering FMC of some sort).

    ReplyDelete
  15. @WhiteLassiBlog - Thanks, but the scenario I am thinking about here involves *NO* business relationship or MVNO-style deal.

    I am doing a lot of work at the moment on operators doing their own OTT-style services. I am trying to work out what (if any) role IMS can play in this.

    In many such cases, the other operator will be competing directly with the "host" operator's services, and thus neither will have the inclination to cooperate.

    Most operators are actively considering or already launching own-brand OTT services, so whether such offerings need to be completely separate from any IMS, or can somehow be integrated, is pretty important.

    Colin: the "sunk" costs you are referring to are not that high. The difficult part for IMS is not the core network, but the radio and the handsets, especially for voice.

    Any discussion about next-generation service platforms needs to *start* by answering the question "Will this work well, in the hands, eyes and ears of the user?".

    I've been tracking the progress of IMS-enabled phones for 6 years, and full mobile VoIP for 5 years. To say that progress has been "slow" is an understatement.

    The "gotchas" are nothing to do with interoperability, authentication or core-network packet prioritisation. The hard problems are in the radio, the user interface, the phone battery, the acoustics, tuning of everything and so on.

    Oh, and the minor issue of creating a service that the user actually wants, and which is competitive with everything being generated on the Internet.

    VoLTE has started with the right premise: "we need plain-vanilla mobile telephony" but is at least 3 years too late, and is in danger of feature-creep by being too heavily integrated with videotelephony, RCS-type messaging and so on.

    I am yet to be convinced that centralised, SIP-based services can compete with Internet-based HTTP services in areas such as social networking.

    And I am also yet to be convinced that Mobile VoIP (using VoLTE or anything else) can compete with the quality & reliability of a $20 GSM phone when used for basic telephony.

    And I see no effort by the telecoms standards community to consider "non-telephony" or "undemanding telephony" voice applications as being worthy of specific consideration.

    Dean

    ReplyDelete