I completely misread the article's title....
When you put disgusting in quotes you may leave those of us with failing vision to potentially misread the rest of the title and get the impression of other parts of the internet that are "not so nice".
Microsoft recently outlined several new features it is building into Windows 11, from file recommendations and one-keystroke shortcuts for the XAML context menu in File Explorer to Local Security Authority (LSA) protection against secrets and credential thefts. However, buried at the bottom of the Windows 11 Insider Preview …
…that when I hear Microsoft describe a protocol as “disgusting” and overdue for replacement, my immediate reaction is “it’s from the bad old days when IT was ruled by techies not clever people with MBAs; in other words, we can’t monetize it, or use it to get adverts to the end-user”.
I am getting too cynical.
I can tell Microsoft what is far more "disgusting":
1. Forcing shite like "Focussed Inbox" out turned on.
2. Forcing upgrades to Windows 10 even though users had said NO.
3. Forcing out "reactions" on 365 without even putting in a mechanism for admins to turn that shite off. You have to ask Microshaft to put your tenant on an "exclusion" list.
4. Constant changes to application UIs for no reason other than some idiot in Microshite thinks they need to "improve" it.
5. Defaulting Teams to loading at startup and making the "FFS, stop that sh*t" option only accessible after it has loaded. And yes, I know that's the only way they can Netscape Zoom and Webex out of existence before starting to charge for their own (coming soon! April, I think), but that doesn't make it right. And it has arguably the worst UI Microsoft has ever inflicted on software, and given its history that is saying something. Someone in Microsoft must have won an award for this because it's too decrepit to be accidental.
Surely search for and run "Startup Apps", scroll down to the entry for Teams, toggle Off.
My dear boy, that convention is only for other companies, just like MS likes to use API calls that are undocumented so nobody can compete on a level playing field, can't have that..
Trust me, I have tried, but Teams shows that Microsoft DOES learn from virus infections, but only how to write their own: which is Teams.
Yes and no. The problem is, a lot of these protocols, like SMB 1 were designed and implemented before computers were regularly attached to the Internet - heck most probably never even had a 10Base2 card installed in them, so they never even experienced SMB 1.
So, security wasn't an issue, because, if a PC was connected to a network, it was your network and it only had other devices you controlled on it, so security wasn't even an afterthought. Move forward to the mid 90s and those PCs often came with a network card as standard, an RJ45 Ethernet, if you were lucky, running at 100mbps if you were very lucky and more and more companies were exposing themselves to the Internet and individual PCs often had a modem attached/built-in to allow them to dial up an Internet connection...
And SMB was exposed to the Internet for all to enjoy... Over time things changed and a bit of security was slapped on as an afterthought, but it still wasn't serious though. Fast forward another decade and we had the debacle that was Windows XP & Microsoft hunkering down to make it at least partially secure, something they've been trying to do ever since. SMB evolved to include more and more security by default. Which gave us SMB 2 and SMB 3, and as stated in the article SMB 1 being turned off by default in the mid noughties.
But, there are still fairly new printers around (2016 or newer) that do "scan to share" and expect the server or PC they are connecting to to be using SMB 1, because it is simple and lacks any security that would mean having to actually configure things properly, thus annoying office managers that just want to scan to their PC and don't care about security...
So, the TL;DR answer is: Remote Mailslots is a fine protocol, if you are managing your own network and have no access to the Internet. If you do have Internet connectivity and are still using it, just put a gun to your head now and pull the trigger, it will save you a lot of pain in the long run.
"SMB 1 being turned off by default in the mid noughties."
SMB1 was only turned off by default starting with Windows 10 in mid-tens.
"But, there are still fairly new printers around (2016 or newer) that do "scan to share" and expect the server or PC they are connecting to to be using SMB 1"
Please name and shame.
Ricoh, for example:
Products affected when SMBv1 is disabled
Functions affected when SMBv1 is disabled
The following functions will no longer be able to operate via SMB when SMBv1 is disabled.
1. Scan to Folder
2. Fax Folder Transmission (SMB only)
3. Fax Forwarding (SMB only)
4. Windows authentication
5. SMB printing
Suggested alternatives when SMBv1 is disabled
If SMBv1 is disabled, the following alternatives can be used.
1) Scan to Folder
- Scan to FTP
- Scan to E-mail
- Store the file to a Document Server and then retrieve it via Web Image Monitor
- Scan to URL
- Scan to Media
2) Fax Folder Transmission (SMB only)
-Store received faxes in the Document Server
-Stored faxes can be retrieved via Web Image Monitor
3) Fax Forwarding (SMB only)
-When faxing, enable “Send and Store” to save a copy in the Document Server
4) Windows authentication
- Use LDAP authentication
5) SMB printing
- Change OS settings to use a different printing method like DIPRINT (port9100), LPR, or IPP
Although it seems that most have a firmware update since I first encountered the problem and now support SMBv2 and most now support SMBv3. But directly after Wannacry, that wasn't the case.
Kyocera was in a similar situation for a while, although I haven't tried one lately (last couple of years), we just switched to scan to mail back in the late teens.
It's true that SMB 1 dates back to 1983, which is prior to Flag Day, so it wouldn't even be fair to say that IBM ought to have defaulted to IP as the underlying transport and just used UDP for datagram protocols; at the time, it wasn't at all clear that IP was going to win the networking wars.
And when SMB 1 was implemented in LAN Manager on top of NetBIOS (specifically NetBIOS on 802.2 LLC, aka "Frames") in 1987, ONC RPC (aka "Sun RPC") was only a few years old, so it wasn't like there was an established model for doing datagram client-server operations. Mailslots weren't terrible for the time, and not the worst part of SMB. (SMB has a very IBM / Microsoft look to it, with leaky abstractions and lots of "this looks like it might be handy!" features just tossed in a pot.)
But in 2023 it's long past time to retire it. 40 years is enough.
Remote Mailslots is a fine protocol, if you are managing your own network and have no access to the Internet
An obvious example is running WSL2 inside Windows. Have you used your Yubikey in WSL2? The workaround is to create a slightly unusual client-server tunnel using a couple of tools that re-create a mail-slot like connection between the two sides.
WSL2 doesn't support USB passthrough -- but it does support SMB1, and it can open a SMB1 file on the host (usually only for opening a file on a remote host). On the client side, opening a mail-slot is opening a file: on the server side, opening a mail-slot can be running a program. It's exactly what is required. The Yubikey workarounds use a different protocol, and a different server-agent, but the functionality isn't unique: it's still the kind of connection that is sometimes required.
I think the usage goes like this....
Someone learns about "net send *" and sends an oh so humerous message to everyone.
At that point they realise the large status board in the call center is also a Windows pc on the network, mainly as one of the visitors remarks that you'd "go blind if you tried to do that too often..."
These sorts of facilities – like UNIX's wall(1) and rwall(1), or Project Athena's Zephyr (really an IM system but IIRC it had a broadcast option), or I think VMS DCL had a similar command (REPLY?) – were more popular with multiuser systems, where it was often necessary to tell users that you were shutting the system down or similar. In an environment where everyone's using their own machine, there are fewer valid use cases.
I remember seeing a friend's PC, that he refused to upgrade to XP SP2*, which kept getting spammed with messages from the internet. He was very thankful when I showed him how to disable the service and stop them. I have no idea how he put up with them for so long.
*(he was already running XP, he just didn't want to install the service pack because he's a stubborn sod)
Back in those days you could type "telnet user@ip_address" on the command line of decent operating systems and have a conversation, but that's indeed a LONG time ago (to place this, this was before USENET got too polluted to remain useful and you had to use tools like archie and gopher).
That was the days before anyone thought of encrypting anything on this new internet thingy - the main problem was spam and Usenet UCE and there were parts of Usenet that were actually still usable (UKRM was one of my haunts).
Nowadays, using telnet is an easy way of saying that you don't care that any passing pidgeon can read what you are typing.
(I do have it installed on one of my VMs though so I do SMTP manual testing..)
I recall one of my colleagues discovering a command by which he could lock or shut down a machine, and then demonstrating it to management unwilling to believe him.
Via the WAN, seated in an office several timezones away..
That was fun, btw, as we'd never heard him swear before :).
Oh yes. At Uni in the late 90s we had a lab full of Sun terminals. Someone knocked up a script which would rlogin to a random terminal and play water drop audio file. Looped with a random time delay, and you'd periodically hear a drip sound coming from a random part of the room. And of course since Telnet was still a thing and security wasn't, you could connect (with an appropriate SOC login obviously) from anywhere in the world to confuse whoever happened to be in there at the time. Ahhh, fun times.
And that's on yougov where the main complaint you see in the comments is "there are too many lefties here," thus proving that there are at least a significant number of people there who are so far right of centre that they have either repeated the "daily chat" just so they can post that comment complaining about lefties, or that they have pre-emptively posted it because they assume that the whole world is out to get them...
Yes, the same yougov which was founded by a certain Tory MP who had to pay a multi-million pound penalty to HMRC for (allegedly)* hiding his income from it...
Watch a new Windows feature be announced with great fanfare a year from now which has all those things you mention and several security holes you could drive a bus through so the end result is the exactly same thing as the present day Net Send but 5000 times more bloated.
Oh, it could push adverts - just not Microsoft's adverts. Back in the early 2000s when everyone used USB ADSL modems, you'd end up with Windows systems exposing their Messenger service over the Internet without any firewall, and so spammers started broadcasting NET SEND popups (some even containing pornographic ASCII art).
Many programmers think anything they didn't see in comp-sci 101 is disgusting and not as good as what they create themselves.
I use broadcast UDP ( "unreliable, insecure, and unidirectional") instead of mailslots ("simple, unreliable, insecure, and unidirectional"), and it's much the same thing -- except that on typical networks UDP is more likely to leak more than SMB1.
SMB on IP was complex, verbose, high-latency and flaky.
The other old uses of mailsolts, (where not directly replaceable by UDP), have been replaced by vastly more complex, verbose, high-latency and flaky cross-platform protocols that use application-specific encryption and authentication rather than generic SMB.
SMB on IP was complex, verbose, high-latency and flaky
I remember that, long, long ago, used Microsoft's first iteration of a mail server (Microsoft Mail?). Each mailserver had mailboxes and were supposed to connect via (probably SMB). We had a WAN connection to our partners in the US and they (and we) had a transfer mail server that talked over a very slow, packet switched WAN connection.
It failed more often than it worked. It would start, time out and fail. Again and again.
Eventually, we dumped it and I put in a Checkpoint-1 firewall, a 64K leased line (from Pipex) and started using SMTP to route the emails (via a Mail to SMTP gateway with the reverse at the far end). Worked flawlessly except for the times the gateway fell over.
"not secure, was replaced decades ago by better technology, and should not be used under any circumstances."
.. but we left it in and eabled by default anyway because security problems mean you will be eventually conditioned to apply any old patch without questioning, even if we start using it for self serving surveys ..
Surely if it's merely deprecated, that should be a warning, not an error?
- spoken or written about with disapproval: The much deprecated preference of poorer people for less nutritious white bread over brown has to do with price as well as palatability.
- Computers. (of a software version or feature) marked as not recommended for users and developers because of the risk of damage or compromised security, the existence of superior alternatives, or an impending upgrade: This routine removes all deprecated tags and obsolete elements from the code, replacing them where appropriate.
But anyway, I still haven't forgiven MS for the replacement of known unsafe C calls with equally unsafe (but you feel better about them) calls.
I still haven't forgiven MS for the replacement of known unsafe C calls with equally unsafe (but you feel better about them) calls.
It's what they do best. It's called "security theatre". It's evident they don't have a clue about actual security, but pretending, oh yes, there they can bring several decades of experience to the table.
Nah, they just developed Rossetta stone frameworks because they don't care about backwards compatibiluty while changing to an entirely different CPU architecture so you could continue to run older applications for some 4 years of so. No siree, they don't put any effort in at all.
They also don't bother to update the OS in devices that are 8 years old either, and they refuse to keep their UIs stable so that people have to retrain or play a game of "where the f*ck did they stick this function this time" for months.
No wait, they do. All of it.
Oh yeah, that MacOS update that fucked the third party apps that are no longer compliant with the "new way", the "upgrade" that simplified the user interface which only helps the terminally stupid and frustrates anyone else. Nothing to do with hardware, stable UIs - I don't know what planet you came from.
From a planet that has a couple of machines running only betas for almost two decades and still has had fewer problems with betas than Microsoft has had with actual code released for production.
Microsoft has never been able to write decent code. In the early years they solved that by getting into bed with Intel so they simply wrote on the assumption that people would upgrade (while pretending it would still work on current hardware, while everyone knew it would barely cope but pretended to believe it anyway), later they switched to profoundly butchering UIs so customers wouldn't notice how slow the code was as they were still trying to find where the f*ck Microsoft had hidden the useful stuff they just had begun to develop muscle memory for, a trick they repeated with every. single. update of OS as well as applications. Actually, judging by Win 11 they're still doing it.
Meanwhile, on MacOS, code only stopped working if it was truly seriously old (even their switch from 32bit to 64bit took years), or was so unsafe that the introduction of decent sandboxing would stop it working because it could no longer grab what it wanted without permission. And the command line offered more and more opportunities to avail oneself of the tools that the Internet grew up with, which made integration with that other much safer OS easier too. The UI also changed, but incrementally - basic principles remain to this day so users only need to learn once. LibreOffice, btw, does this too.
So, basically the planet of more efficient and safer computing, the place where TCO studies are honest enough to include staff time..
Fond memories of a lab setup for a CCNA course and all of us sending NET SEND messages around until the instructor lost it.
Can't imagine many people were still using it (you never know though), I'm pretty sure all the services are off by default these days, definitely remember writing GPOs to disable them and prohibit starting a few years ago.
That's the problem, right there. The unsafe things are enabled by default.
The very fact that you have to start disabling things to make it safe is a default they should have lost years ago (not to mention that it risks you forgetting to kill off something and so leave yet another backdoor, leading to yet another company declaring that "sophisticated" hackers made off with information or are holding them to ransom. That sh*t really has to stop, but it is by now very clear that wherever the solution will come from, it isn't going to be from Redmond.
One of my customers has an enterprise application that still uses mailslots to this day.
In fact I learned a lot of about mailslots trying to troubleshoot a loss of connectivity after a patch in 2016. I had to write a group policy company-wide to change the behavior of mailslots due to the security patch. And I recall there was another monthly patch for Windows 10 clients in 2018 that once again broke mailslots and that caused issues with their enterprise application and Microsoft had to come out with another patch for the patch.
What a miserable protocol.