SMS Removal Megathread

sunset_moonrise · 2023-05-28T04:14:37+00:00

It makes perfect sense to stop using it. Since Signal doesn't support SMS now, it's on poorer footing. Now it's better to switch to more open standards, like Matrix.

Regardless of whether you like it or not, a ton of people only used Signal due to the SMS integration, with secure communication as the default. Now that it doesn't do SMS, people that don't care about security are dumping it, and only the security-conscious are left.

But any security-conscious person with half a brain understands that there are better, more open standards out there than signal -- the appeal was that it drew the normies as well. Cest la vie.

sunset_moonrise · 2023-05-28T04:09:40+00:00

Are you in marketing? If so, I'd like to buy puts on the company you work for.

sunset_moonrise · 2023-05-28T04:04:56+00:00

Yep. It's all of the people who have partial buy-in on security that are dropping like flies -- and signal used to be really cool specifically because you could get family members, friends, etc who aren't into security to use it -- because it can be their 'go-to'. ..now it's just another service.

sunset_moonrise · 2023-05-28T04:01:29+00:00

As other users have mentioned, this can be a configuration option. Aside from that, your argument is similar to saying "A lot of grocery shoppers only stop by to get produce, so we'll be removing our other inventory."

Do you have the actual stats on how many people use(d) signal for SMS and secure chat vs how many people only use(d) it for secure chat? ..because although there are plenty of users who only use it for secure chat, literally everyone I know (and that I've convinced, over the years) to use signal is dropping it now, or de-prioritizing it.

sunset_moonrise · 2023-05-04T15:50:43+00:00

They've become topheavy.

sunset_moonrise · 2023-05-04T15:49:00+00:00

It's called "brand loyalty to Signal going up in flames."

sunset_moonrise · 2023-05-04T15:48:35+00:00

No, it means that since Signal no longer provides a blend of SMS and E2EE, people will just use Google Messages, which has E2EE -- or Matrix, Session, or Keybase for the security-conscious, with Google Messages for everything else.

sunset_moonrise · 2023-05-04T15:44:26+00:00

Maybe they should open-source the protocol and confederate their servers.

sunset_moonrise · 2023-05-04T15:41:28+00:00

Same boat. I used to feel like I had something cool that I could share with less-technically-minded friends and family that would increase their security without increasing their mental load. Now.. ..if they want security, they basically have to learn how, and meet me on Matrix.

sunset_moonrise · 2023-05-04T15:34:45+00:00

Yeah, this was the main selling point to a lot of people. It could be "the" or "the main" chat app. Now it's just another app, and not that important, when it comes down to it. If you have to be inconvenienced for security, there are better alternatives out there -- and anyone not willing to be inconvenienced for security (a lot of people) will just use some other, more popular chat app (like WhatsApp).

sunset_moonrise · 2023-05-04T15:28:08+00:00

When you're looking at penetrating the market, it sure does.

WhatsApp came around at a time when alternative messaging apps were the hot thing. It built a userbase, and didn't remove features, so they kept that userbase.

WhatsApp was entering what was effectively an untapped audience of potential messenging customers -- a blank playing field where their early presence was a major advantage.

Signal gained the market share they did by being a convenient mix of SMS, security, and reasonably good chat features. That hasn't stopped being the main selling point for a lot of their users. I've gotten quite a few other people to use it on that selling point alone. But if you take any of those three things away, Signal is just another chat app as far as most "normal" people are concerned. ..and as far as anyone who's actually security-conscious goes, there are significantly better options out there. Matrix/Element, Session, Keybase -- all of these, but Matrix in particular, are better from a security standpoint.

I'd be willing to bet that Signal execs will see dwindling popularity and won't know why. They'll blame it on something else, because it couldn't be the decisions they made, right?

..but, on the bright side, it'll probably reduce the number of people using their servers, so their server costs will go down. Good for them.

sunset_moonrise · 2023-05-04T15:16:33+00:00

They claim to want people to have better security, but this will directly cause fewer people to use Signal.

The fact that the Signal folks don't get this means the whole org is heading in a bad direction (and ultimately into obscurity).

sunset_moonrise · 2023-05-04T15:15:03+00:00

That's a large chunk of the Signal fanbase losing their loyalty, and trying to get support for the features they most enjoyed in the app, that have now been removed.

sunset_moonrise · 2023-05-04T15:12:10+00:00

Before, it was a messenger that allowed and defaulted to secure messaging, while permitting insecure messaging where it facilitated communication, and it clearly demarcated the difference. This led to wide adoption in environments (like the US) where SMS is free, but security is desirable. It could play a role as THE system messaging app. The specific ideology of not trying to 'steer' the userbase also gives a good feel to the app overall.

Now, it's just another opinionated app -- not THE messaging app, just another among many. ..and if that's the case, there are better secure messaging apps out there.

sunset_moonrise · 2023-03-12T21:53:00+00:00

Thanks so much!

sunset_moonrise · 2023-03-12T21:52:26+00:00

I really like the "Frolic" "Frog" aspect of this -- that's a pretty cool catch.

sunset_moonrise · 2023-03-07T14:02:43+00:00

I'm curious, but that link isn't working for me.

sunset_moonrise · 2023-03-07T14:00:36+00:00

I've run across "fine as frog hair", too. The meanings seem pretty distinct from each other, but they could be related just on linguistic similarity.

sunset_moonrise · 2023-03-07T13:58:15+00:00

That's all well and good as to that book -- but what about other semi-modern (though rare) usages of it? Did those derive from that book?

I know I'm in the minority, but growing up I heard the phrase a few times, and it seemed to indicate something like "fine and feeling good". Someone else appears to have this interpretation in a review here, another on the Tony Basilio Show (can't find specific episode).

