Silent Mode - Custom Images?

This post is for folks who use silent mode - I've gotten some feedback from a couple helpful users:

qvim's hope: "...change the silent mode images, it would be my preference for me to choose my own images for this mode. there's nothing wrong with the images just that i would like to have the ones i prefer"

Cranky's hope: "...Ability to add custom images for silent mode from an online database of SFW images (you can memorize the stock images pretty quickly, defeating the purpose)", "Ability to lighten/darken/remove the watermark in silent mode"

  Silent mode is one of my personal favorite features, so it makes me happy to hear that others are using it - and using it enough that they'd like to see it expanded somehow.

So first, let's talk just a bit about how silent mode works right now. I've gotten a number of images from Unsplash, downsized them heavily, and included them directly in the addon (~100 images in ~2MB!). I've also created an index of  metadata for attribution as well as some data for image similarity, so that in theory the images being replaced seem less out of place. Honestly, I don't think that it works particularly well in that regard, but there is a rudimentary method in there right now that does that.

So, what about adding your own images? To do so I think there would be a couple approaches:

1. Drag and drop your images onto the addon settings page.
2. Provide a way to get placeholder images from the web.

Since the image similarity code is done as a pre-build step, the logic isn't even in the JS of the addon, so both potential methods might lack a bit there.

Option #1 wouldn't be too hard but I'd have to look into local storage limits. I think we might hit some issues there, particularly if folks aren't resizing the images as heavily as I did. Additionally, if images are handpicked, Cranky's note about memorizing the stock images still is unsolved unless many, many images are put in - which will definitely have problems with local storage limits.

Option #2 provides more flexibility - for example, see this list of placeholder image services. Most of these image services tend to provide a URL where the desired width and height is supplied, which would mesh well with the addon's current functionality.

I think option #2 comes with fewer headaches, but let me know over on GitHub!

(Update: the adventurous may wish to watch this branch...)

Block/Allow Images?

 Recently I got some friendly feedback from "qvim". There were multiple parts to it, but I wanted to highlight one of the suggestions. The desired feature would be to ...

block with click, sometimes it doesn't work and if possible I would like to click on the image with the right button and be able to block or allow. (very important)

Now, I'm actually a bit surprised that I haven't gotten more feedback around this type of request in the past. It's popped up maybe once or twice. There a couple interesting points about this, one technical and one more based on use cases.

 First, the technical reason. For those who haven't peered at the source code, you may be interested to learn that the addon does not actually interact directly with the HTML elements at all. Nope. The filtering actually ties in at a lower level - it is basically processing the network requests for different media types. When I started the project, I thought about taking an approach that would interact with the HTML for each image, but decided against it because I thought working with streams would do a better job of catching every single image going through the system. Several years in, I think I made the right choice but there are still some exceptions - base 64 images and a few others delivered in special ways. However, I don't have to deal endless hacks against the HTML DOM to try to catch every element change or to try to make images invisible until the addon has scanned them.

So why does this matter? Well, it means that once the data has been scanned, I don't have an easy way to know where it actually appears on the page. The image data is essentially read-only. Similarly, I certainly could create something to interact with the images as HTML elements, but there just hasn't been a strong need.

Second, the use cases. Folks like to use this addon in a variety of ways. In some cases, the user is an adult and would like to filter out the junk. But in other cases, parents are using this as a basic defense for their kids. While it's not easy to lock down addons as a parental control, I do try to avoid showing one-click options to see images. There's also a third use case, where the user is an adult but is trying to overcome pornography. In that case, it may also not be the best option to make it too easy to view a blocked image.

So where does that leave things? Well, since the data is already delivered and read-only, it is not technically easy to go back and show an already blocked image (possible, yes, but definitely not trivial). However, hiding an offensive image that the filter missed is easier because it does not require this coordination - for example, the HTML element can just be altered. Similarly, from a use case perspective, it is likely good to allow blocking an image, but not showing one. The easiest way to do something like this would be to expose it as a right-click context menu, but if you follow that link you may notice that the user experience could get a little clunky.

This also ties in with another request: can users report that images are either being blocked incorrectly or that they should be blocked? This one is a bit more spicy to deal with.

I'd like to hear more feedback about if you'd be interested in this blocking feature and/or if you'd be interested in an image reporting feature. Let me know using the feedback link in the addon, or head on over to GitHub!

Update: you can see a rudimentary version of this here: https://github.com/wingman-jr-addon/wingman_jr/tree/hide-images with relevant issue at https://github.com/wingman-jr-addon/wingman_jr/issues/162

Welcome, Linux Users!

 Recently there was a bump in new users - and the Firefox stats seem to indicate that many of you use Linux. Welcome friends!

Now, I've got a question for you. I don't use Linux desktop as my daily driver, so I need your help in understanding how the performance is looking so far. This addon relies on some level of hardware acceleration ... which hasn't always had the best support on Linux. If you've got a second, I'd love to hear from you over at this poll on Google Forms - can you please help me out?

One last note: if you are finding that the default WebGL backend isn't working well on your machine, it might be worth it to try the WASM backend, which you can pick in the options for the addon.

Hope you enjoy Wingman!

 

Update: Poll results from 4 users - glad to hear it's working well for you!

Console.log CSS Hacks

Short technical post here. If you're a developer, you might be wondering, "Isn't it a bit complicated to see what's going on when you try to debug Wingman?"

Yes! Some of it definitely is, especially trying to keep track of multiple request threads or scanning video frames. But one feature that has made life significantly easier is the ability to place CSS in console.log. I use this to log out debug images. For example, right now I'm trying out a feature to tile images with huge aspect ratios, and this makes it significantly easier - I can base64 encode a thumbnail and log it out like this:

 

 Give it a whirl the next time you need logs with a bit more than ASCII art!