API for Directory Web App

Looking for an API for our Directory. It's fine to use my credentials. I want a way to programmatically update the list of (for example) all of the YM leaders across the stake.

This is extremely tedious to do with the current Directory web application and with our units changing fairly regularly all of the stake leadership would like to get this information on a regular basis. Its not that it is not available - we can get to the same information from the Directory web application, it's just so painful to get a list of all the RS presidencies, etc. I know we can generate reports via the stake clerks - but thats missing the point of the question and the need. We have access to the information already - we just want a way to get the information across units in a much easier way. It took me more time to update the list of Bishops, Exec secretaries, YM presidencies from each unit for my contact lists than it would have taken to write the program to get the same data from a secure API.

So, here's hoping that there is such a thing and someone out there will send me to the developer docs.

Thanks,
Jeff Carlson

carlsonjf wrote:Looking for an API for our Directory. It's fine to use my credentials. I want a way to programmatically update the list of (for example) all of the YM leaders across the stake.

The APIs used by the Directory web app are not available to the public; they can only be used within official apps created by the Church.

I'm certainly sympathetic to your request; I've wanted such information on more than one occasion. But I've seen no indication that the Church has any plans to open up these APIs beyond official applications. On balance, I'm more sympathetic to the Church's position on this -- supporting an API for unofficial developers is a distraction from the important work that the Church's limited development teams need to be doing.

carlsonjf wrote:I know we can generate reports via the stake clerks - but thats missing the point of the question and the need.

Given the above, your best option is still to work through the stake clerks. They have the ability and responsibility to supply such information to ward and stake leaders (as authorized by the stake president, of course). Or you can use the Directory to go through each ward and gather the information yourself as you have been doing; that's admittedly quite tedious, but is certainly something you can do yourself if you would prefer not to involve the stake clerks.

From the online LCR tool, FAQ:

Stake auxiliary leaders and high councilors are primarily responsible to instruct and support ward auxiliary and Melchizedek Priesthood leaders. They orient newly called ward auxiliary and Melchizedek Priesthood leaders and provide encouragement, support, and instruction. They are not responsible for individual ward members. It is the ward clerk’s responsibility to train ward auxiliary and Melchizedek Priesthood leaders on record-keeping tools and responsibilities. If stake auxiliary leaders and high councilors need a list of members for planning purposes, they should request this information through the ward or stake clerk.

That statement resulted from the continuous requests from stake leaders and we are assured is the desire of the General Authorities who have stewardship over these tools. I'm not as sympathetic as others on the board. In my time as a Stake Clerk, I saw more lists of minors with birthdays and full addresses/phone numbers cast aside or left in public areas than I'd like, it was more than once or even 10 times. The rules of availability of this information should be strict, kept confidential and limited in distribution. The online and mobile tools are how the church is responding to this issue and access is granted based on role or calling.

I am well aware that there are still many useful tools that church should be developing or providing, it seems we reduce functionality before we provide a replacement... I wish I had an event management solution that could use the directory information to help organize Conferences, treks, and other multi-ward or stake-wide conferences.

It would be nice if LDS Tools had a "smart lists" option to make a list of everyone who has a certain calling, for example. I imagine something like this could happen.

johnshaw wrote:From the online LCR tool, FAQ:

Note that OP is asking for a list of YM leaders, not of the YM themselves. Being able to email all the ward YM leaders would appear to me to be within the stewardship of a stake YM leader.

carlsonjf wrote:This is extremely tedious to do with the current Directory web application and with our units changing fairly regularly all of the stake leadership would like to get this information on a regular basis.

Directory is not intended for this purpose. Your stake clerks can generate a list of ward leadership very quickly using LCR. From the menu, choose Organizations > Ward Leadership. Generating a list of all bishoprics in the stake takes three mouse clicks after you are logged in. Yes, it requires the assistance of a stake clerk or assistant clerk.

Thank you for the replies. Here is the scenario. I am in the Stake YM presidency. When I communicate with our ward leaders we have found it most effective to email the following groups on one email:
1) The Ward YM Presidency (President, 1st and 2nd counselor and Secretary) for each unit
2) The Bishops and Executive Secretary for each unit on cc:

This means every time I send an email, I need to check 60 entries in Directory web application. Again, its not data that I don't access to. Its just incredibly tedious to get the lists verified for each email I send.

I regularly pull data to build lists like this for work and with an available API this task would take about 45 minutes to write and test the script and 2 minutes each time to run. Instead of the 1-2 hours I am spending today to validate and update the list manually when changes to presidencies and bishoprics have occurred.

As an organization do we think it makes sense for every stake person who sending email to the unit leaders to get an updated list from the stake clerk before every email we send? This does not seem effective either. This is not an information protection issue in any way - I can get every piece of information I need via the web app. In 1-2 hours. It is merely a very poor access issue when you need to communicate across the stake to different organizations at the same time. Surely, anyone with any stake calling that needed to communicate with their units has had this kind of issue.

I suppose that if there is no available API I could write a screen scraper. I cannot think that would be what the Church would recommend but it looks like my only option at this point. The current manual solution is non-tenable and asking the Stake Clerk for an updated list before each email we send is equally non-tenable.

carlsonjf wrote:This means every time I send an email, I need to check 60 entries in Directory web application. Again, its not data that I don't access to. Its just incredibly tedious to get the lists verified for each email I send.

I can't imagine that you really need to verify all those entries for every email you send, because callings don't change all that often. I would think that a new bishop would be mentioned in your stake council meetings, so you would hear of those. And your ward YM presidents should be instructed to inform you when their counselors or secretaries change. And even if you don't hear about changes, what's the worst that happens? Your email gets sent to someone who just barely got released. Whenever I've gotten an email sent to me after I've been released, I've replied to the sender that I have been released and who replaced me. Although not everyone will extend that courtesy, most will.

I appreciate your desire for accuracy, but it seems to me that you could verify your lists every 3 months or so and be pretty accurate, without having to spend 1-2 hours for every email you send out. But of course it's your choice.

As a Ward Clerk and Stake Clerk, I proactively created lists like this for leaders, it takes little to no time. I don't understand why that wouldn't work in this scenario. I realize it's not what you WANT to do, but there's all sorts of stuff I'd like to do for my calling but can't.

Think about this... It took the Church 5 years between allowing Bishoprics and Stake Presidencies to see data in LCR and rolling it out to other Ward/Stake Council members. This is not an Agile environment, it is slow and steady, and then only after a few years of studying the right thing. If you're interested, take a look at the LDS Tech Conference KeyNote for 2015 - Some very interesting into the process the church uses to do new things with technology.

The responses are less than satisfactory. I read these meta-messages.

• You don't know what you're doing.
• You don't need to do that.
• You shouldn't do that.
• Use this workaround.
• Be grateful for what you got.
• The Church knows what it's doing.

All the respondents cared enough to provide a thoughtful response, many giving sympathy. Nonetheless, the ultimate message is

Nope, not going to support public API. Go away.

"
The most disturbing message is by implication.

Supporting an API for unofficial developers is a distraction from the important work that the Church's limited development teams need to be doing.

As an unofficial developer I'm a distraction, and making efficient the work I do for the Church is not important.

As carlsonjf noted, I guess I'll have to screen scrape.

Sorry it came across that way, but with the exception of scgallafent, all of the responses have been user-to-user (including myself).

The bottom line is the church doesn't provide an api. We can only speculate on the reason. The decision is not up to the developers. It would have to be approved by the Priesthood department as well as legal.

The best chance for change is to use the feedback link in LCR and explain what report you need and why.

Dwaggstaff1, your summary is accurate. The only success you'll have on YOUR timeline is a work around. This is a major reason the silicon valley members have up a decade ago on trying to help the church with app dev. It's what it is.

Please understand that most responses you got were from years of experience doing what you're trying to do.

I wish this topic would be revisited and an API made open to the public. This would be very helpful for different things I would like to do as an executive secretary.

I posted in this thread showing how to use the lds.org JSON API, and a moderator approved the post, but it was subsequently deleted. I don't understand why: there are so many legitimate uses for the ward directory info that enable people to fulfill their callings. Can the moderator who deleted the post please explain why it was deleted?

lukeh wrote:Can the moderator who deleted the post please explain why it was deleted?

