Tech Forum Archive

"iWard" iPhone App

44 postsstarted by Mr.Intel-p40 20,909 viewsoriginal topic

Mr.Intel-p40
New Member
#1
There is a new app called "iWard" that allows members to import data from the LUWS with their individual logins. As far as I can tell, the data is sent over the internet just as if it were coming into a browser, only stored on the iPhone for later use.


Edit by Alan_Brown: Moved this portion of the original post to a new thread, since it deals with a different topic.
Bekins
New Member
#2
I was shown the I-Ward app last Sunday and it is very useful. It links to the ward website and downloads the data into the person personal I-phone. It does not have ages, MIR#, baptism information or priesthood. However, it does list the leadership from the ward website and will allow the built-in GPS to map from your location to a members home. For me in a ward covering four stakes, such an app would be highly useful. I hope this is not blocked as it would be very helpful to network with other members of the ward and stake.
Brent R. Ekins
Ward Clerk
Finance Clerk
Pioneer Park (Hmong) Ward
garysturn
Senior Member
#3
brekins wrote:I was shown the I-Ward app last Sunday and it is very useful. It links to the ward website and downloads the data into the person personal I-phone. It does not have ages, MIR#, baptism information or priesthood. However, it does list the leadership from the ward website and will allow the built-in GPS to map from your location to a members home. For me in a ward covering four stakes, such an app would be highly useful. I hope this is not blocked as it would be very helpful to network with other members of the ward and stake.
iWard is not the application being discussed in this post's original thread ("Ward List" iPhone App). The app being discussed there is Ward List which pulls its list from MLS. iWard does not pull from the MLS but from your Ward web site which you already have access to from any computer over the internet. I don't know if that is considered improper or not to download that info.
Gary Turner
If you haven't already, please take a moment to review our new Code of Conduct
russellhltn
Community Administrator
#4
GarysTurn wrote:I don't know if that is considered improper or not to download that info.
Downloading - no. The question is where is it sent next and how well is it secured?

If it's uploaded somewhere such as a server - that's a no-no. I would hope the information is secured in such a way to make easy access by anyone who finds a lost phone difficult.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
auslinford
New Member
#5

iStake

The iStake app is GREAT.
Khall-p40
New Member
#6

IStake/IWard

A friend of mine with an Iphone was showing me this app the other day. It indeed downloads info from the stake/ward website and not from MLS. Since I use a blackberry, I'd love to see the development expand to that platform also. It's certainly very handy.
PaulRobichaux-p40
New Member
#7
alinford wrote:The iStake app is GREAT.
I agree completely-- I just saw it mentioned here and rushed to check it out on the App Store. Nicely designed, fairly fast, and oh so handy. Now the next time my wife, the stake RS secretary, calls me to ask if I have someone's phone number the answer will be "yes!" (Actually I might just buy her a copy for her iPhone instead.)
jeff.larson-p40
New Member
#8

blackberry Storm iward/istake development?

I was wondering if anyone knows if there is any plans to develop iward and istake for the Blackberry storm? I would appreciate any information on this.
jeff.larson-p40
New Member
#9
Khall wrote:A friend of mine with an Iphone was showing me this app the other day. It indeed downloads info from the stake/ward website and not from MLS. Since I use a blackberry, I'd love to see the development expand to that platform also. It's certainly very handy.
Anything on this? I would love to see something for the storm as well.
bmoio-p40
New Member
#10

iStake --- similar for Blackberry

Is there anything similar to iStake for Blackberrys?
Thank you
michael.d.benton
New Member
#11
I emailed back and forth with Avikey and the latest as of October 30th is that they are working on the app for BlackBerry and expect to have it out in a couple weeks.

Michael
sfazen-p40
New Member
#12

iStake-like app for the Blackberry?

Has anyone heard anything about (or created one) an iStake-type application for the Blackberry? This would be very useful. Many thanks!
dicecreaman-p40
New Member
#13
I sent in a request to Avikey the app's maker and they said it would probably be a couple of weeks before it was ready for the blackberry. That was reported to me in an email at the end of November.

David
RossEvans
Senior Member
#14

Is iWard processing on Third Party servers?

My impression from reading this thread and related threads here about the iWard and iStake apps has always been that these apps merely connected the user's device directly to LUWS as a browser-client and downloaded the directory data to the handheld.

Now I am not at all sure that is the case. I have seen a reportthat iWard connects to the vendor's own servers, which in turn connect to LUWS using the user's logon credentials. I have just sent the vendor, Avikey, an email inquiring about this. Does anyone have detailed knowledge about this one way or another?
RossEvans
Senior Member
#15
boomerbubba wrote:I have just sent the vendor, Avikey, an email inquiring about this. Does anyone have detailed knowledge about this one way or another?

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.
LakeyTW
Member
#16
boomerbubba wrote:My impression from reading this thread and related threads here about the iWard and iStake apps has always been that these apps merely connected the user's device directly to LUWS as a browser-client and downloaded the directory data to the handheld.

