Introducing Overkill - Don't let iTunes interrupt your workflow

Exactly one year after the initial launch of Overkill as a shell script, after being #1 on ProductHunt, I’m extremely excited to announce that Overkill is now a native Mac app.

Did iTunes ever launch without you opening it? Use Overkill to instantly kill the iTunes process once it opened itself, so your workflow isn’t interrupted.

But Felix, you can use the check box to not launch iTunes when you connect your phone!

Yes, that is correct, but connecting a device to your Mac is only one of the many reasons when iTunes can’t wait to spread joy:

  • You click the play/pause key while listening to a web-based music player (e.g. SoundCloud, YouTube)
  • Someone sent you a link to an iOS app
  • You click on a link on the web, and didn’t expect it to be a Music link
  • You updated iTunes
  • You launch iTunes by clicking on the icon by mistake
  • You open a video/music file in Finder, and forgot to change the default app to VLC
  • You connect Bluetooth headphones

Before Overkill

As you can see in the video above, iTunes would launch while you’re typing something, stealing the window focus, and making this sound we all love to hear.

With Overkill

With Overkill, you connect your iPhone to charge it, and you can still use your Mac.

Introducing Overkill for Mac

Overkill is a simple, elegant Mac app, that runs in the background and makes sure iTunes never interrupts your work. And for those movie nights where you actually want to use iTunes, just click on Pause Overkill and enjoy the evening.

If you have other apps you don’t want to launch automatically (e.g. Photos app), you can add those apps to the Overkill list as well.

No installation required, just download Overkill from the link below, double click the Overkill icon, and you’re good to go!

Download Overkill Mac App

Unfortunately I couldn’t submit Overkill to the Mac App Store, as the sandboxing doesn’t allow the termination of other processes.


  • Runs silently in the background, and kills iTunes
  • Easily pause Overkill if you want to use iTunes
  • Support for both Dark and Light mode of the menu bar
  • Supports auto start
  • Supports any Mac app, e.g. add the Photos app to be killed also
  • No CPU usage, no polling, no analytics, just 300 lines of native Mac code

Additionally, as most of the project I work on, Overkill is 100% open source under the MIT license:

Open on GitHub

Unless otherwise mentioned in the post, those projects are side projects which I work on on weekends and evenings, and are not affiliated with my work or employer.

Tags: itunes, overkill   |   Edit on GitHub

Introducing Major Key - Easily jot down quick notes

How often are you on the run, or hanging out with friends, only to suddenly think of this really important thing you need to do when you’re back home or back at work?

You want to jot down that thought as quickly as possible so you don’t forget, and you want to be reminded whenever you’re back on your computer.

Introducing Major Key, the best key

With far less than 100 lines of Swift code, this simple app does all you need:

  • Unlock phone
  • Launch Major Key 🔑
  • Type the note
  • Confirm

Within a second you’ll have the note in your email inbox. Extremely useful if you follow the inbox zero approach. All with no waiting times or animations.

Launch the app, write down a note, hit the 🔑 button and immediately have the note in your inbox.

Why a new app?

  • Using any kind of Notes app works rather nicely, however involves overhead, and chances are you forget on checking the notes app when you’re back on your Mac.
  • Sending yourself an email with any email client involves extra work, as you need to start typing your email, and you get to see your inbox (similar idea)
  • The IFTTT Notes app was perfect, however it was discontinued, and the new IFTTT app causes problems on the iPhone X due to abusing Web Clips to make it work.

🔑 Major Key is not available in the App Store, but is open source, and super easy to install if you’re a developer. If interest is there, I could also publish the app to the store.

Open on GitHub

Unless otherwise mentioned in the post, those projects are side projects which I work on on weekends and evenings, and are not affiliated with my work or employer.

Tags: notes, ifttt   |   Edit on GitHub

iOS Privacy: watch.user - Access both iPhone cameras any time your app is running


Once you grant an app access to your camera, it can

  • access both the front and the back camera
  • record you at any time the app is in the foreground
  • take pictures and videos without telling you
  • upload the pictures/videos it takes immediately
  • run real-time face recognition to detect facial features or expressions

Have you ever used a social media app while using the bathroom? 🚽

All without indicating that your phone is recording you and your surrounding, no LEDs, no light or any other kind of indication.


This project is a proof of concept and should not be used in production. The goal is to highlight a privacy loophole that can be abused by iOS apps.

What can an iOS app do?

