QKiSS

• KISS/GS (General Specification), with its extended comments.
• FKiSS (the script language): versions 1 and 2.

That is quite enough to load nearly all the Japanese KiSS sets I could find on the Internet.

But I deliberately decided not to implement the shell() command, to avoid unnecessary security holes. (I don't think I've ever seen a KiSS set that uses it, either.)

A KiSS viewer implemented in Qt 6. Having “KiSS” in the name is a convention of KiSS viewers, like fkiss, GnomeKiSS, KISSLD, and Direct KiSS.

I also considered a few other names:

• QtKISS: pronounced the same as “Cute Kiss”, and named with the same logic as GnomeKiSS: “platform name + KiSS”. Well, actually, QKiSS had this name in the early days of development. But according to the fair use rules of the Qt trademark, the Qt name may only be used “where the Qt name is not being used in a way which suggests sponsorship or endorsement of the product”. To avoid someone giving me crap about it someday, I had to rename it.
• Qute KISS: also pronounced “Cute Kiss”, but argh… Qute is a trademark of a Japanese computer game company. Too risky.

The biggest archive right now is probably Otaku World, though you have to dig through it patiently. It has sets by both Japanese and Western artists.

Some people have also written their own implementations, such as one in JavaScript or one in Haskell, with online demos you can open right in your browser. But most of the sample sets they provide were dug up from Otaku World, too.

Note that these KiSS sets may contain NSFW content, and I can't make any guarantees.

LZH / LHA is a free compression format and tool, developed in 1988 by Haruyasu Yoshizaki, a Japanese physician. It was very popular in the Japanese personal computer scene of the time (by comparison, PKZIP, the ZIP tool that later became the mainstream, did not appear until 1989, and was shareware), so the KiSS developer community, which originated in Japan, naturally adopted LZH to compress KiSS sets.

But today, both the format and its implementations are old, and lha and unar extract LZH files of unknown origin, which makes them the easiest target for a malicious file. So on Linux, QKiSS locks them up:

• Landlock: they can read only the system files and the archive being opened, nothing else in your home folder, and they can write nowhere except unar's temporary folder.
• seccomp: high-risk system calls such as io_uring, sockets and namespaces are turned off.
• AppArmor (the optional qkiss-apparmor package, Debian / Ubuntu / openSUSE only): lha and unar are restricted once more, and QKiSS itself cannot read secrets such as ~/.ssh, nor write files used for persistent attacks, such as ~/.bashrc.

Landlock and seccomp are built into QKiSS, with nothing to install, but they cover only these two external programs, not QKiSS itself.

As for Windows: as Eisen once said, anyone who uses Windows is a brave warrior, and needs none of these little tricks.

As for the App Sandbox of macOS, I have given up on it for now. I believe Himmel the Hero, who, like me, never bought a Mac nor subscribed to the Apple Developer Program, would have done the same.

It doesn't fit the use case. SELinux's security model is inherently bad at “deny access to a few folders such as ~/.config/autostart, and allow access to everything else”, and I can't force users to put their KiSS LZH files only into some hardcoded ~/qkiss folder.

Besides, on the Linux desktop, people who deliberately run GUI apps outside unconfined_t must be rare. Such people either work at the Pentagon^*1, or moved to Qubes OS long ago.

But even if you use SELinux, you still have the protection of Landlock and seccomp, which covers only the extraction by the two external programs, lha and unar.

Because I didn't buy a code signing certificate from Microsoft.

A “signature” (or digital signature) is one of the uses of asymmetric cryptography: a mathematical way to prove that “something was really made by a certain person, and nobody else has changed it”. But I can't say much about it here, or this would get very long, so I only give the main points. If you want to understand it more deeply, ask an LLM.

Simply put, “buying a signature” means: I'm a developer, and once I have written my program, I pay Microsoft (or a certificate authority it trusts), they check who I am, and then they put my public key into a public certificate and issue it to me. Then I can digitally sign the compiled executables with my own private key, so that any Windows computer can use the public certificate to verify that “this executable was released by me, signed with my private key, and not by someone pretending to be me”. Indirectly, it also implies that “there is no malware hidden inside” (because once malware is found in it, they revoke the certificate, and since they have already checked who I am, the FBI can come looking for me any time).

