Tuesday, February 16, 2010

Apple blocking Google Voice blocking webOS App

Oh what a tangled web we weave. I feel like I need to express how extremely disappointed in Google I am right now.

They were all independence and walled garden and network neutrality back in July of 2009 when their official Google Voice App was denied by Apple.

But how hypocritical can you be when they are now doing the same thing to 3rd party apps trying to access Google Voice from other mobile devices. They are not only not releasing an API like they have done with every other Google product out there, but they are implementing byzantine security to actually prevent 3rd party apps from accessing the same functionality that their Android native app is capable of or their new mobile site is able to access.

What does this mean to the non-technical? No matter how much authorization you provide a 3rd party app to access your Google Voice data, they don't want you to be able to dial out using the access number methodology like they have in Android and Google Voice Mobile. So you can give up your username and password to an app and then Google will still block that app from dialing out using the super easy access number that they allow their own apps to use.

But its their product they can do what they want, right? Sure, just don't go crying to everyone the next time some other vendor blocks your product from their platform or device. Would they be so willing to apply the same statement if say AT&T put a block of all users to the www.google.com domain and redirected to bing.com? I don't think so, and there really is no difference. If a user wants to use a 3rd party app to access their Google Voice account and take the same actions you can do on the web or in Android, then why block it?

Safety of users would be a good reason, but at that point if they were worried about it, it is too late, the user has already given the keys to the kingdom and with the extensive Google API's, they could modify your contacts, send email from your account, search your Google Documents, but what they absolutely cannot do? Dial a US no-cost phone number using the access numbers that Google has setup for Google Voice.

Really Google? Really?

How many security keys can you need? You get one when you login with the user's info, then when you go to Google Voice it creates another one, then if you want to dial out, you need yet another key. You protect the phone more than anything else in your offerings and it just doesn't add up.

This is the summation of my frustrations in trying to maintain gDial Pro for webOS mobile phones. I have spent more time on troubleshooting the Google interface piece than anything else on the phone. Why not put out an API? There is an API for Wave, and even the new Buzz, but nothing for Google Voice.

So it begs the question, why is there no API? Lack of resources, I doubt it, security of info, see above as there is a lot better info to access if you were trying to do something wrong.

Where does it leave us? I don't know, they must have some reason for it. Take a look at their Data Liberation Front. Then go to the Voice item, hmmmmm, not a lot going on there for data liberation.

If you profess freedom, then you have to be free yourself or it dilutes the message.

Friday, February 12, 2010

gDial and Google Voice v1.3.1

-Major change to fix up gDial after changes at Google Voice. Please read everything below:

Note this version and going forward will be taking a new tactic in order to provide as much stability as possible for changing Google API's all the time. Starting in 1.3.1, we will be moving more of the interface to a server side solution. So, gDial will communicate with our server (At Google's Appengine, so you can be assured of uptime) and that server will interact with Google Voice on your behalf. We are doing this so that future changes in the Google interface can be fixed on the server side and not require a new rollout of a new client and all of the time that takes. We can fix it on the server and immediately make that available to our users for better reliability.

Great, so what does this mean for privacy? In version 1.3.1 the only interaction with our server is in 2 places. We check your email address against a list of users on our server who are part of a beta program. The second is that we pass a token from gDial to our server which exchanges this token at Google for a Google Voice token that we pass back to gDial. gDial then deals directly with Google for all other operations. Your password is never transmitted to our servers

I wanted to be transparent about that so that everyone knows what is going on. The hosting is at Google's appengine so there has been no noticable speed difference in testing.

Because this takes server resources on an ongoing basis, we will have to charge for this ability. So as of 1.3.1, there will be a monthly fee required to use the following features: web dial and SMS. Manual dialing as well as viewing history will not require this subscription. We are going to try to make this work at $1/month billed by Paypal as we figured that would cover server costs and be inexpensive enough for almost anyone wanting that Google Voice functionality. You will get some extra features with this subscription as well that are almost done beta testing if Google would stop changing things on us