The moderators work together in making sure that the Code of Conduct is followed. We each have different experiences and knowledge, and we help each other to make sure that posts at the Forum meet the requirements that have been set.

We normally work behind the scenes, but since you asked, your post has been moved to a location where it can not be viewed while the moderators consider whether or not it should be posted to the Forum. This regularly happens with a number of posts at the Forum each week.

The Code of Conduct does not allow for the posting of methods for circumventing Church policies or security mechanisms. Your post is actively being discussed by the moderators and we try to respond promptly to these issues. Watch for a Private Message by sometime tomorrow.

In the day and a half since I posted info on how to use the lds.org REST JSON API, I understand there has been substantial discussion among moderators about whether or not to allow the post. While I appreciate that this debate is happening at all, why is it happening behind closed doors? Questions about data access and APIs are one of the very common FAQs at LDSTech, and has been one of the most common offline questions among tech-savvy local church leadership for many years. May I respectfully ask that moderators move this discussion out into the open, so that the benefits and the moderators' concerns about API access may be discussed openly? This topic affects many users of this site.

lukeh wrote:In the day and a half since I posted info on how to use the lds.org REST JSON API, I understand there has been substantial discussion among moderators about whether or not to allow the post. While I appreciate that this debate is happening at all, why is it happening behind closed doors? Questions about data access and APIs are one of the very common FAQs at LDSTech, and has been one of the most common offline questions among tech-savvy local church leadership for many years. May I respectfully ask that moderators move this discussion out into the open, so that the benefits and the moderators' concerns about API access may be discussed openly? This topic affects many users of this site.

Nothing about the Church is analyzed in the open from the General Level all the way to the local level, leaders make the decisions, they engage with whoever they choose to engage with. Regardless of how you feel. Additionally, this is at the minimum the 3rd major attempt to engage with the church around the API's (I've had a small engagement myself at one point) and I don't anticipate the outcome being any different. You're worried about a day and a 1/2 analysis? It took 2 decades to change the Young Women and Young Men program and you think a discussion about membership data being used by 3rd party developers is going to take a couple of days? pure insanity.

In my work as a Clerk/ExecSec at all levels over the last 30 years I'm as disappointed as the next person that the church doesn't provide good administrative tools for use in Wards and Stakes (tracking tools, delegated assignment tools, etc...) all-the-while putting in policy that says NOT to use other tools, and not to develop your own. It means hundreds and thousands of person-hours are being spent duplicating effort across the world, time and resources that could be more focused on ministry aspects of callings rather than administration aspects.

I also have minimal faith in my fellow members not to go bat-nuts-crazy if the church even opened the door a little. All across the globe you can/must be married civilly prior to a temple sealing. Here in the US if we opened that up, it wouldn't take a year before this culture was building marble edifices for the wealthy to have elaborate weddings, - Pinterest, Instagram, internal competition would DRIVE absolute Delusional needs to outdo the last wedding in your ward/stake. It's a very sad commentary on our community, but its who we are as a people.

lukeh wrote:In the day and a half since I posted info on how to use the lds.org REST JSON API, I understand there has been substantial discussion among moderators about whether or not to allow the post. While I appreciate that this debate is happening at all, why is it happening behind closed doors?

A day and a half - on a weekend. What we're trying to determine is to what extent the church allows this. It's not something we're going to get an answer to until sometime during working hours Utah time. The handling of personal information of other members carries moral and even legal implications. As such, it's not something the community, moderators, or admins of this forum have any say in. So, there's nothing to publicly discuss until we learn the answer.

The preliminary information is if this activity is discovered, it will earn the user a pointed phone call from the church's security department, and perhaps suspension of LDS Account access.

I would recommend patience and allow time for a proper response.

It wasn't the day and a half that I was pointing out, it was the fact that the discussion about whether or not to even allow the existence of the API to be mentioned was happening behind closed doors, when this is one of the most commonly-needed capabilities by tech-savvy local leadership. Discussion about the allowability of information on the API should be held openly, so that there is a clear understanding as to the decision process and justification behind any decision. The API itself is not going away -- it is critical to the functioning of both lds.org / LCR and to the LDS Tools app.

I pointed out the following in other posts that have not yet been allowed through by moderators, but I want to specifically point out that what I originally posted about the API in no way constitutes circumvention of security measures: it requires a user's login name and password to be provided, logs the user in the same exact way that a browser would log them in, and then only has access to the data that that user legitimately has access to through lds.org and LDS Tools, as determined by the server's access control policies relative to the user's calling in their unit. There is literally no difference between a user logging into lds.org and copying/pasting all the information on their ward, and getting access to the same information through the REST API, except that the REST API will save them a lot of time and frustration.

Efforts to stop local leaders from applying their time and talents to magnify their callings in ways that they locally deem necessary is very much antithetical to D&C 58:26-27. Please trust that local leaders will do the right thing with their stewardship over the data in their unit.

lukeh wrote:I want to specifically point out that what I originally posted about the API in no way constitutes circumvention of security measures

The code of conduct prohibits discussion of 'circumventing Church policies or security mechanisms'. It sounds like they are trying to ascertain for certain whether direct use of the JSON APIs is prohibited by church policy. So whether it avoids security mechanisms is almost surely not the issue.

I'm not a moderator and I'm not privy to their discussions but I am absolutely sure the discussion is not about whether use of the APIs should be against the policy or not. That decision is made by the general authorities in charge of the church systems and is not and will not be an open discussion. They have or will make that decision based on study, legal advice and inspiration. But the forums will not be involved.

lukeh wrote:There is literally no difference between a user logging into lds.org and copying/pasting all the information on their ward, and getting access to the same information through the REST API, except that the REST API will save them a lot of time and frustration.

I think it safe to say that if the church prohibits use of the API then they also mean to prohibit mass copy/paste and/or screen scraping. From everything I've seen, I don't think they want electronic copies of large sets of members floating around in any way.

I understand perfectly that this is frustrating to many clerks and leaders, myself included. Back when MLS had exports and before the currently membership data policies were in place I used the exports with my own databases to fulfill my calling. But now I avoid that and just tell other leaders that they need to make due with what the church provides in their website and apps. I may not know all the reasons but I have confidence the general leaders have their reasons for these policies.

lukeh wrote:Discussion about the allowability of information on the API should be held openly, so that there is a clear understanding as to the decision process and justification behind any decision.

For better or worse, as johnshaw pointed out, this is not the way the Church has chosen to do many things.

In the interest of clarity, since I did mention the moderator discussion, I would share the following.

The discussion is not about the existence of the API. It is about whether or not its use circumvents Church policies or security mechanisms. This is the reason posts with specific details on how to use the API are being discussed. Posts about its existence and the benefits of its use are not at issue.

Because this is a Church forum, some topics and moderator decisions receive a higher level of interest from those who make policy and security decisions for the Church. I am not at liberty to say more and it would be unwise for me to do so.

I can say that the excellent information you have presented in posts both visible and being held is being used in this review. You have made a compelling case that this is not a security issue. There are many who agree with you. Please know that all sides of this issue are being considered at the highest levels with regard to both security and policy implications.

The Forum will follow the policy the Church determines for us. An example I enjoy sharing is that we have been asked not to give out the meetinghouse WiFi password, even though it is widely available to those who seek it.

lajackson wrote:Because this is a Church forum, some topics and moderator decisions receive a higher level of interest from those who make policy and security decisions for the Church. I am not at liberty to say more and it would be unwise for me to do so.

I am now at liberty to say more. As I hinted, this issue has received a higher level of interest.

A response to this topic is being prepared today. Because of the level to which this topic has escalated, the response will be officially reviewed before it is posted. I have been told that the review is not going to be a fast thing and will probably take a couple of days.

In my personal experience, "a couple of days" is actually pretty fast in these situations. And again personally, I would rather those involved take the time to provide the best guidance possible the first time around.

So, as difficult as it is, patience is the virtue of the day, and probably the week. If I become at liberty to say even more, you will see it here first.

lajackson wrote:The Forum will follow the policy the Church determines for us. An example I enjoy sharing is that we have been asked not to give out the meetinghouse WiFi password, even though it is widely available to those who seek it.

Your LDSAccess WiFi example is actually a great illustration of how API access should work -- it's there, and you can use it if you can find out how, but it's not publicized ("Public but not publicized.")

