Tech Forum

boomerbubba wrote:It turns out that the vendor's server is in the processing loop. The reply from Avikey to me said:

Yes.. the parsing rules for the device are delivered using our server.
That way, if the church substantially changes the layout of LDS.org,
we can adjust the parsing rules remotely that are used by your device.
So in this sense, yes, the app doe require the use of a third party
server to work. If that server is missing, the app will fall back on a
default set of parsing rules.

To me this says that the third party server is merely passing instructions on how to scrape the screen of the LUWS. If that is the case, then the app is still within policy since no actual membership data is processed/stored on the third party server. This approach actually makes a lot of sense as otherwise, the developer would have to release an update to the app through the app store every time the Church modifies the LUWS.

jbh001 wrote:To me this says that the third party server is merely passing instructions on how to scrape the screen of the LUWS. If that is the case, then the app is still within policy since no actual membership data is processed/stored on the third party server. This approach actually makes a lot of sense as otherwise, the developer would have to release an update to the app through the app store every time the Church modifies the LUWS.

If that's all they are doing, the "third party server" concern over the data content may not obtain. That's the only part of the question Avikey talked about in response to my query. Their response was silent about how the connection to lds.org is made. So I asked a follow-up in reply:

Well, what I want to know is whether the actual connection between a user's iPhone and lds.org goes through your server, and whether the data is processing on your server in any way.

Is the actual connection to lds.org, using the user's logon credentials, made by your server or by the user's client?

After more than 24 hours, I have not received a follow-up reply. Meanwhile, a credible colleague performed a network trace and confirmed that when the test iPhone running iWard makes an SSL connection, the only server it apparently connects to is Avikey's. The user's device does not seem to make the SSL connection to secure.lds.org at all.

SSL is end-to-end encryption between a client and an https server. If we read Avikey's stated description literally, what is apparently happening is that there are two SSL connections: The iPhone app contacts the Avikey server and passes the LDS Account logon credentials. Avikey then logs onto secure.lds.org and retrieves the data, forwarding it with or without transformation back to the iPhone.

boomerbubba wrote:I rather suspect that most users of this product are not even aware of how it really functions.

[...]

A user might be forgiven for thinking that he is connecting to secure.lds.org via a single, end-to-end SSL connection to his own device, just like he might do with an online banking client or browser.

Of course, compromising LDS Account credentials is more serious for leaders, because their credentials can potentially connect them to other things that rank-and-file members cannot.

[...]

I am not accusing the operators of iWard/iStake of doing anything malicious with anyone's credentials. But I think I would be violating policy to use the product. Knowing what I know now, I certainly would be violating common sense. The architecture is inherently insecure.

But your report that data from LUWS is being processed on a third party server comes from a single source, and that source happens to be a competitor to iWard/iStake. This raises some questions:

• Has the packet trace that showed iStake ONLY communicating with avikey.com instead of both avikey.com and lds.org been replicated/verified independently?
• How was the packet trace done? Could it have been flawed in some way?
• What is avikey's response to the the allegation that iStake never communicates with lds.org directly?

Having used iStake, I can inform you that an early version of the app stored the LDS account password on the iPhone. A subsequent update to the app removed that ability--reportedly at the Church's request. The most recent version of the app restored the functionally--again with the apparent permission of the Church. To me this shows:

• The developer is working with the Church to have the app comply with Church policy.
• Using the app in its current form apparently does not violate Church policy or compromise LDS account credentials as alleged.
• The accuracy/comprehensiveness of the packet trace done by the competitor is in question.

boomerbubba wrote:After more than 24 hours, I have not received a follow-up reply.

Curious.

I wonder if their reticence could be due to wanting to protect a trade secret. (Or the fact that to day is a Monday )

If iStake only communicates with avikey.com, then is a pass-through connection to lds.org a violation of Church Policy as long as no data is stored on the third party server? (I don't know the answer, I'm just raising the question.)

For now, iStake bills itself as a screen scrapper on steroids. One data point has been introduced that challenges this, and that by a competitor. I'm waiting for more data that refutes or corroborates.

