Telegram removed from the App Store for 'inappropriate content'

Are you saying that Facebook is responsible to make decisions for us - because all it takes is one advertisement to override the average human's discipline and self control?

Facebook taking down cryptocurrency gambling ads is much different than Apple removing a general purpose instant messenger. You're finding a connection you want to find, I'm guessing based on your knowledge of PnD groups being on Telegram, that being your sole exposure to Telegram, and your opinion on cryptocurrency.

Apple is very conservative with adult content which I consider the far more likely reason, be that buggy image search, some kind of trending view that porn snuck into, that kind of thing.

Think about what you're suggesting.

Y'all are right, there a probably very could counterarguments to that, but I don't think that makes Apple potentially any less liable.

I think the interesting thing to note here is that for most end users a standard protocol is not nearly as appealing as a standard user interface. Like how most iOS apps follow common navigation paradigms, so users don't need to spend time learning each new one. And how people tend to prefer buying things on Amazon instead of any random webshop. And how WeChat has almost become a little web of its own with custom chat UIs for e.g. ordering pizza. If open software for consumers is ever to stop being beaten by these walled gardens, it needs to get a ton more UX people involved and focus on the end user UX, not just the technical implementation.

Subscriptions to web-based services don't count as paying for web sites?

There's more to the Internet than websites. Believe it or not, there are lots of protocols out there, not just HTTP.

Imagine a city where public parks are all bought out by private entities, that is the Internet right now.

We have less and less public space in the digital world and that is not looking good for the future of democracy.

It's always been Apple vs The Rest Of The World.

Are there? Really? No, they're not. No one who isn't in tech is going to install F-droid. Few people will uninstall untrusted sources, or even know what that is. Fewer Apple users than ever jailbreak their phones.

For over 90% of the market, no, there are no alternatives (other than a mobile website). Due to the non-standard nature of ARM and SoC/binary drivers, we don't even have a real alternative OS for old Android devices that's universal like most Linux distros on the PC in the 90s (although PostmarketOS is making some huge strides in this area).

30% is an insane cut. Bandcamp sells music with a 15% cut, literally half of Amazon/Google/Apple. I always prefer it because I know the band gets more money and I get a higher quality version of the song without a patent encumbered codec (FLAC and OGG downloads are supported).

But no, there are no real alternatives. AppStore/Play are bastardizations of the software repo concept from Linux.

If Google Play was a real package managers, it'd keep standardize shared jar files across apps (dependencies to reduce massive app size) either by mirroring maven repos and signing dependencies or creating their own system, and they'd also allow for easily adding 3rd party app trees.

Both Apple and Google are closed walled gardens, where everything you need has to be contained in your bloated package, and where their corporate overlords get final approval of what is in and out.

After all, there are alternatives to bridges, why do the travelers opt to pay the fee?

-- Obviously, /s

