Thread
:
Chrome OS
View Single Post
Capt'n Corrupt
2011-05-23 , 20:39
Posts: 3,524 | Thanked: 2,958 times | Joined on Oct 2007 @ Delta Quadrant
#
192
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.
Quote & Reply
|
Capt'n Corrupt
View Public Profile
Send a private message to Capt'n Corrupt
Find all posts by Capt'n Corrupt