I am glad this is finally being addressed, but I'm starting to think that forgiveness would have been better than permission -- I only posted publicly in the hope that having the info out there would help others.

There has to be a model that can address the needs of local leaders for information processing capability while aligning with Church policy, protecting privacy, and maintaining control over data dissemination. This could be either a technological solution -- something like how FamilySearch allows data access to third parties through OAuth -- or policy-based, for example allowing use of the API to retrieve, display and print data, as can be done through the browser at lds.org, but not allowing anything other than member IDs to be stored locally on the API-user's drive. This would allow for the creation of things like Ministering management applications, where the mapping of member IDs to the IDs of their Ministering Brothers and Sisters is retained on the local server, but the contact details and callings of members are not stored locally. Every time you start the application and want to display contact info for members, you have to connect to the REST API to download the current membership contact info for display, and it is only ever stored in RAM, it is never allowed to hit persistent storage. Applications using the API would not allow for an electronic copy of the data to be saved, sent, copied or disseminated in any way, other than through the print / PDF generation option for reports. This would keep the exact same fence around the data as currently exists on lds.org, but it would allow sufficiently motivated leaders to move the fence so that it surrounds their own custom applications.

Is this a reasonable compromise? Whoever is working on the policy statement about the use of the API, please carefully consider the above suggestion before you finalize the policy. The above suggestion would actually fall in line with usage of data in other places, e.g. in the LDS Tools app, which forces you to re-sync frequently, so that the church maintains power of revocation over data.

It is critically important for the church to allow local leaders to figure out the best way to minister to their local congregation (Isa. 54:2 "spare not, lengthen thy cords, and strengthen thy stakes" -- the Church has to move in the direction of giving more autonomy to stakes and local units, if it is to fulfill its purpose). Please don't issue a blanket statement shutting leaders out of data usage outside of using the UIs of lds.org and LDS Tools -- they are highly inadequate for a number of important use cases, as evidenced by the number of local leaders who over the years have dreamed about and asked about getting data access so they can build something better. We technology-interested saints currently have no way to directly contribute to the development of these systems, since they are not open source.

I would like to add to this proposal and note that if a secure API is being considered with OAuth or whatever it be, it will take time and experimentation. If it is being considered, I propose an alpha prototype be developed, backed with false data, to allow the LDSTech community to experiment and develop on. I believe those of us who are eager to contribute and utilize such a powerful tool would be more patient with the current state of things if we had an Alpha release to work with. If it were developed this way, then by the time a properly secure solution is reached and stable, we'd have working client applications ready to plug in and go from day one. An approach like this would greatly boost the moral of the LDSTech community.

ljcrapo wrote:An approach like this would greatly boost the moral of the LDSTech community.

I am quite certain it would. Unfortunately, I do not believe the morale of the LDSTech community is a factor for those who are making these decisions.

Speaking of which, the expected post for this topic is still being reviewed at high levels. I do not know if the fact that it is taking longer than expected is a hopeful thing or not. But the question has neither been forgotten nor lost, which is a good thing.

lajackson wrote: But the question has neither been forgotten nor lost....

25 days later...are you sure?

nutterb wrote:

lajackson wrote: But the question has neither been forgotten nor lost....

25 days later...are you sure?

It hasn't finished wandering in the wilderness for 40 day yet.

On a more serious note, it is still making progress, scgallafent and I discussed its status just a few days ago.

I believe if jonesrk and scgallafent were the decision makers, it would be a done deal. Unfortunately, this issue seems to have gotten a whole lot of attention at levels I do not have enough oxygen to penetrate.

As far as I can tell though, everyone involved already knows about computers and websites. So the issue itself is the only thing needing explanation to those who are considering where the policy will be going from here. And they are taking the time to give this matter some very serious consideration from all sides.

I just want to mention I messaged a couple of the moderators involved, a while back, and requested a chance to go and talk to the legal team at Church Offices (or whoever is currently working on the new policy that my post describing the JSON API apparently provoked) -- hopefully before the policy is released, not after. I haven't heard anything back from this offer, and I realize the Church doesn't usually seek any sort of external opinion in making these decisions. Nevertheless, if the policy ends up being a blackout on any use of electronic membership data outside of viewing in the official website and app, this would be damaging to local leaders' abilities to apply creativity and their own best judgment in how to utilize membership information to magnify their callings. I believe there are some clear ways to protect membership data from falling into the wrong hands while allowing tech-savvy local leadership to use membership data in creative ways. For that reason, I want to please reiterate again my interest in having an objective face-to-face conversation about these issues before any sort of official policy is released on this issue. Whoever is connected with the legal process involved here, please reiterate my request to go talk with the team face to face.

I've heard, but not yet found a quote that said "The church moves slowly, if at all". I know from experience that things move slowly, even slower than employee predictions. From what I've heard, this hasn't been forgotten, but it's still working it's way though the process.

However, in looking for something else, I did find this: From Help Center, Keeping Church Information Safe, dated 22 August 2017:

Do not export membership or financial data from Church applications.
Do not store data found in Church applications in consumer cloud storage apps (such as Dropbox or Google Drive).

To be honest, I would be very surprised if the policy statement, once it's done making the rounds, says anything significantly different.

This is why I belive that: The data doesn't belong to the church. It belongs to the members. It's entrusted to the church so it can carry out it's mission, but there are laws that would impose costly liability if that trust is violated. As such, the church is going to keep a pretty tight grip on that data. While it's easy to say the local leaders should be trustworty, I've heard enough stories to know that some have made some really boneheaded moves. And that's just the stories I've heard. I'm sure they (and the church legal defense team) has heard a lot more.

It's simply a product of the current legal/liability environment. And I don't expect that to change until the second coming.

Suggesting specific reports that leaders need would be probably be more productive.

Right. The solution I proposed above is to allow use of the API, including display or printing of information obtained via the API, but not electronic storage or forwarding of any data downloaded through the API, other than perhaps user ids, along with any external metadata (not obtained from record information) or relationships between ids needed for the custom app to function. This does not violate either of these guidelines.

russellhltn,
there is another option you're not considering here. One proposal is to give us access to an API that we can develop applications against. It is possible to restrict access to the API to only applications that have gone through an approval process. That way we are empowered to build what we need while the church retains it's control of sensitive data.

ljcrapo wrote:there is another option you're not considering here. One proposal is to give us access to an API that we can develop applications against. It is possible to restrict access to the API to only applications that have gone through an approval process. That way we are empowered to build what we need while the church retains it's control of sensitive data.

Interesting. But I don't think the church has the resources needed to vet the applications for approval. The development team is very small.

I think using the in-app feedback on LDS Tools to ask for certain reports/views would be more likely.

