What are you talking about? Signal is open source, and its cryptographic security is trivially verifiable. If you don't trust the nonprofit behind it for whatever reason, you can simply compile it yourself.
> and its cryptographic security is trivially verifiable
That's going quite far. Even with all the details of it documented and open, there's a relatively small number of people who can actually verify that both the implementation is correct and the design is safe. Even though I can understand how it works, I wouldn't claim I can verify it in any meaningful way.
Sure, there are teams who have done it. But it's not trivial. The fact there's a price for it shows it's not trivial. If I choose a random developer, it's close to guaranteed they wouldn't be able to reproduce that. The chances go to 0 for a random Signal user.
Alternatively: it's trivial for people sufficiently experienced with cryptography. And that's a tiny pool of people overall.
The idea isn't that you do formal verification of the protocol every time you run it. It suffices for the protocol to be formally verified once, and then just to run that one protocol. If you thought otherwise, you might as well stop trusting AES and ChaCha20.
It is possible for the core protocol to be tightly secure, while a bug in a peripheral area of the software leads to total compromise. Weakest link, etc. One-time formal verification is only sufficient in a very narrow sense.
It is also possible for a state-level adversary to simply hijack your phone, whatever it is, and moot everything Signal does to protect your communications. Cryptographically speaking, though, Signal is more or less the most trustworthy thing we have.
In some sense, no - the protocol protects the contents of your messages. In another sense, yes - a compromised server is much easier to collect metadata from.
Metadata, yes. Of course, the protocols, and thus all the inconveniences of the Signal app people constantly complain about, are designed to minimize that metadata. But: yes. Contents of messages, though? No.
If Signal, the service, was designed to minimize metadata collection, then why is it so insistent on verifying each user's connection to an E.164 telephone number at registration? Even now, when we have usernames, they require us to prove a phone number which they pinky-swear they won't tell anyone. Necessary privacy tradeoff for spam prevention, they say. This isn't metadata minimization, and telephone number is a uniquely compromising piece of metadata for all but the most paranoid of users who use unique burner numbers for everything.
This is the most-frequently-asked question about Signal, it has a clear answer, the answer is privacy-preserving, and you can read it over and over and over again by typing "Signal" into the search bar at the bottom of this page.
The answer is not privacy-preserving for any sense of the word "privacy" that includes non-disclosure of a user's phone number as a legitimate privacy interest. Your threat model is valid for you, but it is not universal.
The question you posed, how Signal's identifier system minimizes metadata, has a clear answer. I'm not interested in comparative threat modeling, but rather addressing the specific objection you raised. I believe we've now disposed of it.
I don't believe there has been any such disposition in this thread. There have been vague assertions that it's been asked and answered elsewhere. Meanwhile, the Signal source code, and experience with the software, clearly demonstrates that a phone number is required to be proven for registration, and is persisted server-side for anti-spam, account recovery, and (as of a few months ago, optional) contact discovery purposes.
I don't know, a lot? They could with the same amount of effort just get Google to ship a backdoored operating system. Or the chipset manufacturer to embed a hardware vulnerability.
The cryptography is not where Signal is vulnerable. What Signal is running on, as in operating system and/or hardware that runs other embedded software on "hidden cores", is how the private keys can be taken.
Anything you can buy retail will for sure fuck you the user over.
Retail hardware actually has a better track record at the moment than bespoke, closed market devices. ANOM was a trap and most closed encryption schemes are hideously buggy. You're actually better off with Android and signal. If we had open baseband it would be better, but we don't, so it's not.
Perfect security isn't possible. See "reflections on trusting trust".
Bespoke but-not-really-bespoke closed-market devices made by the right people are very secure, but they are not sold to the profane (you).
> ANOM was a trap
Yes, ANOM was intended to be a trap.
> and most closed encryption schemes are hideously buggy
Yes they are. Hence some of us use open encryption schemes on our closed-market devices.
> You're actually better off with Android and signal.
I am better off with closed-market devices than I am with any retail device.
> If we had open baseband it would be better
And the ability to audit what is loaded on the handset, and the ability to reflash, etc. In the real-world all we have so far is punting this problem over to another compute board.
> Perfect security isn't possible.
Perhaps, but I was not after "perfect security", I was just after "security" and no retail device will ever give me that, but a closed-market device already has.
The main reason I use a Google Pixel is because of its automated call screening feature. I crank it up to maximum sensitivity (screen all unknown numbers) and answer every call that gets through because it's always a human, and it's never a spam call. I'm surprised more smartphone companies haven't already implemented similar features.
The most important features of my Pixel phone are all the ways it prevents me from getting unwanted phone calls and text messages. It's pretty good at it.
We've allowed the entire telephone medium to get corrupted by scams. It has been ruined.
I don't get why other phones don't do this. Is it complicated? I think it just plays a recorded voice greeting. It's simpler than a answering machine. There is no fancy AI or anything like that.
Telcos already keep this information and Google having it as well doesn't really change much. Both are going to sell it plus give it up to law enforcement when asked.
It doesn't play any kind of greeter. Seems to be an online database of spam numbers, I receive calls marked as Spam with a big red exclamation mark. it's not as simple as blocking any calls that aren't already contacts. I could never use that professionally.
It simply rejected calls that lacked caller ID, which is what I assume the GP meant by unknown callers. It wasn't only Nokia either, every single phone that I have ever owned has been able to do this. Its right there alongside novel features such as "sending a text" or "making a phone call."
If you meant the Pixel feature then there are probably lots of videos and posts covering it.
I have one from Verizon since they are my carrier. For free it does an amazing job blocking spam calls. If I was willing to pay (I’m not) it would tell me what kind of spam call it is.
Not worth the price.
I still don’t answer calls unless they’re in my address book or I’m expecting one. But I get very very few calls anyway thanks to the app.
And they are allowed to leave voicemails, which they never do. Real callers do if I get an unexpected genuine call.
Add in the features iOS has had in the last few releases to be able to see transcriptions of voicemails, now live as they’re being left, and most of the hassle is gone.
The spammers trained everyone to stop answering. I shouldn’t have to do any of this. But it’s better than it was a few years ago.
I mean, the paper's been published. The cat's out of the bag. If a sufficiently motivated villain wants to use this technology for villainy, they can now.
Eh, I wouldn't count on it. Transit's trying to compete with the behemoths, and this seems to be their latest shot at securing a competitive advantage. I, too, hope they open-source their work eventually, but I also want to see them succeed in disrupting the transportation navigation space! (Not that those things are mutually exclusive, of course.)
How many different dentists have you been to in the past twenty years? Does she see the same dentist as you now?
I once had a dentist who claimed I had a cavity every visit. I saw him once a year, and he did little more than look at my teeth. I've since switched dentists three times as I moved around the country and my dental insurance changed, and with all three, I've gotten nothing but rave reviews about the state of my teeth. I see my latest dentist twice a year, and he does an X-ray and an intraoral scan every other visit, and on my most recent visit, he discovered that one of those alleged cavities my first dentist had filled was filled improperly and appeared to have become reinfected. Unfortunately for me, I was busy at the time and postponed treatment for too long, and now the filling has fallen out and the tooth has collapsed in on itself, requiring a root canal and a crown, which in addition to being somewhat painful, will likely set me back several thousand dollars.
If you have access to the Journal of American Medicine (JAMA), I highly recommend reading this recent review of overdiagnosis and overtreatment in dentistry[1]. If you don't have access to JAMA, you can find pertinent excerpts in this Reddit post[2], along with some interesting backlash from some thoroughly offended dentists (all of it without any real supporting evidence, of course, though some of the points brought up are worth considering).
I think my current dentist might be overdiagnosing a bit, we were doing a bunch of work even though another dentist said everything was fine just a year before. My biggest regret currently is a decade old root canal done by my previous dentist that was never good and kept getting sore and inflamed in the gums. The new dentist eagerly redid the root canal a year ago but we eventually had to pull it out since a big abscess formed. Looking back, I should've extracted it sooner, since the bone was basically eaten away by lingering bacteria and I'll have to do some bone augmentation for an implant.
I ask about the tools I will be using during the interview process. There are several that I refuse to work with and will end the interview at the next possible polite point if they are required. Microsoft Windows is on my blacklist.
The entire point of private retirement accounts and transferable skills is that you aren't required to stick with one employer. If your employer requires you to use bad tools then find a better employer.
Entire industries are almost exclusively Microsoft (basically all those that make the modern civilized world work: medical, transportation, semiconductor, logistics, automotive, industrial, architecture, infrastructure, CAD, etc).
Your choice then is unemployment. Not everyone is an app/web developer who can freely choose employers based on stacks and tools, end even then, not in a bear market. Most people wishing not to be homeless don't have the choice of saying no to employment just because they use Windows.
Your comment is the equivalent of "let them eat cake".
My last Windows OS is Windows XP and I've never been unemployed.
Going through the Windows stack has significant disadvantages to your career as well. Those companies are likely to pay less than their competitors, they are usually less modern and offer less remote options or modern development organizations. It's a lose, lose choice.
>My last Windows OS is Windows XP and I've never been unemployed.
Like I said, not every office worker is a front-end dev. In other industries you have no choice but unemployment. Your lack of empathy towards other classes is showing.
>Going through the Windows stack has significant disadvantages to your career as well.
I don't know many but I've never met a .NET or SharePoint dev who's unemployed. On the contrary. All those crusty non-IT corporations seem to pay very well for others to fix their Microsoft stack. Maybe take your head out of the sand and see the real world.
It's in your own example, you are less likely to find remote working, modern development practices or competitive salary at your average SharePoint gig compared to your average fullstack, devops or data engineering job.
I don't think you know the meaning of the world suffering.
And data science and IT infra/support are different career choices that differ around skills and education rather than choice of OS vendor. Those jobs are not interchangeable.
Even if otherwise, it's not like you can move from .NET dev to DS jobs on a whim whithout any kind of experience or specialization.
And where I live .NET jobs are far more abundant and better paid than DS jobs which are few and have loads of coopetition from newgrads due to all they hype they genrated.
That's exactly what I meant by suffering from the market yeah. That's another reason why I'm not working on windows. I'm enjoying higher salaries and better working conditions thanks to that.
Also development is a global market nowadays so that makes it even worse for this kind of jobs since they don't usually offer a remote option. It's telling that you say "where I live", where I live there's just no development job at all actually.
You still haven't proven how those people making a living on .NET/Microsoft stacks careers are suffering. Habe you actually seen people suffering, like from war and poverty?
Also, dvelopment careers being "global" is mostly in theory. In practice it doesn't work everywhere. Some countries don't have global remote work opportunities due to tax and labor laws making that very difficult meaning you're stuck with what the local market offers. And those few global remote jobs get hundreds of applications so actually getting one is almost impossible especially in the current bear market.
There's no shortage of full stack developers globally willing to work for cheap. Competing globally in this race to the bottom is no good if you work in a high CoL area unless you score a high paying FaNG or scale-up but getting such jobs is insanely competitive that's not realistic for most people I know.
That's some hyperbole right there, I'm just saying that they get paid less than they could and generally have worse working condition that they could have, that's all. Again, that's okay if they are aware of this tradeoff.
> There's no shortage of full stack developers globally willing to work for cheap.
That has to be the worst argument here, even Microsoft themselves outsources their own .NET work to India.
Parent comment here, chiming in days after this thread.
My primary purpose in making my comment was to help employees that feel stuck using bad tools. I hope my advice helps to encourage people to look for better opportunities, and to consider the software they will be using in those opportunities. I have given dozens of technical interviews, and no one has ever asked me "what is your development setup like?" as part of the interview. I wanted to share with other people my little trick.
Maybe my comment smells of privilege, but this is a privilege anyone can claim. After all, all tech workers have transferable skills and access to private retirement accounts.
>On the flip side, your comment is "Thank You Sir May I Have Another?"
I never said that. I said in many industries that choice is none existent other than unemployment and people care more about employment than they do about OS martyring.
Sure. But just because that's true of some industries doesn't make it true of all industries. Your comment comes across like rejecting hx8's practice because it could not be universal.
Even your use of 'martyring' is bizarre. My avoidance of Windows for the last 20 years is a mild discomfort, not martyrdom.
There is a long history of using one's privilege to help those with less privilege. If hx8 "entitlement" changes the workplace to allow Ubuntu as an alternative to MS Windows, then those with less privilege may be able to follow.
By rejecting hx8's practice, you close off that pathway.
reply