The Skout mobile application talks to Skout’s servers through a simple API.

What’s returned is a blob of XML containing the user’s complete profile data. In fact, the profile data is too complete, including some bits of data information that is never actually used by the app. For example, we can see the user’s exact date of birth… but only the user’s age in years is actually displayed. Most serious, however, is the high-precision location information that is returned in the homeLocation and location tags.

The three decimal places of precision in the co-ordinates is enough to locate a user to within about 110 meters north-south, and substantially less than that east-west depending on the distance from the equator.

Fortunately, the vendor patched the API within a few hours of notification.

I really should get into the habit of checking all my apps from time to time for this kind of leakage.

This is a form of two-factor authentication — when you sign in to twitter.com, there’s a second check to make sure it’s really you. After you enroll in login verification, you’ll be asked to enter a six-digit code that we send to your phone via SMS each time you sign in to twitter.com.

This is great, and has been an increasingly frequent request over the past couple of years. However, there’s one drawback: You can only use your phone number with one account.

So if you have a public Twitter account, and another one you use for work, or for close friends, or for headlines from your blog…you can only enable two-factor authentication for one of those accounts.

The growing use of phone numbers or email addresses as a substitute for an account name is something that’s been driving me crazy for a long while, this is just another example of how it can unnecessarily hamper users.

Comments Off on Two-factor authentication for Twitter: One account at a time

McCain does have a point. It’s really annoying to pop open the App Store every time there’s a new update. We wish iPhones worked more like Android phones in that respect, letting you update apps automatically.

But is that really a good idea? I know there have been several times in the past year where an upgrade to an app broke things, and needed a subsequent “emergency” fix from the developer.

The announcement of the improved Google Hangouts the other day worried many of us who use Google Talk (through third-party clients like Adium). Were they completely killing Jabber/XMPP? I tested some this morning, and found that I can chat between Hangouts and Adium. Then I found this article, which explains in a little more detail what’s going on:

There’s some bad news that comes with the new Hangout architecture, at least for others who want to have interoperability with Google chat users on the server side via XMPP. Google will not allow server-to-server connections. Chee Chew said that “we haven’t seen significant uptake” in federation with Google Talk via server-to-server connections. The majority of the uptake Google did see was from organizations or individuals looking to bombard Google Talk users with chat spam, Chew said. As a result, server-to-server XMPP has been left out of the consolidated Hangout environment.

That means that users of Jabber, OpenFire, and other open-source XMPP-based instant messaging servers won’t be able to tie into Hangouts through their own systems and will have to have separate Google credentials to chat with Google users. But it doesn’t mean that Google has euthanized XMPP completely, as some have reported.

The good news is that Hangouts will still support client-to-server connections via XMPP, though only for one-to-one text chat. That means that Web and client-side chat applications that have used XMPP to connect to Google Talk will still be able to see presence information about their contacts in Google+ and chat with them via text in Hangouts.

So the grand, federated world where all kinds of chat services interoperated is dead. At least, it’s not happening through google. Which I think we knew anyway — I think they killed at least some degree of XMPP federation some time ago. And I’m not sure anyone ever really tried to make it work anyway.

Shame, though, that these companies can’t just try to get along. Remember when Apple promised that FaceTime would be an open, interporable standard?

This is a few years old, but worth reposting, as the question comes up regularly (like it did a couple minutes ago in my Twitter stream). The goal, it reminds us, is to pick an algorithm that’s “slow as hell”:

So we’re talking about 5 or so orders of magnitude. Instead of cracking a password every 40 seconds, I’d be cracking them every 12 years or so.

Note also that scrypt and PBKDF2 are generally recognized as valid substitutes, as the basic logic of this post still applies to those algorithms.

More and more websites use like-buttons from Facebook, Google+ and Twitter. However, these buttons send information to these social networks even if the user doesn’t click them, but even if they are just present on a webpage. This way these networks are able to track which websites users are visiting and are able to build fairly complete browser histories of their users. Because this is neither what a user might expect nor what many website operators that embed like-buttons want, this alternative way of using these social services was developed.

Though one wonders why this sort of feature isn’t built-in to browsers to begin with.