If I knew how to trace packets on my iPhone I'd be glad to put it to the test. But I don't, so I can't.

jbh001 wrote:
If iStake only communicates with avikey.com, then is a pass-through connection to lds.org a violation of Church Policy as long as no data is stored on the third party server? (I don't know the answer, I'm just raising the question.)

In some contexts, the so-called "third party server" rule is not written down very clearly. In many respects, especially with MLS data, it exists mainly in advisory remarks on LDS Tech.

However, in the case of LUWS data, the user covenants to some specific language in the Rights and Use Information document of lds.org, which says in part:

You may not post material from this site on another web site or on a computer network without our permission. You may not transmit or distribute material from this site to other sites.

The issue here is not whether Avikey is violating an agreed-to policy. They have no agreement with the Church, AFAIK. The question is whether the user is abiding by the policy he agreed to.

Besides, the "third party server" rule is not the only policy that is apposite here. See the LDS Account Conditions of Use linked above. Do you assert that passing the user's LDS Account password to Avikey is not reasonably considered a violation of that covenant? That policy does not say, "You may not share your LDS Account password with anyone who stores it on a third-party server." It says, "You may not share your LDS Account password with anyone."

(BTW, the next time your stake president needs to look up something in LUWS, tell him just to give you his LDS Account username and password on a flash drive, then you can retrieve the data and send it to him. If you and he are okay with that interpretation of the LDS Account terms of use, then go for it. And the next time you have some online banking to do, just send me your username and password. I'll be glad to do it for you.)

jbh001 wrote: For now, iStake bills itself as a screen scrapper on steroids. One data point has been introduced that challenges this, and that by a competitor. I'm waiting for more data that refutes or corroborates.

Information from my correspondence with one of the iward/istake developers.


The explanation of how the application works:

> In terms of your specific questions, the mode we use for the retrieval
> of data to the device is as follows:
>
> - The user enters their username and password into the device where it
> is stored in a private database (the database, per Apple's security
> model, is only accessible from inside the application. No other
> applications or services on the device have access to the information
> stored in the tables).
>
> - Once the user has entered their username and password, the device
> sends a request to a custom web-service adapter over an encrypted SSL
> connection. The purpose of this adapter is to handle the translation
> and data download from the LDS.org web-site. The adapter, after
> retrieving the data from LDS.org, translates the data into XML format
> and feeds the XML back into the device, again, using an encrypted SSL
> connection.


And the follow up email which outlines the future of the product.

>...we've shifted all of our development
>priorities to address these two things as quickly as possible. We're
>moving all of the code that communicates with LDS.org directly into
>the application (so all communications between the device and LDS.org
>will be done DIRECTLY with no intermediary layer). And, of course,
>we'll adjust the app so that it does not remember the password to
>LDS.org.


These emails were exchanged in May of 2009. To my knowledge they have not yet addressed these and other security concerns which were raised at that time.

Tom

jbh001 wrote:But your report that data from LUWS is being processed on a third party server comes from a single source, and that source happens to be a competitor to iWard/iStake. This raises some questions:

Actually, the lead developer of Ward Tools, who first revealed the facts to me, is not a "competitor" in any reasonable sense. In the first place, Ward Tools is now open-source and free. In the second place, it is designed to serve leaders using exports from MLS, while iWard and iStake serve any members with data from LUWS. So their functionality does not completely overlap. Many users install both.

The question arose in the support forum for Ward Tools, where an end user was frustrated for lack of access to the MLS data. I referred him to iWard, and the ensuing discussion on the thread revealed the facts about iWard's security model. That same discussion revealed the news about the new MyWard product (which is a direct, commercial competitor with iWard/iStake). Just as he had done with iWard, the Ward Tools developer ran similar network-trace tests on the MyWard product and verified that the SSL connection of that new product was a secure, end-to-end-link between the iPhone and lds.org. He accompanied that with high praise for the functionality of the MyWard product, which also was praised by the contributor who first mentioned MyWard there. So your attempt at ad hominem does not wash.

jbh001 wrote:

• Has the packet trace that showed iStake ONLY communicating with avikey.com instead of both avikey.com and lds.org been replicated/verified independently?
• How was the packet trace done? Could it have been flawed in some way?

You and anyone else are free to replicate the test using open-source tools. The methodology was documented here:

http://groups.google.com/group/wardtool ... 2892?hl=en

jbh001 wrote:

• What is avikey's response to the the allegation that iStake never communicates with lds.org directly?

As I mentioned above, Avikey has never responded to my direct questions on that point. But as you can see in the comment above, they essentially confirmed that architecture several months ago in correspondence with lakeytw.

jbh001 wrote: Having used iStake, I can inform you that an early version of the app stored the LDS account password on the iPhone. A subsequent update to the app removed that ability--reportedly at the Church's request. The most recent version of the app restored the functionally--again with the apparent permission of the Church.

That peripheral matter has little to do with the more important issue of transmitting the password to the Avikey server. (I really don't care if the password is archived locally on the phone, so long as the app does it securely. I store all my 50+ professional and personal passwords in an encrypted password-management tool.)

You seem to be saying that the Church has approved the iWard architecture. Do you have some authoritative source for that? If not, I suggest that you not imply this is the case.

Obviously, you are one of those I mentioned above who had a good-faith misunderstanding of how iWard/iStake has been functioning. (You can be forgiven that, since Avikey has apparently not disclosed the details except to those with the requisite technical skills who actively probe for the underlying facts.) Now that you do know what the actual architecture is, my advice to you and any other users of the product as currently constituted is:

1. Stop using iWard/iStake.
2. Uninstall it.
3. Immediately log into LDS Account and change your username and password.

lakeytw wrote: And the follow up email which outlines the future of the product.

>...we've shifted all of our development
>priorities to address these two things as quickly as possible. We're
>moving all of the code that communicates with LDS.org directly into
>the application (so all communications between the device and LDS.org
>will be done DIRECTLY with no intermediary layer). And, of course,
>we'll adjust the app so that it does not remember the password to
>LDS.org.

These emails were exchanged in May of 2009. To my knowledge they have not yet addressed these and other security concerns which were raised at that time.

That would seem to correspond roughly to the time frame of when the app lost the ability store the LDS Account password (which ability was subsequently restored a few months ago).


EDIT: The ability to store the password was regained in version 1.4 of iStake

Latest Update

New in v1.41:
- Fixed the bug that caused issues with accessing and creating stake smart lists.

New in v1.4:
- Support for Stake and Ward Events
- New tabbed browsing interface
- Fixed a bug when emailing large numbers of people
- Smart-list names can now be edited
- Improved setup screen
- Now that iPhone OS 3.0 supports saved passwords in the browser, we've returned that feature to the app.

boomerbubba wrote:You and anyone else are free to replicate the test using open-source tools. The methodology was documented here:

http://groups.google.com/group/wardtool ... 2892?hl=en

Actually, I can't run Wireshark on my version of OSX (10.4.11) so for now I will have to rely on others.

I noticed that the conditions of the packet trace required the iPhone to be in airplane mode AND use Wi-Fi. I don't understand how this could be since airplane mode, by definition, shuts off ALL radios on the iPhone including Wi-Fi (see page 138 here). So something is amiss with the trace, with Apple's documentation, or something else somewhere.

EDIT: I just tested this, and apparently switching the iPhone to airplane mode switches all the radios off, but you can then manually enable Wi-Fi while still in airplane mode (see page 139 here). To get the rest of the radios back on you have to switch out of airplane mode apparently.

jbh001 wrote:Actually, I can't run Wireshark on my version of OSX (10.4.11) so for now I will have to rely on others.

I really feel no need to replicate the tests (and I don't own an iPhone). The methodology is documented for anyone else to do so. Calvin is a known and credible source to me. I have been working with him ever since Ward Tools went open-source several months ago. I don't think he has any ax to grind here, and I have high confidence in his technical abilities and ethical standards. Besides, Avikey essentially confirmed all this in correspondence to lakeytw.