nym's avatar
nym
nym@primal.net
npub1hn4z...htl5
nym's avatar
nym 1 year ago
Don’t Use Session (Signal Fork) Last year, I outlined the specific requirements that an app needs to have in order for me to consider it a Signal competitor. Afterwards, I had several people ask me what I think of a Signal fork called Session. My answer then is the same thing I’ll say today: Don’t use Session. The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy (which is an important security property of cryptographic protocols they inherited for free when they forked libsignal). Lack of forward secrecy puts you in the scope of Key Compromise Impersonation (KCI) attacks, which serious end-to-end encryption apps should prevent if they want to sit at the adults table. This is why I don’t recommend Tox. And that observation alone should have been enough for anyone to run, screaming, in the other direction from Session. After all, removing important security properties from a cryptographic security protocol is exactly the sort of thing a malicious government would do (especially if the cover story for such a change involves the introduction of swarms and “onion routing”–which computer criminals might think sounds attractive due to their familiarity with the Tor network). Unfortunately, some people love to dig their heels in about messaging apps. So let’s take a closer look at Session. ![](https://m.stacker.news/73122) originally posted at
nym's avatar
nym 1 year ago
The slow death of TuxFamily TuxFamily is a French free-software-hosting service that has been in operation since 1999. It is a non-profit that accepts "any project released under a free license", whether that is a software license or a free-content license, such as CC-BY-SA. It is also, unfortunately, slowly dying due to hardware failures and lack of interest. For example, the site's download servers are currently offline with no plan to restore them. originally posted at
nym's avatar
nym 1 year ago
The Great Unpermissioning It starts with a click: “Do you agree to our terms and conditions?” You scroll, you click, you comply. A harmless act, right? But what if every click was a surrender? What if every "yes" was another link in the chain binding you to a life where freedom requires approval? This is the age of permission. Every aspect of your life is mediated by gatekeepers. Governments demand forms, corporations demand clicks, and algorithms demand obedience. You’re free, of course, as long as you play by the rules. But who writes the rules? Who decides what’s allowed? Who owns your life? originally posted at
nym's avatar
nym 1 year ago
RSYNC: 6 vulnerabilities Two independent groups of researchers have identified a total of 6 vulnerabilities in rsync. In the most severe CVE, an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on. originally posted at
nym's avatar
nym 1 year ago
The future of gig economy runs on relays The employment trends in the gig economy are clear. More and more people take on some form of freelance or temporary work often on top of their full time job. In fact, according to recent estimates, approximately 1.57 billion people, or nearly half (46.4%) of the global workforce, engage in gig work. As gig platforms continue to expand across borders and sectors, this number is projected to keep rising. ![](https://m.stacker.news/72850) In the UK, the gig economy is particularly popular, with many workers supplementing their income with side gigs. According to a recent survey, almost half (48%) of UK gig workers have full-time jobs on top of their side gigs, while 71.5% use gig work to supplement their income rather than provide their sole earnings. The top gig occupation in the UK is online administrative work, with 39% of gig workers offering virtual assistance, data entry, clerical services, or similar computer-based tasks. Sounds like a great way to earn some sats, doesn't it? Despite the growth and popularity of the gig economy, traditional platforms like LinkedIn have reached their peak and become increasingly plagued by spam from aggressive recruiters and profiles of people with increasingly unverifiable experience. Meanwhile all the centralised platforms like Fiverr and Upwork take a significant cut from freelancers' pay, leaving many workers feeling undervalued and overworked. It's no wonder that many are looking for alternative solutions that prioritize fairness, transparency, trust and compensation paid in money that will last! Here comes Nostr, a decentralized, censorship-resistant protocol that's laying foundations for the future of the gig work. With its censorship-resistant, peer-to-peer approach, Nostr is poised to revolutionize the way we work and connect with each other. In this article, I'll explore why Nostr is an exciting development for the gig economy, what it means for the future of work and what platforms are already available. What makes Nostr different? It’s built on principles of decentralization, freedom, trust and Bitcoin as its native currency. Forget walled gardens; with Nostr, your identity is your own. Nobody’s mining your data, and no shadowy algorithms are deciding who sees your posts or what posts you should see. It's a perfect setup for a job marketplace where companies post jobs and freelancers get them done. All paid with Bitcoin with no middleman to take your money And it’s not just theory. Real solutions are already built, transforming how professionals connect, collaborate, and commit their skills, time and creativity. All open-source and Bitcoin/Nostr-centric. originally posted at
nym's avatar
nym 1 year ago
Challenges to funding open source I’ve had the good fortune to get paid to write open source as part of my job several times. For more than 15 years, I’ve also done a lot of open source development in my free time as a volunteer. Along the way, there’s been a fairly constant refrain that it’d be better if more open source maintainers were paid to maintain their projects. And I’ve seen a lot of ideas for how that could happen. While some of these ideas were successful, many more were not. I’m writing this post to explain three reasons that I’ve seen open source funding concepts fail. These aren’t the only reasons, but they’re reasons that I think are often ignored in the discourse. This is not a normative piece, I’m not expressing an opinion on if anything here is good or bad. This is entirely descriptive of the things I have seen. **You can’t articulate what it is people are funding** Specifically, you can’t articulate how the world with funding would be different than the world without it. For many maintainers, the ideal form of open source funding is something like: instead of working on my project in my spare time, I get paid to do it and I can do it during the work day instead of stealing time from my other hobbies and personal obligations. Unfortunately, if you’re asking someone for money, this doesn’t tell them anything they’re getting for their money. The underlying premise here is that if you can maintain your project without stealing time from other activities that the project will be more sustainable. This is a better premise, but still falls short, because sustainability is not about anything being different, it’s in fact about things being able to stay the same more predictably. Rationally, this sort of risk mitigation may make sense to invest in, but practically its a very difficult to assess risk (What are the odds that the existing maintainers will stop doing so as volunteers? Who knows! Many open source projects go years, if not decades, with exclusively volunteer maintainers). This explains why we see so little of the open-source funding that does occur is justified in this way. If you are an open-source maintainer, be prepared to articulate: what will be different from the status quo if you have more time and money to work on your project. Is there a major feature that needs dedicated design and implementation time? A queue of bugs that need to be triaged and fixed? All of these are concrete things that can motivate people to support an open source project. **Many open source maintainers do not want to be paid** Or more accurately, they don’t want the expectations that come with taking money. If you’ve accepted money, that generally comes with some expectations (see the previous section). However, for many open source maintainers, having no expectations is the point. For many folks, open source is enjoyable to work on precisely because you can reject features that offend your sensibilities, even if many users want them. You can take as long as you want until you find a design you like, you don’t have to ship something “good enough”. You can walk away for months if you’re bored, frustrated, or just don’t feel like working on the project. There’s nothing wrong with this mode of maintainership (indeed, in my experience, having this approach makes my own open-source work more sustainable, even if it is entirely nights and weekends). But if this is why you love open-source, it is going to be challenging to find a way to take money for it without compromising some of what makes it enjoyable for you. **Time and money are not interchangeable** For open-source developers with a full time job, money does not translate into significantly more time for their project, unless the money is at the level of replacing a full time salary. It can offset some costs in life, and may be very appreciated. But the largest time obligation most people have is their day job, and for folks with full time jobs, a fraction of their salary doesn’t buy them extra hours in a week. This means that for many open-source developers, small sums of money do not substantially increase their capacity to maintain their project. It doesn’t give them additional time to implement features, fix bugs, or triage issues. This means that to have an impact, open-source maintainers often need to find salary-replacement level funding for their open-source work. This combines poorly with another simple observation: many open-source projects, including critical ones, do not make particular sense to fund at a full time level. A library for a stable compression format, for example, does not make sense to staff for 40 hours a week, that much time cannot be used efficiently. Of course, even if the format is stable there’s more than 0 hours a week of work! There’s porting to new platforms, updating for yet another backwards incompatible change in a dependency or CI platform, triaging bug reports, performance improvements, etc. Perhaps some projects are so critical that as a society that we should fund them as a full-time endeavor even though the scope doesn’t justify it. However, one risk this carries is that developers who find themselves in such a position will need to be on guard against the temptations that more time provides, such as backwards incompatible changes for limited value and adding features of marginal value but with substantial new attack surface. As an open-source maintainer, ask yourself how your life situation allows you to channel money effectively into work on your project, and what the scope of your project reasonably justifies in terms of hours spent on it. originally posted at
nym's avatar
nym 1 year ago
Viewing images How hard would it be to display the contents of an image file on the screen? You just load the image pixels somehow, perhaps using a readily available library, and then display those pixels on the screen. Easy, right? Well, not quite, as it turns out. I may have some experience with this, because I made an image viewer that displays images in the terminal emulator. But why do such a thing, there are countless image viewers already available, including those that work with terminal emulators, why write yet another one? That’s an excellent question! As always2, the answer is because no other viewer was good enough for me. For example, catimg uses stb_image to load images. While stb_image is an outstanding library that can be integrated very quickly, it doesn’t really excel in the number of image formats it supports. There’s the baseline of JPEG, PNG, GIF, plus a few other more or less obscure formats. Another example is viu, which again is limited to the well-known baseline of three “web” formats, with the modern addition of WebP. Following the dependency graph of the program shows that the image loading library it uses should support more formats, but ultimately I’m interested in what the executable I have on my system can do, not what some readme says. The overall situation is that there is widespread expectation and support for viewing PNG files (1996), JPEG files (1992) and GIF files (1987). So… what happened? Did image compression research fizzle out in the XXI century? Of course not. There’s JPEG XL (2022), AVIF (2019), HEIC (2017),3 WebP (2010). The question now is, why is there no wide support for these image codecs in software?4 Because nobody uses them. And why is nobody using them?5 Because there’s no software support. So maybe these new formats just aren’t worth it, maybe they don’t add enough value to be supported? Fortunately, that’s easy to answer with the following image. Which of the quality + size combinations do you prefer? ![](https://m.stacker.news/72844) But that’s not all. There is a variety of image formats that are arguably intended for more specialized use. And these formats are old, too. Ericsson Texture Compression (ETC) was developed in 2005, while Block Compression (BC) and OpenEXR date back to 1999. BC is supported by all desktop GPUs, and virtually all games use it. ETC is supported by all mobile GPUs. So why is it nearly impossible to find an image viewer for them? And speaking of texture compression, I also have an ETC/BC codec which is limited in speed by how fast the PNG files can be decoded. There are some interesting observations if you look into it. For example, PNG has two different checksums to calculate, one at the zlib data stream level, and the second at the PNG data level. Another one is that zlib is slooow. The best you can do is replace zlib with zlib-ng, which provides some much-needed speed improvements. Yet how much better would it be to replace the zlib (deflate) compression in PNG files with a more modern compression algorithm, such as Zstd or LZ4? The PNG format even supports this directly with a “compression type” field in the header, but there’s only one value it can be set to. And it’s not going to change, because then you’d have to update every single program that can load a PNG file to support it. Which is hopeless. originally posted at