Now I am not at all sure that is the case. I have seen a reportthat iWard connects to the vendor's own servers, which in turn connect to LUWS using the user's logon credentials. I have just sent the vendor, Avikey, an email inquiring about this. Does anyone have detailed knowledge about this one way or another?
That is my understanding as well. You actually send your user credentials to Avikey and they use them to access your unit website.
Flandry-p40
New Member
#17
Reading the linked discussion on google groups and this thread gives me the heeby-jeebies. When i consider all the special instructions i was given as a membership clerk to sanitize our ward directory of various sisters' names and contact information due to stalking problems, that these apps are used by leaders and not strictly forbidden by policy is shocking.

One would hope that the membership information in the ward web page would be clear of such information already (thing which i have not tried to verify), but regardless of that, it just seems irresponsible to carry around such a comprehensive set of information about members on a computer without any security arrangements. The only way i could see such an app being acceptable is if it
  1. used an official church-provided tool to download the data securely, using the user's login via interactive prompt
  2. said tool encrypts this local data archive according to a user-provided password
  3. each invocation of an app that accesses the data requires a password that should not be saved in the app (this is IMO the only appropriate place to allow trust that an app developer will follow policy)
Is this member data security nightmare just a temporary artifact of the time it takes to get policy decisions through a large organization, or does the church IT dept. really not care about this?
RossEvans
Senior Member
#18

Look at the new MyWard / MyStakeapp instead

lakeytw wrote:That is my understanding as well. You actually send your user credentials to Avikey and they use them to access your unit website.

I have recently heard about a new and different iPhone app called MyWard, which has functionality similar to iWard/iStake but apparently without the issues raised about the latter.

(Note: This may be confusing, because there already is a very different product also called "MyWard,"which uses MLS data and has nothing to do with this matter.)

In any case, I have been assured by the developers of the new MyWard app that it does make its secure connection directly to lds.org from the user's device. And I have been told of independent testing that confirms this empirically: Traces of the SSL connection go from the phone to lds.org.

As for Avikey, the iWard developer, I sent them a followup message last night asking specifically if their server connects to lds.org, rather than the iPhone client. I have received no reply, and the empirical tests results I have seen seem to show that the iPhone connects only to Avikey's domain.

Frankly, at this point, I feel like I have been misled about Avikey's products, and I feel bad that I have recommended them to users. I now see that a strict reading of Avikey's website can be parsed to encompass what the real architecture is. But that is certainly not the impression that I had before from reading that site or reviews in the LDS community.

So I would recommend against iWard/iStake, and suggest that users investigate MyWard from truestarapps.com instead. (Just to clarify, the app is called MyWard but it apparently also includes the stake functionality.)
lajackson
Community Moderators
#19
Flandry wrote:Reading the linked discussion on google groups and this thread gives me the heeby-jeebies. When i consider all the special instructions i was given as a membership clerk . . .

Is this member data security nightmare just a temporary artifact of the time it takes to get policy decisions through a large organization, or does the church IT dept. really not care about this?
The Church IT department cares very deeply about this. Yes, these are very changing times. And it does take some time to get policy decisions through a large organization.

However, the policy is actually in place, and this particular very large organization is not in the business of providing detailed day to day instructions on living our lives. The Church teaches principles, and then we do as Joseph said.

There are policies in place relating to the use third party servers, and leaders have very specific instructions about securing any information that comes out of MLS and goes onto their personal devices, including passwording, protecting, using only for callings, and removing it when they are released. You have outlined some of them in your post.

The challenge I see is that there are many who seek convenience over the care that should be given to protect membership information. The current policy, as I understand it, points to protection before convenience.

And that inconveniences some who do not wish to be inconvenienced in that manner.

The Israelites had the same problem when Moses led them out of Egypt. We just have different toys today. [grin]
RossEvans
Senior Member
#20
lajackson wrote:There are policies in place relating to the use third party servers, and leaders have very specific instructions about securing any information that comes out of MLS and goes onto their personal devices, including passwording, protecting, using only for callings, and removing it when they are released. You have outlined some of them in your post.

The particular case of iWard/iStake is not necessarily a matter of knowingly choosing to disregard policy. And it does not affect only leaders, but also rank-and-file members. The immediate information in question is not MLS content, but LUWS content -- plus two very significant pieces of data: the LDS Account username and password of the user. That notwithstanding the fact that the LDS Account Conditions of Use say (emphasis in original):

You may not share your LDS Account password with anyone.
I rather suspect that most users of this product are not even aware of how it really functions. I was not until about 24 hours ago, and I am probably better informed than most non-technical members. The very cleverly worded PR of the site obscures these facts, IMHO, if only by omission and ambiguity. 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. The website says:
All of the data exchanged between your device and LDS.org is done over encrypted SSL connections and we don't store or view any of your information our servers (or anyone else's servers, for that matter).
Note the "s" in "connections."

