Saw this exact claim on a billboard not too long ago
It's a strangely worded statement. What about data collection, metadata, other third parties
Maybe it's related to the fact that plaintiffs lawyers are now trying to verify what's going on inside Meta with WhatsApp through litigation discovery:
You can't unless you've chosen to back up your WhatsApp messages to iCloud/Google in which case it's Apple/Google responsible for preserving the messages and subject to their encryption standards, nothing to do with Meta.
Try logging in on a new device and putting your main device into aeroplane mode as soon as the login succeeds. Loading of old messages on the new device will stop.
Moxie Marlinspike (founder of Signal) [0]implemented the same E2EE algorithm as Signal (Signal Protocol) into WhatsApp, but that was 10 years ago, so who knows if things have changed since then.
Practically speaking, it isn't secure; no closed app can be. It receives regular compulsory updates (old versions refuse to work) and there's nothing at all stopping Zuck from sneaking in backdoors targeted at you personally.
Nobody gives a damn. What matters is that it works even on a potato.
SMS security only became a problem due to 2FA, which is just one of many use cases, and the failure isn't even technical here but organizational. I agree it should've prompted more pressure to secure the system against SIM-swapping; alas this is too close to the Real World, so the tech industry instead responded with alternative that side-steps the problem by offering zero customer support. No humans to talk to = no humans to social engineer = secure. So much win.
(I'd also say the 2FA proliferation is itself a problem, but that's an unpopular opinion and for a separate discussion.)
> Nobody gives a damn. What matters is that it works even on a potato.
It doesn't work on my computer, nor does it work on my phone when I'm traveling (different SIM), so I give a damn. WhatsApp, iMessage, Signal etc. do both. I really wish there was an open, federated standard (and no, RCS is neither), but until then, I'll use what actually works for me.
SMS just sucks, and I hate that it's become so ubiquitous an authentication method when it's not even secure.
You can rent a virtual mobile number in your home country and consult SMSs on the web or even redirect them to email. I have done this for years, using Twilio for 2€ a month. Can't say the UX is great but it certainly fixes the whole problem.
I've never understood why so many people still chain their identities to physical SIM or even eSIMs. It's so fragile.
> I've never understood why so many people still chain their identities to physical SIM or even eSIMs. It's so fragile.
Living in a place where getting a replacement sim is gated behind obtaining an id from the police tied to your national id number, I wish there were other identity systems which were as robust. Much easier to get back to normal operations when the id device becomes damaged or lost with a physical sim you can shove into a cheap replacement device, than relying on backup services you need one of your digital id devices to access in the first place, especially if they're all lost at the same time in a house fire or something. The police will presumably get all my photo backups and savings if they ask nicely anyways, so the big threat to the single point of failure doesn't have a great marginal impact, while I dread the possibility of having to recover the accounts I can't get back through the local legal system given the poor 2fa recovery ecosystem.
>Much easier to get back to normal operations when the id device becomes damaged or lost with a physical sim you can shove into a cheap replacement device
If the device can get damaged or lost, then the SIM can too. To buy a physical SIM or rent a virtual number online, in most jurisdictions you need to provide ID docs these days, so nothing is changed there.
Yeah, that's a good workaround. Google Voice can work too.
Unfortunately, more and more services are declining to send to VoIP numbers because of seCurItY, so it's a game of cat and mouse.
Fortunately SMS is so expensive in parts of Europe and it's not allowable anymore to use SMS by itself for online payment authentication, and both issues combined have slowly been pushing companies to explore alternatives.
There unfortunately seems to be no such pressure in the US. Passkeys could solve the issue, but probably increase support request volumes enough for most companies to not bother unless forced.
It's easy and cheap to determine the original carrier (or its sucessor) for a US phone number. It costs money to do a porting lookup to determine the current carrier.
Most of the reason to deny voip users is that many voip services give phone numbers away like candy and then those phone numbers are used to abuse other services, so checking the original carrier tends to be enough for abuse screening.
Some use cases want more though. Banking KYC has some back channel to get subscriber identification or be alerted when ownership changes; those institutions may be willing to pay for current carrier lookups and deny usage of numbers where they don't have a back channel to the current carrier.
In the US, I belive there are three number categories in the NANP porting database (wireline, cellular, and VoIP), and SMS senders can definitely tell, even though it might take a while (presumably there's a lot of caching going on).
If you're lucky, the service you care about only validates at number registration time, not at text sending time, and you can get away with it indefinitely, I suppose.
I thought that too but many carriers around me don't allow porting any VoIP-using number back to cellular. (Not sure if you were making a distinction between landline and cellular)
Unfortunately that means that my cell number which I wanted to temporarily park into VoIP while abroad is now permanently VoIP.
Also, the studio paid a professional to peep at all the inter-frame pixels and turn the knobs right when they encoded the bluray. I might be able to get a perceptually lossless rip that's 25-50% smaller than the original, but it's just not worth my time.
I don't because that would be impossible. Every business has different rules. But if you (as a business) want to to use this, you will find a way to make the changes to those "middleboxes". It's not your network, it's your business's network.
Large multi-national corporations, by way of their sheer size, tend to force their vendors to bend towards their needs, not to adapt to meet their vendors' unusual networking requirements.
Of all the SSH servers in the world, what percentage are listening on a port other than 22? To answer this question, you can visit https://data-status.shodan.io/ports.html and see for yourself.
By "unusual," I literally mean "not usual/not typical." Not "never happens."
I'll explain it once again, then leave this thread:
Companies frequently put egress network policies in place that confine certain protocols like SSH and HTTP to certain ports. They do this in order to achieve compliance with regulations, to achieve security or operational certifications, or simply because they're paranoid. It's not necessarily the least restrictive means of accomplishing their goals, but that's what they do. And if they're big enough, they're going to use the size of the deal and their brand equity to persuade their vendors, who might ordinarily prefer to offer a service on a nonstandard port, to provide it on the customer's preferred port instead.
If you still don't understand, I'm sorry, but I cannot assist further.
Companies might do that. They have the right to do so. If they still want to use that service, they will find a way to use it. Be it by vendor-coercing or simpler methods.
Just because those companies exist, does not mean that their shitty practices have any imapct on real internet connections. If you as a paying ISP customer want to use a custom port or whatever, it is going to work. So you as a developer don't have any restriction (which you don't know anyway beforehand) if you are developing a solution for a problem.
"Middleboxes" is a hackernews meme that is thrown around because people here work at places who restrict stuff and they can't bother to change that situation but instead complain about it.
The fact that games exist and they use all kind of ports is proof that this is not a problem for normal networks.
I think the previous post is talking about a search that will find the sibling domain names that have obtained certificates with the same account ID. That is a strong indication that those domains are in the same certificate renewal pipeline, most likely on the same physical/virtual server.
Run ACME inside a Docker container, one instance (and credentials) for each domain name. Doesn't consume much resources. The real problem is IP addresses anyway, CT logs "thankfully" feed information to every bad actor in real time, which makes data mining trivially easy.
This is publicly publishing the account ID. There is an optional extension in RFC8659 that extends it but it isn't required by any implementer. This puts that ID into a public well known location that is easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).
Very resource constrained systems, systems where consistent admin between *BSD and Linux is important. Containers where you have reasons to break the single process practice.
reply