GoogleEarth and Membership Data

Discussions around using and interfacing with the Church MLS program.
supertitus-p40
New Member
Posts: 6
Joined: Sun Mar 11, 2007 4:12 pm
Location: Maryland

GoogleEarth and Membership Data

Postby supertitus-p40 » Sun Mar 11, 2007 6:33 pm

In our stake we have found pressing needs for Geographical membership data. These include tracking lost members, matching active members with members who need rides, creating home teaching routes, or a ward emergency plan, just to name a few. We experimented unsuccessfully with several programs... and then came Google Earth.
Google Earth has all of the user-friendly functionality that we could possibly use, and the price is right- Free. However, I have been unable to confirm that Google does not/ will not save meta data entered into Google Earth KML/KMZ files. And to complicate matters, members (in my stake, anyway) are already using the service with lds.org's csv membership dump feature.
Here are the issues: Some members have a (reasonable) expectation that their contact information is held with fiduciary confidence, even when part or all of it may be available through other public or commercial sources. Some members have a legitimate need to keep their contact information private (such as those with restraining orders, or law enforcement, or minors). I don't think a single member would expect that by choosing to share their personal information with the Ward Clerk, that they run a risk that their information (or their children's information) could end up in the hands of a major data miner, such as Google. But this is the very risk members are now running.

