Infinite loop on phones with IM -> text capabilities

[GoogleCodeExporter]

(I'll post the applog when it happens again)

If you have your phone set up to receive IMs in the form of text messages when 
you go offline, gtalkSMS will go into an infinite feedback loop with itself 
after sending any sort of message.

Feedback loop:
1. My AIM account goes offline
2. gtalkSMS sends my AIM account a message (in this case: "Battery level 100%")
3. AIM sees that I am offline and forwards my message to my phone (in the form 
of a text message)
4. It pings on my phone
5. gtalkSMS sends me an IM to my offline account telling me that I got a text
6. AIM sees that I am offline and forwards my message to my phone
7. It pings on my phone
8. gtalkSMS sends me an IM to my offline account telling me that I got a text
9. AIM sees that I am offline and forwards my message to my phone
10. It pings on my phone
11. gtalkSMS sends me an IM to my offline account telling me that I got a text
 ... et al ...

To rectify the situation, one must log back in to their account (SOL if you're 
not around your computer!) to stop the message spam (which may lock up some 
phones) and then block the AIM contact from sending messages to said phone 
(ironically, accomplished by sending a text to AIM).

Additional informations:
IM service in question: AIM (Google and AOL have been playing nice with 
eachother)
Phone model: HTC Glacier (MyTouch 4G)

Original issue reported on code.google.com by trefight...@gmail.com on 14 Aug 2011 at 11:27

• Blocked on: Constant loop-back if using GTalk also. #43

[GoogleCodeExporter]

AppLog:

GTalkSMS Preferences
notifiedAddress: tre***********@aol.com
useDifferentAccount: true
useGoogleMapUrl: true
locale: default
smsMagicWord: GTalkSMS
manuallySpecifyServerSettings: true
batteryNotificationInterval: 20
serviceName: gmail.com
startAtBoot: true
showStatusIcon: true
markSmsReadOnReply: true
useCompression: false
notifyBatteryInStatus: true
notificationIncomingSmsType: same
notifyInMuc: true
login: x********e@gmail.com
ringtone: content://media/external/audio/media/216
displayIconIndex: 0
smsReplySeparate: true
startOnPowerConnected: true
startOnWifiConnected: true
notifySmsDelivered: false
xmppSecurityMode: opt
debugLog: true
smsNumber: 15
connectOnMainscreenShow: true
notifySmsSent: true
callLogsNumber: 10
roomPassword: gtalksms
serverHost: talk.google.com
showSentSms: true
serverPort: 5222
mucServer: conference.jwchat.org
notifyApplicationConnection: true
notifyBattery: true
notifyIncomingCalls: true

GTalkSMS Version: 3.1
Android API: 8
Kernel info: 2.6.32.21-g899d047
htc-kernel@and18-2 )
#1 PREEMPT Tue Oct 26 16:10:01 CST 2010

--------- beginning of /dev/log/system
--------- beginning of /dev/log/main
08-14 18:42:21.947 I/gtalksms( 7525): Update presence: 
2owlhavp9wowi@id.talk.google.com - Offline
08-14 18:42:21.947 I/gtalksms( 7525): Update presence: tre***********@aol.com - 
Online

Original comment by trefight...@gmail.com on 14 Aug 2011 at 11:46

[GoogleCodeExporter]

Ok, a nice feedback loop, two notification mechanisms chained together. You 
could disable the battery notifications, but I this won't solve the underlying 
problem.
How to you suggest that we solve this? Blacklist some phone numbers?

Original comment by fschm...@gmail.com on 15 Aug 2011 at 9:10

[GoogleCodeExporter]

That was the first thought that came to my mind: blacklist the AIM short codes, 
but upon further investigation it looks like either AIM changes short-codes 
every now and then or it has a crap-load of them under its dominion. So vanilla 
blacklisting wouldn't work.

I also through about just warning users to disable IM->text capabilities, but 
that just seems so draconian. I'd save that as a last resort.

I do not develop on the Android platform all that often (yet), but I'm pretty 
sure that most of the following solution(s) would be feasible whilst 
maintaining gtalkSMS's amazingly minuscule use of battery life. They're all 
based on some sort of feedback loop detection (which could be turned off or 
"customized" by the end user, of course).

To accomplish such protection, one could:

1. Attach some sort of hidden identifier in the form of an "invisible hand" to 
outgoing messages (I'm not sure how the SMS/MMS or XMPP protocols work, but 
this would definitely be a viable solution with the HTTP protocol xP). Use this 
identifier w/ #3 down there and be *sure* that the message is being looped from 
gtalkSMS and not some person spamming their heart out. -- not sure of its 
feasibility.

2. Scan incoming messages and compare them to the messages gtalkSMS sends out 
using statistics/heuristics to determine an acceptable level of similarity. If 
a message arrives that is deemed "too similar," trigger some sort of feedback 
loop prevention in the form of temporary blockage or blacklisting. Of course, 
such a blacklist would be manipulable from the end-user perspective 
(add/delete/edit entries). -- would work instantly, but might misfire if 
someone sends a message that looks too similar to a gtalkSMS response/alert.

3. Keep track of the frequency of the messages received, and if messages are 
determined to be coming in from the same source too frequently, trigger the 
feedback loop prevention. This "prevention" would include the ability for the 
user to disable it when it activates; e.g. "possible blah blah feedback loop 
detected blah blah. Click this button to ignore (or something)." This would be 
in the form of a popup of some kind, and in the interim between the message 
popping up and the button press, incoming/outgoing messages would be throttled 
(so the phone wouldn't lock up). -- would probably work the best, but it 
wouldn't work instantly. The user's phone would already have sent/received for 
a bit before the "feedback loop" status of the correspondence could be 
determined. Scary.

4. Some combination of the aforementioned.

Not really sure (again, I don't dev Android), but hopefully I sparked some 
bright ideas? :)

Original comment by trefight...@gmail.com on 15 Aug 2011 at 6:02

[GoogleCodeExporter]

I am going to add an resource filter, which will for example filter out Android 
resources. If the filter turns out to be practicable, well could extend that 
for this issue also.

Original comment by fschm...@gmail.com on 9 Nov 2011 at 9:54

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by fschm...@gmail.com on 1 Dec 2011 at 5:35

• Changed state: Fixed

[GoogleCodeExporter]

Fixed and deployed with GTalkSMS 3.4

Original comment by Florent....@gmail.com on 7 Jan 2012 at 3:20

• Changed state: Deployed