That's a very valid concern. There are two technologies that are used for single sign-ins.

The first is open ID. Basically it allows the site that you're trying to access confirm through a host party.

The second is OAuth, and it's a little different. It sets up way of sharing information between two services authorized through the host service (eg. Google). Generally the information that you are authorizing is presented on the authorization screen of your host service at application installation. You should always ensure that the URL of the host service is encrypted and accurate as to avoid phishing.

These are pretty secure as you're never giving your login information to the party that's requesting the authorization. With the OAuth solution, you have to trust that that the system that you're connecting to will handle your data with care, so there is a point of vulnerability. If you don't trust the handling of your data, you shouldn't use the application!

As always, there is a degree of trust that you must have with the services that you use. Even if you roll the code yourself you trust to a degree the competency of that code. However, using an external service requires more trust, and as always, authorization of information should be not handled with impunity.

It's the same thing when you download software. You must trust that the application treats your FS data with care. Therefore you choose software that you trust not to be malicious. OAuth/OpenID allow authorization of specific bits of data so it's a little more fine-grained than typical downloaded programs, but the trust in the service must still be there.

I have no problem sharing my email address with an oAuth setting, or even certain dropbox files, but in both cases, I must have a degree of trust in the online service that I intend to use. I would not, for example, share authorization to my financial accounts with any service. I just wouldn't.

Something very interesting happened when I tried to re-open Vector Paint, a previously installed application in the web store. Chrome had disabled the link and notified me that the access permissions had changed.

I suppose on one hand, the notification is good. On the other hand, the new authorization would give Vector Paint access to data that I'm not comfortable sharing. This led to me uninstalling the application.

I have no problem with oAuth, but I'm not crazy about the way that it's implemented on most sites and certainly not the Chrome web market. It would be far better to use oauth/openid to log in seamlessly and authorize CRITICAL data -- data that the app must need in order to function. All other authorization requests should be relegated inside of the application, and the user should be presented with the option.

So for example. You are trying out a paint program, and you click the install button. On first run, the program asks to authorize the login and your email address. You say yes. The program offers 10MB of storage for your drawings, but gives you the option of using a cloud-drive storage solution like dropbox for your pictures. In so far as you trust the service, you give authorization to paint program to access your dropbox data. If you are not comfortable, you use the 10MB storage provided. Done!

In this model of web app development, the user has control over what data is shared with the app, and this can be accomplished in a few minor clicks (for popular services). It even opens the door for non-standard services by way of offering the ability to put in a URL -- you can choose to share files on your own server with this type of a setup.

IMO, this model of design is not restrictive to requiring a full authorization up front, and the annoying discovery of changed authorization requirements. It lets the user control authorizations.

Another example. Suppose you're trying a real-time-strategy (RTS). You may choose to authorize access to your designated cloud-storage service that is wholly separate from your cloud-stored sensitive information. This authorization can't be known up front, and must be determined by the user when in the app. It would be better to present the user with the option to authorize, rather than force it down his/her throat.

The one thing I like about the Chrome Web Store is that it seems that security is at its heart. The permissions that each installed app needs are presented in easy to understand language, which makes it very convenient when installing applications or extensions.

This FAQ breaks down the permissions and their definitions:
http://www.google.com/support/chrome...er=186213&rd=1

This takes a lot of guess work out of installing apps, and producing complex relationships between services.

Here's a great music 'app':

Mixcloud

CHROME STORE: https://chrome.google.com/webstore/d...mggpk?hl=en-US

This is a glorified link to web-page, but it's so damned good! It lets you listen to 'cloudcasts' of music/podcasts/documentaries/etc prepared by hopeful DJs. You can find heaps of audio to tickle your tympanic membranes.

This could be given a better interface to make it more web-like to make it better. It would also be nice to use an extension to allow control regardless of the window you're on. Currently, it uses a pop-up window.

