taviso

A recent update broke the file history service for me, which I only discovered when I went to restore a previous version of a file. If you use it too, you should probably check it's actually working.

> the biggest failure of MV3 is not in lacking anything new whatsoever, it's in forcing the removal of a lot of API options which were useful in the name of ulterior motives.

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!

> Nevertheless, MV3's ability to offer limited filtering on startup does not seem like such a blessing when the other option was to just support full filtering on startup

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.

> and then the request had to wait until it was given to and processed by the blocker.

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.

> content can load without the blocker being ready to filter

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.

I think the new features in MV3 are great, and UBO lite is great. The initial versions of UBOl worked, but definitely lost some power user features. Those are basically all back, it now has full scriptlet support, custom dynamic filters work, element zapper is back and you can now have custom dnr rules. That's a very powerful feature that doesn't exist in UBO.

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 :)

I have one of these, there is an open source project called gshock_api that supports it. I think that makes it a much more interesting device. I don't use the app, I tag alarms in remind, and sync them from cron - works great.

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/izivkov/gshock_api/pull/3

They still do! AMD Zen cores use RISC86, I documented it a little bit here:

https://github.com/google/security-research/blob/master/pocs...

That's nothing to do with MV3 though, that was also true with MV2. The situation actually seems improved in MV3, because static (and dynamic, IIRC) DNR rules are initialized and enforced immediately, right?

Hey, another 1-2-3 nerd :)

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

Major breaking bugs.

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.

I'm experiencing something similar with another piece of software. ledger-cli is a boring, dependable accounting application.

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.

If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.

why would you post such a patently absurd accusation.

I really liked the QNX Photon aesthetic, for a long time I maintained an absurdly complex FVWM configuration designed to look like it.

This was a screenshot of my Gentoo desktop around 2004!

https://lock.cmpxchg8b.com/img/fvwm_desktop.jpg

The point is to view it in a terminal (e.g. XTerm, Konsole, etc), of course you can just run it in an X server.

It's fun, but reminds me of a trick using Xvfb.

For example...

    $ Xvfb :7 &
    [1] 21688
    $ xeyes -display :7 &
    [2] 21697
    $ xwd -display :7 -name xeyes -out /dev/stdout | convert xwd:- sixel:-

It looks like this: https://imgur.com/a/Eq2ToVO

Obviously no input though, you would have to use xdotool! The main benefit is that you probably already have all these tools installed :)

In 2022, Google TAG were awarded a "lamest vendor" award at defcon for fixing a Chrome vulnerability they discovered was being exploited in the wild... without asking for permission from the NSA first. That was the turning point for me.

I've used the tool sequin in the past to debug issues: https://github.com/charmbracelet/sequin

It worked great for me, seems much easier to debug logs directly in the terminal.

They accidentally used the example key from AES-CMAC RFC, the full details are in the accompanying blog post: https://bughunters.google.com/blog/5424842357473280/zen-and-...

The attacker doesn't need to literally be sitting at a keyboard, that can just be automated.

> I'm curious though why you don't think TOTP or similar are good against credential stuffing though

I have written about this before, but looks like I lost the article somehow. https://web.archive.org/web/20210219185711/https://blog.cmpx...

Imagine you reuse the same password everywhere, and are sick of credential stuffing attacks. You ask your friend for advice, and your friend tells you to just enable TOTP when available, explaining that when there is a data breach you will be safe.

That is obviously bad advice, the vast majority of services do not use TOTP and you will have to race attackers to change your credentials quickly at dozens (hundreds?) of services. I think a reasonable person would say that you have not "prevented" credential stuffing.

A far better solution is unique passwords, it works today with all service providers.

I'm not familiar with the expert they consulted, but the claim that "The main advantage of 2FA is that it is much more difficult to gain access to your accounts via phishing attacks" is just plain false.

TOTP or SMS-2FA are obviously phishable, if you just entered your password into a phishing site, why wouldn't you also enter a TOTP code? I usually point to Modlishka as a practical example (https://vimeo.com/308709275) to help visualize this.

In fact, the main (claimed) advantage of 2FA is that it prevents "Credential Stuffing" of reused passwords. I personally don't think TOTP (or similar) are a good solution to this problem at all, but this is a thorny issue.

I think that's a miss for Claude, this doesn't look right at all. The accrual account is an okay solution, but the syntax is wrong! That syntax is only used for budgeting and forecasting.

I think the solution is effective dates, there is an example pretty close to this scenario in the manual:

https://ledger-cli.org/doc/ledger3.html#Effective-Dates

This seems like a weak excuse, the same problem exists on UNIX, but slocate solves it well enough. The slocate solution is to build the index and record permission and ownership, then it can restrict output to entries you have permission to see at query time.

I bought a few items at a drugstore yesterday, and noticed the cashier had very elaborate nails.

She used the second knuckles on her inverted hands (i.e. palm facing up) to operate the touchscreen PoS system, and was very efficient. Tool usage can sometimes be adapted.

I think they're talking about the cp example, doesn't seem like it would handle filenames with spaces!

Super neat project, btw!

Super cool, I didn't know about this - too bad it's not archived. I did know about a different game for 1-2-3, I even managed to track down original media and get it working in Linux!

https://lock.cmpxchg8b.com/doom.html

There is a brief gameplay video, if you want to see it.

I dunno, I think Debian are being wise here.

A while ago KeePassXC published a glowing audit report, but the report just ignored the scary stuff -- i.e. the things being disabled here like browser integration. I took a quick look, and thought the design could use some work -- but when I tried to discuss it they were very dismissive.

I did file a bug for one of the vulnerabilities we discussed, but I don't think they changed anything and didn't seem interested.

> Testing cannot be used to prove that a flaw doesn't exist, only that it does.

FWIW, I wrote a similar blog post about a different encryption bug that really seemed like it should have been found by fuzzing, and had 100% coverage.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...

Not that I disagree with you, just a practical example.

I think I feel the same way, lag has never occurred to me when using xterm -- and I use the heavier features like translations and sixels day-to-day. Maybe it's just the Athena widget style that is making people dismiss it, because it's great.