Bill- We decided early on to use a client/server architecture for a number of reasons, the first of which was historical. I had been working on a Salesforce/Google sync system (which for obvious reasons was cloud- based), and much of that codebase became the basis for the server portion of Spanning Sync.
We also wanted to make sure that *all* communication from our Mac client was SSL-encrypted, which was not an option for all Google API access at the time. Security is a big deal, and the idea of passing around personal data in cleartext is anathema to us. Some other sync solutions do exactly that. Finally, we wanted to be able to make changes (some minor, some major) without distributing new code to a large and growing user base. The Google Calendar API has stabilized significantly since the early days, but the Contacts API is still maturing at a rapid clip. For instance, when Google added the ability to see the Suggested Contacts group in the API we were able to add filtering, our most-requested feature, by changing only server-side code. Being server-based also gives us a valuable perspective on how Google itself is operating. Since we contact Google on behalf of tens of thousands of different people every day, we can often tell the difference between isolated outages and those that are more widespread, which gives us the ability to provide better support. But the bottom line is that if you don't trust us to handle your data securely you shouldn't use our service. We're proud that tens of thousands of people--including one of the most prominent data privacy and security experts in the world, not to mention numerous Google employees, prominent software company CTO's, and others specifically interested in security--have chosen to trust Spanning Sync with their data. We appreciate it when our users care abut the details. If you have any other questions, please contact me directly at [email protected]. Thanks, Charlie -- Charlie Wood Spanning Sync, Inc. [email protected] blog.spanningsync.com +1-512-217-6551 (direct) On Mar 1, 12:48 pm, Bill Bonney <[email protected]> wrote: > Why have you chosen a architecture that requires our data to be on handled > by an intermediary server? What are the advantages, and what are the > challenges in providing the service with this architecture. ? > > Who hosts the spanning sync service? Where is the spanning sync sever box > located? > > You state in the FAQ that it is more secure architecture. Please can you > elaborate? > > I'm coming from the position that from a security aspect involving a third > party in security terms is always inherently less secure. It's weighting of > flexibility over security. What processes to you have in place to mitigate > that? > > How often do Google change there Calendar API? > > Sorry for these direct questions, but i had no idea my data was being > handled elsewhere. > > Thanks > > Bill > > 2009/3/1 cwood <[email protected]> > > > > > That's right. Your calendar and/or contact data is processed on our > > servers, which act as an intermediary between Google and the client > > running on your Mac. The communication between the Spanning Sync > > client and our servers is all SSL-encrypted. Your password though goes > > directly from your Mac to Google, also over an SSL-encrypted > > connection. > > > Regards, > > Charlie > > > On Mar 1, 6:54 am, Bones <[email protected]> wrote: > > > Interesting. > > > > So, during a sync, my data is passed through your servers before being > > > forwarded to Google? > > > > Just trying to understand the architecture ... > > > > Bones > > > > On Mar 1, 12:47 am, cwood <[email protected]> wrote: > > > > > the actual sync, much of which > > > > takes place on our servers, which in turn talk to Google. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Spanning Sync" 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/spanningsync?hl=en -~----------~----~----~----~------~----~------~--~---
