model

t the stream level, rather than relying on web page fixups - which also means no Chrome. I soon found Tensorflow.js which made things much easier. By late 2018, I had a first cut and I released it on the Mozilla Addons site as Wingman Jr. It's been quite a journey since then! I developed the bulk of the code but have had a bit of community help as well. There is now a small but steady user base, and I've learned so much. * NSFW content detection is a hard task - I believe much harder than just general image recognition, and whereas many think of of image recognition as "solved", I would argue that NSFW content detection is far from it. * Having your own dedicated toolset to assist in creating and managing the dataset is invaluable. I was surprised to see that as a single individual it was quite feasible to create a fully-curated dataset in the hundreds of thousands. * Servers are more different than laptops/desktops than one might think. I had a good time setting up an old Supermicro with K80's on a budget. * For this problem at least, even several hundred thousand images was still not enough to see an advantage on training from scratch vs. tuning a pre-trained model. * Fun ways to slice up GIFs at a "transport" layer to allow for good-enough filtering on frames. * Character encoding detection is a hard problem, and the existing filtering API's don't do a good job of helping the developer down the right path. So with development being relatively stable for quite some time, why share now? Well, I've kept the addon fairly "primordial" in the sense that I haven't tried to cater too heavily to narrowed use cases yet. Three general use cases seem to be represented based on user feedback - there are others but so far this is what is being said: * Adults casually enabling it for daily browsing. Think things like browsing stock photo sites, Google Images, etc. * Adults struggling with pornography and looking for tools to help. * Adults looking for an extra safety net when their kids browse the web. I'm contemplating adding more specific feature sets in one or more of these areas, but thought that it might be a good time to put it out there and get some perspectives. The tech is far from perfect, but it seems that it is good enough that it is helpful for some users. It's also my hope that there's potentially some things to share here that the HN crew might find of interest. (Although I can assure the UX is not currently one of them!) * The addon itself (https://addons.mozilla.org/en-US/firefox/addon/wingman-jr-fi... and https://github.com/wingman-jr-addon/wingman_jr) - maybe it's not your thing, but if you're like me, there's a good chance somebody in your family might find it useful * The model (https://github.com/wingman-jr-addon/model) - I've tried to make a competitive model for its size, such that enterprising individuals can try this as an alternative to paying for API calls. It does not use NSFW.js as a base. Both .h5 and TF.js models are provided. Maybe it'll be good enough for your use case? * Real world examples of the webRequest.StreamFilter API. In particular, the bit about character encoding is probably worth a short read if you're thinking of using this API yourself. See https://github.com/wingman-jr-addon/wingman_jr/blob/79a1a882... * Examples of image-based logging for Firefox. * Some fun GIF parsing stuff! Thanks!

the confluence of Firefox's webRequest response filtering (which is why I didn't make a Chrome version) and Tensorflow.js that allowed me to move from dream to reality as I had been waiting prior to that time. I can't afford server infrastructure if the user base grows, and people don't want to route all their pictures to me. So I guess I see the current way it works as a bonus, not a flaw - but it DOES impact performance, certainly. Regarding data collection with respect to server - yes, this is something I've contemplated (there's a GitHub issue if you're curious). There are, however, two things that I've long mulled over: privacy and dark psychological patterns. Let me explain a bit. On the privacy front - it is not likely legal for a user to share the image data directly due to copyright, so they need to share by URL. This can have many issues when considering e.g. authenticated services, but one big one also is that the URL may have relatively sensitive user-identifying information buried in its path. I can try to be careful here but this absolutely precludes sharing this type of URL data as an open dataset. On the psychological dark patterns front - while I'm fine with folks wanting to submit false positives, I think there's a very real chance some will want to go flag all the images they can find that are false negatives (e.g. porn). I don't think that type of submission is particularly good for their mental health or mine. So, in general, I think user image feedback is something that would be quite powerful but needs a lot of care in how it would be approached. Regarding the UX - thanks! And you're welcome to try the model as well - I've tried to include enough detail and data to allow others to integrate as they wish: https://github.com/wingman-jr-addon/model/tree/master/sqrxr_... Also, let us know how things go if you try out Darknet. Good luck!

er of tech, but also of considering the human element - the state of the art may not be up to the challenge of perfection, but it is definitely up to a point of true utility for some use cases. I'm happy about that. As a note, it uses an EfficientNet Lite L0 backbone - I'm a bit limited in what type of scanning I can perform in a sufficiently speedy manner. I also agree on the context for sure - one reason I haven't tried switching to an object detection method (and that I don't rely heavily on truly random crops) is that the focus of the image is highly important for the NSFW-ness in some cases. True, two images may contain the same content ... but one is far worse than the other. The nature of CNN's still has some of this location-invariance baked in, but I don't want to exacerbate it. One challenge I think the OP may run into here that may also not be immediately obvious is that accuracy on image stills does not translate that well to video. I have basic video support in my addon, and while I knew there would be some differences, I was surprised at how many discrepancies there really are. As two examples: - Images in video are often blurrier. In true still images, there is a somewhat higher prior involved with amateur NSFW content and blurriness. This can be a source of false positives. - The opposite of the note above about focus. Taking stills of moving images will have many transitory frames that seem inappropriate on their own because it seems as if they are focusing on something when in reality the camera is just panning - obvious to the human, less so to the model trained on stills. At any rate, given how well your list of edge cases coincided with failures I've grappled with, I'd be interested to see how well you think my addon stacks up for still images when set to stay in "normal" mode. I'd love to hear any feedback you have via GitHub so I can make it better.