[size=84]How Google Earth Works[/SIZE]
A user downloads the Google Earth client program onto their computer. A subscribing Google Earth customer may create Keyhole Markup Language (KML or KMZ) files (using Google's services, or other third party services), which are XML data files that overlay onto Google maps to create placemarks and boundaries based upon address information. They may also include other meta data such as names, phone numbers, ID numbers, notes, etc. They can be created from comma delimited (CSV) files which are output by MLS, and the lds.org ward/stake websites.
When you use Google Earth, the client computer reads the KML files, and requests the relevant maps from the Google Earth server.

Summary
Using Google Earth presents three potential threats to Members' personally identifiable information: First, Google Servers (or other third party) may store and capture the information when creating the KML/KMZ files. Second, Google Servers may upload, capture, and store the information when the Google Earth Client reads the KML data and requests the relevant maps from the Google Earth Server. Third, since Google Earth is so powerful, user-friendly, and useful, it may encourage clerks/ members to make and distribute larger numbers of KML/KMZ or CSV dumps.

Using the guidelines listed below, I think you can reduce or eliminate the risks. However, enforcing them is impossible, especially since members have access to their own CSV dumps.


Assumptions
  1. The Church of Jesus Christ of Latter-day Saints (and its agents), owe members of the Church sacred fiduciary duties of the highest order.
  2. One of these fiduciary duties it to not release potentially private or sensitive information to any third parties. This information may include names, addresses, and phone numbers.
  3. Church members have a reasonable expectation that agents of the church will not disclose personally identifiable information about them to third parties.
  4. Church policies dictate that member contact information be used only for church-related purposes.

Privacy Concern: Third Parties Harvesting Membership Data
It is manifestly inappropriate under any circumstances for the Church to become a donor of personally identifiable information to a major data miner, such as Google. If Google harvests information, it may theoretically occur at two times:
  1. When the user first creates a KML file from a CSV file, if a remote server creates the KML file.
  2. When the client computer uses the KML file to request maps from the Google Earth server.
First, based upon my research so far, it appears that the local Google Earth client creates KML files, not a remote Google server. However, the free version of Google Earth limits the number of records you can batch at one time. Thus, other third parties (such as GPS Visualizer, Andrew Davidson, etc.) offer server-side services that will batch hundreds or thousands of records at a time. If third party servers create KML files, then the damage to Members' privacy could be done the instant you create the KML files, if the remote server captures the data.


Google and Google Earth's End User License Agreements (EULAs) and privacy policies are carefully silent about whether Google Earth reads or stores KML information on remote servers; they leave open the possibility that they may currently harvest the information, or may choose to do so in the future. I e-mailed Google Corporate several weeks ago, but have not yet received an answer to this question. However, I was able to find two online conversations between Google Earth users and engineers:[INDENT][User]: Does the application send my placemarks and my travels… to the Google servers?[/INDENT]

[INDENT][Google Engineer]: MyPlaces is stored in a local file called myplaces.kml and is not sent over the network. Only items explicitly shared with GEC or posted on the public internet will be visible to the Google search engine…. (http://bbs.keyhole.com/ubb/showflat.php/Cat/0/Number/353011/Main/325243).[/INDENT]

In the next conversation, a business owner with proprietary information was afraid that Google would retain it on their servers, and requested a confidentiality agreement. He got this answer from a Google engineer, [INDENT]...as for the privacy concerns, as long as you don't post your [KML files online]… no one can see them.[/INDENT]

[INDENT]…Just because your data is viewed in Google Earth doesn't mean you're 'sharing' it with Google or anyone else on the Internet. Your data can stay safely behind your firewall, or your own laptop, etc. (http://bbs.keyhole.com/ubb/showflat.php/Cat/0/Number/559090/Main/481105).[/INDENT]
Though these statements are not in an official corporate document, I tend to believe them. Google has many business clients with sensitive and proprietary data, each of whom pay several hundred dollars for Google Earth Pro. If Google collected their proprietary data, and these businesses found out, they would instantly drop the service, causing Google to loose a lot of money.

In addition, Google includes this somewhat helpful hint in their official documentation:[INDENT]A KML file is processed by Google Earth in a similar way that HTML and XML files are processed by web browsers. Like HTML, KML has a tag-based structure with names and attributes used for specific display purposes. Thus, Google Earth acts as a browser of KML files.[/INDENT]

[INDENT]...[The] benefit of this is that images are self-contained in the file and do not need to be hosted on a network server, as with KML 1.0. (http://earth.google.com/kml/kml_intro.html)[/INDENT]
For these reasons, I believe that Google servers do NOT read or capture KML information, other than which map view you request.
Privacy Concern: Data Proliferation
The second privacy issue is increased data proliferation. Because computer files are so easy to share, copy, and lose, MLS strongly discourages creating CSV files, except by an administrator, and only for authorized church purposes. However, lds.org allows all members to create CSV membership data dumps, which are easily shared via e-mail. E-mail is more secure than posting information on a website, but less secure than many other forms of data transfer.


Summary & Guidelines
Despite my questions, our Stake (and a few of our members) have whole-heartedly adopted Google Earth, without answering the questions about privacy. I submitted the following guidelines to my Stake, which were largely rejected in practice, and are virtually impossible to enforce, anyway.
  • Find Out if Google harvests KML Data.
    • If it is not doing so now, Google may choose to harvest KML data in the future. If this occurs, members and clerks must cease using Google Earth immediately.
  • When converting CSV files to KML and KMZ files, the client computer should be disconnected from the internet. If this is impossible, members and clerks must create additional safeguards (such as splitting the name from the address).
    • This will ensure that the client is not communicating with a remote server, and that a remote server is not creating the KML/ KMZ files.
    • [font=Courier New][font=Arial]It is impossible to enforce.[/font][/font]
  • Members and Clerks should use not use Google Earth on personal or work computers connected to the internet.
    • A good idea, but impossible to enforce.
  • KMZ files should not be widely distributed
    • [font=Courier New]
    • [font=Arial]A good idea, but impossible to enforce.
    • [/font][/font]Members/ Clerks should do their best to delete sensitive files from thumb drives and inboxes.
  • KMZ files should contain ONLY basic contact information.
    • Do not include additional information, such as Membership Number, Confirmation Date, etc.
Stupid Anti-Privacy Arguments:

Here are a few stupid anti-privacy arguments that have been raised explicitly or implicitly, again and again.

Stupid Argument 1: "It's already out there..."
No, "it's" not. First, take the obvious examples I gave earlier: victims of domestic violence, law enforcement, or minors. Their personal information is NOT already out there.
Second, "it" is a whole lot more than an address. "It" includes religious affliation, and may include meta data such as Full Name, Phone Number, Membership ID, Confirmation Date, Birth Date, Family Members, etc. Even if some or all of the information is "out there," it may not be connected to an individual. The Church should not be in a position to connect the dots for data miners.

Stupid Argument 2: "There is no such thing as Privacy, anyway..."
We live in a world where market forces have significantly eroded traditional notions of privacy, and individuals have much less control over how some personal data is shared. There are two ways to psychologically cope with decreasing control: Some continue to try and exercise control, and others take a "if you can't beat them, join them" attitude, which is almost defeatist in nature. This argument simply identifies the speaker as a defeatist.
The point is, there is such a thing as privacy. There are such a thing as fiduciary duties. There must be, even in a connected and fluid world. Privacy and fiduciary relationships are the basis for institutional trust, which is arguably one of the church's most valuable assets.

Stupid Argument 3: "The Church condones it, because they provide the tools to allow it to occur..."
This is a reference to the CSV dump option on lds.org. I reject the notion that creating a tool condones abuse of it.

Stupid Argument 4: "Everyone can do it, so it doesn't matter if I do, too..."
This is a classic variation of "Everybody's doing it..." Really, this argument is a restatement of, "If my actions cause damage, you won't be able to trace the damage to me."

Stupid Argument 5: "It's no different than..."
Fill in the blank with "...e-mailing an Excel file," "...printing a Stake membership directory," "...mailing an announcement to the ward," etc.
If Google Earth does not harvest data, then I agree wholeheartedly that no harm is done. However, sharing membership information with a data miner is drastically different from any of these examples.

Anyway, I just wanted to put these thoughts out for comment and discussion. I'm certainly no technophobe, and I love Google Earth's functionality. I'm just concerned that we're making important privacy policy decisions without a discussion.

-Aaron Titus

russellhltn
Community Administrator
Posts: 20734
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Sun Mar 11, 2007 9:53 pm

Members who are concerned about their information (such as those you mentioned with restraining orders, in law enforcement, or just generally concerned) may ask the unit website administrator to remove some or all of the information.

The options are:
  • Do not showing anything about this Family on the Web site
  • Do not show home address
  • Do not show telephone number
  • Do not show spouse's name
  • Do not show children's names


That would keep the information out of the CSV file where it could be mishandled. Problem solved.

supertitus-p40
New Member
Posts: 6
Joined: Sun Mar 11, 2007 4:12 pm
Location: Maryland

Postby supertitus-p40 » Mon Mar 12, 2007 5:58 am

Not quite, at least in the real world. CSV Membership data can come through two major sources: lds.org, and MLS. If a concerned member wants to limit membership information online, several things must occur, each one acting as a potential node of failure:
1. The concerned member must be aware that lds.org exists.
2. They must know that lds.org has the ability tomake a computerized file of their contact information.
3. They must be aware that even well-intentioned members may accidentally share membership data with data miners.
4. They must be aware that they have the ability to limit the information online.
5. They must know who to ask in order to take the information down.
6. A ward member must be trained on how to hide the information, and actually do it.
7. Even after the information is hidden, the member is only protected from future CSV dumps.

I live in a relatively poor, undereducated ward in the Washington, DC area. Many of our members do not own a computer, and are completely unaware that LDS.org exists, much less that it contains membership data. Until last week, even I (the administrator) was unaware that it had a CSV dump option. Because of high turn-over, our ward also has a very spotty history of training someone to administer the website.

The idea of limiting displaying membership data only to members is very smart, and is a time-tested method for limiting distribution. Distribution decreases as the transaction costs increase (ie, the time to copy information from paper to computer, or to copy and paste web text). The transaction cost of downloading membership data in a spreadsheet format is now very low (just a single click). And even well-meaning members with completely legitmate uses do not understand that by using third-party remote servers to complete a task, they may be yeilding that information to the third party.

And of course, opting out of the website only solves half of the problem. It of course does not prevent clerks from making CSV dumps. In our stake, this is the single largest source of CSV dumps (as far as we can tell). Clerks are also the single largest set of users of GoogleEarth (for good reasons).

So, in the real world, I don't think many problems are solved. The transaction costs are too high for the concerned member, and too low for getting the data.

One positive step would be to bring the "Do not show..." function directly into MLS.

User avatar
WelchTC
Senior Member
Posts: 2088
Joined: Wed Sep 06, 2006 7:51 am
Location: Kaysville, UT, USA
Contact:

Postby WelchTC » Mon Mar 12, 2007 6:28 am

Each member has the responsibility to keep any data exported from LUW or MLS private, secure and confidential. Your use of the data is limited to your domain (in other words, those who are within your organizational unit such as a ward or stake) and your area of responsibility (calling). Common sense and judgement should prevail when using this data.

As a reminder, never upload information that you have downloaded from MLS or LUWS to a 3rd party server (unless it is an official Church server).

Tom

User avatar
bhofmann-p40
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

Postby bhofmann-p40 » Mon Mar 12, 2007 7:27 am

This was a very thorough and informative posting about Google maps. Great job! I learned quite a bit from reading your post.

I think it boils down to educating and trusting the members. There are so many things that have the potential to be abused that I think we could go crazy thinking about them all.

russellhltn
Community Administrator
Posts: 20734
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Mon Mar 12, 2007 11:49 am

supertitus wrote:CSV Membership data can come through two major sources: lds.org, and MLS.


At least the MLS data goes though the leadership. The LUWS data could be captured by any member in the stake.

User avatar
tomj
Community Moderators
Posts: 45
Joined: Tue Feb 06, 2007 8:49 am
Location: South Jordan, UT
Contact:

Wow what a thread

Postby tomj » Mon Mar 12, 2007 2:21 pm

Wow, very imformative . . . with that I guess I'll just comment that we all need to be good responsible stewards of this data.

Above the area where you can do the Data dump it says:

Note: Information on this page is for Church use only and is not to be used for any commercial, business, or political purpose. Click Feedback to contact your administrator if you do not want information about yourself or your family to show on this page.

When you actually click the csv llink, you get another warning message that says:

Church membership information is confidential and is not to be used for personal, political, or commercial purposes. Continue loading? cancel or OK

It looks like there is a privacy warning there. I guess the question could be posed: "Is this enough?", "Could it be reworded?", "Should it be more explicit & detailed?"

User avatar
bhofmann-p40
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

Postby bhofmann-p40 » Mon Mar 12, 2007 3:10 pm

Tomj wrote:
It looks like there is a privacy warning there. I guess the question could be posed: "Is this enough?", "Could it be reworded?", "Should it be more explicit & detailed?"


This is a great idea to help educate the members. It could be a quick and cheap way of reminding them not to put the data on anybody else's servers.

User avatar
WelchTC
Senior Member
Posts: 2088
Joined: Wed Sep 06, 2006 7:51 am
Location: Kaysville, UT, USA
Contact:

Postby WelchTC » Mon Mar 12, 2007 6:05 pm

Tomj wrote:It looks like there is a privacy warning there. I guess the question could be posed: "Is this enough?", "Could it be reworded?", "Should it be more explicit & detailed?"

We are working on a more comprehensive policy.

Tom

JasonG-p40
Member
Posts: 68
Joined: Thu Jan 25, 2007 5:21 pm
Location: Pampa, Tx

Postby JasonG-p40 » Wed Mar 21, 2007 5:11 pm

Looking at the waning messages you get when you download the .csv though, almost everybody that does it is going to be doing it for church use. Granted, they might be doing it for a personal/church reason, but if it's related to the church, then they are probably going to bypass the warning as they think that it's alright.

One of the things that might help with the restriction of that information is allowing members to log in to the LUWS (thus encouraging the use of the LUWS at the same time) and setting their personal profiles to not allow the data to be downloaded and/or displayed. Not everyone is going to have a computer, of course, so you would need to allow the ward/stake admins to restrict the data as well, but I think encouraging the members to do it themselves (if they have a computer) would be the best way to allow for restricted data.
Jason D. Griffith
Pampa Ward, Amarillo Stake (Texas)
Community Guidelines


Return to “MLS Support, Help, and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest