The Always Logged In Experience
Last week I blogged about mobile notifications which I think is a big game changer. There are a few other aspects of the mobile experience that I think present great opportunity. Another one is the always logged in experience.
On the web, you may or may not have a web app open in a tab in your browser and you may or may not be logged into it. But on your mobile, you are permanently logged into every app you have on your device. When you get a notification, you click on it and are taken right to the exact part of the mobile app you want to engage with. No log in is required. That in and of itself is a big deal.
But there is something more interesting. Think about OAuth and Facebook Connect and Sign In With Twitter and other similar techniques for signing into and connecting to apps. When you have lots of apps on your mobile device and you are permanently logged into them, there are a host of opportunities that open up which are harder to execute in the current web app paradigm.
Imagine you are building a mobile app that connects to the Facebook platform, the Twitter platform, the Foursquare platform, and the Google Maps platform. Assuming your users have all of those apps on their mobile, you can quickly and easily do the connections directly on the mobile device. And then you can pull data from those apps to create new experiences for the mobile users. You can create cross app notifications and other data driven experiences for users.
Like with mobile notifications, I have not done a deep dive on where we are with all of this stuff. Is there a mobile implementation of oauth that doesn't require a browser session to do the auth? Can one app deliver notifications that take the user to another app?
When I was at the music hackday a few weekends ago, I noticed that it was easy to build something interesting by simply snapping together a few web apps and then building some light glue between them. I suspect it will be even easier to do that on mobile and the era of "meta apps" that deliver functionality across multiple apps is upon us. And I think that has the potential to create some new startup opportunities.
Won’t that just be what they end up building into the OS, rendering that glue obsolete or just what the browsers are evolving into? (Just wondering, perhaps a dumb question)
maybe. the same may be true of notifications
..Just shook up my day with this post.
Unlikely that it will end up in the OS near term, for the same reasons that the elusive “single sign on” in the enterprise SW space never occurred. Primary cause: legacy, secondary cause: rate of change of the web app space.Having said that, the momentum around mobile payments could well provide the impetus to a (semi) universal digital ID that could be used for any number of applications for identity verification. This would only provide one piece of the puzzle, however. The apps themselves would need to leverage it, and there are a whole host of trust issues involved.A lot of people have looked towards things like biometric identity as a possible solution – but ultimately, virtually any identity system can be compromised, and when that system is biometric, it ain’t easy to change “passwords” if your password is your retina pattern or fingerprint…A global, secure, universally accepted digital ID is probably one of the key enablers for the next wave of digital value, and it’s going to be hard to achieve – because it’s hard to get *global* agreement, a suitably *secure* ID, and *universal acceptance*.
This may be a dumb question forgive me, …but in that case do you think some of the NFC advancements/innovations could instigate a forced large “cultural” (industry wide) push for “devices/virtual aplliances/meta-apps” that balance between/ prioritize/mutually verify NFC notifications and wider general notifications that are more hard wired? Could that force a “glue”/meta/app or the like… that is more native to a device/person which verifies remotely or person verified. (If that makes any sense) Forgive my ignorance.. your comment about mobile payments (& Fred’s questions/thoughts) and what we are doing with transmedia interface/architecture has my interest.
Hard to say. My gut feel says that it will likely create some momentum towards unification, but like any attempt to standardize an industry or technology that is (ironically) both fast moving and bogged down with legacy, the skeptic in me questions whether it can happen globally. Regionally and within specific segments, definitely. There are also (currently) some significant security holes and usability issues with NFC and with mobile payments in general that are going to need to get ironed out. I think starting with the more general concept of a universal digital ID, and then creating a variety of means for implementing it, is the real challenge.Too often we pick a technology and build/design within its limitations rather than thinking about the macro problem/opportunity. Some piece of me is convinced that NFC may become to mobile what RFID was to logistics and retail (an overhyped bust and an incorrect focus on a specific implementation of AutoID rather than on the broader opportunity).
Thank you. Appreciated ..sincerely.
i think that is quite likely.
the OSs already have plenty of IPC mecahnisms and those are exposed to apps. But the operating system can NOT specifiy application specific IPC ..only how it is accomplished. Apps need to specify the app-specific notificatons they expose:- what notifications they can send to other apps- the format of the data- which os IPC api is to be usedTo put all this in web terms – the process is not unlike defining an api for a web service 🙂
agree… i’ve always felt like Group.me, at least in their initial execution, should’ve just been a feature of iOS.
Boxcar does notifications for iOS and seems similar to the Android functionality you described the other day, maybe someone mentioned it already.
Boxcar does notifications for iOS and seems similar to the Android functionality you described the other day, maybe someone mentioned it already.
Completely agree with thinking, specially “And then you can pull data from those apps to create new experiences for the mobile users.”We’re building VoIP/voice app and new experience emerged when we’ve been playing with all the data we have.So when a user ends a voice conversation (and that’s when you’re still holding phone in your hand), we check if user is checked-in on foursquare yet. And if not, we offer user to check in at the most probably location. Works like 90+% and brings another app (4sq in that case) like 2-3s check-in experience instead of many more seconds now.
music hack was inspiring and noticeable for the “light glue” for sure. content APIs like Echo Nest and others will help. today i’m pitched on so many apps that solve a part of my problem – the concept of “meta apps” is due and agreed likely.bring it on
i have to login on some of my apps, and on other apps i’ve put up a password to make logging in required each time (apps requiring extra privacy…so i can let my friend borrow my phone briefly and not worry about them clicking on something i’d much rather them not click on).”Assuming your users have all of those apps on their mobile”a massive assumption IMHO. i think making this assumption more realistic will shed more insight into the trajectory of mobile technology.i agree that creating cross-app experiences is a huge opportunity, but only if the primary platform (operating system) is on board and has the governance policy to make this possible in the way that works for app developers and customers, and only if there is sufficient trust amongst apps so that all feel comfortable that one will not pull the plug and leave, perhaps breaking part of the meta app in doing so. if the meta app is a point of monetization, property rights will become a more important issue as well.we also run into challenges surrounding how much the end user is willing to trust the operating system/platform dictator, and whether the platform dictator understands our value systems and how we wish to integrate our apps in the context of our lives. i also don’t think the OS is going to let any extra powerful app subvert its authority to govern the platform (and so we will see acquisitions or behind the scenes manipulations).
spot on analysis Kid
Interesting comment and post, Kid and Fred.Your comments and Fred’s post remind me – though the connection is not immediately obvious – of an OS I had read about quite some years ago (I think in BYTE magazine when it was still a printed one); the OS was called Oberon – http://en.wikipedia.org/wik…. It was a research OS created by Dr. Niklaus Wirth – http://en.wikipedia.org/wik… – of ETH Zurich, Stanford Univ and Xerox PARC – a renowned computer scientist who is known for Pascal, Modula, Modula-2, Oberon, among other things, and also wrote some highly regarded books on software / computer science, on topics such as structured programming (which was the forerunner of object-orientation), stepwise refinement, algorithms and data structures, Pascal, etc. I read some of his books in my early programming days and they were very good. He was considered a major software guru in those days and his work was highly influential on the software industry.I made the connection (between this post / your comment and Oberon – which is both a language and an OS) because a key feature about Oberon (the OS), IIRC, was that _all_ programs running in it, run as part of the operating system itself, that is, in a single process. So it’s more like the different apps you run are subroutines rather than standalone programs. This may (or may not) help with the issues of inter-app communication that Fred talks about, if an OS or infrastructure that had this Oberon feature, was to exist on mobile OSes. Of course there would still be the issues of trust and security that are applicable without this approach, and that many other readers have mentioned.- Vasudev
Beyond liking this comment, i have two comments for you.1) What are you using for the extra password protection2) I really think you should check out Mint’s app – it is a hybrid model in that it keeps you login, but in order to access the app you must provide a pin. It is a nice middle ground of being logged in and not being logged in. And I wish I would see more people use that sort of hybrid for identity oriented apps.
some apps have a feature that lets you enable password protection as one of their settings. i have my whole phone configured so that when the screen shuts off after 30 seconds of non-use, a pin is required to access any phone functionality again.i’m a little afraid of mint. they probably already know information about me that i’d rather them not know. and of course they will turn it all over upon government’s request via the patriot act…..
[…] have my whole phone configured so that when the screen shuts off after 30 seconds of non-use, a pin is required to access any phone functionality again [..]wow! if to be honest i would like have a phone like yours… can’t say that i have a lot to hide, but somethng should be left as private, right? and some people just can not understand this simple thing..
We are building an app that is cross platform and I’d rather integrate it into Twitter etc at the server end and connect there than on the handset, I think it gives you more control.
Regarding oauth without browser session, some services implement xauth, but it requires the user to share his username/password with the app. The Facebook iOS implementation is quite smooth, instead of opening a browser, it opens the Facebook app where you can validate access to your data without the need to enter login credentials.I like the idea of apps being able to communicate with one another directly on the phone, locally, without the need for any web connectivity. That could enable some interesting applications.
yeah, that’s what i am thinking about
>I like the idea of apps being able to communicate with one another directlyThis has already been possible for ages on UNIX / Linux / the BSDs and other UNIX variants via IPC (Inter Process Communication – a standard, well-known set of techniques: messages, semaphores, etc. and via sockets (which are sort of Net connectivity but not Web) (except for UNIX domain sockets which don’t need a Net connection at all – I mean even within the machine) Some of those techniques or similar ones also exist on Windows. Not sure if Android (even though based on Linux) supports those UNIX-style IPC techniques though (or it might, but not expose them to app developers, only system developers). Mobile OS creators should consider adding / implementing such APIs for inter-app communication on devices. Also see my earlier comment about D-Bus – this is used on the Nokia N900, which was, regrettably, possibly the only smartphone Nokia released that ran on the Maemo 5 OS (a variant of Linux optimized for phones); Meego (the merger of Maemo and Intel’s Moblin) was to have been the successor to Maemo 5 and was to have been the basis for a large percentage of new advanced Nokia mobile phones before they recently decided to tie up with Microsoft and use Windows Phone OS, relegating Meego to the role of “research OS for next-generation stuff”.- Vasudev
Nokia N900: http://maemo.nokia.com/n900/Seems to be a pretty interesting mobile, note: mainly for developers, though, not general consumers.I got to know of it only recently though it has been out for maybe 2 years now. Heard good stuff from a couple of owners of it, though it does have quite a few cons too. Might have got one except for the fact that Nokia will probably now withdraw support for it and pull down the sites from where you can get online software updates, re-flash the firmware if anything goes wrong, etc.- Vasudev
Health tip: stay completely disconnected for 24 continuous hours each week.
To me your post about how mobile business models will morph with web business models has an implication for this post. I also think that the valuable mobile companies will also have strong web components. I’m not certain why we would integrate at the device level when we can integrate and stream at the server level instead. It is much cleaner, much less controlled by the mobile OS and their sandboxes, and much less reliant on a particular user having a particular app on a particular device.
its a good point Elia that much of the notifications can be done with the help of the server. especially for straignt forward notifications with small data payloads. But for a notification that results in ‘pulling data’ that is huge out of an app ( imagine video ) …and aleady local to the device i suspect it would be a better user experience to cut out the server.
I can concede that but am not certain that it is really possible today. I can’t speak for Android today but non-running iOS apps cannot “run” in the background, for the most pa, and thus could not initiate a download or other process without becoming the foreground app. Therefore, something external would still have to trigger the download to begin.
ah shucks – you’re right. I keep forgetting about that. However, as I was sitting here wondering about if we could somehow send a local “push notification” I found this on stack overflow: http://stackoverflow.com/qu…They talk about “local notifications” there… Elia – time to figure out how to add a local app api for your powerOne app 🙂
I have always signed in using OAuth/OAuth2 without a browser in my applications, using htmlunit that simulates a complete browser (in java). But other alternatives are using a hidden browser. I think these use cases are against many sites policies.
Sorry, can you correct it?
One of the things I think we need to see here is someone besides Facebook (Twitter, Google) fight seriously to be the standard identity system. For example, Facebook now makes single sign in across apps possible (http://www.facebook.com/blo… but I don’t think any other major identity services do.
i agree chris
Agree. Connect is Facebook’s most important asset (by far). The wider it spreads, the deeper Facebook embeds itself in the fabric of the web. I think they will remain a leader in the ‘social layer’ for a long time, but some startup will disrupt them way before they claim identity and the ‘personal layer’. When considering all the user accounts & accompanying data outside of Facebook (waaaaay more than inside), there is tons of space for others to innovate and create new value for users.I think identity aggregation/standardization could only happen by piggybacking on a compelling use-case. No way it comes from any quasi-standardization effort – my mom would never understand the potential benefits of something like OpenID, but she sure finds value in keeping up with the jones’ on facebook.My bet: within the next 18 months, some startup will crack the magic use-case around personalization and the web will shift.But I suppose I’m preaching to the choir on this 🙂
One of the things that other identity systems will have to compete with is the sheer volume of data that Facebook offers developers.To be able to understand your users’ demographics, education, employment sector and interests is hugely valuable to developers. And it’s not done in a creepy way, because (a) I put the data into Facebook and (b) I gave the app permission to get it.I’d love to see a strong competitor to Facebook on this front, but I need some incentives as a developer to pick such a competitor.
Agreed. FB has perfected how to propagate their social plugins easily, and they have been gaining ground by infiltrating websites and user experiences that way. As time goes by, it will be increasingly difficult to dislodge them.For eg I just noticed that TechCrunch has switched to FB comments, and that’s scary and annoying.
i hope, expect, and pray they will switch back
They lost me as a commenter, but in their defense the quality of comments and replies has improved.
are you sure of that?i went to a bunch of comment threads and its gone from trolling tocheerleadingit’s a lot more positive for sure, but lame as hell
“lame as hell”No worries about that happening here at AVC. 😉
quick impression, the better solution would be a comment aggregator
What if Disqus implemented a more rigid identity-based registration? And get rid of anonymous commenting. That’s the stupidest idea ever. It’s like I’m speaking to you and I put a mask on because I don’t want you to know who I am.
I disagree. Fake Grimlock and Kid Mercury are great examples of why peopleshould not be forced to comment with their real identity
Good point. Maybe we need both, as long as pseudo-identities don’t take over the real ones.
Honestly, I don’t think TC care about whether there’s cheerleading in the comments (despite what MG Siegler says). They want to stop the trolls at all costs because it was seriously damaging their reputation.The only thing that might reverse the decision is if their page views go down.
I don’t think that is true
On the money, yet big thing is Fbook is getting exposure and at same time trying to establish they’re platform has intelligent bantor…remember so many screwballs think they world knows they had a good trip to the restroom.It will remain lame.
this post says FB commenting is killing authenticity http://stevecheney.posterou…
@TECHCRUNCH NEVER STOP USING FACEBOOK COMMENTS BECAUSE THEM LYING ABOUT REASONS FOR USE IT.THIS NOT ABOUT TROLLS. IT ABOUT GET MORE EYEBALLS FROM COMMENTS IN FACEBOOK FEED. 1990S HERE AGAIN, AOL/HUFFINGTON JUST WANT MORE EYEBALLS.SOON THEM HAVE MORE POSTS ABOUT LIFESTYLES OF SILICON VALLEY, WHAT FOUNDERS WEAR TO E3, WHO DATING WHO, AND THEN TRANSFORMATION INTO PEOPLE MAGAZINE FOR TECH COMPLETE.
The only thing I liked about the FB interface is that you can delete the comment — which is exactly what I did when Suster ran identical posts on TechCrunch and Both Sides… and I saw that I had the option of commenting on Disqus instead.I’m not the typical TechCrunch commenter anyway, but will be less so (if at all) while they are using FB comments.
You can delete your comments as well on Disqus. I think perhaps that TC wanted to tighten the anonymous or frequent trolling, and an FB signon forces you to use your own identity, whereas Disqus is a bit loose in that regard.
Right. Thanks. I forgot that you can now do this from the Disqus dashboard. No more “…” for deleted comments. Love the dashboard.
Am I the only one who thinks some anonymous trolling is a good thing on the internet. Some privacy means we are willing to say things we wouldn’t have said otherwise.
Yes and no, why say something you wouldn’t say otherwise? In a sense it forces users to be honest about their opinions, its a better reflection of real world interaction. Take comments on youtube for example, people can be really offensive on youtube precisely because no one knows who they really are a lot of the time. I doubt people would be as ruthless if they had to use their own identities, that said if they were it would only show who they really are as a person without hiding behind a mask.On the flip side anonymity can give people the ability to be brutally honest in positive ways too.
No you are not the only one. Trolling, if managed, has real positivesThe problem is that TC doesn’t manage their community
Simple solution. Disqus could let the site require Facebook sign-on. That would be lame, but if that’s what Techcrunch is looking for, more power to them – I’m not really a commenter over there.
If that’s what they want then they shoukd stick with the lame cheerleadersthey are getting from FB
fFred, I agree completely with your reply – “conflict about ideas” was the only reason I ever looked at TC comments.Go Disqus!
I agree.I don’t like using web services that require you to login ONLY via Facebook (or Twitter or any other third-party web service). I don’t use such services. If they have an option to create your own login id and password, in addition (or rather from my point of view, that should be considered the main option), only then do I use such services. I simply don’t like the idea of sharing my credentials on one service with another service, no matter how well known or respected they may be – IMO, it opens up too many cans of worms such as security loopholes. I don’t have an idea for a solution for this, though, except to say maybe some kind of specialized, legally sanctioned, legally accountable (for security transgressions / data theft / hacking) identity provider. This point also ties in with Rick Bullotta’s comments down below, which I agree with – doing this well (i.e. securely, universally and globally) is a _hard_ problem.- Vasudev
>except to say maybe some kind of specialized, legally sanctioned, legally accountable (for security transgressions / data theft / hacking) identity provider.Along with a whole set of policies for a framework / API for trust between apps, etc, to enable data sharing.On the tech side, at least for Linux based systems, D-Bus may be of use here – this is only based on what I’ve read of it, have not used it yet.http://en.wikipedia.org/wik…- Vasudev
After your post on notifications, I started considering the iPhone users behaviour. Most of them seem not to be bothered by popups or by the need to enter into the apps they have to check, instead of having them notify. To me, mobile notifications are a big deal since I got an Android phone. But I wonder if the iPhone user’s attitude is still determining the market and the business opportunity of some startups, when it comes to exploiting or not the potential of notifications and of always logged in experience.
Not an expert here, but intuitively I would think it is better to keep the device end as simple as possible, i.e., keep all that bridging in the cloud.A second point though: there is a huge opportunity for a mobile security startup. All these open accounts are a potential mine field for 1) when the device is lost, 2) when malicious apps start meddling with legitimate apps.
What is the realistic monetization/market potential for metaapps over the next 1,5, and even 10 years? While the trend is certainly logical, do you all think there is something to be said about metaapps being before their time (aside from technologists and college students)? Apps are intuitive to infants and baby boomers alike. It seems more complex product concepts, ie metapps for the masses, might be best once the majority of our planet has adopted to App paradigm. Of course there is money in it. Just wondering if app shops will be better off focusing in cash cow apps for 1,5,10 years and then transitioning to metaapps. Perhaps moving too early into this arena would create a bubble. What do you all think
I don’t know about this- I think you are far too close to the technology to make a judgement relevant to the average user. I’ve been doing some casual research to determine which of our titles should be apps vs. Ebooks and I primarily get blank looks. 99 per cent (why doesn’t the iPad keyboard have a per cent sign?) don’t have any of these apps on their phones (excluding Angry Birds). I can understand why given the awfulness of using apps on Android, but we’re still really early into this.Not to do a fanboy rant but Apple understands this strategically and Google and MS don’t. The readers of this blog probably connect all their social apps on their phones but that, in my limited experience, is not out there in the non-techie world…I think that OS designers (or an enterprising start-up!) should offer preset app connections as an option for new buyers. That would be a game changer- and Apple seems to be headed in that direction…what an interesting idea.
Re: “Is there a mobile implementation of oauth that doesn’t require a browser session to do the auth?”yes, sortof, app devs can embed a web engine ( webkit based engines ) in the mobile app and display an ‘in-app’ browser experience that is seamless with the rest of the app functionality. ( oh oh GINORMOUS shameless plug follows:) we do this with the AppUp encapsulator tool we’ve built http://appdeveloper.intel.com/… )
OAuth 2.0 addresses direct app to platform interaction without requiring any use of the browser.
(For the record, I know that you, Fred, know this. But I’ve seen vast armies of young devs in Silicon Vallley who don’t because they’ve mostly used and built web apps. It’s a pet peeve.)It seems to me that the only new thing about ‘notifications’ and ‘always logged in’ is ‘mobile’. The reason these things appear to be new to some people is the current fascination with ‘web apps’ set user experience back by many years. When developers starting building applications using web pages, they lost OS services. They couldn’t save any data locally. Asynchronous UI was too hard (until someone made AJAX easier) so they stopped using proper async-UX patterns. No more notifications. No more background processes. “Html5” is trying to add some of these features to the web. Mobile OS’s came along and didn’t implement these OS features for awhile either.Adding ‘mobile’ to the existing software experience has vast untapped potential. Phrasing it as adding notifications to web apps or mobile apps may be useful for ideation as it lets you see those OS services with fresh eyes. Just don’t fall into the trap of thinking that these features are at all new.
Fred this post ( and comments ) remind of me the 10 golden principles interview where APIs were mentioned ..adding ‘local device apis vis a vis notifications’ to your evangelism of apis would be a great thing ( imvvvvvvho ..plus im not at all biased by being employed by a company with vested interest in client side compute 😉 )
I was envisioning a screen on an ‘always logged in service’ that lets you manage which features appear on which devices, much as you can manage notifications or privacy settings.And while most in this thread are writing feature-y things, I do think about better ads. Knowing one’s ‘Device Graph’ and the fact that a user hits certain apps on certain devices (but does not use certain apps on other devices) strikes me as an big opportunity as well.And I think ‘always logged on’ may not necessarily be a requirement. Hash-encrypted, anonymous GUIDs that are asynchronously ID’d to a single user is possible. It may not fall on a specific app, site or service to do this — real-time networks may fill this gap.
I’m not sure if what you are describing is a feature or if it’s something worthy of a startup with business model. At least, it’s not clear to me.
This is why I love your blog Fred; you’re always thinking about how things could be better, and you understand the technologies that can be used to make things better.It’s perverse to ask for more, but what would make this post even better is an example. I mean, why can’t you build a website that uses APIs to display, say, real estate listings on a Google Map, with Facebook as a login, with Foursquare check-ins to show which homes to buy that are close to your friends’ daily routines? I am being too literal and too dense, I know, but I’m just trying to figure out how mobile apps can be better in this regard than web apps, which can always have links to launch other sites if that is what is needed…
it’s a half baked post for surei’m still working through this stuff in my mindi am hoping the community helps out
Don’t worry about being half-baked. This post really got me thinking, probably in the way that it has you. So I’d like to see more of these…
Are you saying that the mobile is turning into the device equivalent of a Facebook, where the primary reason for being at the destination is to connect to all the people and communities you wish to engage? I can see this as being true.Always logged in means, to me, that you take your content with you everywhere, and add to that content anywhere you have an interaction that gives you or that content value. I see apps as content, by the way. I think there will one day be a kind of education certification system that appraises this content and values its interaction with other people.This may not make sense but it’s also just an off the cuff response to what you are saying, Fred. Not sure if I understand exactly what you are saying, or what I am saying fully. It’s a hazy area.
Yup. That’s my thinking
WORLD DESPERATELY SEARCHING FOR UNIVERSAL ID. NO ONE COME UP WITH RIGHT ANSWER YET.PHONE NOT ID. PHONE NEED TO BE WINDOW TO ID. ID LIVE IN CLOUD, THAT WAY ACCESS IT WITH PHONE, COMPUTER, TABLET, ETC.MAIN BARRIER = CONTROL. NO ONE WANT TO PROVIDE UNIVERSAL ID WITHOUT CONTROL IT. BUT IT NOT WORK UNLESS PERSON CONTROL OWN ID. BUT THAT MAKE HARD TO MONETIZE.PERSON THAT FIGURE OUT HOW TO MONETIZE OPEN UNIVERSAL ID IN CONTROL OF USERS WIN WHOLE INTERNET.
What you say is wise, but remember the forest thru the trees ;D
It’s actually harder to do what you’re suggesting in mobile than on the web right now. Web apps have URLs and APIs and different apps reference each other all the time. There are plenty of mobile apps that use a web service backend plugging into these APIs to accomplish this. On the device, Android has the Intent model to communicate between apps and iPhone has some primitive URL handling mechanisms, but these are VERY immature compared to the web.Also, I really don’t see what you’re getting at with being always logged in. I’m always logged in to all of my web apps just as much as I am to my mobile apps. It sounds like you’re referring the ability to give one app PERMISSION to have access to the data of the other apps.Now, the problem of being able to quickly have one app use the “API” of all of your other apps and services – that is interesting… There are some solutions to this, but I don’t think the ideal architecture has this happening ON the mobile device.
While I think having single sign on and staying logged in is very important-I want the ability to lock down my phone. If my phone gets lost in a taxi or gets stolen, I want to be able to brick the damn thing very fast. If NFC gets very big, this becomes even more essential (not only do you steal my identity and private information, you end up stealing my wallet at the same time)
Fred, in order to send users from 1 app to another, an app require a URL handler or URLscheme, which is a simple URL that triggers an app on your iPhone. The very large majority of apps don t have one (we have the largest database or URL handlers at appsfire). This is what FB connect is using to send you back to your app once you have connected with the new single sign on. Actually thanks to Facebook more and more apps have URL handlers and more apps can then provide a smooth sign up experience. I wish Twitter and others did the same
That’s a great comment. I will push this
By all means, please do. this is really a hot pointtake a look on how we implemented twitter sharing on appsfirehttp://getap.ps/appsfire (from an iOS device). Requires no more loginnor connect. Takes you right from our app to twitter app (or anytwitter app we detect) and right into the publishing area.I believe this is really a killer experience
Fred, I suspect one problem/opportunity with notifications may lie in notification verification, or “controlling the noise level” as notifications become increasingly popular.That future has already arrived in some parts of the world, including parts of Asia and the Gulf countries. When traveling to some of these places, you receive a barrage of notifications (as you arrive, as you walk through a mall, visit an ATM, turn your phone on and off, etc, etc.)When 10 apps, 2 telcos, and eight retailers are blasting you with notifications via apps, SMS, BlueTooth, etc, and there is no way of filtering them short of turning off the message vector, it can become increasingly hard, as with spam-blasted email accounts, to enjoy the value.
Spam filtering for notifications will be huge
i’ve been playing with the FB login and register components quite a lot recently and they sure make life a bit easier. Logging someone back in to a site if they’re connected and logged into facebook is simply a bit of JS and if you need it some very simple server side code.I think a problem with all this single sign on stuff is the fact that you blindly click connect to multiple services and then forget about where you’re information is going. How many people actually read the permissions notices from FB when they sign up to things – I for one don’t always and I know how the tech behind it is working – and what they’re capable of getting out of FB. This could start info leaking from places like FB without people quite realising and also actually having given consent.Google recently introduces 2 stage auth for google accounts – i signed up to it as a test and at first thought it was a lot of faff, but now I’m quite impressed with the whole thing. I have multiple passwords – one for each app that connects with my gmail account and if I ever lose control of a device with access to my account on I just delete that set of passwords. You do need to be quite careful about not losing your phone as it does have the key gen on it, but the whole system provides quite a secure way of multiple entry points into an app where passwords are saved on devices.
This has always bothered me when I’m on my mobile, I get an email about a new Twitter follower and the link takes me to the browser, not the app.Doesn’t make sense and overall, I’d rather have apps that work together seamlessly.
Not such a good idea to let one app call another app. Flash used to be allowed to do that and Windows Macros still do – and then they are exploited in virus or malicious software design.Those are bad enough on your laptop, but on your smartphone – with pay by phone applications, your contacts, your location(think how much burglars would love to know when you are away), etc.No thanks
I’m going to try and answer your questions, at least from the Android angle.”Is there a mobile implementation of oauth that doesn’t require a browser session to do the auth?” Yes! Android has a built in authentication API, however not very many people use it except for Google. If you install Google Reader you will see it in action on a screen labeled “Access Request” the first time you open the app. This is not OAuth and it appears that Google is the only identity provider that has implemented it. Facebook and Twitter could, if they wanted to, but have chosen not to.You can do OAuth in Android. There are a couple 3rd party libraries for it. They popup a small webview window to put your credentials in. It works, but it doesn’t feel very integrated to me.I hear the Facebook is going to bring better authentication to Android. I assume it will be similar to the iPhone experience described in other comments.”Can one app deliver notifications that take the user to another app?”Yes again! One of the best design decisions in Android is: Intents. Intents are uses whenever you want to do anything; launch a new screen, start a background task, update a widget, interact with a Notification. Everything is Intent based and you can launch anything with Intents. This allows apps to “deep link” into 3rd party apps as long as you know the name of the URI(in this case ComponentName) to get there. I can link to any screen of any installed app that I want to.And yes, you can do that from a notification.I hope that answers you questions.
thanks david this is very helpfu
This is where it all comes together. You want your app to be on the front end. To do this, you have to have an app that makes it ‘easy’ for the User. The User gets to go where they want, the quickest way possible.Insofar as Twit, FB, FSq and so on, you have to take care of that during development so they participate. The going thing where everyone wants to control everybody else will have to be eliminated. To do that, the end run product has to be such where one of those social graphs will regret not taking part. Then you probably have two battles happening simultaneously between the ‘closed’ and ‘open’- iPhone/Android, Twitter/Fbook (or the next one in the game).The consumer wants what works easiest. As a group, the consumer is maturing and will not be so ‘fad’ driven. You deliver the easiest way for them to see what/from whom they want and you’re on top. The consumer won’t care if that photo, vid and/or joke was on Fbook, Twitter and so on. They just want it….now.
the key can be moving the authenication wall outside of the app and into the OS. in the world of the web, moving delegated authentication from the site to the browser would simplify identity management. for example, i should be able to login to my browser via OpenID, and this authentication would load a certificate into the browser that would allow me to login to sites “passwordlessly”. in essence, this would break the traditional password anti-pattern where people are reusing credentials because the browser would be the keymaster. in addition, it would reduce phishing because a site asking for a username and password would become the exception and not the expected behavior. a similar approach, where you login to the phone instead of the app, would be intriguing. a great example of this “paswordless” login to multiple apps is Game Center on iOS.the challenge is not just creating an always logged-in identity for mobile, but federating services via an identity provider. for example, if i choose to let Twitter manage my identity, but then have authenticated Flickr, Instagram, bit.ly, etc. via OAuth against my Twitter, these chained delegations should travel with my primary identity provider. this would allow me to login to a new service via Twitter and have previously chained authentications travel with me, so, for example, i could use a new app without having to declare and reauthenticate every web service i use. OpenID Connect and OAuth Echo began examining this problem, we’re still far from an open system.
Fred, I made the same observation when I wrote about my experience with Android the other day (http://www.kuchinskylaw.com… and agree 100%. The applicable part of the post is:”This made me think about what factors might make Android a better experience than Windows. This is my short list: speed (no hard-disk as a bottleneck), no-logins (I don’t share the device and I’m not being signed out of websites and apps), no lockups or freezes, app design (minimalist design focuses on critical features dropping clutter and UI is similar for most apps so I don’t have to learn a new UI for each website) and portability (obvious, but the size of the device is often preferable for light reading before bed even over a netbook). “
great insights. it is waaay better than windows
App interoperability sucks. More precisely, it doesn’t exist.The challenge is that for it to exist, you need an OS layer. And then the privacy issues get 10X more serious. (Never mind that you need app developers to buy into using it.)
If you haven’t yet, check out the concepts Mozilla are playing with for Open Web Applications:https://apps.mozillalabs.co…Although these Open Web Apps are “installed” in the browser, it’s really more like a persistent login and a choice to use a particular site as a provider of services.So, a like button, share button, payment button, contact selector – they can all be user-controlled cross-site mashups enabled by the choice to “install” an Open Web App that maintains authentication and a record of your preferred services. You could install, say, a Twitter or a pinboard.in app and any site offering a share button can delegate that to your chosen app by way of HTML5 tech and a new browser API call or twoAnd, with Firefox Sync, those installed relationships can be shared across devices, both desktop and mobile. And hopefully, other browsers will take up the APIs that glue this stuff together, since most of the tech is just HTML5
Has anyone checked out Greplin? https://www.greplin.com/ It’s a search engine that let’s you search within all of your own stuff – Facebook, Twitter and Google for free and other apps like Evernote with a paid membership. I read about the 19 year old founder the other day (really great story) but just realized the site has launched. Just checked it out> nice, clean, easy set up = maybe a big step towards the day when our apps can work together in harmony!
Fred, I’m loving this series of posts, and this one rings true to my comment on the previous one. I think communication between apps is still the key stumbling point of the native app world. +1 for the web.With that said, I’m not sure login is the connector. I understand that this is the natural binding point for all discussions, but it invariably creates a single point of failure (or even worse, a single point of trust). Really, I don’t think users want to login. Although I like the prospect and subscribe to the oAuth methodology, I have to think this is a rabbit hole for most users. Security is huge, but it’s a reality that most users would prefer not to spend much time thinking about.Where does this leave us? It leaves us considering the always logged OUT experience. How do we connect apps, websites, and email without navigating a trust funnel? Could we give more thought to verification instead of authentication? Do we shift content or meta data? As I mentioned in your previous post, a consumption paradigm that is both app and device agnostic is extremely appealing to me.I’ll add that the native versus web debate is likely irrelevant to the end user, and any solution needs to be transparent to this. In the end, the one-up that the web has on native apps is, well, the web.
Communication apps (call, sms, email) built in to the OS were the first to be always connected. I guess what has changed now is that more types of apps can be always on: News apps, games, Location apps etc could compete with the communication apps for your attention.I agree that this is a huge difference to web pages that are we are not always connected to. Perhaps mobile will turn into a more push experience than pull. Push messages that are relevant for me depending on who I am, where I am, etc etc. I unlock my phone to see what is going on, not to search or to browse.
I don’t want to be “always logged in” and if there is something that needs my attention, I want to force a login. This uber-technogeek lifestyle is created for people who have money to burn and don’t have to work, and that’s why only kids and about 15% of the adult population will ever participate fully.
I’m betting a lot of money that you are wrong with that last comment
A real problem in application sharing even with defined URL’s as discussed in the comments is, that if an application requires a particular service (i.e. maps) or sub-service (i.e. 3D maps) and the device does not have an app that supports the required services, it can totally mess with the user experience. If however the application requires cloud based services, the application is free to pull it through the cloud or from within the app using the browser engine.
I agree… I really do not believe this is a hard problem to solve. We need to abstract the connection api and the notification api and the natural place for this is the underlying OS. So I would presume Android, iOS or any of the Mobile OS platforms should be able to provide a plug-ability for this.