No, I was already convinced that relying on colour alone is insufficient. I still think they can be useful helpful if they don’t rely on colour alone.

True, there are exceptions (that’s why I keep saying most), and I think the pattern is more common on web than on desktop. (Though I think Gnome also compensates a bit with their boxed lists as an additional affordance.)

Note that I am 100% on your side in saying that there are annoying toggle boxes that are unclear. In your image, I can only tell that the second is probably on because the right-hand side is usually used for the on state in LTR locales. But they can be better, e.g. with an on/off label integrated. Ironically, GNOME has a toggle to enable this:

Well, I’d encourage you to keep an eye out; I think you’ll find that the majority of controls on the web behave as I described. And I think that’s a good thing, too: it’s far quicker and easier to be able to deduce behaviour from the control you’re handling at the moment, than having to scan the complete context. And especially if e.g. you’re visually impaired, the latter can be a major hassle.

(And indeed, the other controls you mention almost never apply instantly, so their behaviour is still predictable. When they do, they’ll often still have some other affordances to indicate that they do apply instantly.)

I was trying to make the point that the way a control looks gives you some information on how it will behave, because software has generally been consistent with associating those looks with those behaviours.

So if you see multiple options with a circle in front of them, selecting one, then selecting another will usually deselect the first one.

On the other hand, if those options have squares in front of them, selecting one, then selecting another will usually result in both of them being selected.

And in both cases, usually they will be part of a form and will only take effect when you submit that form using a button.

On the other hand, something that looks like a toggle usually takes effect immediately on toggling.

Of course it is technically always possible to have each of those behave like any of the others, but you will be breaking conventions if you do so. Styling is an affordance to inform the user about the behaviour.

I mean, they can, and they can also be mutually exclusive - but it’s better to use radio buttons in that case. If that pattern is used, there’s not really a good way that a checkbox will take effect immediately beforehand, or whether it will require submitting a form, except scanning the full page to look for such a button.

It’s nice to be able to know that they take effect immediately though, instead of needing to click a submit button.

Oh yeah I wasn’t trying to say this wasn’t interesting, just trying to make sure people didn’t get the wrong idea of what it meant.

Right, so for the vast majority of users, their Firefox instances won’t actually be running this, right?

Is this a step towards implementing Google’s same extension restrictions in FF, setting themselves up as the primary arbiter of adblock tools?

I wouldn’t expect that:

Firefox, however, will continue supporting both blockingWebRequest and declarativeNetRequest — giving developers more flexibility and keeping powerful privacy tools available to users

https://blog.mozilla.org/en/firefox/firefox-manifest-v3-adblockers/

and

And even if we re-evaluate this decision at some point down the road, we anticipate providing a notice of at least 12 months for developers to adjust accordingly and not feel rushed.

https://blog.mozilla.org/addons/2024/03/13/manifest-v3-manifest-v2-march-2024-update/

So even if that would change (which I’d be very surprised by), it wouldn’t happen for another twelve months, so plenty of time for outrage then.

Haha, I don’t think anyone’s talking about killing uBO, and I’m fairly sure gorhill wouldn’t do that, unless he grew tired of maintaining it.

(They could remove the APIs it uses, like Chromium did to some extent, but Mozilla has publicly committed to not doing that.)

The mentioned bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2013888

Titled: “add a prototype…”

Description:

This’ll be pref-controlled and disabled by default, but will enable some fun playing around, foxfooding, and further development.

So doesn’t sound like it’s “landing” in the sense that your Firefox instance will actually be running this (yet), I think? Though maybe the prototyping was successful.

Yeah I think that’s fair. As far as I know, it’s also mostly been used for detection, not patching, and possibly it’ll be better at exploiting than at patching.

I’m on Nightly, so it might not be in release yet, but I have “Open Link in Split View” in my context menu when I right-click a link, so if it’s not there yet, it’s coming.

I don’t think these are all Mythos, but it’s more than 2 fixes: https://infosec.exchange/@tomrittervg/116443139069130293

The author seems to put a lot of stock in the whole “the blue team has access to these AI tools that the red team doesn’t currently have access to” argument

I didn’t read it like that. I think the point was that the red team had an edge over the blue team (by being able to spend a lot of effort on a single exploit), so when both teams have access to these same tools, it’ll be more of an equal fight.

Looks like there’s a lot happening there too: https://infosec.exchange/@tomrittervg/116443139069130293

Well, and after vertical tabs, tab groups, a free browser-wide VPN, …

That makes sense!

That sounds like exactly what I meant; where the GPL is viral on the project level, MPL is viral on the file level. So if code, under MPL, is added to a file, that whole code becomes MPL.

AFAIK MPL is viral, but only at the file level. In other words, if you modify an MPL-licensed file, your modifications need to be MPL-licensed, but if you add additional files, those can be a different license.

(In practice, I suppose that that’s fairly weak?)