Open SecUpwN opened 10 years ago
Sound great, but this is just eye-candy (well at least, ear-candy.) Let's stay focused on the core functionality.
@E3V3A, you're right: Ear-candy to be added after implementation of ciphering indicator detection later.
Yesterday there was a scandal here in Sweden. Someone had set up an IMSI-catcher and was catching all the cellphone traffic in Rosenbad. (That's Sweden's equivalent to the US white house, congress and senate put into one house.)
Adding an alarm option which alerts the user when an IMSI-catcher is within range would probably be a useful feature.
I have a role in an organisation which support society, for example, during natural disasters. When a natural disaster hits criminal gangs often run rampant. If it is not too complicated to build an IMSI-catcher, one such gang might build catchers and spy on the off duty cellphone traffic of the staff from this organisation, in order to make the crime campaigns they launch more profitable. I deal with communications and information security in that organisation. To me an IMSI-catcher alarm would be very useful.
If the audio alert is trivial to implement, then let's do it.
@E3V3A, I propose to rename Interface Settings
from within the Preferences
to Notifications
and add an additional button named IMSI-Catcher Alarm
below Icons
. Through the new button users should be able to chose their own alarm sound as well as set a vibrational pattern if no sound is wanted. @Heralda, how do you like that approach? Anything to add?
This might be relevant here, when looking into merging icon behavior to use the same icon everywhere based on current status i noticed that there are not implemented any ways to send events/notifications between classes, so all alarm handing is now done from a single class (correct me if im wrong!), instead of every detector sending an alarm event which is then handled by a dedicated "alarm handler":
Any thought/suggestions? Is there a dedicated Android-API for doing such event handling, or is it better to try static classes/Singletons etc?
It depends on what the developer intended that function to be. I think that better describe a detection event, which is later added up to determine what alarm to present. (yellow, orange, red, etc)
Folks, please have a look at the OP and tell me if you agree with that or have further suggestions.
I agree, and putting a very short vibration for newly updated/connected cells should be trivial.
Taken from https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/pull/593#commitcomment-12484913:
Unfortunately still lacks the option audible indication when capturing an alarm. From the orange icons or higher...
@AntiDiesel, instead of bashing into our proud release, how about crafting a pull request to solve this?
I've already partially implemented vibration for new events, but it needs expansion. Then the concept code for a NOTIFICATION
type sound would be:
try {
Uri notification = RingtoneManager.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION);
Ringtone r = RingtoneManager.getRingtone(getApplicationContext(), notification);
r.play();
} catch (Exception e) {
e.printStackTrace();
}
However, we may prefer to have some kind of very short and subtle bleep or pling instead, which would require MediaPlayer instead, and using a pre-made mp3 file.
Uri notification = RingtoneManager.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION);
MediaPlayer mp = MediaPlayer.create(getApplicationContext(), notification);
mp.start();
This is better than using Ringtone, and prevents interrupting other sounds or music that might already be playing in the background.
Yet another version..
However, we may prefer to have some kind of very short and subtle bleep or pling instead, which would require MediaPlayer instead, and using a pre-made mp3 file.
Please do NOT add a pre-made MP3 file into our app, it's bloatware. I prefer to generate the changeable bleep or pling. Looking into IMCKTG, RingCode and Androidomatic Keyer is a good start and maybe @achromaticmetaphor, @bfix and @sussman can help us with solving this Issue? ;-)
Well, the default notifications are mp3, no?
Well, the default notifications are mp3, no?
Yes. But I'd like to avoid shipping any MP3s with our app, rather add code to generate a tone by tapping the screen or enable the user to select a tone from his device to avoid bloating our app.
Re-opening this Issue since I consider it an important core feature. Maybe @smarek can have a look?
EDIT: Fine-tuned vibration settings have already been added with https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/commit/25616a0fc0d185aa9e07c92ee5abddb0094ff4fd and all that would be left is to add a menu entry named Sound on threat level
within the NOTIFICATION SETTINGS
where the user could chose any sounds he wants to be played on each alarm. This would finally solve this Issue.
I'd like a really annoying alert when the app detects potential danger. I imagine something comparable to an alarm clock or an incoming phone call. Definitely some persistent sound+vibration that the user has to actively confirm, not just a single "beep" or short vibration. Of course, the user should be able to adjust that option (eg. only activate alert at higher risk levels etc.).
I'm very interested in this project and just forked your code to dig deeper into it.
I did some research and it seems like what I have in mind has to do with a KeyguardManager.KeyguardLock and the PowerManager flag ACQUIRE_CAUSES_WAKEUP. I will investigate and see, if I can maybe create a class, that creates such an alert.
I did a small mockup of how I'd imagine the alert:
The Arrow thingy at the bottom is kind of a slider that the user has to pull aside to stop the alert.
I'm very interested in this project and just forked your code to dig deeper into it.
Welcome to our project and thanks for forking us, @vanitasvitae!
I'd like a really annoying alert when the app detects potential danger.
Since @larsgrefer has modifies our notifications before to make them less obtrusive, I'd like to hear his opinion on this. Generally speaking, I like your idea. But maybe making obtrusiveness an option is better?
Thank you @SecUpwN . Indeed it would be cool to have a checkbox or something in the settings of the app to change notification modes.
I wanted to say that it has been quite some time since I actively did something for Android and I have to do quite some reading before I can contribute code. Also I am very busy right now with exams, so don't expect some outcomes in the very near future :)
I wanted to say that it has been quite some time since I actively did something for Android and I have to do quite some reading before I can contribute code.
Don't worry. If you see how slow we're currently moving, literally any contribution is a small life saver.
Also I am very busy right now with exams, so don't expect some outcomes in the very near future :)
Take your time and contribute whenever you feel like your coffee is making you enthusiastic enough. ;-)
Aside the visual notification of the current ciphering status, I would like AIMSICD to feature a submenu in the settings for enabling a (custom) vibrational pattern or a sound file to be chosen by the user that fires off once an attack of an IMSI-Catcher takes place. A standard subtle vibration pattern shall be included.
UPDATE - Here is the summary of what this Issue shall accomplish:
Preferences/PROTECTION SETTINGS
calledDetection Alarms
MEDIUM
,HIGH
,DANGEROUS
andRUN!
users shall be able to both:To clarify: The user navigates to
Preferences
, hits the buttonDetection Alarams
underPROTECTION SETTINGS
and finds 4 buttons (no alarm onIDLE
andNORMAL
) to set the above alarms. Furthermore, we would appreciate a very short vibration for newly updated/connected cells.:warning: We would like to avoid including tones or any sound files with our app, they just makes it larger.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.