Still, it's great right now. If you have a web browser (w/ flash) it's well worth checking out. I've never heard 'radio' done this well.

Ars has an editorial on how Mozilla has rejected the WebP image format:

http://arstechnica.com/open-source/n...-to-picasa.ars

I have to side with Google on this one.

I agree with Mozilla that WebP doesn't solve an immediate problem, it lacks features that JPEG has, and even that it doesn't contain desirable features such as an alpha channel.

But I think that these arguments are terribly short-sighted. WebP has one thing that JPEG lacks: openness, and active development.

JPEG has effectively stalled innovation for images on the web platform. While there have been successors to JPEG, they all carry similar licenses which greatly limit the speed or likelihood of adoption. Where is that JPEG2000 we were promised 10 years ago?

Meanwhile, WebP is experimenting with ICC profies, arbitrary metadata (think: EXIF), as well as alpha transparency. This is all within its first six months of release! I expect with these will come more.

Mozilla's short-sightnedness is that they see WebP only as it is today, and not what it is becoming in the near future, and what it can become later still. It already offers advantages over JPEG in certain areas (compression ratios), and looks to pull ahead in a relatively short time frame. For example, an alpha channel with lossy compression would have a drastic effect on web traffic.

I expect Mozilla will change its tune soon enough.

Wow. I've just taken another viewing of ro.me, the interactive video showcasing WebGL and other web technologies. I was floored again, as if having seen it for the first time. I tried it this time in full-screen, and it was simply delightful -- a true work of art.

I noticed that they have a technology section on the site, which show various models and shaders that they used in the making of this interactive video. For novice 3D enthusiasts (like me) it is well worth checking out: http://www.ro.me/tech/

For those that appreciate art, the video is worth exploration: click here to view.

For those that don't appreciate art, read this:
http://www.sciencedaily.com/releases...0523201050.htm

Soon chrome will have an option to encrypt all sync'd data (passwords, bookmarks, etc)!

http://lifehacker.com/5805364/option...ming-to-chrome

This allows you to store back-up your passwords etc to Googles servers and still maintain assurances that your data will be protected. You may use your Google password, or chose another password to encrypt the data.

A very welcome feature.

The Chrome dev channel has been bumped to version 13.0.722.0.

This is a great release. It is greeted with an amazing 'print preview' window, a speedup in the V8 javascript engine, and many bug fixes.

You can get the scoop on the revisions here:
http://build.chromium.org/f/chromium...5463&mode=html

You can install the dev version here:
http://dev.chromium.org/getting-involved/dev-channel

I have been doing a little bit of research into the GWT (Google Web Toolkit) and it is one powerful bit of tech.

I had previously written it off as a technology that provided a rather limited set of widgets, and couldn't see the value in it. After doing some research, I'm thoroughly impressed.

I have begun to migrate to Java as my language of choice and am dabbling in the world of online applications.

Why is this great? Simple. It allows you to use Java's rich libraries and the structure of OO programming to produce a client-side Javascript app. It's so powerful, in fact, that it has been used to port Quake 2 to HTML5!
http://code.google.com/p/quake2-gwt-port/
VIDEO: http://www.youtube.com/watch?v=fyfu4OwjUEI

But because you're coding in Java, there's a tremendous opportunity to create an app that truly spans platforms. For example, it's possible to create an Android/Linux/Windows/Mac/Web app with a single JAR. Not bad at all, and a fine testament to the portability of Java.

I'm also very confident that there will be a NaCl port of a java interpreter, as it can be as small as 50K, a tiny bit of overhead for a web app, especially if you cache it in the client. What's left is a small JAR and a complete app. Write once, run anywhere. Amazing.

Ok, this game Berzerk Ball is a little bit too much fun...

https://chrome.google.com/webstore/d...cpgpb?hl=en-US

The goal is to knock the nerd as far as possible and collect cash and experience for doing so, in turn allowing you to buy more items and become generally more effective.

I thought I would hate it, then realized I was still playing.