I don’t see how spreading FUD and being misinformed are exclusive. I didn’t say he was doing so in bad faith, just stating that the comment created fear, uncertainty and doubt without any factual basis.
To be fair Wikipedia does say it is a manipulative propaganda tactic but I’ve usually meant it in the abovementioned context.
I don’t doubt that in the future Google will kill off the AOSP and disable installing custom ROMs like Apple does. But it just isn’t accurate to say that in 200 days sideloading on GOS won’t work or that Google disabling sideloading on their ROM even affects GOS in any way.
TL;DR The above commenter is spreading FUD. GOS will work fine and allow sideloading.
Stop spreading FUD. Google kills sideloading on Google certified ROMs. Being Google certified doesn’t mean you have more features than ROMs which aren’t certified. Only Google certified ROMs lose the ability to sideload and have to adhere to all Google Play policies. Meaning GOS loses its certified status but doesn’t lose the ability to sideload. The only way in which GOS might be coerced to disable sideloading is if Google pushes these changes upstream to the AOSP and even then forking is always an option. Also when has Google ever hinted at disabling flashing custom ROMs? It might be right down their alley but I wouldn’t make such claims without citing sources.
Just as a side note: Android ≠ AOSP. This is relevant as many people misunderstand the news they read. When Google changes Android (Google’s proprietary AOSP “distro”) it doesn’t necessarily mean that changes are coming to the AOSP or GOS which is also an AOSP “distro”.
Reading through this forum thread is recommended.
I’d really love to see some Blink based browser comparisons, especially Trivalent (which is supposed to be compareble to Vanadium).
Made me chuckle. Truly a comment-of-the-month material.
Never! BSD bros are fellow comrades in arms against the corpos.
BSDs get too little love imho. They have more potential of becoming complete, usable and safe OSs than most Linux distros. Wish they would be discovered/talked about as much as Linux this past year.
Have you enabled local network discovery?
Maybe Peergos?
Tuta’s trancparency report vs Posteos
A reasonable argument and I agree that impersonation is still possible without the scammer taking the excact username but it’ll still be easier to fool your contacts when you don’t have an active account.
For example consider two worlds - in one you have an instagram account, in the other you don’t. The world in which you have the account, people who only know you through that account and don’t use other platforms where you’re on, are less likely to fall victim to scams because they can always verify that the scammers account isn’t your account. In the other world this isn’t possible and thus it is more likely people who don’t know you directly will believe the scammer.
Also my point on the cost of the account still stands. I do admit that having an open account which gets scraped is an issue but if you have a “private” account, most of the 3rd parties lose access to it’s content. Although I’m sure three letter agencies and meta have a custom API which can query all accounts, public or private, the point you’re trying to make is moot, as if we’re talking about opsec, if you already have an (insta) account, all it’s data is logged somewhere and it likely won’t be deleted in the near future.
Unlike most other messengers, Delta Chat apps do not store any metadata about contacts or groups on servers, also not in encrypted form. Instead, all group metadata is end-to-end encrypted and stored on end-user devices, only. Servers can therefore only see:
- the sender and receiver addresses and
- the message size.
By default, the addresses are randomly generated. All other message, contact and group metadata resides in the end-to-end encrypted part of messages.
https://delta.chat/en/help#message-metadata
> Doesn’t store any metadata on servers
> Servers still see the sender and reciever and the message size
Explain how this is not contradictory.
Furthermore my original argument on protocol blocking still stands (if almost all communication platforms rely on a widely used protocol, the blocking of which is infeasble, then how is this a feature noone else besides deltachat has).
And as the FAQ brilliantly illustrates, you don’t have to block the mail protocol to inhibit deltachat users from communicating. All you have to do, is just shut down the relays which are crucial to masking your metadata.
Speaking of relays, all they do is transfer the trust. Without using relays you have to trust that normal mail servers wont’t log your activity (they do). With relays you have to trust that the relay operators won’t log your activity.
Perhaps they’ve changed, but last I checked they didn’t allow IMAP/POP3 due to “security concerns”.
Deltachat can’t be considered as private as Signal, SimpleX, Briar, Threema or Cwtch due to the fact that it’s based on the mail protocol. The mail protocol will always leak metadata (who, to whom, where and when) because it could’t function otherwise. And because we live in a world of surveillence, metadata can be oftentimes more valuable than the message itself.
Also saying that deltachat is unblockable because it is based on the mail protocol would be the same as saying that every app utilizing VOIP is unblockable because it uses the TCP/IP stack and blocking it would render the internet unusuable.
An email provider who doesn’t lock you into their ecosystem and doesn’t collaborate with law enforcement without putting up a fight.
I would advise against deleting your account. When you delete your account you also forfeit your username which can then be used to impersonate you. While I’m not sure on the exact math, it would seem logical that having a stagnant account keeps up their costs but doesn’t bring in almost anything resulting in a net loss on an account basis.
They just changed the maintainers? What in this thread does not give you confidence?
Only a Sith deals in absolutes!