iOS users often grant camera access to an app soon after they download it (e.g. to add an avatar or send a photo). These apps, like a messaging app or any news-feed-based app, can easily track the users face, take pictures, or live stream the front and back camera, without the user’s consent.

  • Get full access to the front and back camera of an iPhone/iPad any time your app is running in the foreground
  • Use the front and the back camera to know what your user is doing right now and where the user is located based on image data
  • Upload random frames of the video stream to your web service, and run a proper face recognition software, which enables you to
    • Find existing photos of the person on the internet
    • Learn how the user looks like and create a 3d model of the user’s face
  • Live stream their camera onto the internet (e.g. while they sit on the toilet), with the recent innovation around faster internet connections, faster processors and more efficient video codecs it’s hard to detect for the average user
  • Estimate the mood of the user based on what you show in your app (e.g. news feed of your app)
  • Detect if the user is on their phone alone, or watching together with a second person
  • Recording stunning video material from bathrooms around the world, using both the front and the back camera, while the user scrolls through a social feed or plays a game
  • Using the new built-in iOS 11 Vision framework, every developer can very easily parse facial features in real-time like the eyes, mouth, and the face frame

How can I protect myself as a user?

There are only a few things you can do:

  • The only real safe way to protect yourself is using camera covers: There is many different covers available, find one that looks nice for you, or use a sticky note (for example).
  • You can revoke camera access for all apps, always use the built-in camera app, and use the image picker of each app to select the photo (which will cause you to run into a problem I described with detect.location).
  • To avoid this as well, the best way is to use Copy & Paste to paste the screenshot into your messaging application. If an app has no copy & paste support, you’ll have to either expose your image library, or your camera.

It’s interesting that many people cover their camera, including Mark Zuckerberg.


How can the root of the problem be fixed, so we don’t have to use camera covers?

  • Offer a way to grant temporary access to the camera (e.g. to take and share one picture with a friend on a messaging app), related to detect.location.
  • Show an icon in the status bar that the camera is active, and force the status bar to be visible whenever an app accesses the camera
  • Add an LED to the iPhone’s camera (both sides) that can’t be worked around by sandboxed apps, which is the elegant solution that the MacBook uses

I reported the issue to Apple with rdar://35116272.

About the demo

I didn’t submit the demo to the App Store; however, you can very easily clone the repo and run it on your own device.

  • You first have to take a picture that gets “posted” on the fake “social network” in the app
    • At this point, you’ve granted full access to both of your cameras every time the app is running
  • You browse through a news feed
  • After a bit of scrolling, you’ll suddenly see pictures of yourself, taken a few seconds ago while you scrolled through the feed
  • You realize you’ve been recorded the whole time, and with it, the app ran a face recognition algorithm to detect facial features.

You might say

Oh, obviously, I never grant camera permissions!

However, if you’re using a messaging service, like Messenger, WhatsApp, Telegram or anything else, chances are high you already granted permission to access both your image library (see detect.location) and your camera. You can check which apps have access to your cameras and photo library by going to Settings > Privacy.

The full source code is available on GitHub.

How does the demo app get access to the camera?

Once you take and post one picture or video via a social network app, you grant full access to the camera, and any time the app is running, the app can use the camera.

What’s the screenshot on the right

As part of iOS 11, there is now an easy to use Vision framework, that allows developers to easily track faces. The screenshot shows that it’s possible to get some basic emotions right, so I wrote a very basic mapping of a user’s face to the corresponding emoji as a proof of concept. You can see the highlighted facial features, and the detected emoji at the bottom.

Similar projects I’ve worked on 

I published more posts on how to access the camera, the user’s location data, their Mac screen and their iCloud password, check out for more.

Special thanks to Soroush, who came up with the initial idea for this write-up.

Open on GitHub

Unless otherwise mentioned in the post, those projects are side projects which I work on on weekends and evenings, and are not affiliated with my work or employer.

Tags: ios, privacy, phishing, camera, video   |   Edit on GitHub

iOS Privacy: steal.password - Easily get the user's Apple ID password, just by asking

Do you want the user’s Apple ID password, to get access to their Apple account, or to try the same email/password combination on different web services? Just ask your users politely, they’ll probably just hand over their credentials, as they’re trained to do so 👌


This is just a proof of concept, phishing attacks are illegal! Don’t use this in any of your apps. The goal of this blog post is to close the loophole that has been there for many years, and hasn’t been addressed yet. For moral reasons, I decided not to include the actual source code of the popup, however it was shockingly easy to replicate the system dialog.

Why does this work?

iOS asks the user for their iTunes password for many reasons, the most common ones are recently installed iOS operating system updates, or iOS apps that are stuck during installation.

As a result, users are trained to just enter their Apple ID password whenever iOS prompts you to do so. However, those popups are not only shown on the lock screen, and the home screen, but also inside random apps, e.g. when they want to access iCloud, GameCenter or In-App-Purchases.

This could easily be abused by any app, just by showing an UIAlertController, that looks exactly like the system dialog.

