taviso
Joined 16 years ago
Joined 16 years ago
What was the ulterior motive? If it was to break ad blocking, it seems like they did a really terrible job, as MV3 ad blockers work great. That's not me saying that, here is a paper from researchers at Goethe University Frankfurt who tested it:
> Moreover, cross-browser experiments yield comparable outcomes, and visual inspection confirms that MV3 ad blockers work effectively without significant ad flickering or loss of functionality
From: https://arxiv.org/abs/2503.01000
> Funnily enough, this morning I ran across another feature I didn't realize was missing in MV3
I think you could accomplish this by redirecting instead of blocking, then increment a counter in a webRequest callback. There would obviously be a performance cost, as blocking is so cheap and callbacks are expensive...
Regardless, I think it's jarring hearing you call custom DNR rules "painting the house red", a legitimately powerful feature... and then point to a missing counter in the UI as evidence of lacking features!
Anyway, let's leave it there!
Sure, but as I said, it's a design decision, and nothing to do with MV3. I'm not trying to litigate it one way or the other.
I do think DNR is a good solution, and that request callbacks were a bad idea. That's my opinion - and the counterargument is obvious -- you can't do literally everything you could do in a callback declaratively. That doesn't sway me, I still think it's better!
> Great if you just want a normal quality user agent switcher
It was just a trivial example of using a powerful new feature that uBO doesn't have, not a full featured extension! The fact that it's possible at all is the point, it's cool.
You can definitely do anything that DNR can do with webRequest, nobody can dispute that. The point is that there are things you can do with uBO lite that you can't do with uBO (and vice versa!). It's not a straight downgrade, there are powerful new features.
Despite the name, the requests were not blocked until the extension had initialized. The browser could make network requests before that happened with MV2. With MV3, static rulesets and persistent DNR rules are enforced immediately.
> With MV2 you'd use blocking webRequest and chrome.webRequest.onBeforeSendHenders
Of course an extensions could do this, I said uBO lite. DNR made exposing this powerful functionality fast and easy. My point is that MV3 uBO lite has useful features that MV2 uBO does not.
This isn't an MV3 issue, it's a Chromium design decision that extensions cannot block browser initialization. It was also true with MV2. In fact, MV3 has improved the situation because DNR rules are enforced immediately.
You could certainly argue that Chrome should allow extensions to block browser initialization, or that it should be user configurable - but it seems like an entirely defensible Chrome decision. Regardless, it's nothing to do with MV3.
> the filter rules aren't as flexible.
That's true, but they are still very flexible, and DNR makes some very nice features possible in uBO lite that were not possible in uBO.
For example, did you know that you can change your User-Agent with uBO lite? Go to the Custom DNR rules tab, and enter something like this to pretend to be Lynx on whatever.com:
id: 5
priority: 100
action:
type: modifyHeaders
requestHeaders:
- header: User-Agent
operation: set
value: Lynx/2.9.2 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/3.5.7
condition:
requestDomains:
- whatever.com
resourceTypes:
- main_frame
I don't think that's possible in uBO, so clearly there are some benefits to switching. I have a ton of custom dnr rules, and love this feature.The big loss for me with the mv2 deprecation was uMatrix, so I made my own replacement. It's a prototype, but you can try it if you like: https://github.com/taviso/matrix3
I think the real question is how have Edge and Mozilla shipped WebExtension support on Android, but Google hasn't. If other competent vendors can ship it then there can't be a technical reason, it must be a policy decision. I'm more open to hearing conspiracy theories about that than MV3 :)
https://github.com/izivkov/gshock_api
The full lifelog (what Casio calls the steps and other metrics) is an opaque binary blob, but we mostly understand it now, so you can access that too.
https://github.com/google/security-research/blob/master/pocs...
I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf
I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).
It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.
I wrote a display driver to make that work a little better: https://github.com/taviso/lotusdrv
A regression here and there would be normal before, major features breaking in this stable 25 year old software is simply unheard of.
This is not exciting cutting-edge software, it's a boring financial app. My instinct is people want stability and confidence that the output won't change and that their records will still parse.
The next release will be the first where the majority of commits will be made by AI, and it has definitely not gone smoothly.
After a dozen or so bug reports, it's mostly in a working state, but I worry the output is no longer reliable in subtle ways.