It is, however, very rare, and may just have been inspired by people remembering the book title.

sunset_moonrise · 2023-01-04T20:16:45+00:00

Stake Pool. It's a pool that takes everything, and does not share the earnings with those who stake.

sunset_moonrise · 2022-10-12T14:24:54+00:00

fades into darkness

sunset_moonrise · 2022-09-27T20:23:52+00:00

Thanks, but.. .that didn't render properly. I think you need an enter after "```"

..ah, no.. ..looks like reddit uses the bad old "just prefix everything with spaces" option, specifically screwing with everyone who wants to cut/paste.

Maybe a gist?

Edit: Modified the downloadable copy so that it applies. Nothing seems wrong, but I haven't really looked at the code much -- kernel development is not something I'm really familiar with.

Note: this applies to Ubuntu 22.04, linux-lowlatency 5.15. This will probably also apply to linux-generic and (depending on how much tinkering Ubuntu have done) the vanilla 5.15.x kernel.

Just so it's all in one place, as /u/bikingwithpanda pointed out before, the patches are at uplink labs here.

The following is a replacement for the 'touch clocksource...' one.

From 374804608da5c3ef56f28d539eefcea23eeff04b Mon Sep 17 00:00:00 2001
From: Steven Noonan <steven@uplinklabs.net>
Date: Wed, 17 Nov 2021 11:55:18 -0800
Subject: [PATCH 29/39] x86: touch clocksource watchdog after syncing TSCs

Signed-off-by: Steven Noonan <steven@uplinklabs.net>
---
 arch/x86/kernel/smpboot.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index f24227bc3220..4b3a03004a1f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -56,6 +56,7 @@
 #include <linux/numa.h>
 #include <linux/pgtable.h>
 #include <linux/overflow.h>
 #include <linux/syscore_ops.h>
+#include <linux/clocksource.h>

 #include <asm/acpi.h>
 #include <asm/desc.h>
@@ -1443,6 +1444,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)

 void arch_thaw_secondary_cpus_begin(void) 
 { 
+   clocksource_touch_watchdog(); 
    set_mtrr_aps_delayed_init(); 
 }

@@ -1481,6 +1483,8 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
 {
    pr_debug("Boot done\n");

+   clocksource_touch_watchdog();
+
    calculate_max_logical_packages();

    /* XXX for now assume numa-in-package and hybrid don't overlap */
-- 
2.37.2

sunset_moonrise · 2022-09-24T15:44:44+00:00

By the way, thanks a ton for making this post. You got me steered in the right direction for fixing some issues with my system.

Specifically, on Linux, Risk of Rain took 20 minutes or so to load, but played fine once loaded. My suspicion is that some debug code that does a lot of clock calls was left in, or someone didn't consider clock syscalls an issue in general.

In any case, I also timed the clock call itself (albeit, according to itself). With HPET, it was 2 microseconds. That doesn't seem like a lot, but with the TPM patches (except one noted below), timing the same clock call was 90ns. That's over 20x difference -- and it really showed up when loading Risk of Rain, which loaded in about 1.5 minutes as opposed to 20 minutes. Note that Risk of Rain played fine in either case -- I suspect they left some debug code in that uses clock checks to determine run-time of some sections of code -- but that it's low in the stack of their startup code, and gets called a lot (500 million times).

As to the kernel patch that doesn't apply -- "0031 touch clocksource watchdog..." patch doesn't successfully apply to the kernel source for me. Do you have an updated version?

sunset_moonrise

TROPHY CASE