Defense against Signal may not be total, but if you build from source (or use a reproducible build) you can check to be pretty sure you have the same software as everyone else, in which case a backdoor would have to be in a public version of Signal, which means any backdoor has a chance of getting discovered.
Backdoors can be well-hidden, but this is the kind of software that people look for vulnerabilities in [1]. This gives a lot less flexibility to any potential backdoor.
Additionally, someone could decide to write a new Signal client from scratch, designed to be compatible with the original server. Such a client would probably be less secure overall, at least at first, but it couldn't have a backdoor inserted by Signal developers, since it wouldn't contain any Signal code. Since the original client also supports end-to-end encryption, a new client can be compatible with old clients.
Maybe I am misunderstanding the summary, but it says: "If you publicly use any adapted version of this database, or works produced from an adapted database, you must also offer that adapted database under the ODbL." <https://opendatacommons.org/licenses/odbl/summary/>
Although copyright-infringing books may be illegal to redistribute in general, the difficulty in determining what counts as copyright infringement and what counts as fair use means you can't really tell for sure which books are illegal to distribute and which aren't, so I'm not sure that really counts as "banned". 60 Years Later had an actual court order which makes things a little more concrete.
Woah, I just realized (because of this comment) that I've been grouping "technique" and "technology" as a single thing in my understanding and calling it "technology"/"tech".
For example, I would describe a method to do something in a video game as "tech" but in my mind I would expand it to "technology" if I thought about it. I didn't realize that the word "technique" would be a better fit in those contexts. Looking at Wikipedia [1], it looks like the words are pretty closely related so I haven't been using the word completely wrong.
> At that point, people shouldn't buy the product if they disagree with the conditions.
I think a problem with this idea is that terms of service can be difficult to understand. For example a lot of licenses or terms of service forbid "reverse engineering" entirely. In my mind, "reverse engineering" is just trying to understand something based on observing what it does, and even though a legal agreement is probably using a more strict definition, how am I supposed to know where the boundary is? "Reverse engineering" isn't usually defined in the agreement itself. And if what I want to do is considered "reverse engineering", it might not be legally enforceable anyway.
Sometimes I buy a physical object, take it home, and then open it and find conditions that I would have disagreed with if I knew about them. I've noticed this with books, but the same could happen with software. I don't know if conditions like that would be legally enforceable, but I think the complexity of understanding this makes individual decisions about what conditions to accept a poor solution to what Stop Killing Games is trying to solve.
The Steam Subscriber Agreement [1] seems to prohibit reverse engineering games (referred to as "content" in the agreement), but I guess I'm misunderstanding it because some GPL games are on Steam (e.g. SuperTux [2]).
I agree that people shouldn't buy a product if they disagree with the conditions, but I think this is too complicated for most people to do for every product. Maybe some of these conditions should be illegal to even put in a terms of service, even if they already aren't enforceable.
There's also the free culture movement, which generally believes all creative works should be free, not just software.
There are many people who would advocate for free software and not free culture, but jxself has also written in support of free culture: https://jxself.org/drm_and_free_culture.shtml
That post is from 15 years ago, so of course he could have changed his views since then (but I don't see any evidence of that in this case).
Would you happen to know where the requirement that "“there is no way” you can make the radio do what the FCC doesn’t allow" comes from? I found an FCC compliance guide [1] but it's very long and not easily searchable as far as I can tell.
If there has to be no way to change the radio's functionality, would that mean that simply using a binary blob wouldn't be enough. Wouldn't device vendors have to sign it as well?
Also, that makes me wonder about the one Wi-Fi chip I know of that does have free firmware: AR9271 [2]. I wonder what makes that situation different. Maybe I'm misunderstanding and there's firmware on a separate chip stored in ROM.
It's not the same as what you suggest, but there's still hope you could regain consciousness, and this is a process that some companies already have infrastructure for. It is pretty expensive though.
A connection to Microsoft's servers will also be required to download the game in the first place, so I'm not sure this is really a problem (for compliance with the bill). I think the official launcher won't even let you download the game without authenticating first, but I'm not sure.
Does Minecraft's offline mode not work indefinitely? I'm not familiar with the official launcher but this article [1] doesn't say anything about needing to reconnect occasionally.
This would be a way better outcome than the current default. I've even seen this suggested before [1].
If game-specific logic is not public, information needed for reverse engineering could be completely missing, but if game-specific logic is available plus the names of the missing libraries, reconstruction of the game should be possible eventually.
What software do you use for the reCAPTCHA on archive.today? I use a fork of hacktcha [1] but I had to modify the software myself to get it to work conveniently [2], so I'm curious how other people do it.
1. Any given system has a finite number of findable vulnerabilities.
2. All findable vulnerabilities are fixable (if not in software then with a new hardware revision).
3. Fixing a vulnerability while keeping the same intended functionality introduces on average less than 1 other findable vulnerability.
4. It is possible to cease adding new features to a system and from that point forward only focus on fixing vulnerabilities.
If all 4 are true, then perfect security seems possible, in some sense. I think some vulnerabilities might not be fixable, if you include things like the idea that users can be tricked into revealing their passwords. If you restrict the definition of vulnerability to some narrower meaning that still captures most of what people mean when they say computer vulnerability, then I think those 4 statements are probably true.
Perfect security might be near impossible in practice because vulnerabilities will get more difficult to find and fix over time, but I think we should expect the discovery of vulnerabilities to eventually become arbitrarily slow in a hypothetical system that prioritized security above all else.
Would you be willing to license this code as GPL-3.0-or-later, or some other free license? I'd like to include a JavaScript derivative of this for Haketilo (a userscript manager). I would add it to a collection of scripts that aim to replace proprietary JavaScript here: https://codeberg.org/JacobK/unfinished-site-fixes/
In this case, it also seems like the paywall doesn't show up if you have JavaScript disabled, which I find strange, but lots of news sites are like that I think.
Backdoors can be well-hidden, but this is the kind of software that people look for vulnerabilities in [1]. This gives a lot less flexibility to any potential backdoor.
Additionally, someone could decide to write a new Signal client from scratch, designed to be compatible with the original server. Such a client would probably be less secure overall, at least at first, but it couldn't have a backdoor inserted by Signal developers, since it wouldn't contain any Signal code. Since the original client also supports end-to-end encryption, a new client can be compatible with old clients.
[1] https://community.signalusers.org/t/overview-of-third-party-...