Wait for OCID download before start CID check
He3556 opened this issue · 24 comments
The CID detection is running before there is OCID data to check it against. We need to wait until the db is downloaded before we check the CID against the data of OpenCellID. Otherwise we get a wrong alert just right after the installation. Maybe we use a flag, that is changed when the DB download is finished? But only the CID check needs to get stopped not the changing LAC detection. There are many possible ways to fix it.
But I would prefer to run a wizard at the first start, after installing the App. Then we can assist users to get the OCID key and download the OCID data (if they want). We get everything ready so the app can do its job. Described here #181
Quick question: Shouldn't the yellow CID warning disappear once the OpenCellID data has been successfully downloaded? On my phone, the yellow flag persists even after a successful download. Just wanting to make sure I'm not constantly booked into a honeypot or something. Feeling monitored and thus a little paranoid as well.
I think you're confusing this (CID) issue with the changing LAC one.
No, I don't think so. I am running build 20 and @He3556 opened this Issue right after we've discovered and discussed it in the internal rooms: The Cell ID does not exist in the OCID database.
Otherwise we get a wrong alert just right after the installation.
That is exactly what both of us are experiencing - and for me it stays after downloading the OCID DB.
I have the same problem. So if you can pinpoint me to the code that is doing the CID check, I can have a look at it.
It used to be here:
https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/blob/229e1f84b65e25374293a563006653b0df62a219/app/src/main/java/com/SecUpwN/AIMSICD/adapters/AIMSICDDbAdapter.java#L299
But since 2015-01-19, we have the detection here:
https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/blob/6c492fc1598749bccce0554d78547311c6592a18/app/src/main/java/com/SecUpwN/AIMSICD/service/CellTracker.java#L758
We should also copy the logcat from the old position to the new. Also the insert Cell should be deleted (Like you wrote in the comment there (the first link = old position) the 2. Link is the new position)
Yes, this lines made their job pretty good but we don't need them anymore.
I was testing the App today, while i was driving around. After leaving a 15km radius i had to manually download more towers, because i had the CellID detection (Bug) again. Maybe we need to think about a automated downloading in the background. Maybe after leaving a 5km radius?
Maybe we need to think about a automated downloading in the background.
That would mean we'd have to have internet connection enabled. Not good. What happpens if it is disabled? People would still drive home and file a bug report or tell that they "detected something".
Maybe after leaving a 5km radius?
Not sure if there is a way of downloading a larger part of the database, maybe for the whole country?
Maybe we need to think about a automated downloading in the background. Maybe after leaving a 5km radius?
Great idea. But this brings us straight to #303. As we've already discussed in the past, we should not expect to have good detections without false-positives when moving around. But the data need to be there. But there is no sensible or decent way to download all the BTSs from a whole country, so we have to take it piece by piece.
The sad thing is, they already have it their API. But only if our APP would contribute data to them. http://wiki.opencellid.org/wiki/API#Getting_the_list_of_cells_in_a_specified_area
Strange. I wonder why I still get the warning Cell ID does not exist in OpenCellID Database even though I've downloaded it. Is anyone experiencing the same on internal build 26?
I think it is better to keep it (talking about the bug) all in one place.
For getting the cells of the area, we can use the BBOX thing. The automatic download (when the location is changed) itself is not implemented. Well, i would rather download to much cells than less cell towers.
But ok, when the radius is smaller, than we have to check more often if the location of the user has changed. Can we use another check that runs from time to time and add this code?
If you use 1 km radius we had to check every 5 minutes? Still not often enough when you are in a car, i am afraid.
Another problem can be, if we are starting to delete entities in the downloaded OCID DB. We need all CellIDs we can get from this db. I think this clear to all of you. I just wanted to remind you
Well it seem that the discussion is constantly regressing to "I'm driving around in my car and I'd like to detect a false BTS." This is not possible, unless we implement ALL the detection from the list. So if you wanna be able to do anything at all right now, we'll have to stay put, and not leave the CID/LAC on purpose, which is exactly what you do when driving around. Also what you describe is not a bug, it's simply not implemented, which is why we should open a new issue.
The same LAC? How do you know the cell 100m away has the the same LAC or maybe not? Maybe another local area code starts right there.
That is no argument.
And sorry but the yellow alarm when the db is not downloaded looks like a bug for the users - and we can not tell the people they are not allowed to change the area when the app is running.
@E3V3A, I am afraid that I have to reopen this Issue as it seems to be present again in our latest internal build 30. Maybe @KaiRenken can have a look at this Issue which prevents our new release?
What are you talking about. It's not present. Send screen shot please!
I can't see it either. I've tried the app from testroom.
What are you talking about. It's not present. Send screen shot please!
@E3V3A, why do I need to send you a screenshot? Upon a fresh install, build 31 instantly turn yellow - and it doesn't change when downloading the OCID DB after it turned yellow either. Just believe me?
EDIT: @E3V3A and @KaiRenken, I'm eating my broom right now. Restarted phone and it works. 🌴
Hmm, that it nevertheless funny behavior. Probably because the flag we use, are still in your system until next reboot. Which is why we need to use SharedPreferences instead of a system property via shell, to ensure it gets wiped after app removal.