Talking about my own experience, once we've made clear that In-App Purchase wasn't a fit for us as we already had our own payment system (we are a SaaS business), things got way more difficult to us. As you can imagine (but I didn't at the time), our app would be in review for weeks sometimes, we started to see arbitrary denials and a lot of "issues" not present on their guidelines started to be identified on our apps.

If there is one thing that I'm now sure is that, if you decide to not play their game (even though following their rules) there will be retaliation.

Not if you want to build a secure system which runs on an iPhone, there aren't. JavaScript crypto is fundamentally insecure; the only secure option is a native client.

Pictures from birthdays and everyday life to aunts/uncles and grandparents etc.

Many also use it for social/professional groups (again many-to-many) where it offers simplicity but also includes moderation features in "supergroups" that can have up to 100 000 users.

Lately I've also joined a few channels. Channels are one-to-many (or rather: one or a few-to-many)

As for why Telegram it is super easy to use, it seems well aligned with my interests in that it's owner already lost his previous company to authorities and seems obsessed with preventing that from happening again.

That said: if your life or professional life depends on strong crypto I'd think twice or more as certain bright and leading cryptographers seems to distrust/hate it.

(Anyone who needs that should think carefully anyways but Signal seems to be a good option that is also aligned with the users interests.

WhatsApp is often recommended as well and they also seem to have solid crypto but I actively avoid them as they've broken too many promises already and also has a owner that is not aligned with my interests.)

Telegram is a messaging app with group chat you can join and others where you're invited to. And bots of varying utility.

It's pretty handy, and how deep you go is up to you.

https://telegram.me/ebanistika

I was referring to the recently re-discovered paper about group chats (e.g. https://www.helpnetsecurity.com/2018/01/11/whatsapp-signal-g... paper here: https://eprint.iacr.org/2017/713.pdf)

https://conversations.im/omemo/audit.pdf

Tells you everything you want to know about Signal. Or read the secushare comparison page:

http://secushare.org/comparison

Here, some choice quotes from the OMEMO audit that pertain to the Signal protocol:

"Metadata

The protocol leaks metadata about who is communicating with whom and how much they are communicating. Alice’s request for the server cache leaks to the server that she wants to start a conversation with Bob, as does the PreKeySignalMessage. The plaintext message counters that are included in each SignalMessage make it possible to track the rest of the conversation. Unlike the ratchet used in the Signal Protocol, the regular variant of the Double Ratchet [24] also encrypts the message headers, which would make it possible to avoid tracking of the conversation. It would only make sense to implement this if this information is not leaked already in the transport layer."

"Message authentication

Messages are authenticated by the randomized key, which protects the message integrity from outsiders. However, anyone with access to the key can alter the message, which includes a malicious device. There are a few possible mitigations, each with their advantages and disadvantages. A possible solution would be to authenticate inside the Signal session. By authenticating the payload with the tag of the SignalMessage, the full message is authenticated in such a way that no other device can compromise the integrity. The ciphertext (and not the plaintext) of the payload message should be authenticated, so that the MAC-then-encrypt pattern is applied.8 This solution increases the computational load on the sender side, because the payload needs to be authenticated more than once. When the ciphertext is added as authenticated additional data (AAD) of the Signal message, it would reduce the message size slightly, because no authentication tag is required on the payload. The payload encryption method should then be simplified to a non-authenticated block cipher mode. It will also require some alterations on the Signal library, as the current implementation does not allow the library user to add their own AAD. The payload can also be authenticated by including a hash of the payload ciphertext in the SignalMessage plaintext (and therefore the corresponding encrypted hash in the SignalMessage ciphertext). This would not require changes to the Signal library, but it would increase the size of each <key/> element. This solution is less elegant than the previous, as the hash of the payload ciphertext is sent encrypted, even though the recipient can compute this value themselves. By authenticating a list of all recipient device ids in the tag of the SignalMessage, Bob has a guarantee about which devices Alice has sent the message to. Bob’s client might provide him with a warning if that list includes untrusted devices. This protects him against the specific attack described above, but the protocol remains vulnerable if one of the devices gets compromised by another attack. This solution can be combined with the above solution of authenticating the payload ciphertext with the SignalMessage ciphertext or tag."

"Device linkage

There is no cryptographic link between identities and device keys. In other words, Eve can attach her own device identity key as if it is a resource belonging to Bob and fool Alice into adding it. There is a solution: each device could sign a certificate on each device identity key of the same user. While Eve might fool Alice into thinking that Bob has another device, it is highly unlikely that Bob is tricked into accepting another device as his own. Device identity keys with a certificates that was signed by an already accepted device of the same user could be accepted automatically. In order to account for compromised devices, users must have the ability to revoke certificates and certificates should have a finite lifetime. This solution can be extended into a full-blown public key infrastructure (PKI) or web of trust, but I recommend to keep that out of the scope of the OMEMO specification (although compatibility with such systems could be taken into account when updating the OMEMO specification)."

Granted, most of these come down to issues solvable in UX - but Signal doesn't. And the deceptive UX like the disappearing messages (which, for obvious reasons, can't expire on the server and get synced [and subsequently deleted from the client] until the last device has it), because the Signal developers only consider it a "convenience feature" (a fact which they offhandedly communicated in their blog, but think about it, how many users actually read that?), the whole phone number binding, and... Ugh. Just ugh. I don't wanna continue because Signal nauseates me. It's not that it's bad, it's not, but that doesn't mean it doesn't suck.