Why does SpanningSync "call home" all the time ... ?

[Bones]

So,

I just downloaded the trial version of SpanningSync and installed. I
have a network monitor application on my Mac that tells me when a
program attempts to make an outbound network connection and to what
server, port, etc. I noticed that when I was configuring SpanningSync
to work with Google, the application kept trying to connect back to
www.spanningsync.com on port 443 (SSL).

Strangely, it does this right after I enter my logon and password
information for Google.

Why does your program "call home"? Are you capturing people's Gmail
passwords?

Please explain ...

Bones

[Bill Bonney]

I suspect SS is checking you have a valid license to use the software.

Bill

[cwood]

Bones-

The Spanning Sync client on your Mac authenticates directly with
Google, then talks to our servers to do the authorization (checking
the status of your subscription) and the actual sync, much of which
takes place on our servers, which in turn talk to Google. Our servers
never handle your Google password, and calendar/contact data is
processed but not stored.

Please let me know if you have any questions or run into any
problems.

Thanks,
Charlie

On Feb 28, 3:24 pm, Bones <joshua.leewar...@gmail.com> wrote:
> So,
>
> I just downloaded the trial version of SpanningSync and installed. I
> have a network monitor application on my Mac that tells me when a
> program attempts to make an outbound network connection and to what
> server, port, etc. I noticed that when I was configuring SpanningSync

> to work with Google, the application kept trying to connect back towww.spanningsync.comon port 443 (SSL).

[Bones]

Interesting.

So, during a sync, my data is passed through your servers before being
forwarded to Google?

Just trying to understand the architecture ...

Bones

[cwood]

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

[Bill Bonney]

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 <charli...@gmail.com>

[cwood]

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
charli...@spanningsync.com.

Thanks,
Charlie

--

Charlie Wood
Spanning Sync, Inc.
charli...@spanningsync.com
blog.spanningsync.com
+1-512-217-6551 (direct)

On Mar 1, 12:48 pm, Bill Bonney <billbon...@gmail.com> 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 <charlie.w...@gmail.com>

[Larry Hendricks]

Another perk of the server-based architecture is that letting our
servers perform all the overhead of negotiating and syncing with
Google can save a substantial amount of CPU time on your Mac. A
typical sync only involves a single https request from your Mac. Of
course, getting changes from Apple Sync Services can take a lot of CPU
cycles, but you get that either way so it's a wash.

Cheers
--
Larry Hendricks
la...@spanningsync.com
http://spanningsync.com

On Mar 1, 10:48 am, Bill Bonney <billbon...@gmail.com> 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 <charlie.w...@gmail.com>

[Bones01]

Larry & Charlie,

Thanks for the replies. I understand the reasons for doing this as you
outlined above. Makes for a better user experience, et al. The big
question is, what happens to our data as it passes through your
servers? For instance, does it get stored on your hard drives for X
period of time? Is is just maintained in memory long enough to be
transformed and pushed to Google?

From a consumer (and infosec consultant's) point of view, I would like
to see some kind of statement about the privacy controls you have in
place to protect our data transiting your systems. I appreciate you
mitigating the greatest risk: forcing SSL between us, you, and Google.
But in the 21st Century, handing my data to someone else still makes
me wince as Bill pointed out.

I think this can be cleared up with some explanation.

Appreciate the chance to discuss,

Bones

[cwood]

Your data is never stored on our servers unless you've asked us to
turn on detailed logging in order to resolve some specific problem.
Once we're finished with the investigation that log is deleted. In all
other cases, your data is held in memory long enough to do the
processing and then released.

Please let me know if you have any other questions or run into any
problems.

Thanks,
Charlie