You misidentified your objection. It isn’t sideloading removal, which isn’t happening. It’s developer verification, which affects the sideloading that remains available.

Just because you don’t understand the value of verifying signatures doesn’t mean it lacks value.

I recall the same alarm over secureboot: there, too, we can (load our certificates into secureboot and) sign everything ourselves. This locks down the system from boot-time attacks.

I will never ever ever be able to get friends and family access to third-party applications after this change.

Then sign it: problem solved.

Developer verification should also give them a hard enough time to install trash that fucks their system and steals their information when that trash is unsigned or signed & suspended.

Even so, it’s mentioned only in regard to devices certified for and that ship with Play Protect, which I’m pretty sure can be disabled.

Google promised they would allow on-device sideloading

Promise kept.

their word means fuck-all and you know that

No, I don’t. Developers are always going to need some way to load their unfinished work.

Signal being easy to rely on is its biggest benefit. No one will adopt something that’s more complex, but I don’t think extra complexity would offer better security for the average person. More complexity just means more things to go wrong.

My concerns on this are more that acceptable share in something in the internetworked world seems to be in percentages far smaller than the usual common sense percentages. Like - there are political systems with quotas, and there are anti-monopoly regulations, but with computers and the Internet every system is a meta-system. Allowing endless supply of monopolies and monocultures.

Signal is so easy to rely, that if you ask which applications with zero-knowledge cryptography and reliable groupchat encryption and so on people use, that are available without p2p (draining battery and connectivity requirements), with voice calls and file transfers, it’ll be mostly Signal.

Doesn’t matter it’s only one IM application. In its dimension it’s almost a monoculture. One group of developers, one company, one update channel. An update comes with a backdoor and it’s done.

It’s not specifically about Signal, rather about the amount of effort and publicity that goes into year 2002 schoolgirl’s webpage is as much as any separate IM application should get, if we want to avoid dangers with the Internet which don’t exist in other spheres. And they usually get more. The threshold where something becomes too big with computers is much smaller than with, I don’t know, garden owner associations.

Even if there are already backdoors put by their developers in a few very “open”, ideologically nice and friendly and “honorable” things like Signal, then such backdoors can exist and be used for many years before being found.

I mean, there are precedents IRL, and with computers you are hiding the needle in a much bigger hay stack.

Obviously I’m no smarter than this person

I’m bloody certain you are smarter than this person in everything not concerning things they were directly proficient in. And while being an idiot, they would stuck their nose into everything not their concern in very dangerous (for others, not for them) ways.

but without cryptography how is any “secure” project actually “secure”.

There are security schemes, security protocols, security models, and then there is cryptography as one kind of building blocks, with, just like in construction materials, its own traits and behavior.

In the end, I personally think having an easy to use platform that is secure gives everyone amazing power to recoup their free speech wherever is it eroded.

And I think the moment anything specific and controlled by one party becomes popular enough to be a platform, we’re screwed and we’re not secure.

Reminds of SG-1 and the Goauld (not good guys, I know) adjusting their spawn genome for different races.

Perhaps something like that should be made, a common DSL for describing application protocols and maybe even transport protocols, where we’d have many different services and applications, announcing themselves by a message in that DSL describing how to interact with them. (Also inspired by what Telegram creators have done with their MTProto thing, but even more general ; Telegram sometimes seems something that grew out of an attempt to do a very cool thing, I dunno if I was fair saying bad things about Durov on the Internet.)

A bit like in Star Wars Han Solo and Chewbacca speak to each other.

And a common data model, fundamentally extensible, say, posts as data blobs with any amount of tags of any length, it’s up to any particular application to decide on limits. Even which tag is the ID and how it’s connected to the data blob contents and others tags is up to any particular application. What matters is that posts can be indexed by tags and then replicated\shared\transferred\posted by various application protocols.

It should be a data-oriented system, so that one would, except for latency, use it as well by sharing post archives as they would by searching and fetching posts from online services, or even subscribing to posts of specific kind to be notified immediately. One can imagine many kinds of network services for this, relay services (like, say, IRC), notification services (like, say, SIP), FTP-like services, email-like services. The important thing would be that these are all transports, all variable and replaceable, and the data model is constant.

There can also be a DSL that describes some basics on how a certain way of interpreting posts and their tags works and which buttons, levers and text fields it presents, kinda similar to how we use the Web. It should be a layer above the DSL that would describe verification of checksums, identities, connections, trust, who has which privileges and so on.

Except all these DSLs should be concise and comprehensible, because otherwise they will turn into something like TG’s protocol in complexity and ugliness.

OK, I have temperature and I think I’ve lost my thought.