LCR does have a "custom reports" feature (that's currently only available to the Bishop and Ward Clerk). MLS also has a custom report feature.

The issue that I've been concerned about is related but has been more policy focused. I posted the details of the Church policy mismatch here: https://tech.lds.org/forum/viewtopic.php?f=4&t=31784

In my case, I was wondering if an application would be permitted for Church purposes in a local ward if permission was granted by every single member it affected (i.e. every single member of whose data it would involve).

Also, I wondered if the Church could require that certain security standards be required (such as dual layer encryption + SSL for transport) like is required for personally identifiable information in the educational technology industry.

However, I can understand the Church's reasons for not wanting to expose access to the data because they have no way to determine how to control the public developers' security mechanisms. What happens if one of those softwares unknowingly implements unsafe storage of the password, for example? Or uses unsafe transport? Or accidentally unsafely integrates with another service? Is the Church liable at a general level for a data privacy breech? We have probably heard what happened to Facebook. They were getting congressional hearings and all simply because a single developer abused their privileges. The Department of Defense had a recent high profile security leak as well. It doesn't take an expert to know that there are some pretty bad people who find ways to exploit Church members. What if someone broke into the home of a Church member and stole their computer and gained temporary access to member data? Of course, that could happen if someone wrote their account password on a sticky note by their computer as naive Church members sometimes do, but the Church would also need to implement a very deep defense against other types of cyber attacks against their API from efforts to circumvent the controls from members with legitimate data access who were either ill intended or had their credentials compromised perhaps unknowingly.
That is not a small feat to secure a service like that, and as a software architect, I can testify that it requires significant expertise across multiple domains of knowledge to completely secure an API to the public. It is often extremely difficult to get an API perfectly secure because software dependencies often have their own issues. The Heartbleed exploit is a well known example of that.
Theoretically, if P=NP for even some inputs (see http://www.claymath.org/millennium-prob ... NP-problem), it's actually not even possible for anything to be secured no matter how encrypted it is. Based on my years of study, I have reasonable confidence that the problem is possible to solve for at least some cases, but I haven't had the time to finish working on it yet, so I don't yet know if it applies to the integer factoring problem like would be required to break RSA encryption.

If the matter is under consideration by our general leaders, it is important for us to remember that the Lord is in charge and will inspire our leaders to make the right decision, especially when it really matters. This is not the most serious issue that they've needed to receive revelation on lately, but I promise that even then, it is not insignificant to the Lord, and He will ensure that the correct decision is made. We need to have more faith and trust in His plan, and sometimes that requires a little more long-suffering on our part. But look what He suffered through. If He can do what He did, we can be patient for our leaders to obtain the revelation they are seeking.

devinbost -- you are right, security is a hard problem in general. But you are very much over-complicating the problem. The Church already has a login system, with its own security measures in place, and to use the JSON API, you have to authenticate through that login system. That means that to create an app of your own, yes, you should encrypt the data over HTTPS, but no, you don't need to add your own login system, you just use the lds.org login system to get your session cookie. Combined with the other suggestion I have made above -- that any sites that use membership data are forbidden from transmitting that data (beyond displaying it in a UI) or storing that data (beyond storing the relationship between member ids, if necessary, for organizational purposes) -- then there is nothing that can get cracked by hackers. You would be simply building a *viewer* for membership data, with all the same security constraints and protections of lds.org, but this would give you as a local leader the ability to build a better or a different front-end to the system to meet your local organizational needs.

lukeh wrote:but this would give you as a local leader the ability to build a better or a different front-end to the system to meet your local organizational needs.

And there you've defined the real object to face.

Here's another thing to consider:

If there are more apps available that do what we need through a secure API, I believe members will be less inclined to copy and store information in a less secure format, like a spreadsheet, and share them with people that maybe shouldn't have access anymore. People will find a way to do their job the best they know how. If the secure option isn't more useful than another less secure option. It'll be difficult to get people to not do said less secure option.

"If you want the water to stay in its course, you'll have to make a place for it to go"
- President Boyd K. Packer

Well right now, we already have local leaders having to copy and paste information from lds.org, or type it back in from printed records, because the Church pulled the plug on the CSV export option in MLS. It doesn't stop people using the information, it just makes life more difficult for everyone.

That's exactly my point.

lukeh wrote:devinbost -- you are right, security is a hard problem in general. But you are very much over-complicating the problem. The Church already has a login system, with its own security measures in place, and to use the JSON API, you have to authenticate through that login system. That means that to create an app of your own, yes, you should encrypt the data over HTTPS, but no, you don't need to add your own login system, you just use the lds.org login system to get your session cookie. Combined with the other suggestion I have made above -- that any sites that use membership data are forbidden from transmitting that data (beyond displaying it in a UI) or storing that data (beyond storing the relationship between member ids, if necessary, for organizational purposes) -- then there is nothing that can get cracked by hackers. You would be simply building a *viewer* for membership data, with all the same security constraints and protections of lds.org, but this would give you as a local leader the ability to build a better or a different front-end to the system to meet your local organizational needs.

I agree that the developer wouldn't need to create their own login system, but my point is that there would need to be controls in place to ensure that developers didn't introduce security vulnerabilities by introducing unsafe measures. For this reason, standards like OAuth 2.0 have emerged (see https://tools.ietf.org/html/rfc6749). I will quote the OAuth 2.0 RFC 6749 directly:

In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:

o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.

o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.

o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.

o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.

o Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.
Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation-specific credentials (access token)."

As mentioned in that RFC, OAuth is designed to conform with HTTP (https://tools.ietf.org/html/rfc2616).
However, since the Church can't just use any identity provider service for authentication (unless I'm mistaken), such as Google+ or Amazon, they would probably need to create their own identity provider service. The Church is not a software development company like Google or Facebook or Twitter, etc., so it would be quite a burdensome request for us to ask them to go down the path of managing, developing, and maintaining all of the software that would be required for something like this -- even if a lot of the development could be simplified if they used the latest cloud technologies, such as those offered by Amazon Web Services.

Again devinbost you are over-complicating the problem.

(1) The Church does already operate a Single Sign-On system that spans all their properties (e.g. your lds.org login works on FamilySearch). I assume it's OAuth2 under the hood, but I don't know for sure. The Church would have to authorize API keys or similar to use this SSO system in third party apps.

(2) However, more importantly, you don't need to use SSO at all to make this all work, assuming you don't mind giving your login name and password directly to a custom Android app or website (this is the entire purpose of OAuth/OAuth2, to prevent you having to give your creds to a 3rd party -- but it wouldn't matter much for a custom or open source app developed by or for local units to set up and run in their own instance). Critically, the login creds don't have to be stored anywhere, they are only used once to log in to lds.org via an HTTPS request to grab your session cookie, and that session cookie is then sent with each subsequent request to the JSON API.

(3) As I pointed out in my previous response, of course you do need to worry about not sending data unencrypted etc., and you can't store sensitive data locally either, or transmit it to a third party. But if you don't do any of these things, there is actually nothing to crack/hack, since there is no stored personal data, and no leakage of data over an unencrypted connection.

lukeh wrote:(2) However, more importantly, you don't need to use SSO at all to make this all work, assuming you don't mind giving your login name and password directly to a custom Android app or website (this is the entire purpose of OAuth/OAuth2, to prevent you having to give your creds to a 3rd party -- but it wouldn't matter much for a custom or open source app developed by or for local units to set up and run in their own instance). Critically, the login creds don't have to be stored anywhere, they are only used once to log in to lds.org via an HTTPS request to grab your session cookie, and that session cookie is then sent with each subsequent request to the JSON API.

So, if you were the Church, what would you do if some developer created a web app that was exploited by cross site scripting (for example), resulting in actual lds.org user passwords being intercepted? Or do you have a suggestion for preventing a risk like that from occurring?

Or do you have a suggestion for preventing a risk like that from occurring?

Absolutely: as the developer, follow all the OWASP guidelines for preventing XSS/CSRF and similar attacks, or only use libraries that have certified that they follow those guidelines.

More to your point, though, as a user of the site, you would almost certainly not be vulnerable, using a site of the type I have described in messages above. There are two main types of XSS attacks: stored and reflected. If all you're storing on persistent storage are relationships between internal record ids, maybe with some other metadata, but you are not storing any ward directory information whatsoever that will be displayed to the user (since all the information has to be pulled from the lds.org API and displayed immediately to screen, without hitting cold storage or transmission to a third party), then there is no way for stored malicious scripts to be displayed to the user. For a reflected attack to work, assuming that each ward that develops an app around the API (or deploys an open source app) deploys their own instance, you would need to have one of the ward leaders be ultra-knowledgeable about web security and also dead set on stealing the password of another leader of a different auxiliary in the same ward, so that they can craft the right sort of malicious spoof email to trick the server into displaying a malicious script to the user (and you would have to have an XSS reflection vulnerability in the site too, which you wouldn't have if you followed the OWASP guidelines, as I mentioned above). But the malicious auxiliary leader gains very little by stealing the password of the non-malicious leader, since they already have their own login into the site anyway, for the same ward, and can see at least the same directory information. And frankly, if you have that sort of problem in your ward council, you have bigger issues to worry about than web security!

But really the security concerns you are worried about are all surrounding hosted web apps that access the lds.org website. For a large number of uses of the JSON API, you wouldn't even produce a hosted site, you would just build a little tool that the clerks or EQ Presidency or RS Presidency can run on their own computers for organizational purposes.

For example, it was just announced that my ward is splitting, but figuring out exactly where to put the new boundary is very difficult when you have to make complex decisions about the distribution of member addresses, priesthood holders, activity rates, proximity to chapels, overlap with other wards/stakes (in the case of singles wards), construction / in-move growth rates, etc. -- there are simply no good tools that the Church has developed to let you see all the information in one place, and slice/dice it (while you pray about it) until you get just the right mix. That is a tool that you can imagine someone creating, putting up on GitHub, and letting any unit download and run it on their clerk computer. There's no need to set up a hosted web server instance to run it, you would just run it locally. And then 100% of the security issues you are worried about reduce to simply, "Is the antivirus software on the PC up to date?"...

lukeh wrote: Absolutely: as the developer, follow all the OWASP guidelines for preventing XSS/CSRF and similar attacks, or only use libraries that have certified that they follow those guidelines. . . And then 100% of the security issues you are worried about reduce to simply, "Is the antivirus software on the PC up to date?"...

So you're saying that if the Church created the API correctly, it would be impossible for an app created by a member-developer to create a situation that could result in membership data being leaked in a way that could have been prevented if the developer had not been able to have programmatic access to the data? This would include accidents such as a developer accidentally uploading an AWS key to a public github.com repository, allowing their software-engineering savvy relative who posts on Ex-Mormon forums and sells data on the dark web to access their computer with a shared computer login, cases where the member-developer thinks they know more about security than they actually do, cases like where they are still using a machine running Windows XP or they end up with a rootkit that their anti-virus didn't detect, as well as other security risks that could be introduced by inexperienced or ignorant member-developers?

lukeh wrote:For example, it was just announced that my ward is splitting, but figuring out exactly where to put the new boundary is very difficult when you have to make complex decisions about the distribution of member addresses, priesthood holders, activity rates, proximity to chapels, overlap with other wards/stakes (in the case of singles wards), construction / in-move growth rates, etc. -- there are simply no good tools that the Church has developed to let you see all the information in one place, and slice/dice it (while you pray about it) until you get just the right mix. That is a tool that you can imagine someone creating, putting up on GitHub, and letting any unit download and run it on their clerk computer. There's no need to set up a hosted web server instance to run it, you would just run it locally. And then 100% of the security issues you are worried about reduce to simply, "Is the antivirus software on the PC up to date?"...

Actually the stake leaders that do the ward split have access to a very nice tool to divide wards and see how the changes impact numbers on the fly. I've used it in a couple of ward splits in my stake and they were much easier than the ones I worked on before the tool was available.

So you're saying that if the Church created the API correctly, it would be impossible for an app created by a member-developer to create a situation that could result in membership data being leaked in a way that could have been prevented if the developer had not been able to have programmatic access to the data?

Yes, I split this into two cases in my previous message: hosted and non-hosted. For hosted, it would be a tiny server instance run by each unit, and it wouldn't store any membership data (only organizational metadata), so XSS vulnerabilities are a non-issue for all the reasons I described. For running organizational tools locally, XSS isn't an issue at all, because you're not even running on a server -- the only thing you have to worry about is keylogger viruses -- *but* you have the same exact threat of leaking your password via a keylogger virus every time you log into lds.org from any device, so this is no less safe than just logging into the Church's own website in a browser!

Actually the stake leaders that do the ward split have access to a very nice tool to divide wards and see how the changes impact numbers on the fly. I've used it in a couple of ward splits in my stake and they were much easier than the ones I worked on before the tool was available.

Thanks, I hadn't seen that. I have been a clerk seven times before, but this must have been released after my time!

I gave the ward division tool suggestion only as an example of the sort of tool you might want to develop using the API -- there are many more things that I and others have needed over the years that would be useful to do with a proper API (hence the number of times people have posted to LDSTech asking about API access...).

Actually what I would love to see is for the Church to open-source all their code, for both websites and mobile apps, then we could all just dive in with any spare time we wanted to donate, and help add features to those, rather than wanting to develop external apps that work through an API. I think there were a couple of Church Android apps that were open source at one point, but were later turned into closed source projects (Gospel Library? Or LDS Tools? Anybody remember the history?).

lukeh wrote:

So you're saying that if the Church created the API correctly, it would be impossible for an app created by a member-developer to create a situation that could result in membership data being leaked in a way that could have been prevented if the developer had not been able to have programmatic access to the data?

Yes, I split this into two cases in my previous message: hosted and non-hosted. For hosted, it would be a tiny server instance run by each unit, and it wouldn't store any membership data (only organizational metadata), so XSS vulnerabilities are a non-issue for all the reasons I described. For running organizational tools locally, XSS isn't an issue at all, because you're not even running on a server -- the only thing you have to worry about is keylogger viruses.

Okay... So, what method would you employ on the Church side of the API to prevent data from being stored in the member-developer application after it is transmitted across the wire? A legal agreement? How would you programmatically detect if the terms had been violated so that access could be immediately revoked and the Church's legal team could be notified before much damage had been done? Would the member-developer be required to implement a library on the client side that continuously monitors all of the user's files and network I/O? That would open some pretty major privacy issues on its own, among other issues.

You would put the same type of usage restrictions on the API as are currently shown on PDFs generated from lds.org, and printouts from MLS -- "For official Church use only" or similar (though you would maybe be more explicit about not transmitting the data to third parties or storing it in persistent storage), then you would trust that people who have a calling that should give them API access will do the right thing with the data. This is the very standard of expectation the Church applies already to membership data.

The Church already can't stop anyone from copying the whole ward directory and publishing it on a public website, or selling it to telemarketers etc. -- but they have to believe that the overwhelming majority of the time, that simply won't happen, and the good uses far outweigh the potential bad -- while giving every member the ability to unlist themselves from the directory at any time if they care about misuse of their data.

There will always be tradeoffs between how locked down or controlled data is, and its usefulness.

lukeh wrote:

Actually what I would love to see is for the Church to open-source all their code, for both websites and mobile apps, then we could all just dive in with any spare time we wanted to donate, and help add features to those, rather than wanting to develop external apps that work through an API. I think there were a couple of Church Android apps that were open source at one point, but were later turned into closed source projects (Gospel Library? Or LDS Tools? Anybody remember the history?).

There was an army of volunteers are first, they quickly figured out the 'pace' the church was willing to go and found better things to do with their time. The church and open source philosophies are just not compatible, otherwise we'd have had come, follow me 2 decades before it happened, we'd have 2 hour church with 4 to 5 wards per building so you don't have wards the size of an international stake. we're a top-down org.

I think giving individual members the ability to opt-in and opt-out in a controlled way to each specific API consumer (meaning each specific member-developer-created application) that desires to access their data would be the only possible way I could see something like this happening. In such a case, the liability to the Church would be limited because the Church would be only facilitating interactions between members and member-developers rather than forcing members to either allow their data to be used or not used in some particular way. Members who don't opt-in to a particular API consumer simply wouldn't have their data visible to that application, and if a member opts-in to no applications, their data wouldn't be available to the API at all for anyone. This approach could also give the Church administrative control because if a particular API was violating the terms of usage of the member data in any way, the Church could revoke the authorization, and this could be controlled either at a general level or at a ward or stake level, depending on how the Church wanted to do it.

Also, for most applications, you'd absolutely need some way to be able to track or collect data on some level. However, if the Church provided an ID for each member that was unique but contained no personally identifiable information, such as an ExternalUsageID integer field, then information tracked by the application (like whether a reminder email was sent or not) could be tied to just that ID so that no personally identifiable information would need to be stored outside of the lds.org directory. That way, member information could be retrieved as needed without risking leakage of membership data.
Of course, on the API side, there's nothing they could do to force developers to not store data that was provided to them (since it would still require trust), but at least an ID like that would keep honest people honest because they wouldn't need to store members' personally identifiable information separately to have reasonable functionality in the application itself.

As I'm thinking about it, if this ExternalUsageID method was implemented, the Church could utilize a machine learning application to automatically code-review or audit member-developer applications to check that they aren't storing any sensitive data, though it wouldn't be perfect, so they would still need a manual review process to deal with false positives for developers who flagged the classification for manual review. However, I'm guessing that it would be unreasonable for me to expect the Church to start a machine learning project like that considering that I've never seen the Church post a job ad for anyone with an AI or machine learning background.

An ExternalUsageID field is still a personal you identifying field as long as it can be exported with other identifying information. It doesn't have to be derived from personal information to qualify as "protected data."

MLS used to have a compromise in the membership export file that gave an integer ID to each member of the unit. It was only unique within the unit, and when a member changed units, she was assigned the next largest unused integer for her ID. This kind of convention would be preferable to a global, church-wide integer system (which is basically what the MRN is anyway)

But frankly, the more discussion I read about how people would utilize this, the less inclined I am to favor it. My interest in having access to the API is so that I can generate slightly more advanced reports for my Ward leaders without having to download CSVs or transcribe data. It's merely a matter of streamlining work flow. Much of what has been discussed here has been qualified with statements like "if the developer..."

I'll be candid, I don't trust amateur developers working on their own time to properly safeguard my personal data. And when you step back and look at the bigger picture, that's ultimately where this ends up--in the hands of someone somewhere that has a good idea and not enough domain expertise to do it correctly. If the only solution to that is organizing some body to review and approve apps, then I don't see how this succeeds.

Did you trust that clerks, bishoprics and RS/EQ presidencies would use the CSV exports from MLS appropriately before? (I did...). This is really no different than that. Nervous church lawyers in the end did not trust local leaders enough to deal with data appropriately, and/or the church wanted people to only use the official viewing tools, so the CSV export feature was pulled, but ultimately the usecases for the JSON API are basically the same as for the CSV exports.

lukeh wrote:Did you trust that clerks, bishoprics and RS/EQ presidencies would use the CSV exports from MLS appropriately before? (I did...). This is really no different than that.

I did not have any issue with leaders using the export file for use in tasks that lived on the local computer. I also don't have any issue with experienced and qualified developers utilizing an API to develop applications. But the reality we face is that the church is a conglomeration of minimally trained volunteers that sometimes have more good intentions than common sense. (I include myself in that description)

The question for me isn't whether or not the data can be secured. It's how you can secure it without establishing some sort of gatekeeper organization to screen and review access to the data to prevent breaches caused by ignorance. Given the limited resources the church has for technology development, I don't see it assuming that responsibility.

lukeh wrote:Nervous church lawyers in the end did not trust local leaders enough to deal with data appropriately,

There's an old saying, "absence of evidence is not evidence of absence." I'd suggest that the absence of reports of past abuses reaching our ears is not evidence that it did not happen. I don't think the export were pulled just because of what lawyers were afraid of, but the decision was based in part on what's actually happened.

I don't have (or at least don't remember) any stories about misuse of data, but I have heard stories about jaw-droppingly bad judgement by leaders. The most memorably being a few stories told by President Monson during a regional leadership meeting. So, I know there's a number of things that happen that don't make it to the ears of the general church population.

Yes, in the past there were exports. Most notiably the "Palm" exports from MIS that could be loaded into a Palm Pilot(tm). That intended use has been replaced by LDS Tools. Of course, those simple CSV exports were used for other things as well - and some of those uses may have prompted their removal.

I wonder how many people would donate to a technology fund if the Church started allowing donations to be provided through lds.org for improving the Church's available software.

I don't want to "develop" anything! I just want to be able to access a phone number for someone who lives less than a quarter of a mile from me, but is in another Stake! There are no "phone books" as we used to have. If you try to get a phone number online, you have to pay a fee to get all kinds of personal information about an individual including whether he has broken the law etc. etc. I am not trying to bother the privacy of anyone! I just have a need to contact a friend who lives in another Stake in the same small town that I live in. If you know of a website that will allow this, please, tell me what it is.

Hi All

Thank you for provoking action on this topic. What was the outcome of API access for development?

Not going to happen.

sbradshaw wrote:It would be nice if LDS Tools had a "smart lists" option to make a list of everyone who has a certain calling, for example. I imagine something like this could happen.

Despite this conversation revolving around an API, the OP use case would be completely solved if something like this would be implemented. The ability to create a list based on callings would be really great and make maintaining lists over time much, much simpler.

Well, I was warned off-list after posting the method for downloading ward data that "this matter has caused a big reaction at Church Offices, and has gone high in the hierarchy, higher than you want to know". I was told I could expect to be called in for a meeting with some very senior people. So I pretty much dropped the issue, and the meeting never happened.

I wrote disclaimers in the original posts stating that the data should only be used for legitimate Church purposes, just as official ward lists do. Legally I don't think it's at all defensible to say that the data could not be manually downloaded and manipulated, since there is absolutely no data available through the API that you can't also view through the Web interface, filtered according to your calling and stewardship. The JSON just makes it much easier to programmatically deal with the data. Maybe they're worried about copies of the data being broken out of the web interface. But you can print, photocopy, copy/paste, or right click and save any web content already, so that's not legally defensible either: as soon as you publish anything electronically, you lose control of that data. Data can be copied at zero cost and usually with zero friction, so in a real sense any control over this information is illusionary as soon as the data is published, and the Church is really just asking people to honor their covenants and the stewardship of their callings by asking that it be used only for official church business. But most importantly, ecclesiastically it's not possible to make the case that a leader shouldn't use their initiative and/or any God-given programming talent to magnify their calling, since the Scriptures teach the opposite (D&C 58:26-29). I was just a small fry trying to magnify my calling, and thought I could help others to do the same. Maybe these are all reasons why the meeting never happened.

The JSON API is presumably still there. It was very straightforward to figure out the exact API using Chrome Web Development Tools, simply watching the requests and responses -- anybody with a little bit of web development experience could do the same today -- and, frankly, could have figured this out on their own without me even suggesting it. Probably a few people have independently done this already. However my posts describing how to do it have been pulled twice, and I'm guessing reposting them would be fruitless. I cannot probably write here suggesting that people actually *do* this, or this post will be pulled too. But what I will say is do what you think is right to fulfill your calling, and I'm sure the Lord will appreciate your efforts!

drewsky5 wrote:

sbradshaw wrote:It would be nice if LDS Tools had a "smart lists" option to make a list of everyone who has a certain calling, for example. I imagine something like this could happen.

Despite this conversation revolving around an API, the OP use case would be completely solved if something like this would be implemented. The ability to create a list based on callings would be really great and make maintaining lists over time much, much simpler.

Sorry, I missed your core point. I agree, giving much more powerful filtering and crosslinking options for generating custom reports would go a long way towards eliminating the need for API access. Also a lot of reports I needed over the years surrounded Home teaching and visiting teaching, but with Ministering, most of the reporting complexity is gone.

Hello guys !

I am looking to build in Xamarin an application that controls the interview schedule, caravan schedule to the temple, ward activity schedule, control of expenses receipts, control of payments for youth camps, control of assignments and, for that, I need to consume a updated base of the MLS system, I want to make this integration with the LDS.org church system which in turn receives the updated information, the information to be redeemed would be the member's name, the member's record and his / her call.

I can do this in a few days if I can access the church API.

And if the church wants to be able to make my official church application, I don't want to receive anything for it, it's just difficult to do these controls manually.

thankful.

atte

Erasmo Carvalho

erasmosud1 wrote:if I can access the church API.

Other than for FamilySearch partners, I've never seen the church grant access to any API.

Applications that access the web pages without authorization have been shut down.

Seems rather controlling to not even have a public API

Part of the BITE model

Compartmentalize information into Outsider vs. Insider doctrines
a. Ensure that information is not freely accessible
b. Control information at different levels and missions within group
c. Allow only leadership to decide who needs to know what and when

Why not ease our access to be better workers of the faith? The control is still in their hands by way of our individual login permissions.

Covid-19 had made staying in touch nearly impossible... I want the leadership to allow us to help ourselves help them help us helping them helping us... LOL

Perhaps it's not so much about authoritarian control as it is about the Church's legal and moral responsibility for managing and protecting membership data.

kevinmjacobsen wrote:Seems rather controlling to not even have a public API

What information would you like to see on a public API that doesn't need to deal with all the various PII privacy laws around the world?

I'll answer both scgallafent and jonesrk here...

jonesrk wrote: What information would you like to see on a public API that doesn't need to deal with all the various PII privacy laws around the world?

I've already access to the data via church controlled apps. I'd just want an API that allows me to be more flexible on how I use the data I have access to currently.

If you think an API would grant me more access to PII data you would be wrong. Again, I already have access to a level of PII data via my login to tools. Are you suggesting that tools is exposing PII data?

Perhaps you and I aren't speaking the same tech language. I want members (PUBLIC) to have access to the APIs (PRIVATE or Restricted) that the tools app and other apps use currently.

I want to use the data I have access to in ways that don't fit the limited use cases the tools app currently employs. If you want some use cases look to the forums for requested features that have either been rejected, but are allowed but won't be implemented, or have yet to be implemented.

I want the APIs currently in place to be made available to the public community of Saints.

Thanks for considering my POV.

PS - I cannot see how access to those APIs currently not public would change the morality or legality in any way. The data is already in the app and people abuse it already... "No, I don't want to join your MLM and please quit using tools to call members in the stake, that you have never met, with your pitch."

We are speaking the same language. You want public access to the APIs used by Church-developed tools so that you can build your own applications that utilize those APIs. To keep the answer succinct: "no." The Church does not provide access to application APIs so that third-party applications can have access to data in Church databases.

There is a common belief that because you already have access to the data through Church-provided tools, you should be able to access that data through an API so that you can build your own tools. While that may be the way you see it, that is not the way that the Church sees it. There is a significant difference between providing information to you through a Church-developed tool and giving you access to the data in an API so that you can manipulate it in your own applications.

We know that there are developers who are reverse-engineering the APIs for Church applications for their own purposes. When external applications using Church application APIs are identified, the developers are contacted by the Church. The stake president is often contacted in these situations so that he is aware of the issue. In some cases, users have had their Church accounts blocked from accessing the tools because of API usage. I'm not talking about being blocked from the API, but about being blocked from using the Church tools: LCR, Directory, CDOL, and possibly Member Tools.

I'm following the discussion about access to the "Public" Member Tools API.

Can we get permission to get "private" access to the Member Tools API?

I'm the Clerk in the Aspen Grove Branch and we have 90 new BYU students (45 men, 45 women) that we need to fill callings in the Branch each year. They are the Staff at Aspen Grove and it changes each year. It's quite a task for the Presidency of the Branch to organize interviews with all the new staff and make new callings.

We are using a Google Form created by BYU and our own database application for storing more information from each Student. We are using GroupMe to communicate with the Staff during the summer camp months.

I would like to simply connect our database to a Private Member Tools API, so when a student/staff changes their phone, picture, email, etc., it will change in our app as well.

Thanks, JohnW
John Wright
Aspen Grove Branch Clerk
801-221-1800

JohnWWright wrote:Can we get permission to get "private" access to the Member Tools API?

No.

There is a possibility that BYU OIT could sponsor a BYU project to do this and work with the Membership department to integrate membership data into that application, but there isn't a way that you can get access to any membership data APIs for a ward-sponsored project.

Ok, Thanks. I'll try that!

I sent some follow-up information by private message. For everyone else who might be wondering... It is possible that BYU might feel this is important to support Aspen Grove, but my personal opinion is that it isn't likely. Their IT teams are nice folks and they are also very busy taking care of the needs of the university. They don't have the staff to start building projects for BYU wards.

Short of an official project managed by the Church or an affiliated entity (BYU in the case of this request), there isn't a way to get access to membership data.

Ok, thanks. Just to clarify... We wouldn't need BYU to build a project. We have the Aspen Grove new member tools app built. BYU would just need to get access to the API, which could include the ability for the students to use their Member Tools username and password for SSO.

Also, my "day" job is building cool apps. We built the current "Tree of Life" Augmented Reality app for the Church last year that now has over 250,000 downloads.

We are modifying another note/crm/ticket/database app we are building, called Banna (www.banna.app), to use for the Aspen Grove Member Tools.

Okay, It took me more than an hour, but I just read over the past 4 years of posts on this thread regarding access to an api for LCR member data. There were a lot of references to policies, but no working links, so I'm not sure where to find some of these policies, and my questions weren't fully answered.

• Is there a policy barring me from creating some kind of chrome extension that can read the information in LCR (once the user has logged in) and present or organize it in different ways?
• Is there a policy barring me from publishing an LCR scraper on a scraper registry for members to use?
• Is there a policy preventing me from writing an application that a user provides a username/password which logs in in the user's behalf and reads the information to display it in helpful ways (without the user having to login themselves)?

None of these would be duplicating the information onto any kind of persistent storage. I suppose I generally view any information presented on a website as fair to view or organize according to the users's preferences, whether that's to just peruse, or copy notes into a notebook, or manually create reports with, or create automated filters, views, maps, etc with. If there's no policy barring someone from doing any of these things manually, then I'm assuming there wouldn't be one barring them from doing it automatically. In my mind that would be the equivalent of allowing someone to use pen and paper for their tasks, but not a mouse and keyboard. I'm not sure I understand where we're drawing the line.. or why. Is the issue with sending the information over the wire? It's already being sent over the wire to the user's browser.. which is just basically just a specific kind of 3rd party application that users are typing their usernames and passwords into.

How I'm hoping to utilize this is by combining LCR information with locally gathered information to help with:
- Better Mapping: Color coordination on status, callings, orgs, activity, age, interests, etc. Splitting wards into chunks, organizing members by ward area. Augmenting ward maps with non member info and non LCR info. organizing block activities, organizing fellowshipping assignments, etc.
- showing information gaps on ward members directory info, showing gaps in activity or visits,
- displaying timelines of events and visits to people of interest (similar to missionary's area book app), allowing members to keep a rolling record both ministering and non-ministering relevant events.
- keeping a kind of notification/visitation preferences list for weekly/monthly newsletters, invitations, visitations, etc.
- automated email/text reminders to leaders of certain reports (upcoming birthday visits, etc)
- creating custom views and reports for a variety of metrics, and automated task lists based on certain criteria

That's a start. I realize a lot of these utilizations could have privacy concerns if treated improperly, just like any of the manual data entry that leaders do on a daily basis. (a lot of these would probably reduce the amount of data that member leaders pass around like candy). I'm just trying to understand if there's a policy laying out specifically what I'm not allowed to do, beyond not storing PII. So many of my meetings are spent conveying information that could have been conveyed automatically given the software to do so. Or manually gathering reports that could have been manually automatically. The church has done a great job over the past few years giving us what we have in LCR, but there are a ton of very smart engineers in this church that have seen what good software can do that are just chomping at the bit to build better tools.

gisheri wrote: Mon Dec 13, 2021 5:41 pm There were a lot of references to policies, but no working links, so I'm not sure where to find some of these policies,

Links change over time. You might want to review the Terms of Use found at the bottom of each webpage.

You further agree not to: (i) use any robot, spider, or other automatic device, process, or means to access this site for any purpose, including, without limitation, for monitoring or copying any of the material on this site; (ii) use any manual process to monitor or copy any material on this site, or for any other purpose not expressly authorized in this Agreement, without our prior written consent;

Updated link for Keeping Church Information Safe

Meetinghouse Policy has been replaced by Technology Standards

gisheri wrote: Mon Dec 13, 2021 5:41 pm • Is there a policy barring me from creating some kind of chrome extension that can read the information in LCR (once the user has logged in) and present or organize it in different ways?
• Is there a policy barring me from publishing an LCR scraper on a scraper registry for members to use?
• Is there a policy preventing me from writing an application that a user provides a username/password which logs in in the user's behalf and reads the information to display it in helpful ways (without the user having to login themselves)?

The first two will get noticed by Security. The last one WILL earn you a phone call from Security. In some cases, a user's access to applications has been completely blocked due to their use of the APIs.

Church application APIs are not public APIs intended for external developers to use to build their own applications. russellhltn has already provided the relevant links. If you have further questions, you can contact the Church Data Privacy Office at dataprivacyofficer@ldschurch.org.

I have pushed back on these policies hard many times over the years, including publishing information in this forum detailing how to get the information over the JSON API that is used by the Church's own website (rather than having to scrape it). All my posts have been deleted by moderators, and a couple of moderators told me that my posts resulted in some vigorous internal discussions -- so even the moderators are not fully aligned with church policies on this, but they abide by those policies. I have been threatened with having the Church's lawyers sic'd on me several times. I gave up in the end.

I don't understand the policies. I think that they are unreasonable, and out of touch with the leakiness of the data access already granted on Church properties (e.g. you can easily copy/paste information out of your browser view of the ward list). These policies about API access actively impede our ability to fulfill and magnify our callings, or to use our initiative to do good things (D&C 58:26-28).

Moderators: PLEASE DO NOT DELETE THIS POST. People need to know that if they try to go down this road, they will fail, just like I did.

Well, thanks for the quick responses, and for the info, and the links.

The wording in the code of conduct is actually more lenient than I expected.

[you may] view, download, and print materials from this site for your own personal, noncommercial use (including such use in connection with your calling in The Church of Jesus Christ of Latter-day Saints (“Church”))

• So we can download the data? So I could distribute a locally installed program that processes the data in creative ways?

nor will you impersonate another user in order to hide your identity or to implicate another in such actions

• Impersonating is not expressly forbidden unless done for bad reasons? [/quote]

[not] use any robot, spider, or other automatic device, process, or means to access this site for any purpose, including, without limitation, for monitoring or copying any of the material on this site;

• "automatic process to access" generally means not driven by a user, which still leaves quite a bit of room for automatic processing if the access was human driven. There's no wording saying anything like "This site can only accessed by a user typing into the url of an approved browser and data processing is strictly limited to their eyeballs". Enforcing rules around processing data on the web is tricky business there are usually so many arbitrary and assumptive lines being drawn, I'm not sure exactly how this sentence should be interpreted.

I don't think that requests for approved methods of getting creative with membership data are going to go away. And i don't think they should. Can we keep this conversation open? You mentioned that the api isn't designed for developers to make applications out of, but honestly, any bit of data someone has access to gets processed and applied by the user in whatever methods they're literate with. Maybe "developers" can make user friendly applications out of them, but an EQ president might make an excel graph, a ward mission leader might put dots on a map, and deacons president might make a 3 column layout of names and addresses on a paper. Each of those is an application, and everybody is an engineer to some degree, so at some point as people get more literate with tech, you'll have to start placing arbitrary lines on how 'advanced' an application can be. We have to keep this conversation open. The church is smack dab in the middle of one of the most engineering talent dense areas in the country, and has an army of potential and eager allies wanting to help solve the tech problems we're facing. Instead of utilizing this incredible asset, we keep getting told to basically stop bothering the church with our ideas. It's a spiritual dilemma when we're feeling constant spiritual pressure to utilize our talents for the good of the church, but the church blocks us from doing that.

I'm not one to judge the processes (okay, maybe I question everything too much), if this policy comes from revelatory intervention from approved leadership I can sit with it for now, but it feels more like it's just something that just hasn't been discussed enough. If someone posting simple instructions on how to use an internal api causes a flurry of discussion, that makes me question. Is it possible to re open this discussion with the powers that be, and see if we can experiment with some kind of Oauth? Or at least an approved scraping application?

gisheri wrote: We have to keep this conversation open.

Actually no, we do not. We can discuss these things until the cows come home, but we are not the decision makers and they do not see our discussions.

As scgallafent said, the answers to all of these questions come from the Church Data Privacy Office at dataprivacyofficer@ldschurch.org.

Oh.. well okay then. So nothing in these threads ever reaches the decision makers?

I don't think the church wants to be doing this, but between privacy laws (especially Europe's General Data Protection Regulation), and the general legal environment, they don't have much choice. If they allow it, sooner or later someone will misuse it and end up costing the church a small fortune. GDPR fines and notices

Some of us remember "the good old days" when the church actually provided a "Palm Pilot" file where you could import information into the popular PDA of the day. It was trivial to import it into a spreadsheet.

As lajackson indicated, this isn't open for debate. There's no question this would help wards and members magnify their callings. That's not the issue. It's the law of the land and its ramifications. Particularly given SLC's experience of members not following rules. Given the public's interest in privacy, I don't see this changing in our lifetime or until the Second Coming - whichever comes first.

Instead, I'd suggest that you define the reports you need and use "Feedback" in LCR to make the case for them. It won't happen quickly, but it's more likely to be productive.

Yah, I can see that. Thanks for the responses. Though, i (and many others) can make a convincing case for how opening an api would only improve privacy, but I suppose this isn't a useful platform for presenting such a case.

gisheri wrote: Mon Dec 13, 2021 10:13 pm Yah, I can see that. Thanks for the responses. Though, i (and many others) can make a convincing case for how opening an api would only improve privacy, but I suppose this isn't a useful platform for presenting such a case.

This is not the platform for making that case. Although there are Church employees who frequent the forum and answer questions and there is a small official presence here, the forum is primarily user-to-user discussion.

The only option you have for presenting your case would be the Data Privacy Office. They are responsible to ensure that the Church complies with data privacy laws around the world and that personal information is handled appropriately.

I agree that competent, motivated, and skilled volunteers could potentially do a lot of good things with membership APIs. However, the Church's current position, as I understand it, is that it's not worth the risk, and especially after looking at russellhltn's GDPR link above, I'm inclined to agree.

I don't know of any organization with 16 million+ members that provides publicly-accessible APIs to membership data – even behind a login (which would limit the results coming back to a few thousand members) – without explicit consent from the members whose data are included in the API. APIs with data about people, in any organization, are usually private, and limited to employees who have signed legally-binding agreements to obey privacy laws and follow policies to keep data safe.

Even if API access were somehow limited to ward clerks who sign legal agreements, there are about 31,000 wards or branches, run by volunteers, with few training qualifications required, no security vetting process, and a line of accountability through similar volunteers (ward and stake leaders) who may not think to contact the Data Privacy Office if an issue is discovered. Chances are high that something could go wrong, either by accident or by malicious actors.

gisheri wrote: Mon Dec 13, 2021 9:36 pm Oh.. well okay then. So nothing in these threads ever reaches the decision makers?

Sometimes developers or QA engineers visit the forum to help provide support, but not usually in an official capacity. Those who actually make decisions about policies or product direction – product managers, general authorities, etc. – don't generally visit the site. The forum is mainly for user-to-user support and discussion. The best way to send feedback is either through the Feedback link on Church websites/apps (which goes to a support team who can reply, forward feedback, or share summarized data with the appropriate teams), or through ward and stake leaders who can pass on needs to area and general leadership.

I just did a search on Google with these words: church of jesus christ of latter-day saints api I got back a page that looks like an actual API to get directory information? It shows calling an API Endpoint: https://lds.io/api/ldsio/:account_id/st ... s/:ward_id to retrieve the information. Does anyone know if this is legit? I know I'm probably getting my hopes up, but was just wondering?

Thanks,

Craig

craigmadsen wrote: Mon May 30, 2022 11:41 am I just did a search on Google with these words: church of jesus christ of latter-day saints api I got back a page that looks like an actual API to get directory information? It shows calling an API Endpoint: https://lds.io/api/ldsio/:account_id/st ... s/:ward_id to retrieve the information. Does anyone know if this is legit? I know I'm probably getting my hopes up, but was just wondering?

All church data is served at access-controlled HTTP endpoints returning JSON, yes. (The access controls are role-based, and based on a login cookie.) This API surface is used by both the churchofjesuschrist.org member portal website and the LDS Tools app. I found the JSON endpoints by observing data flowing through the browser using Chrome Developer Tools, and I published a list of them in this forum, years ago, but my post was pulled by moderators and I was threatened with legal action by church lawyers to whom the matter was escalated, so I don't recommend doing the same.

Yes, it's sad that the church has chosen this policy.

The thing I find funny is the vast variety of who wants and does what on these forums, I was active from before the tech forum was alive and we were the clerk wiki, and before that on the mailing list. What I've learned is that the church doesn't mind that those with callings at the local level spend enormous amounts of time inefficiently, the frank truth is that the end user is NOT the customer of these tools and services, but the local departments of the church are the customer. Once you start thinking in these terms it becomes easier to understand. Call it security, call it a global service of membership data trying to keep up with global laws, but these are all just people guessing what the reasons are.

We have those trying to do something fancy and cool with the directory, and others that can't get something recorded on the calendar, or move our someone that moved several years ago even after being handed the information about where they went, once, twice, three times, new Bishops, new clerks, my neighbors that moved 3 years ago are still listed as living there, I'm even assigned to Minister to them. So, to those of you with overwhelming time to create cool tools, I salute you!

Dang I miss that demographics info from the exported directory, that was the absolute coolest thing to help see trends, it still amazes me that Bishops don't have that information to help them plan for the future.

craigmadsen wrote: Mon May 30, 2022 11:41 am I just did a search on Google with these words: church of jesus christ of latter-day saints api I got back a page that looks like an actual API to get directory information? It shows calling an API Endpoint: https://lds.io/api/ldsio/:account_id/st ... s/:ward_id to retrieve the information. Does anyone know if this is legit? I know I'm probably getting my hopes up, but was just wondering?

Thanks,

Craig

The domain isn't owned by the church, and has a "buy this domain" banner, so if it ever was legit, it doesn't look like it is now.