Using machine learning to classify NSFW images

Hi, all! I have a favor to ask. I have an alpha version of my app, Transitions, that can classify images as NSFW with an 80% or higher accuracy, most of the times (top-1 accuracy as it is known in the ML world). It uses Mobilenet V1. The predictions are made on-device. So your data is not used for predicting whether an image is NSFW or not.

I was wondering if any of you would be interested in signing-up to be in an Internal Test Track? I already run an Open Beta program but before releasing a beta, I’d like to test it with a closed loop of users. Sorry, but my app is Android-only. You’ll need a device with Android 6.0 or higher. So please PM me if you are interested. Once you are part of the testing program, I am hoping you would also be OK to submit feedback so I can improve the model’s accuracy.

Why NSFW classification?

Transitions serves user-generated content from flickr, 500px, and Unsplash. Even with category filtering, inappropriate images show up all the time. I currently have an ESRB rating of Teen on Google Play, because of this. I can’t change that rating;¬† even with the automated classification and dynamic blurring of such images. But I want to give my users the ability to browse high-quality photos on Transitions without the uncertainty of what they’ll see next.

What do you (as a tester) get from this?

Uh, the joy of helping me? Early access? Take your pick.. ūüėÄ


Remote debugging an embedded WebView in Android

And there I was, thinking that I was done with AzureStorageExplorer for Android v1.0.0. But, nope. In my last round of testing, I couldn’t even login using my work account. The Sign In button didn’t do anything. I went back a few versions to see if the Android update for WebView¬†could have done something to break it. That wasn’t it. The OAuth client library I was using had the recommended code for enabling Javascript in the WebView client so I knew that wasn’t it. I was able to login through the Azure OAuth flow using my personal Azure account. So, I knew there was something about the enterprise account login screen, which could have changed recently that ended up breaking the authentication in the app. It turns out that it did. Read on to know how I found out.

The first step was to prove that something was indeed broken in the login screen for enterprise accounts in Azure in embedded WebViews. To do this, I looked up Chrome’s remote debugging options and found this page describing how to remotely debug WebViews in mobile apps. So, I enabled the setting as recommended by Google, which required adding this piece of code in my activity’s onCreate(Bundle) method.


I ran the app, launched Chrome’s Developer Tools, and¬†connected to the app’s WebView. This is what I found..


That last error in the console is what was logged when I pressed the Sign In button after entering my work account credentials for Azure. It turns out that the page’s JS now has code to store something in the browser’s localStorage. The reason this isn’t a problem, if you were logging into Azure through a desktop or even a mobile browser, is because localStorage is enabled for every site by default in the non-embedded browser view. But for a WebView in an Android app you need to explicitly enable the DOM storage, just like you need to enable JS through the WebSettings class.

After finding this, it was easy to know where I needed to make the fix. So, I set out to fork the source repo of the OAuth library I was using, made the necessary changes and created a pull request. If you are using the same library and have run into this issue, you could clone my repo and build the project to produce the patched .jar (or an .aar), which you can use in your project directly until the author of the library can get to my pull request (if at all!).