Shared publicly  - 
 
Niantic have just released an update to the standard intel site. However, due to recent improvements in the code, IITC successfully auto-detects the minor changes and continues to work.

For IITC Desktop, you will need to reload the intel page. If you still have issues, try clearing your browser cache.

However, IITC Mobile may not pick up the changes by default. If IITC Mobile fails to load, do the following:

"go to settings, then advanced settings (last item), set 'aggressive caching' to 'never'. Go back to the map, wait for the reload to complete, then change back the caching setting."
162
40
IITC's profile photoВиктор Виноградов (Fly33)'s profile photoMike Castle (Nexus)'s profile photoJonas Jerner's profile photo
35 comments
 
Hahaha! You guys are like the south park parody of Steve Irwin: "Now I'll stick my thumb right up 'is butthole. That'll really piss 'im off!"
 
Ah, so that's why I had some errors earlier this evening. I thought it was just another minor intel server error, because it worked again after the reload. Silly me. :)
 
Soon IITC will gain sentience and trigger the robot revolution
 
+IITC I opened an issue on Github. Can you see what else was changed?
IITC
+
5
6
5
 
Looks like bug fixes only on the standard intel site - capture date, mod tab on portal info, and a fix in their caching code. Nothing we need to make changes for as far as I can see.
Mike N.
+
2
3
2
 
Nice work, gents!
 
capture date on page load or portal load?

If page load, does that mean it could be added back to portal-list?
 
Portal load. Won't return to portals list
 
Ahh.  I'd heard that it not showing up on the page load was a bug and thought they'd fixed it.  Darn.
 
Never mind, I misread the other discussion and makes sense now.

Still, darn.
 
+Billy Wheeler As far as I understand, people were only banned because their accounts pretty much attacked Niantic servers. When Niantic servers changed their data model, IITC mobile went all bonkers and started flooding the server. Niantic responded to the attack by banning. (As they should to protect the game for the rest of us that aren't accidentally trying to shut it down.)

So it wasn't the idea of using IITC that caused the ban, it was the fact that IITC's seriously screwed up code caused you to unknownigly attack Niantic.

Therefore, if IITC says they've fixed the issue, then used of IITC should no longer cause bans.

Frankly, though, I wouldn't trust their fixes much after such a screwup. When you're creating a thrid-party service that is againt the ToS, you should always start by writing some pretty heavy safeguards to protect against instances like this. The fact that they didn't have such safeguards in place makes me wonder if there are other remaining situations that could cause this to happen again.
 
+Ilari Kajaste Software is always just as good as those who develop it. Making mistakes is human. Nobody's perfect. And how are you going to prevent situations that you don't know? Nobody knows what Niantic will do next with their Intel API. They don't publish a specification that we can use. We look at the stock map and reverse engineer that. Every time the stock map changes, we need some time to adopt IITC to these changes.
 
+Felix Kloft As I said, when writing sensitive software, you start by building safeguards in place. For example, make every possible action visible to Niantic go through an independent process that will make sure they are within safeguard limits, and will deny further requests. And always fail fast - when the code notices something is wrong (e.g. unable to understand data), it signals the safeguards to stop immediately.

That way, when something breaks, the system shuts down. IITC becomes unavailable to users until fixed, but nothing more.

Yes, there will always be bugs, but you can prepare for them even if you don't know what they will be. Of course, there could also be a bug in the safeguard system as well, anything is possible, but that is a lot, lot less likely if the safeguard is kept as simple as possible.
 
Actually, IITC has these safeguards. It checks whether the munge set is still correct. If not, it tries to get a fresh munge set from the stock code. If that fails, it should throw an error and stop booting. But for some reasons, the mobile version went crazy and didn't abort. Unfortunately, the mobile code is a heavy mixture of java and JavaScript and nearly impossible to debug (at least the JavaScript part, which does most of the work). Also, everything is running with android's WebView, which has a lot of quirks and sometimes reacts completely unpredictable.
 
+Felix Kloft Alright, so it was then the unlikely case that the safegurads did fail. I stand corrected.

Thanks, that's good to know!
IITC
 
+Ilari Kajaste It is much safer now than it was. However, I'm not actually convinced the problem was caused by excessive requests - rather, I think we triggered an alarm in the backend for 'unusual requests', this 'unusual' is brought to the attention of the support team, and was treated as 'excessive requests'.

And why were they unusual? IITC at the time fell back to a old munge set, due to one piece of legacy code left over from the initial implementation of munging. At the time the munge sets were changing between a few in a set, so if IITC couldn't auto-detect the correct one, it would just try each in turn until it worked. Niantic later gave up alternating them, so the code that cycled to the next had been removed. But, by mistake, it still defaulted to the first in the list when it failed to detect the active one.

Safeguards in place now:
1. no defaulting to a default munge set if it fails to find which one is in use
2. old munge sets removed from the code when new ones added.
IITC
 
.. and
3. reduced the tile retry count from 4 to 1, and increased the retry delay from 5 to 10 seconds - just in case excessive requests was the real reason

Unlikely though, as it was only mobile users, not desktop - and both have the same retry behaviour.
 
+IITC Interesting. If that is the case, the bans were very much an overreaction. (Well, anything above a short suspension was overreaction, really.)

Has the mobile connection been verified, or is it possible desktop users were affected too? Did the old munge set bug only affect mobile version?

I wouldn't be surprised if repeated malformed requests made the cheat alarms go wild.
IITC
+
1
2
1
 
The mobile connection was what was reported - it's not something I tried myself though ("do X, you get insta-banned" wasn't something I risked testing).

The munge set bug was the same for desktop and mobile, yes. And desktop, being larger screens, generally sends more requests too. Maybe it was something else that triggered the bans, but with Niantic being silent on ban reasons we can never be sure.
 
Yes. I absolutely abhor the never-tell-anything policies of these companies. Unfortunately we just have to learn to live with them. But they really are disgusting.
 
I get 0.10.1 stop on my phone. I have it 2 times but it is a small bug.
Add a comment...