Even when you are national-state-level target, there are easier ways to grab the screen.

For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.

Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.

However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.

I am not sure what you saw, but on regular Linux processes of the user can spy on each other anyway. In any case, X had the concept of untrusted clients basically forever but nobody cared to invest even the small amount of work necessary to make it work well because nobody thought it would make a different. That this was later used as a major argument against X convinced me that this is not at all about technology.

Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do, soon any old user process will no longer be able to read any other process’s memory. I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.

> I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.

It is when you are essentially putting bars in front of your windows while leaving the front door unlocked, i.e. you are making things worse in the name of security while not actually providing any additional security.

> Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do

Who is we? I don't want or need any of that on my free software system.

I agree. My point was only that this hole can easily be patched in X as well. So the argument was essentially "we do not bother to patch it with X, so we must rewrite X".

It was my understanding that changing the original codebase to fix it would’ve been involved enough as to warrant a rewrite.

I think this is nonsense.

Lutein helps me.

Can this UEFI firmware be ported to other ARM devices, e.g. phones, tablets, books?

Yes, it's just a port of the EDK2 UEFI reference firmware

Have you checked out uboot?

https://u-boot.org/

Doesn't everything under the sun boot with uboot? Uboot is usually what people want to replace when they say "why can't this just run UEFI?"

I have yet to find a valid reason for UEFI to replace u-boot, or UEFI to exist at all.

That's an interesting way of looking at things. Now we just need to have some sort of arbiter who decides what is harmful and what is true eh?

Why not just a quick duel?

I'll go arm the icbm

I wish, we will have something like Fil-C as an option for unsafe Rust.

Fil-C works because you recompile the whole C userspace. Unsafe Rust doesn't do that... and for many practical purposes you probably want to touch the non-safe-version of the C userspace.

Still, it's all LLVM, so perhaps unsafe Rust for Fil-space can be a thing, a useful one for catching (what would be) UBs even [Fil-C defines everything, so no UBs, but I'm assuming you want to eventually run it outside of Fil-space].

Now I actually wonder if Fil-C has an escape hatch somewhere for syscalls that it does not understand etc. Well it doesn't do inline assembly, so I shouldn't expect much... I wonder how far one needs to extend the asm clobber syntax for it to remotely come close to working.

at the bottom of the turtle stack, there's a yolo-c libc that does some syscall stuff:

> libyoloc.so. This is a mostly unmodified [musl/glibc] libc, compiled with Yolo-C. The only changes are to expose some libc internal functionality that is useful for implementing libpizlo.so. Note that libpizlo.so only relies on this library for system calls and a few low level functions. In the future, it's possible that the Fil-C runtime would not have a libc in Yolo Land, but instead libpizlo.so would make syscalls directly.

but mostly you are using a fil-c compiled libc:

> libc.so. This is a modified musl libc compiled with Fil-C. Most of the modifications are about replacing inline assembly for system calls with calls to libpizlo.so's syscall API.

That links here: https://github.com/pizlonator/fil-c/blob/deluge/filc/include...

Quotes from: https://fil-c.org/runtime

Unsafe Rust actually has a great runtime analyzer: Miri. It's very easy to just run `cargo +nightly miri test` in your project to get some confidence in the more questionable choices along the way.

s/webserver/DNS/

HTTPS is there, so you go down to that level only if you want to distrust any element of the public key infrastructure. Which, to be fair, there are plenty of reasons if you are paranoid -- they do tell you who's doing what in a shady way as they revoke, so there's a huge list of transgressions.

It is not only that directly; the domain name might be reassigned to someone else, resulting in a valid certificate which is different than the one you wanted. (If you have the hash of the file which you have verified independently then it is more secure (if the hash algorithm is secure enough), although HTTPS is not needed in that case, it can still be used if you wish to avoid spies knowing which file you accessed. You can also use the server's public key if you know what it should be, although this has different issues, such as someone compromising the server (or the key) and modifying the script.) (There is also knowing if the script is what you intended or not anyways (or if there is something unexpected due to the configuration on your computer); if that is your issue, you can read it (and perhaps verifying the character encoding) before executing it, whether or not you trust the server operator and the author of that script.)

> the domain name might be reassigned to someone else

If that happens its game over. As the article I linked noted, the attackers can change the installation instructions to anything they want - even for packages that are available in Linux distros.

Any info on recent ban of SafeDot by Android and GOS? Any plans to implement SafeDot as an official GOS app?

Isn't that now a native android function?

A little green dot? No, it's a small fraction of SafeDot functionality. I'm interested in audible notification when camera, mic, or gps is accessed. Currently, I cannot make it work on GOS (maybe, may phone is hacked).

It works properly again after post on HN. :-/

Users are trying to solve their own problems.

Graphic artists are creating graphics editors (Gimp, Krita, Blender, ComfyUI, etc.) with tons of options.

Earlier free software has/had tons of free artwork: icons, themes, skins, mods. I had few dozens window border skins and GUI themes for Gnome 1.x, for example. gnome-look.org has 1.5k themes for GTk3/4, but I'm OK with stock theme now, because 90% of the time I see browser or console.

No.