Even users who know a lot about technology have a hard time detecting that those alerts are phishing attacks.

How can you protect yourself

  • Hit the home button, and see if the app quits:
    • If it closes the app, and with it the dialog, then this was a phishing attack
    • If the dialog and the app are still visible, then it’s a system dialog. The reason for that is that the system dialogs run on a different process, and not as part of any iOS app.
  • Don’t enter your credentials into a popup, instead, dismiss it, and open the Settings app manually. This is the same concept, like you should never click on links on emails, but instead open the website manually
  • If you hit the Cancel button on a dialog, the app still gets access to the content of the password field. Even after entering the first characters, the app probably already has your password.

Initially I thought, faking those alerts requires the app developer to know your email. Turns out, some of those auth popups don’t include the email address, making it even easier for phishing apps to ask for the password.


Modern web browsers already do an excellent job protecting users from phishing attacks. Phishing within mobile apps is a rather new concept, and therefore still pretty unexplored.

  • When asking for the Apple ID from the user, instead of asking for the password directly, ask them to open the settings app
  • Fix the root of the problem, users shouldn’t constantly be asked for their credentials. It doesn’t affect all users, but I myself had this issue for many months, until it randomly disappeared.
  • Dialogs from apps could contain the app icon on the top right of the dialog, to indicate an app is asking you, and not the system. This approach is used by push notifications also, this way, an app can’t just send push notifications as the iTunes app.

I’ve reported this as a radar, which you can dupe: rdar://34885659 👍

Sometimes iOS shows the following notification on the lock screen, which opens up the iCloud Settings screen, this is a much better approach than to ask for the password directly: 


Showing a dialog that looks just like a system popup is super easy, there is no magic or secret code involved, it’s literally the examples provided in the Apple docs, with a custom text.

I decided not to open source the actual popup code, however, note that it’s less than 30 lines of code and every iOS engineer will be able to quickly build their own phishing code.


Imagine if everybody read this before posting a comment on HackerNews/Reddit #oneCanDream :)

But, I have 2-factor enabled, I’m safe, right?

Good for you, everybody should use 2-step verification obviously, however many people don’t. At the same time, even if your Apple account is 2FA protected, many users still use the same username/password combination on most web services, meaning if hackers know your Apple ID password, chances are high, they’re gonna try the same combination on other common services.

Also, even with 2FA enabled accounts, what if the app asked you for your 2 step code? Most users would gladly request a 2FA-token and ask for it, and directly pipe it over to a remote server.

Apple would never accept such an app, right?

Apple is doing a great job protecting users from dangerous third party apps, that’s why the App Store is built and provided like it is, that’s why we code sign our application ( not really, but kind of).

However, it’s rather easy to run certain code only after the app is approved, those are not new ideas, but just to give you some ideas:

  • Use remote code (which is not allowed by itself, except for JavaScript), React Native or a custom JS bridge is your friend
  • Use the iTunes search API to compare the current version number with the App Store version number (example request), this way the app can automatically enable malicious code after it got approved.
  • Use a remote configuration tool to enable a feature only after an app is approved by Apple
  • Use a time-based trigger: just skip running certain code for the first week after submitting the binary, meaning the code will only run once the app is either approved or rejected.
  • Pull an Uber and don’t run certain code when the location is near Cupertino (it’s probably fixed by Apple by now)

The things above is public knowledge, most iOS developers are aware, and I strongly advise against using any of this, Apple will eventually catch you and block your account.

The point of this list is: While the review process provides a basic safety filter, organisations with bad intent will always find a way to somehow work around the limitations of a platform.

Phishing on mobile? Is that a thing now?

This area will become more and more relevant, with users being uninformed, and the mobile operating systems not yet clearly separating system UI and app UI. This is kind of related to detect.location, where apps would write their own, custom image picker to provide a better “experience”, but in reality, with that, they also get full access to your image library, and optionally also your camera (related to watch.user).

iOS should very clearly distinguish between system UI and app UI elements, so that ideally it’s even obvious for the average smartphone user that something seems off. This is a tricky problem to solve, and web browser are still tackling it, you still have websites that make popups look like macOS / iOS popups, so that many users think it’s a system message.

But, but, but, why is the . symbol within the “, is this all fake?

Nope, actually, that’s how the system dialog looks like, the . is within the “string notation, so I designed the phishing dialog to also include the same style.

Similar projects I’ve worked on 

I published more posts on how to access the camera, the user’s location data, their Mac screen and their iCloud password, check out for more.

Open on GitHub

Unless otherwise mentioned in the post, those projects are side projects which I work on on weekends and evenings, and are not affiliated with my work or employer.

Tags: ios, privacy, phishing, login, credentials   |   Edit on GitHub