hm... I thought I posted a response to this but it doesn't seem to have appeared?
Anyway, basically you can get around the authenticity problem by using RSA to sign the state data in the gadget, to ensure the state is valid. ie. - Gadget instance wants to make update. - Gadget instance creates update event. - Gadget instance signs update event with private key. - Gadget instance posts update. - All other gadget instances get the update. - All other gadgets verify the sig using the public key. - Invalid events dropped, valid events are added to the private (non- wave) state of the gadget instance. There are two problems: 1) Getting the gadget-instance for a user to have only the secret key for THAT user. 2) Classic public key distribution problem. You can overcome (1) by using XSS / login form / cookies to get gadget information on a per-user basis each time the gadget loads, not a huge issue. You can overcome (2) by having a Robot Overlord that sits and watches (and fixes) public key records which are part of the gadget state, and signs them using it's own private key, with the public key hard-coded as part of the gadget so users can verify the changes come from the robot, not someone else. ...but, its _hard_. It shouldn't be this difficult to verify changes. Personally I think the gadget state would be much more useful if there was a seperate user state for each wave user, which can be access by anyone but only posts updates to the other instances if the state instance id == the current user id. Robots would then have their own user state objects, and we could avoid problems with robots playing games on the behalf of users too. Private user data is always a problem, but it's not a big problem, the html5 datastore basically solves it; as does server access to fetch user information via login, etc. This would even be relatively easy to implement I imagine; just add one extra api: Constructor Description wave.State() Constructs a wave.State. wave.State(id) Constructs a wave.State object for the specified user id. reset(), submitDelta() and submitValue() are not valid on this object unless the id matches the current user id. I'm actually tempted to post this as a feature request. ~ D. On Dec 10, 12:41 am, David Nesting <[email protected]> wrote: > On Sun, Dec 6, 2009 at 11:59 PM, dougx <[email protected]> wrote: > > - Competative game gadgets, where users can gain an advantage by > > faking their own high score. > > > - Gadgets where users collaborate in general (prone to spoofing; even > > on playback you can't really be sure of the changes being made coming > > from the supposed author). > > There doesn't seem to be any way to verify the authenticity or integrity of > events or any piece of data stored in the wave. The best workaround is to > store your state with your gadget (e.g. in an appengine data store), but you > still have the problem of being certain that the gadget you're interacting > with in the wave is *really* the gadget you expect to be there, and not some > evil/malicious gadget there to capture your credentials/data. > > I have ideas for some gadgets that I've effectively shelved, because they'll > never work safely with the API as it stands today. :( > > David -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