There is no signature, but the whole compiling and building process of the software is transparent: you can check it yourself on GitHub Actions.

Also, the license of the lha bundled in the packages of this project is a bit unusual: it is not a license approved by the Open Source Initiative (OSI). So I can't apply for a free signature from the companies that offer free signing to free software projects, either.

Anyway, opening an unsigned program on Windows isn't much trouble: just a couple more clicks to confirm.

Because I don't want a Prepear incident of my own (the case record at the US Patent and Trademark Office).

Apple's official guidelines say this:

These guidelines are for Apple licensees, authorized resellers, developers, customers, and other parties wishing to use Apple’s trademarks, service marks or images in promotional, advertising, instructional, or reference materials, or on their web sites, products, labels, or packaging. […]

Authorized Use of Apple Trademarks

[…]

2. Compatibility: Developers may use Apple, Macintosh, iMac, or any other Apple word mark (but not the Apple Logo or other Apple-owned graphic symbol/logo) in a referential phrase on packaging or promotional/advertising materials to describe that the third party product is compatible with the referenced Apple product or technology, provided they comply with the following requirements. […]

Unauthorized Use of Apple Trademarks

[…]

3. Variations, Takeoffs or Abbreviations: You may not use an image of a real apple or other variation of the Apple logo for any purpose. Third parties cannot use a variation, phonetic equivalent, foreign language equivalent, takeoff, or abbreviation of an Apple trademark for any purpose. […]

Under the nominative fair use of trademark law, you may mention someone else's trademark to say that your product works with theirs, but only “as much as is reasonably necessary”. So I may only write plain text like “macOS”, because in theory that is already enough to say what it means, and I can't add an Apple icon to it. But my OCD makes me feel uncomfortable all over without a little icon for decoration, and since even images of a “real apple” are banned, I had to think of something else.

My spare time for this project is precious. I don't want to spend a single moment of my life drawing an icon by hand, only for salaried lawyers to make me take it down and redraw it for a reason like this. But I can't accept the ugly-as-sin plain “macOS” wordmark they require in its place, either. In a case like this, it's enough to let AI make a rough draft, then touch it up a little myself (any fruit will do, as long as its shape has nothing to do with an apple's, so that not even a one-year-old would be misled).

This is also a signature problem, and it works much like the warning on Windows. I don't buy one because it means paying Apple 99 US dollars every year for the Apple Developer Program.

But first, I stopped being a Mac user long ago; second, I don't make a living from the Mac or iOS; third, I'm only developing a free software project that I like and give away at no cost, and its source code and build process are all public, right there. So I have no wish at all to spend 99 dollars every year feeding this company, which wants to control even the ways you pay.

Makima: “Do you remember what Apple did to out-of-store payments?”

Kishibe: “”

Kishibe: “”

Kishibe: “Out-of-store payments…?”

Although I already mentioned that this project was meant to be a “native desktop application”^*1 from the start, this is a question people really do ask sometimes, so let me answer it here anyway.

I know there are some KiSS implementations which can run in a Web browser by using Web technologies directly, but they are (technically and architecturally) awkward when you want to turn them into a desktop application integrated with your OS and file system; and such a thing which actually can be done in a lightweight way should not need a browser at all.

On top of that, I would have to keep chasing Electron's breaking API changes, there's npm, a super uncontrollable thing that makes packaging a hassle and can even get poisoned, and the compatibility between Node versions and Electron versions to deal with (not to mention the versions of each distro)...., and so on and so forth. Taking all of this into account, for a small project like QKiSS, I don't believe at all that developing and maintaining it with Electron or Web technologies would cost less, and I can guarantee that I would have a miserable time developing and maintaining it.