(I actually have never used the product because I don't happen to be an iHead. But if I owned an iPhone I probably would have done so in ignorance of the technical facts. While misunderstanding these facts, I have referred other users to the app. Actually, it was while doing so in another forum last night that I learned what I wish I had known earlier.)

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. And I know from anecdotal comments in this forum and elsewhere that many stake leaders use iStake.

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.
jbh001
Senior Member
#21
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.
RossEvans
Senior Member
#22
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.
jbh001
Senior Member
#23
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.
jbh001
Senior Member
#24
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.
RossEvans
Senior Member
#25
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.:))
LakeyTW
Member
#26
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
RossEvans
Senior Member
#27
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.
jbh001
Senior Member
#28
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.
jbh001
Senior Member
#29
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.
RossEvans
Senior Member
#30
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.
mkmurray
Senior Member
#31
boomerbubba wrote:(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
Senior Member
#32
mkmurray wrote: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
Senior Member
#33
boomerbubba wrote: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
Senior Member
#34
boomerbubba wrote: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
Senior Member
#35
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
New Member
#36
Sorry I haven't responded earlier, let me see if I can clear up some things.
jbh001 wrote: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
Senior Member
#37
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
Senior Member
#38
mkmurray wrote: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
Member
#39

Test updates

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
Senior Member
#40
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.
michael.d.benton
New Member
#41

iStake Released for BlackBerry

Got this email about four days ago...sorry I didn't post it sooner. So far it works great on my Storm.

Michael

Greetings,

Great news.. I'm sending you this email because a while back, you asked about a Blackberry version of iStake.

I'm happy to announce that iStake for the Blackberry is now available!! The Blackberry version includes all of the same features you're used to on the iPhone side -- including one additional treat: You can copy ward and stake events straight to your Blackberry calendar (no need to use google or other third party services).

If you've got a touch-screen Blackberry Storm, you'll be thrilled to know that iStake for Blackberry looks and feels nearly identical to the iPhone version. If you've got a traditional Blackberry, you'll find the app super intuitive and easy to use.

Please visit http://www.avikey.com/blackberry/ to purchase the app. Installation is easy, and you can be up and running in a few short minutes.

Thanks!

Brian
RossEvans
Senior Member
#42
michael.d.benton wrote:Got this email about four days ago...sorry I didn't post it sooner. So far it works great on my Storm.

Michael

I wonder how the LDS Account login, data flow and processing are being handled on the Blackberry version, and if those methods are any different from the flawed methods used for the iPhone and described upthread.

Interestingly, Avikey's website uses different language in its claims about that subject for the Blackberry and iPhone versions. The relevant language for the Blackberry is:
  • None of your ward / stake information is stored or passed through "third party servers", in accordance with church policy.
  • All communications between your phone and LDS.org are encrypted.
  • Fully compliant with church policy regarding data protection, privacy, and the handling of member information.
For the iPhone, the comparable language still reads this way:
  • Your confidential information is not stored on "third party servers", in accordance with church policy.
  • All communications between your phone and LDS.org are encrypted.
That does not give me any confidence that the security problems for the iPhone version have been cured. But perhaps the Blackberry version is different in the way it processes the content.

From the website, I am unsure about the critical point of whether the LDS Account login to secure.lds.org is made directly and end-to-end from the user's device. The descriptions for the Blackberry and iPhone versions are very similar:
iStake for Blackberry retrieves your ward and stake directories from the LDS.org web-site using your LDS.org username and password.
and for the iPhone:
iStake retrieves your ward and stake directories from the lds.org web-site using your LDS.org username and password.

So without some explicit statement to the contrary, I have to assume that the LDS Account password is still captured, however briefly, by the iPhone version. The Blackberry version may be different. In any case, I would not believe anything without an empirical test.
jbh001
Senior Member
#43
boomerbubba wrote:I wonder how the LDS Account login, data flow and processing are being handled on the Blackberry version, and if those methods are any different from the flawed methods used for the iPhone and described upthread.
I'm curious if this changed for the iPhone too because they recently upgraded the iPhone app to version 2.1. But I have no way to test to see if it is still using its previous method to get the data from the LUWS to the iPhone.
RossEvans
Senior Member
#44
jbh001 wrote:I'm curious if this changed for the iPhone too because they recently upgraded the iPhone app to version 2.1. But I have no way to test to see if it is still using its previous method to get the data from the LUWS to the iPhone.

As far as I am concerned, the vendor has an affirmative obligation to disclose the facts, and should have disclosed the facts all along. You previously quoted from release notes, which are apparently provided to you as a customer or iPhone user. Do the release notes for version 2.1 say the flawed practice has been discontinued? Have you asked Avikey?

The Avikey developer conceded in his Jan. 6 email that the iPhone app's method was not compliant with Church policy, and asserted that it would be made compliant at some point in the future. In my own correspondence with the vendor, I did underscore that I thought they should inform us all if and when that happens.

As of today, the vendor does not even make the same claim for its iPhone product that it does for the Blackberry product: "Fully compliant with church policy regarding data protection, privacy, and the handling of member information." (I'm not even sure if that Blackberry language precludes the LDS Account password being captured anwhere but in the client app or the SSL terminus at secure.lds.org. A Philadelphia lawyer might always argue otherwise because the PR statement does not expressly include that element.)

Absent some express claim that the flaws in the iPhone product have now been cured -- which, given this vendor's history, still would need verification by testing to convince me -- I think the presumption must be that the iPhone version remains non-compliant today. If it ever becomes compliant, the burden is on the vendor to say so.