Is your clock adjusted correctly?

FoxToPhone now uses OAuth

In July I changed the authentication routines in FoxToPhone to start using OAuth like the latest version of ChromeToPhone. Using OAuth in a Firefox extension was a little harder at the start because I couldn't find something easy to use like the snippet that it's available for Chrome extensions.

Finally I took that code and adapted it to be able to use it the way that I wanted, without the need of a "background page", and reusing most of the code to avoid introducing any unexpected error.

This weekend this version 1.2 of FoxToPhone has been approved and now it's being updated as Firefoxes check for updates of the extensions. And despite all our hopes on the beta testers it's clear that not everything is OK.

Some people have been experiencing login problems with ChromeToPhone getting a hardly useful "redirecting..." message, and it's not clear what's going on, so it should be expected that some people would get also strange errors in Firefox with the new authentication. We fixed one or two such issues during beta testing, and today I've found another reason.

Your clock settings

Other people have already commented about it in that ticket, and I didn't look at it, but today one user reported login issues and after a little testing I found that while starting the authentication, one request is done that includes the current time, and in this case the request showed that it was one hour ahead of the current time. And the Google server replied with an status 400 meaning that the request was wrong.

So the user just moved his clock one hour back and then he was able to login and start sending the requests. Great!, we're moving ahead.

So if you get a response status 400, then you should check the settings on your control panel about the time zone and daytime savings are correct. Even if you see that the clock matches the one in your wrist, the computer also has additional information like the zone/country where you are, so when it tries to convert that local time to a global timestamp it will generate the wrong data if some of your info is wrong.

Testing time

This is a little script that tries to request the current time to the Yahoo servers and then checks it with your local time, if you see an error message then you should review the time settings in your computer

 

Hey Google, can you improve that error page?

Certainly returning "400 (Bad Request)" when the problem is the timestamp seems a little rude. It's clear that it's possible to check that the parameter is out of the allowed bounds, so in order to be helpful the error message should give a clearer hint that the problem is just that parameter. No real attacker is gonna try to send a request with that parameter wrong, it's just too easy to do it right, so the only people that would pass wrong data there are those users that don't realize that there's a problem with their clock settings.

Just as I've been able to mock a little script that performs a simple test, I guess that you should be able to provide at the very least the same check in a dedicated page and working a little further it should be able to guess more exactly if the problem is the time zone, the DTS or just the clock itself, something that shows the user the correct screenshots to check their settings etc...