"iWard" iPhone App

[mkmurray]

(comment removed from original post)

I think you made your point more than thoroughly about how you feel with regard to the product's compliance with policy. But I think you are borderline going too far with statements like this.

We can discuss the pros and cons of why something may be within policy or against it, but ultimately it comes down to individual responsibility for living within policy. In some cases, the policy is vague enough to merit individual interpretation as well.

Present the policy as stated by Church representatives, show some facts about the situation, and maybe even give your explicitly stated opinion on whether you think it could be in or out of policy, but that really should be the extent of it. I think it is going too far if we interpret policy on others' behalf that we have no priesthood responsibility over.

[RossEvans]

I think you made your point more than thoroughly about how you feel with regard to the product's compliance with policy. But I think you are borderline going too far with statements like this.

We can discuss the pros and cons of why something may be within policy or against it, but ultimately it comes down to individual responsibility for living within policy. In some cases, the policy is vague enough to merit individual interpretation as well.

Apologies. I have deleted the comment, which tried to make an argument badly.

That point is that we were not debating policy here, over which we all might have our own interpretations. We were debating facts. And I agree that it does seem pointless to pursue that debate further.

[RossEvans]

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?

For the record, I just received a reply to that follow-up. It said:

The app connects directly to LDS.org.... Other than the third party server (our server) that was mentioned that is required to feed the app with the correct parsing rules.

I do not know how to reconcile this with the testing and historical correspondence, unless something has changed or someone has made a mistake.

[jbh001]

I do not know how to reconcile this with the testing and historical correspondence, unless something has changed or someone has made a mistake.

The procedure for the packet trace was documented, but not well. For example, what version of the iPhone OS was used, was it the current version (3.1.2) or something previous? What version of iStake was tested, was it the current version (1.4.1) or an earlier version? What version of Wireshark was used? etc.

I would hope that the tester used the most current versions of each, but since this was not explicitly stated, it cannot be assumed. There may also be additional variables in play--which no one has thought to check yet--that might confound the results of the packet trace as well. That is why I would like to see if someone else can replicate the packet trace results.

As I read the quoted responses from the vendor, they appear consistent with the approximate versioning of the app. The version of the app referenced in May-2009 (v 1.2?) is apparently substantially different (by the vendor's own admission) from the current version of the app (v 1.4.1) released Sep-2009 in the way it downloads data from the LUWS. That is enough of a change over the course of a few months to satisfy me as to the differences between the current and historical correspondence cited from the vendor.

[mkmurray]

It is possible the software makes most calls directly to LDS.org for authorization and data download, but calls the Avikey server to get the latest parsing rules.

[calvinrg-p40]

Sorry I haven't responded earlier, let me see if I can clear up some things.

The procedure for the packet trace was documented, but not well. For example, what version of the iPhone OS was used, was it the current version (3.1.2) or something previous? What version of iStake was tested, was it the current version (1.4.1) or an earlier version? What version of Wireshark was used? etc.

I tried to produce a screen-capture of the process of performing the packet trace but it's nearly impossible to read. Here are the details of what I set up.

The capture was done using a MacBook Pro with OS X 10.6.2 running WireShark 1.2.5. The MacBook was set up to share it's internet connection over it's wireless card. An iPod touch running OS 3.1.2 was connected to the MacBook's wireless network (to allow the packet trace) and a fresh copy of iStake version 1.41 was installed from the iTunes App Store on the iPod touch.

I then started the packet trace in WireShark. I launched the fresh install of iStake which had no stake data installed and went to the Setup screen where I entered my lds.org username and password. I then touched the "UPDATE" button in the "All Data" cell of iStake and let the packet trace run capturing all of the packets until iStake informed me it was updated. WireShare had stopped receiving packets at that point so I stopped it and verified that iStake was now populated with all of my stake data.

The packet trace starts off by showing the iPod touch making a standard address query for http://www.avikey.com and getting back the IP address 66.240.210.125. From that point until the end of the capture there is only SSL communication between the iPod touch and 66.240.210.125 (along with some DNS, ARP, and DHCP packets to my router etc.).

There is no communication in the entire process to lds.org or secure.lds.org. I do not see how the claim that iStake talks directly to lds.org and only uses avikey.com to download parsing rules can be true. As I see it there are only two possible explanations.

1- Wireshark is somehow dropping all of the lds.org packets (highly unlikely since I did a similar trace on MyWard and was able to verify it only talked to secure.lds.org).

2- The person making the claims either does not understand the product and how it works or they have only worked with a yet to be released product which behaves differently.

The packet trace was really quite simple to set up and I've duplicated it several times to be sure.

[RossEvans]

I replied to Avikey support, asking them to explain the discrepancy between their communication to me and Calvin's test results.

Overnight I received a reply, which follows in its entirety. (In context, for the benefit of those who don't know me, my name is Ross Evans.)

Hi Ross,

I've read the thread you pointed out.. I'm one of the developers of the iStake and iWard apps. Perhaps I can shed some light here -- and apologize for the confusion that's been generated. The person taking care of our support emails isn't fully up to speed on the internal workings of the app (which will be corrected).

First, as Tom has pointed out, we were contacted by the church (both Tom, and a gentleman in the security department) regarding the architecture of iStake. Our initial release did indeed use a third party server (our server) to handle the screen-scraping.

It's actually an immense undertaking to pull it off inside the phone itself and doing it 100% inside the phone posed several key problems..

1) Without some very clever coding -- it takes forever to download the membership and calendar data for an entire stake (as demonstrated by "My Ward" which can take several hours to do a full update).

2) If the church changes even the tiniest detail on the LUWS, portions of the app, or the entire app altogether, can break -- leaving the developer in a scramble to push out a new app update, which can take a week (usually more) due to Apple's lengthy approval processes.

