I hear you... For us, there is a difference between offering platform services that allow you to build "secure" systems that a customer can trust (not to state that they can not trust you or your current implementation) in the sense that Google as the data provider in this story can state "here is the security system in place, that's what can happen, here is the way to disallow the property to access the data again" and individual problems, like the ones the calendar is having right now.
Those are bugs, and they will get fixed over time. For us, it is better than not having a good story in the first place, as this is an issue for all services that provide GData.
Frank Mantek
On 9/21/06, Mark Swanson <[EMAIL PROTECTED]> wrote:
Frank Mantek wrote:
> No. It's more a principal issue. Example:
>
> - if i go and write my own www.mantek.org <http://www.mantek.org >
> website that shows MY calendar, i can easily go and use client login
>
> - if i create www.mycoolservice.com < http://www.mycoolservice.com> and i
> show only MY calendar, it's fine
>
> - if i create www.youhaveclientsservice.com
> < http://www.youhaveclientsservice.com> and i want to show GOOGLE account
> data (calendar, blogger, etc...) on my clients behalf, the only way to
> do that with client login is that you collect/passthrough you clients
> username/password to google. Now, this is all cool and fine, if they do
> trust you.... but, would you give a 3rd party your account info for
> another party? Considering that this is more than problematic, on
> security levels, and most likely most customers won't trust a 3rd party
> to actually take care of username/passwords of another site we put out
> AuthSub. With AuthSub, you can grant access for a certain set of data
> for a 3rd party, where giving the 3rd party your account info means
> giving them access to all data...
Well, 99% of users will download an Active/X control and give it full
access to their entire machine. 99% of those users will not read the
Active/X EULA and in some cases without knowing agree to let the
Active/X component parse their private data and log which websites they
go to etc...
Don't get me wrong, because in theory I agree with you. I even went
further down this path; several years ago I designed and put into
production a feature similar to AuthSub that allowed folks to share
_encrypted_ calendars. It was even more secure than AuthSub in that the
server couldn't decrypt the calendar components, yet a group could share
access to individual components and view/edit them just fine.
> Makes more sense? Or did i misunderstand your question ?
I agree with the theory. It's just that given the choice between
security and broken (hosted calendars will not sync because of AuthSub),
or less security and working (hosted calendars will sync with
ClientLogin) almost everyone will choose the latter.
If AuthSub will work with hosted calendars soon, that would be fantastic.
Thank you for responding.
Cheers.
--
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/tg/
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Calendar Data 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-calendar-help-dataapi
-~----------~----~----~----~------~----~------~--~---