• I'm a KDE user, and Qt feels the most seamless to use.
• Qt Widgets is mature and stable: its major versions last for years, with few API breaks. I don't have to build any widgets myself, and I can get 80% of the features done with hardly any third-party libraries.
• Rust would need a binding, and then I'd have to worry about its API breaks, its quality and its extra pitfalls, plus the Qt C++ patterns that don't translate directly into Rust. I'd have two things to keep up with, Qt and the binding, and I'd lose all the help from Qt Creator.
• I want to practice C++.

• This project does use help from LLMs, but keeps it under control as much as possible, with various engineering methods (e.g. isolating LLM agents in KVM virtual machines, the principle of least privilege, and reviewing commits by hand).
• No damn vibe coding, ever, in the main program (Qt / C++) or in the Python code. Even with help from LLMs, the code was reviewed and modified by hand, line by line: I can understand and explain every line of it. I also proofread the translations by hand, as much as my broken foreign languages allow.

How much LLMs directly generated in each area

• Qt / C++ 10%
  • Microsoft Copilot
  • ChatGPT
  • Claude

  Discussing design patterns, finding suitable Qt APIs, and writing some examples for difficult Qt APIs (e.g. the delegates of MVC).
  Since v0.9.3, I have used LLM agents for trivial debugging and fixes.
  The CRT simulation, though, was developed entirely by an LLM agent, because I am burned out: my passion for this project has almost burned to ashes, and I just want to finish it quickly and get it out the door.

• Python 40%
  • Microsoft Copilot
  • ChatGPT

  Rough scaffolds (e.g. argparse) and some snippets. Learning the latest “Pythonic” ways, and the best practices of type annotations in Python 3.

• Translations 80%
  • Microsoft Copilot
  • Codex
  • Claude Code

  Translating the strings in *.ts from English or Japanese into the other languages, then fixing them by hand, line by line.

• FKiSS specification Docstrings only
  • Claude

  Collecting all the FKiSS commands from the FKiSS references in HTML, and organizing them into a formal list and docstrings in fkiss.cpp.

• CMake 60%
  • ChatGPT
  • Gemini

  Surveying and discussing the best practices of CPack and CMakePresets.json for a cross-platform Qt app. Learning Windows packaging, NSIS and the deployment of DLLs.

• GitHub Actions 60–70%
  • Gemini
  • ChatGPT
  • Claude Code

  For the Windows packages (I have no Windows development environment). Before the public release, I realized that fighting this was a waste of time, so I let an LLM agent debug it and write the rest of the code.

• osc / RPM / DEB 40–70%
  • Gemini
  • ChatGPT
  • Claude Code

  Learning the many detailed rules of DEB and RPM packaging, troubleshooting, and how to build locally with osc. Discussing how to connect the CI/CD of GitHub Actions to the _service of OBS. Before the public release, I let an LLM agent debug it and write the rest of the code.

• Security measures 90%
  • Claude
  • Claude Code
  • ChatGPT

  Claude Code is in charge of directly writing the code that uses Linux APIs like Landlock and seccomp (but all of it was still reviewed by hand afterwards, 100% of it, even though my knowledge of security is no match for an LLM's anyway, heh). It is also in charge of extracting the parts suitable for QKiSS from the AppArmor profiles that the author of QKiSS uses privately, and organizing them into compatible packages for each distro. ChatGPT also took part in the security review of the C++ code.

• This website 80%
  • Claude Code

  All the translations, and all the HTML / CSS / JS… I can't be bothered anymore to spend my free time writing web pages.

• Icons 0%

  Tango / Nome / Humanity are all forked from versions of the era before LLMs appeared. All the icons forked afterwards, and QKiSS's own icons, are hand-drawn by the author of QKiSS with Inkscape.

• Writing 0%
  • Claude Code

  All the text of this website and the README is hand-written by a human. LLMs are only in charge of translation or grammar correction, and of talking the author out of writing anything even more aggressive.

…Argh, I guess this might be my last project whose code is mainly written by hand… Not only KiSS itself: another era is over.