The original discussion we had with Tom indicated the approach of using our server in the middle was a problem, and the reasons (which have been described clearly here in the thread you posted) were understood. We agreed to correct the architecture as quickly as possible to communicate directly with the church web-site rather than using the third party server.

It was also understood that this was not something that needed to be done overnight, and that we would be granted the time to correct the problem appropriately.

So.. we set out to correct the issue. Unfortunately, we had enough customers at this point that it would have been inappropriate and irresponsible to use them as "beta testers" for the transition. Screen-scraping of this magnitude is extremely complex, and we couldn't risk breaking the app by implementing this change all at once... So we opted to take an incremental approach and "phase-in" the device being 100% responsible for all screen scraping. (Once again, the "My Ward" app is a good example of what happens when you just throw it out -- as we've heard lots of reports of it not properly parsing certain types of ward/stake details).

Anyway, we are nearing the end of this -- And, in SOME cases, the use of our server is still required to complete an update (the network trace given in the example shows that his particular instance was 100% through our service -- but that's not the case for the most of the users of v1.41 at this point).

Given that it looks like we have a competitor actively monitoring the thread, and this reply will likely end up there, I would prefer not to disclose more than that. But I can confidently say that we have properly solved both of the problems I mentioned above. The updates are still extremely fast, and we can respond effectively and quickly to changes in the LUWS.

For now, in the cases where the use of our server is still required to perform a complete update, absolutely NOTHING is stored on our servers. I (and we) have absolutely no intention of harvesting, data-mining, or collecting information -- not even in log format. Further, all communications are done over SSL, and they're fully encrypted.

Our goal is to comply with church policies and still maintain the usability and durability of the application, and for the most part, we're there. By the time we get our next release out the door, we should be 100% compliant.

Hopefully, this helps to clear up some of the confusion.

Thanks,

Brian

I have some reaction to this, which I will probably post later. But for now, I will let the facts speak for themselves. I don't want to make my own opinions the immediate focus.

[mkmurray]

It is possible the software makes most calls directly to LDS.org for authorization and data download, but calls the Avikey server to get the latest parsing rules.

So a very trusted friend of mine basically replicated calvinrg's results in every respect. Here are his findings:

So I tried the packet monitoring of iWard myself.

I installed Wireshark on my MacBook running OS X 10.5.8 and put the Airport in promiscuous monitor mode. You probably already know this, but promiscuous mode causes the wireless adapter to pick up all traffic on the local network, even if it was intended for a different recipient. Monitor mode causes the wireless adapter to pick up all traffic in the air, even if on a different local network. I then put my iPhone (running OS 3.0.1) in airplane mode, turned on the Wifi, and connected to the wireless router in my house. I verified that I was picking up traffic by using my iPhone to go to a few pages on lds.org that I had never before visited, and watching the traffic appear in Wireshark on my MacBook.

I then started iWard, entered my dad's LDS Account info (so that I would get fresh data... this account had never been used on my iPhone) and tapped update. Once the update completed, I stopped capturing data and sorted the packets by IP. The only external IP that sent or received data during that time was 66.240.210.125 (http://www.avikey.com). Not a peep to or from 216.49.176.34 (secure.lds.org).

So despite their assertions in the email to boomerbubba, they is no visible evidence that they are anywhere near compliance. I can understand having their own proprietary server that hosts on-demand parsing rules for LUWS content, but I don't see how that server needs to play any role besides that, as everything else should really be between the device and secure.lds.org over SSL.

[The_Earl]

And, in SOME cases, the use of our server is still required to complete an update

It appears that a new sync may be one of the cases that MUST go through the third party. I would be interested to see a trace of an update to an install with existing data.

I think until we have some corroborative information from an independent source, we can still be skeptical. Avikey seems headed in the right direction, but any course other than that in the email is likely the kiss-of-death for the application.

The Earl

[RossEvans]

I have replied to Avikey's latest response to me above, but in language that is probably not nice enough for the prevailing standards of this forum to quote in its entirety.

The gist of my reaction it that I think Avikey had an obligation to disclose the facts about its true architecture all along to its users and potential users. Up until three days ago, I was actively recommending the app to others, including my own bishop. I never would have done so if I had known the true facts. My negative opinion about this matter is not limited to the particular email response I got from their support person yesterday.

I also am surprised to read the assertion that the Church has been giving its permission for this architecture privately.

The issues raised about the practical problems posed for third-party developers are more than interesting, they are very important. But I think that really deserves its own thread.