cultural reviewer and dabbler in stylistic premonitions

  • 29 Posts
  • 265 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle
  • When it’s libre software, we’re not banned from fixing it.

    Signal is a company and a network service and a protocol and some libre software.

    Anyone can modify the client software (though you can’t actually distribute modified versions via Apple’s iOS App Store, for reasons explained below) but if a 3rd party actually “fixed” the problems I’ve been talking about here then it really wouldn’t make any sense to call that Signal anymore because it would be a different (and incompatible) protocol.

    Only Signal (the company) can approve of changes to Signal (the protocol and service).

    Here is why forks of Signal for iOS, like most seemingly-GPLv3 software for iOS, cannot be distributed via the App Store

    Apple does not distribute GPLv3-licensed binaries of iOS software. When they distribute binaries compiled from GPLv3-licensed source code, it is because they have received another license to distribute those binaries from the copyright holder(s).

    The reason Apple does not distribute GPLv3-licensed binaries for iOS is because they cannot, because the way that iOS works inherently violates the “installation information” (aka anti-tivozation) clause of GPLv3: Apple requires users to agree to additional terms before they can run a modified version of a program, which is precisely what this clause of GPLv3 prohibits.

    This is why, unlike the Android version of Signal, there are no forks of Signal for iOS.

    The way to have the source code for an iOS program be GPLv3 licensed and actually be meaningfully forkable is to have a license exception like nextcloud/ios/COPYING.iOS. So far, at least, this allows Apple to distribute (non-GPLv3!) binaries of any future modified versions of the software which anyone might make. (Legal interpretations could change though, so, it is probably safer to pick a non-GPLv3 license if you’re starting a new iOS project and have a choice of licenses.)

    Anyway, the reason Signal for iOS is GPLv3 and they do not do what NextCloud does here is because they only want to appear to be free/libre software - they do not actually want people to fork their software.

    Only Signal (the company) is allowed to give Apple permission to distribute binaries to users. The rest of us have a GPLv3 license for the source code, but that does not let us distribute binaries to users via the distribution channel where nearly all iOS users get their software.


  • Downvoted as you let them bait you. Escaping WhatsApp and Discord, anti-libre software, is more important.

    I don’t know what you mean by “bait” here, but…

    Escaping to a phone-number-requiring, centralized-on-Amazon, closed-source-server-having, marketed-to-activists, built-with-funding-from-Radio-Free-Asia (for the specific purpose of being used by people opposing governments which the US considers adversaries) service which makes downright dishonest claims of having a cryptographically-ensured inability to collect metadata? No thanks.

    (fuck whatsapp and discord too, of course.)


  • it’s being answered in the github thread you linked

    The answers there are only about the fact that it can be turned off and that by default clients will silently fall back to “unsealed sender”.

    That does not say anything about the question of what attacks it is actually meant to prevent (assuming a user does “enable sealed sender indicators”).

    This can be separated into two separate questions:

    1. For an adversary who does not control the server, does sealed sender prevent any attacks? (which?)
    2. For an adversary who does control the server, how does sealed sender prevent that adversary from identifying the sender (via the fact that they must identify themselves to receive messages, and do so from the same IP address)?

    The strongest possibly-true statement i can imagine about sealed sender’s utility is something like this:

    For users who enable sealed sender indicators AND who are connecting to the internet from the same IP address as some other Signal users, from the perspective of an an adversary who controls the server, sealed sender increases the size of the set of possible senders for a given message from one to the number of other Signal users who were online from behind the same NAT gateway at the time the message was sent.

    This is a vastly weaker claim than saying that “by design” Signal has no possibility of collecting any information at all besides the famous “date of registration and last time user was seen online” which Signal proponents often tout.




  • You can configure one or more of your profiles’ addresses to be a “business address” which means that when people contact you via it it will always create a new group automatically. Then you can (optionally, on a per-contact basis) add your other devices’ profiles to it (as can your contact with their other devices, after you make them an admin of the group).

    It’s not the most obvious/intuitive system but it works well and imo this paradigm is actually better than most systems’ multi-device support in that you can see which device someone is sending from and you can choose to give different contacts access to a different subset of your devices than others.






  • The primary purpose of those buttons is of course to let those sites track everyone’s browsing activity across every site that uses them, which does not require that anyone ever click on them.

    Even if less than 0.0001% of people click them, anyone with an SEO/spammer “grindset” will assure site operators that the potential benefit of someone sharing a link they otherwise wouldn’t have is still at least theoretically non-zero. And, since there is absolutely no cost at all besides an acceptable number of extra milliseconds per pageload, really, it would be downright irresponsible not to have them there!




  • Arthur Besse@lemmy.mlMtoLinux@lemmy.mlWhat was Linux like in the 90s
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    25 days ago

    encryption would prevent the modem from seeing it when someone sends it, but such a short string will inevitably appear once in a while in ciphertext too. so, it would actually make it disconnect at random times instead :)

    (edit: actually at seven bytes i guess it would only occur once in every 72PB on average…)







  • Arthur Besse@lemmy.mlMtoLinux@lemmy.mlA good e-mail client for linux?
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    2 months ago

    still of Obi-wan Kenobi in Star Wars with subtitle "Now, that's a name I've not heard in a long time. A long time."

    At first i thought, wow, cool they’re still developing that? Doing a release or two a year, i see.

    I used to use it long ago, and was pretty happy with it.

    But looking closer now, what is going on with security there?! Sorry to be the bearer of probably bad news, but... 😬

    The only three CVEs in their changelog are from 2007, 2010, and 2014, and none are specific to claws.

    Does that mean they haven’t had any exploitable bugs? That seems extremely unlikely for a program written in C with the complexity that being an email client requires.

    All of the recent changelog entries which sound like possibly-security-relevant bugs have seven-digit numbers prefixed with “CID”, whereas the other bugs have four-digit bug numbers corresponding to entries in their bugzilla.

    After a few minutes of searching, I have failed to figure out what “CID” means, or indeed to find any reference to these numbers outside of claws commit messages and release announcements. In any case, from the types of bugs which have these numbers instead of bugzilla entries, it seems to be the designation they are using for security bugs.

    The effect of failing to register CVEs and issue security advisories is that downstream distributors of claws (such as the Linux distributions which the project’s website recommends installing it from) do not patch these issues.

    For instance, claws is included in Debian stable and three currently-supported LTS releases of Ubuntu - which are places where users could be receiving security updates if the project registered CVEs, but are not since they don’t.

    Even if you get claws from a rolling release distro, or build the latest release yourself, it looks like you’d still be lagging substantially on likely-security-relevant updates: there have actually been numerous commits containing CID numbers in the month since the last release.

    If the claws developers happen to read this: thanks for writing free software, but: please update your FAQ to explain these CID numbers, and start issuing security advisories and/or registering CVEs when appropriate so that your distributors will ship security updates to your users!