On Wed, Apr 25, 2012 at 10:13 PM, Damion Alexander <[email protected]> wrote:
> ----- Original Message -----
>> To quote a friend:
>> "Comparing to dropbox' TOS - https://www.dropbox.com/privacy#terms -
>> I
>> suppose theirs read a bit clearer, but Google's are more precise;
>> where DB say "you allow us to do whatever we need to do to provide
>> the
>> service", Google says "if you use our services, you allow us to do
>> these things". I don't really know which way I prefer, but the effect
>> is pretty much the same."
>>
>
> Based on your synopsis I would prefer DB's wording. It seems to me that
> arguing the letter of the TOS is easier than debating the spirit if the need
> arises. And google's wording depends more on the spirit.
>
>
>> A provider has contractual
>> obligations about snooping your data with legal recourse: the data
>> stored at past employers has no contractual standard.
>> How many times
>> on this and other mailing lists have sysadmins told stories of the
>> CEO
>> or other executive making them hand over someone else's private email
>> or giving them access to someone else's files?
>
> Devil's Advocate:
>
> How can one verify that the provider is upholding their side of the contract
> continually? Who verifies that the provider is actually storing data as
> stated? As for legal recourse don't all TOS nowadays have a phrase about
> giving away your right to sue if your company is disrupted, lose income etc?
>
> For past employers, are you saying that they had no contractual standard to
> their employees about the privacy of the employer's data that employees
> generated for the purpose of the employer's use? Yeah the Sysadmin shouldn't
> be doing that on his own, but the CEO? Seems to be well within her realm to
> request whatever company data she wants.
>
Since you are playing devil's advocate, so will I. How can you tell
your employees are following the procedures as stated? You have them
pass a SAS70, SOX, or other audit. A CEO can't be expected to be
technical enough to know for sure so they put their trust in the
auditors (another risk to manage!). So how do you verify your vendor?
You check for the same kind of audits.
>
>> And lastly, we all believe when we store data we do it
>> more securely than others but how many people here actually do all
>> the
>> right things required to properly handle their certs, passwords, and
>> so on?
>>
>
> Devil's Advocate:
>
> How do we know that the providers are doing the right thing? I'm sure a web
> search or two will reveal many of the big names having a bad day as far as
> protecting user's data.
>
A web search also finds inside employees are a risk too. I don't think
you can count on web searches for this kind of thing. Both have
problems... you have to audit. ("Trust... but verify").
>
>> I used to feel the same way: I would never put critical information
>> on someone else's server. Then I worked for a CEO that wanted to use
>> SalesForce.com. OMG! Our valuable, valuable customer data! Sales
>> information! Customer lists! Financial data!
>> I fought against moving to Salesforce but the CEO said "managing risk
>> is the responsibility of the CEO. You're job is to inform me of the
>> risks. I've taken them under advisement." Well, switching to
>> Salesforce.com turned out to be one of the best things that company
>> every did.
>>
>> It turns out nothing in this world is black and white. The value of
>> the features in Salesforce.com and the value of being able to access
>> that data from anywhere was much more important than the risk that SF
>> would violate their ToS.
>>
>> We, as system administrators, often forget that these trade-offs
>> exist.
>>
>
>
> IME it seems that the SysAdmins know very well that trade-offs exist, but
> senior management are the ones assuming that there is no risk to moving to
> the cloud. That is if they even use the word risk in the same domain as
> internal use services.
>
I think they understand the risk but in a different way. They think
"our secret budget plans get stolen" not "CERT bug xyz in Samba could
let someone steal a spreadsheet". We know it at a deeper technical
level.
By the way.. to continue that story. The CEO then had his lawyers
look at the TOS and, based on our advice, was particularly careful
about the sections on the risks we had warned him about: recourse in
the case of theft, the ability to pull out data out and switch
providers without cost, (and a bunch of other things I can't
remember). So, yes, plenty of dumb executives are going into the
cloud blindly and with too much trust. However, most of them will be
protected/educated when the legal department gets their hands on the
contract. Those that aren't smart enough AND don't have good lawyers
will be burned. In a perfectly darwinian world, those people will
fail and the world will be a better place by not having that company
around any more.
>
>> There are no absolutes.
>>
>
> Until skynet comes online, I see the absolute that everything we use, be it
> in the cloud or in our private data centers, is run by humans. And because of
> that there will always be mistakes made and bad things will happen at some
> point. Can we live with the fallout of those mistakes is the question.
>
If we don't take risks we can't move forward. Some risks are "in our
head". Most of us have our email hosted on someone else's computer...
and for some reason don't consider this the same risk as "the cloud".
It's the same thing. When I moved my email server to Google Apps my
users complained until I told them "here's Google's TOS. It's a lot
better than the TOS you have with me." They asked, "what's your TOS?"
Well, it has 3 parts: 1) if the cops come, I'm turning you in
because I'm not doing time in jail for your sorry asses. 2) if
there's an outage and I'm having a busy day, suck it. (3) if you have
any complaints, suck it. They definitely found Googe's TOS an
improvement.
Tom
Disclaimer: I work for Google. I do not speak for Google.
--
http://EverythingSysadmin.com -- my blog
http://www.TomOnTime.com -- my videos
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
