Risk Complete Failure

Recently I've been in a couple of conversations where the idea of testing whether a user is logged in to Google came up. This can be helpful for tuning the experience when presenting sign-in options: you can highlight the Google+ Sign-In button on the basis the user was already signed-in to Google, so should just need to consent. It's also one way of responding to the fact that signed-in users typically are going across search using HTTPS, so you don't get information about the search terms a user used to reach you. By highlighting the benefits of signing in, the users may choose to do that, and hence give much more ability to personalise and so on The (slightly arcane) method for doing this is checkSessionState . This is a bit of Google oAuth 2.0 plumbing that allows cheaply checking whether things have changed without round-tripping to the server in many cases. There is a session state, which is kind of a hash of various aspects of the user's signed in status, local

Having been involved with ZeroMQ for a few years now, and having taken a deeper look at messaging last year, I enjoy occasionally dipping into various network protocols. One of the most interesting recent efforts is QUIC, from the Chrome team (who are just a short bridge away from my Googley home of the Google+ team), which is aimed to provide a post-SPDY protocol to be used instead of HTTP over TCP for high performance web sites. Things at Google tend to start with a design doc that lays out the rational and the plan for a given project, and happily the QUIC doc is openly available . It's a great read, and its worth highlighting some of the more interesting problems the team are addressing. To start with, the document lays out the (12) goals of the project and the motivations for them. These roughly break down into two camps for me: Usable Now This is a protocol the team intends to deploy, and it is one that has to do the job of existing setups. That means it's got t

Applications which access Google APIs are configured in the API console as 'projects'. Each project can contain multiple client IDs, and each client ID can represent a different variant of the application: for example an Android client ID, a web client ID, and an iOS client ID. There can multiple of each, so there might be different client IDs for two different versions of an Android application within the same API console project. One common question is whether a developer should group their applications under a single API console project, or have separate projects for each. While it's pretty easy to see that FooPlayer iOS, FooPlayer Android and FooPlayer.com should all be under the same project, the question is what to do with a situation where there are actual differences other than platform, such as FooPlayer Pro and FooPlayer Free. As a rule of thumb, if the different apps provide similar core functionality, they should be one project. For example, if an applicati

Social sign-in adds an extra twist to sign-in on the web. While systems like OpenID are often used purely to assert identity (e.g. you are the same person as when you came here before), OAuth and OAuth 2.0 were always about granting access to data (e.g. you give me permission to know who your name and friends). While both of these get to the same place for most developers - someone can log in, and you can reliably and securely know which user in an application they map to - the difference is largely about what other data is available. Most social sign-in systems grant access to profile information, such as name, gender, email address, age or age range, and other more specific information. They often also grant access to a users activities on the identity provider, either explicitly or implicitly: for example if I sign in with Google+ you can retrieve a list of the people I have circled (or at least the ones I have given you access to), or if I sign in with Twitter you can easily get