It's been a productive several weeks! I've been using Codex to help advance development significantly, while working hard to ensure that Wingman Jr. remains well-crafted. 5.x is starting to take shape, and will contain significant new features.
Who Uses This Thing?
Perhaps a good place to start is to ask "Why 5.x?". The key driver for this is to help better serve different types of users:
- Everyday Protection - Adult using this for themselves as a basic layer of protection
- Protector - Someone setting it up to help protect someone else, often someone younger
- Guardrails - Adult using this primarily for themselves, but trying to add more guardrails in their life.
Historically, I'd originally thought the main use case would be for parents of kids, but in practice it's mostly been adults using it as an extra layer of protection - so that's where I've focused. On the other hand, I've always been skeptical of how well home computers can really lock down browser usage, particularly against, say, a determined teenager. Technology helps, but I think relationship and accountability are key aspects of a healthy digital life regardless of age.
But after looking at many survey results about who uses Wingman and why, it's clear all three are needs - and that people are using this addon whether it's a perfect fit or not. This release tries to help make a better experience for both the Protector and Guardrails use case. The Guardrails use case is primarily a subset of the features for the Protector, so let's look at the new features for the Protector.
Protector
One of the longstanding challenges here is that you can't as easily block removing or disabling an addon (although there are some ways!), and even if you can block the addon removal it's harder to stop someone from just e.g. switching over to Chrome. This still remains true.
But, there are things we can do, particularly in a home setting:
- An audit feature - even if someone removes the addon and brings it back, this will be observable via a gap in the history
- A password feature to change settings - while again this could be removed or even reset, as long as it wipes the audit it helps determine if there was any monkey business
- A history of blocking by site - store blocked images in a review-friendly way
Here are some in-progress screenshots - note these might change!
 |
| Timeline of block history |
 |
| Expand the timeline to get by-site and review-friendly info |
 |
| Options view when settings are locked |
A New Model
Finally after many years I'm planning a new model as the default experience! The current candidate is
N017, a MobileNet v4 fine-tune. I may still tweak on it further, but there should be an improvement here. For the technically inclined, here's a three way comparison ROC (zoomed in) of the old model SQRXR 112, a popular open filtering model NSFW.js, and the new candidate N017. Take the NSFW.js line with a
giant grain of salt as we're comparing apples and oranges, but the key story here is the brown line for N017 showing improvement over the green line for SQRXR 112.
The new model is generally stronger, but remains weak in drawings and cartoons. Historically these have been a challenge for machine learning models, and so remain a continued area of improvement.
Note that the new model is heavier - image scans on my machine are about 30ms for the old model and 52ms for the new model. For this reason, I've left both the new and old model in as options, but will default to the new model.
Video Scanning
I've also tweaked on video scanning. In addition to some changes to make QuickScan more performant, I also made an important change in behavior to all scanning.
Many videos have a separate thumbnail image apart from the video itself. So, if the thumbnail is sketchy, it gets blocked and you don't click on the video.
But, not all videos do this - many just use the first video as the thumbnail. This led to a bad interaction: a certain number of frames have to get blocked to block the video, but the thumbnail of the video was quite sketchy and you still see it because it was just one frame! So, for that reason, I now treat the first frame of the video differently: it's essentially treated as an image and if it fails, the whole video gets blocked. Otherwise I continue with the normal scanning checks.
Performance on Content Sites
Certains sites, such as Imgur and Amazon Haul, have exhibited slower performance - even relative to other image and video heavy sites like YouTube or Pinterest. When I introduced the new model, it made the slight problem significantly worse. Did some digging here and turns out that the GIF scanning strategy would cause certain bottlenecks and the performance of the whole site would basically collapse, so by tweaking that it makes a decent improvement.
