Notices by Matt Campbell (matt@toot.cafe)

There's a new product that has been gaining some buzz in the blind community, a Windows app called Guide that uses AI to perform tasks on your computer. It's pitched as a way to get around web accessibility problems in particular. I won't link to the thing itself, because I don't want to give it that validation, but I'll link to a previous discussion thread about it: https://fed.interfree.ca/notes/a5wf4yss764nf6h7

I've spent some time taking this app apart. The level of shoddy work here is deeply disgusting. 1/?

The frontend being fully unobfuscated would of course be a good thing if this were supposed to be open source, but it's not. And that frontend seems to be the only part of the program that validates that you have the license/subscription. That's just begging to be cracked. 3/?

First, it's an Electron+Python monstrosity. Specifically, the Python backend runs as a web server on the local machine, and the Electron frontend connects to that local web server. Along with the size of Electron itself, the frontend app is about 27 MB, mostly a node_modules tree with no hint of tree-shaking / dead code elimination. The front-end JavaScript code is not minified at all, so once you extract the .asar file, it's easy to look at it. 2/?

To spell it out, the problem with directly connecting to third-party services using API keys inside an application running on a user's machine is that you're just begging to have someone steal those keys and run up your bills. Without having your own server in the mix, there's no hope of reining in that usage of third-party services and tying it to some kind of authorization system. They do have an API server (on Azure) for the license/subscription, but as I said, that's easily circumvented. 5/?

But now let's talk about the Python backend. The first obvious question, of course, is what AI model it's using, and whether the inference is done locally or remotely. It's using Claude 3.7 Sonnet with its computer use feature. But here's the really crappy part: the connection to Claude, and to other services like Azure Speech and ElevenLabs (yes, both), is happening on the user's machine, using API keys embedded inside the application. 4/?

It wouldn't be right for me to knock the product for the bloat alone. But taken together with the direct use of third-party services in the app on the user's machine, and the actual functionality problems detailed in the thread I linked to, the whole thing smells of something hastily cobbled together to catch a ride on the AI hype train. If this is the accelerated future of software development that businesses want, then as I said, it's deeply disgusting, and kind of scary. 7/7

The Python backend is packaged using pyinstaller. There's 30 MB (compressed) of Python bytecode in the executable, and then there's also an "_internal" directory with tons of dependencies, adding up to about 200 MB (uncompressed), again with no apparent attempt at eliminating dead code in the package. I readily admit that I'm perhaps overly obsessed with trying to make non-bloated software, but come on. 6/?

Perhaps I need to more explicitly call out what is actually the scariest part here: if you use this product, you're letting an application take control of your computer, using the output of a large language model as input. I know better than to describe an LLM as "just" a next-word predictor, because we've all seen how surprisingly powerful that can be. But still, it's all too common for LLMs to output things that don't make sense, especially when venturing outside their training.

To clarify what my last boost (https://gts.trycht.cz/@tyrylu/statuses/01JN0P5VFG5XWDMAC1VWVXHJN5) is about: This means that perhaps the biggest problem with using GNOME with the Orca screen reader on Wayland rather than X11, namely the inability for Orca to consistently watch and grab keystrokes, is now solved. Congratulations to @tyrylu for getting this done. I'm glad that some of the code I wrote during my contract with the GNOME Foundation last year helped with this.

Is there any screen reader or browser extension that eliminates soft hyphens when reading a web page? Some authors or blog themes add soft hyphens throughout text, presumably to allow the browser to do hyphenation at the end of the line, but this has the side effect of breaking up words, which is bad for text-to-speech. Here's the latest example I've come across: https://www.robinsloan.com/lab/reasons-ing/

@skinnylatte Was that from a Chinese person or a westerner?

@ariadne Thanks for that clarification. I'm still inclined to go further by building stripped-down versions of dependencies for my specific application, but I won't use your post to justify it.

Question for #blind programmers: Are there any good accessible interfaces for viewing the output of a profiler?

@jason I wonder if it's mostly developers and sysadmins who choose to deal with more accessibility issues to get the otherwise better OS.

Also, I know you were active on the Emacspeak mailing list going back at least to the late 90s when I started participating in that community. I wonder how much you use GUIs as opposed to Emacspeak or other solutions these days. Emacspeak and text-console screen readers both have a steep learning curve for those used to GUi screen readers.

@glyph

@glyph

> individuals without full control of their technology stack

And note that this doesn't just mean people who can't install Linux because, for example, they're sharing a computer, but also people who can't practically use Linux because free software hasn't solved everything yet. I think it's safe to say that a lot of blind people, for instance, put up with Windows because, in some ways, it's the least bad platform with regard to accessibility.

@anna I went to RustConf in 2023 (in Albuquerque), when they still had a strong COVID policy (requiring proof of vaccination, a negative COVID test, and masking). I got to meet people in person, eat with them, etc., but came back home still healthy. Yes, wearing a mask is slightly annoying if one's not used to it, but there's always a tradeoff.

Came across this Hacker News comment by @rain which succinctly describes one reason #Rust's approach to ownership and borrowing is valuable: https://news.ycombinator.com/item?id=39831978

> Which popular GC languages have mutexes owning the state they guard, such that it is structurally impossible to access that inner state without holding the lock? To do that you must have single ownership.

Posting for the benefit of anyone else who, like me, is sometimes swayed by the backlash against Rust.

@skinnylatte . I wonder if it also works the other way. I already have perfect pitch, but have never learned a tonal language. I wonder if it would be easier for me to learn a tonal language than for other adult learners.

Hot take: I think Rust makes it too easy to do lots of short-lived memory allocations. I don't know what language and/or library changes would have most effectively guarded against this. Maybe enforced manual drops instead of C++-style automatic drops. Maybe having to pass an allocator into every function that allocates. But it would be nice if there were something to nudge us in the direction of reusing long-lived allocations, besides just individual developers being obsessive about it.

@anna Then did the computing and informatics faculty have some kind of over-engineered infrastructure that was unreliable in practice? (I've done that before.) Or were they just incompetent?