It wouldn't do anything bad for the makers of those devices. In fact, a HCF instruction would be a boon:
1: Everyone would buy a v2.0 of their smart whatzit, when they are told that their existing one can't be fixed or upgraded. 2: If they catch fire, that's their problem. They clicked on the EULA and now have to deal with arbitrators paid by the company. 3: If a ton of devices catch fire, the C-levels short their stock before the announcement, then make their local shipwrights happy with new yachts. 4: Even if the smart whatzit is not bought from brand "A", someone will buy it from brand "B", so the IoT industry benefits as a whole from insecurity.
OpenPGP/GPG has two advantages. It is pretty much the only encryption mechanism that doesn't depend on how messages are stored or transported. A GPG encoded message is just as secure going through E-mail as it is via Facebook, SMS, Signal, Telegram, a file on a FTP site, or a file on a USB flesh drive. I can put files on a public Amazon S3 bucket encrypted for another person fetching them , and know that the data will be protected.
Another advantage is the WoT. Yes, you can use a CA as a trusted introducer, but from there, if you know someone personally, you can sign and vet their key. That way, damage done by a rogue CA can be mitigated by people signing the CA's key with zero trust allowed.
GPG isn't harder than any other crypto. It is just the fact that it is applied before everything else in the process makes users not want to deal with it, compared to a little push button that turns on a lock icon.
Money. To a lot of companies, the top brass feels that security gives zero return to them, so they skimp as much as possible on it. In fact, the faster they can rush a product out the door, no matter how many odious show-stopping bugs, the better.
I wish we had something like Underwriter's Laboratories, except for computer product security, and security in the correct ways, as most companies only focus on security against the intended user, so a broken device can't be reflashed with custom firmware and made useful again. Or perhaps, take that one step further and go with a Sold Secure like system, where products are white-box tested, black box tested, source code is audited, chip supplies are audited, and so on. Of course, the downside here is regulatory capture, but if this is a multinational organization with people who are not beholden to one country, this could be an acceptable solution.
Until this, or some regulatory system is in place, these compromises will only happen more often, as one attack based on UEFI allows others to happen, and we have only seen the start persistant threats. Things like ransomware that quietly encrypts files via a transparant driver, so even backups have the files encrypted, then a certain date elapses, and the decryption keys are chucked, all drives are ATA locked and the machine puts up a message demanding whatever currency is in fashion (Bitcoins, e-Gold, etc.)
Physical attestation, or just a way to check that there is a layer 8 presence, can go a long way when it comes to security. This is why Google went with a Yubikey-like setup internally, since malware would have to get the user to physically jam in their physical device and hit the button to work for every action.
I wonder how this can be done in modern times. Perhaps repurpose the "Turbo" switch into a "firmware updates allowed after next power cycle" mode, where firmware stuff can happen when the button is pressed... but it requires a full power cycle to do so. This is similar to how ATA password protection commands are locked out on bootup to ensure some rogue program can't lock the HDDs, then demand a random notice.
This has been the case for a long time. At least you can deny permissions on Android, or on a rooted Android device, use a utility like XPrivacyLua to allow nosy apps to go slurping all the data they want, as it is fed to it from/dev/urandom.
Before this, it was commonplace for even a basic fleshlight app to require every permission under the sun, even ACCESS_SUPERUSER, and with Android's all or nothing permission approach, most people just allowed the app to install and start slurping data to its hearts content.
I would say SV people do "get" it. A lot of them know that their products are nightmares when it comes to security. But they don't care. To them, security is a cost center. Even more, if some scenario of every device they have has some major vulnerability, the top brass just short their stock, make the announcement, and all go to the local shipwright for new yachts from the money made from the fallout of the announcement.
There is absolutely zero incentive for privacy and security in most industry sectors. Especially IoT where an IoT company benefits from devices that can't be upgraded, as customers will happily buy a new 1.0.1 device because their 1.0 device can get them pwned, and it can't be fixed or firmware updates.
I have already this happen. A few years ago when I was working for a different employer, I had a friend of mine take a picture of me in a store's humidor. The pictures went on Facebook. Less than a week later, I got a demand from my health insurance company to take a physical with bloodwork or pay smoker's rates.
Already, location data from apps has been uses to spy on Tesla and other firms, tracking where employees are in the building. With tensions getting greater between nations, a person's location can potentially make or break a military initiative.
If I have to have an IoT device, there are precautions you can take. The best precaution is not to buy the device in the first place, or if it is a device like a smart TV, if it requires an internet connection to function, or it puts up a EULA, the TV goes back in the box and gets returned.
1: Put it on its own VLAN, with its own internal IP space and different NAT. If you use 192.168, chuck it in a 172.16.x.x subnet, or a 10.x.x.x subnet. Hell, make the IP space 9.x.x.x, so the device thinks it is in some lab at IBM, as that internal IP doesn't matter to anyone but the device itself, and its masters.
2: Firewall the living heck out of the VLAN. Geoblock everything. Log what the IoT device tries to communicate with. Does it need to have a constant outgoing tunnel to some site in Lower Elbonia? No, block it. In fact, it might be wise to buy a Raspberry Pi or another ARM based microcontroller and have that handle the ACLs so you can be sure nothing gets in or out that you don't explicitly want.
3: Ideally, put each device on its separate VLAN with separate ACLs. That, or use the tiny ARM based firewalls with two network ports to handle firewalling on each port. This borders on overkill, but the devices can provide some interesting logs, potentially worth making public.
4: It might be nice to have the router do a dedicated VPN link out just for that IoT VLAN, just so the IoT devices cannot geo-locate where they are accurately.
[Citation Needed]. China has things to disparage it, but banning encryption is something I have yet to actually see as a law. I personally prefer having IoT stuff made from other sources than China (the ye old China +1 methodology), but I'd rather aim criticism accurately.
Of course, in China, any venture on their soil has to be 51% or more owned by a domestic firm, and domestic firms have Chinese government officials on board, but I wouldn't say encryption is directly banned.
As someone who has worked for an IoT company, a lot of companies actually build in insecurity:
1: If there is a major show stopper that hits customers, causing lawsuits, the top brass shorts their stock the day before the announcements. They laugh all the way to the bank.
2: Unfixable security issues force customers to re-buy everything. The more issues that are unpatchable, the more revenue an IoT provider gets. Especially if the IoT devices are designed to be resistant to "jailbreaking", so they can't be patched via third parties.
3: IoT devices sending up a constant telemetry stream can make more cash than the device itself, especially to advertisers.
Want to know how to have IoT devices have a lot better security? Not hard:
1: Have a dedicated IoT firewall hub. This hub only allows communication as per signed manifest files. This way, if a device only communicates via HTTPS to a load balancer for updates, and suddenly starts phoning home to Lower Elbonia, that will be blocked. Of course, a lot of IoT providers will just do 0.0.0.0/255.255.255.255 for a netmask of permissive sites, but will be a cause of public humilation.
2: Have the IoT firewall hub communicate in an offline state, similar to UUCP forwarding. That way, the IoT hub grabs updates and offers them available for devices. Since there is no direct access to the devices, it becomes difficult to attack them without physical access.
3: Have something similar to UL, or Sold Secure, where devices get tested by an independent group and given a certification that they passed white box, black box, and other security attempts.
With genetic algorithms, you can come up with a solution in linear time (as in 100 seconds for 100 cities, 200 seconds for 200 cities, etc.) that is "good enough". It won't come out with the best one, proven mathematically, but if you are looking for a useful answer rather than _the_ answer, it works.
This work with the amoeba seems like it can give a passable solution, but it would be interesting if it did give the actual shortest out there.
Citing Wikipedia is a no-no. However, Wikipedia does point to links, otherwise one will find the page reverted [1] with a [[Citation Needed]] as the reason. What you then do is visit the pages cited, and use those (if relevant), and use the citations from those pages. Wikipedia is a good place to find authoritative works on a topic.
[1]: Assuming you don't find the page reverted anyway.
Even if someone does break it, I applaud Microsoft for having this in the first place. Running a Web browser in a VM, sandbox, or isolated environment, where it has no access to documents is a step forward.
This is already done. A lot of malware checks for drivers and won't run if it sees a VMWare driver, 3 CPU cores, or an oddball amount of RAM. This is a good thing, in a way, if one uses VMs for partitioning tasks (for example QuickBooks goes into its own virtual machine, so it is isolated and protected from malware for the most part. You can also add encryption, either in the VM via BitLocker or store the VM files somewhere secure (VeraCrypt volume), to ensure better protection when the machine isn't in use.
I'm hoping Microsoft starts moving more towards a QubesOS model.
If you are technical, you can build a VM, use Chrome Remote Desktop to remote in from anywhere you are to that VM, and have Facebook goodness anywhere. Plus, if Facebook compromises the VM via malvertising or some other means, a restore from a snapshot is a click away.
Facebook also created a compression standard, zStandard or zstd. This is being used as a mainstream compression algorithm, replacing LZMA/xz for a number of applications. It doesn't get as much compression as "xz -v9e", but it is a lot faster, so achieves a better balance, and decompression is also faster.
Working Scrum environments are rare in my experience. For example, when a daily standup meeting goes 4-6 hours minimum, with everyone whining, "I'm blocked! Blame him!" and pointing fingers at someone else for every thing in their swim lanes, it gets old. Or a manager demanding to keep the dev team always in sprint mode, because marketing demands their deliverables that were already sold to customers, and the devs are always in a fire-fighting mode, trying to code something in place to make the customer happy (and keep their job), the fix stuff later.
In fact, because of this daily push for deliverables, and when they are done, marketing heaps more, extreme shortcuts are taken. I have seen developers have all their production code run as root, with a DB user with full permissions (and doing a quick check... no full rights, code exits.) They feel that if a security hole gets exploited and made public, with lawsuits happening, they have layers of corporate bureaucracy protecting them, while failing to make a deliverable too often will get them to get pink-slipped, so security, readablity go out the window. Technical debt? That's for the next schmoe to deal with, because there is no time, ever, to refactor and fix the fact that code is a tangled mess of garbage.
Standup meetings are pointless, because they turn into blamestorming fests, and after lunch, little winds up getting done anyway other than finding another blocker to point at for tomorrow's kangaroo court.
One of the best things I've seen was IBM's ZTIC. The implementation was flawed, as it had to piggyback via USB onto the network. Instead, a cellular modem could be used. With a device like this, whose only function is to confirm transactions posted on it, it would go a long way to stop fraud, mainly because the attacker would have to have that device and be using it, as well as 2FA access into the account.
Of course, there are always Yubikeys, which also confirm physical presence.
To expand on the phone service analogy, there are plenty of paid-for robocalls as well, often times given higher priority than other people. To boot, the robocalls can be paid for and be on any topic, even if it is an overt lie.
It is funny looking at memes on FB, looking to see where the picture came from, and finding that it originated at some political campaign organization.
I don't have the time to fact check every single lie, and I can't really make a macro to automatically post a Snopes link when they pop up. Best thing to do is find another communications medium. MeWe is a decent alternative, and for private messaging, they even offer that, although it is a buck a month (worth it though... beats the FB ads.)
This is already happening. Look at your DOCSIS modem. For most ISPs, it has to be on an approved list, and they flash their firmware onto the device, even if is owned by you. I wouldn't be surprised to see "AV" software forced into all Internet connected devices, which scanned for pirated stuff and unlicensed movies, under the guide of "anti-terrorism".
The thing about the business love affair for monthly stuff is twofold:
1: Shareholders will sue if stuff gets charged off for other expenses, so companies have to minimize CAPEX costs (payroll, equipment, etc), and move to OPEX, so they can keep the same numbers as the previous quarter. Moving to the cloud means that they don't have to worry about having to buy new stuff every 3-5 years and lose profits. Even if a company does a "forklift", which costs them almost an order of magnitude more, because it is a monthly cost, and the trendy thing, they get a free pass. Plus, it allows for people (rackers/stackers, OS/Ops people, etc.) to be laid off, making them look better on Wall Street.
2: Businesses who sell stuff love monthly subscriptions. Companies highly feared lock-in with mainframes, but they are embracing a technology where they -have- to pay no matter what, or else they don't run. To boot, there is no real way to effectively port in or out of the cloud without major internal redesigns, and those can be impossible.
The good thing is that this has been moving people to open source software. For example, password programs like 1Password and mSecure require monthly commitments, whether or not you use their cloud offering, when in previous versions, you just bought the app and stored the databases yourself. Now, people move to KeePass and other F/OSS software, just because they are tired of the greed involved. Some companies even run completely on Linux now, desktop, directory, and all. When some company demands a SAM audit for a Microsoft true-up, they can laugh in the person's face, since nothing MS goes in the door, and machines are sent from the factory with no OS on them.
Very true. However, after all the fallout, even Outlook is up to par. Thunderbird isn't perfect, but decent. There are others out there that one can try. Worst case, there is always Mutt, which laughs at bogus HTML attacks.
This doesn't mean that 2FA is the culprit. Instead, what is one major problem, is the fact that we use web browsers for everything. With a decent mail program, the only time you really need a password is during the initial setup. From there on, it hands the authentication, forcing attackers to either attack the mail server or the endpoint.
We are starting to come to a point where a single application that has to handle anything and everything just cannot be made secure against every eventuality. Going back to a mail program for mail means that the images in the HTML file will not be displayed by default, even in Outlook.
Couple this with the lack of security in SMS, which telcos -could- remedy, but seem not to be interested, and it is no wonder why this happens.
Blockchains are so generic that I can call myself a "blockchain developer" because I use the -S option (e.g. "git commit -a -S -m 'same old crap`") when doing a push.
Slashdot Mirror
It wouldn't do anything bad for the makers of those devices. In fact, a HCF instruction would be a boon:
1: Everyone would buy a v2.0 of their smart whatzit, when they are told that their existing one can't be fixed or upgraded.
2: If they catch fire, that's their problem. They clicked on the EULA and now have to deal with arbitrators paid by the company.
3: If a ton of devices catch fire, the C-levels short their stock before the announcement, then make their local shipwrights happy with new yachts.
4: Even if the smart whatzit is not bought from brand "A", someone will buy it from brand "B", so the IoT industry benefits as a whole from insecurity.
OpenPGP/GPG has two advantages. It is pretty much the only encryption mechanism that doesn't depend on how messages are stored or transported. A GPG encoded message is just as secure going through E-mail as it is via Facebook, SMS, Signal, Telegram, a file on a FTP site, or a file on a USB flesh drive. I can put files on a public Amazon S3 bucket encrypted for another person fetching them , and know that the data will be protected.
Another advantage is the WoT. Yes, you can use a CA as a trusted introducer, but from there, if you know someone personally, you can sign and vet their key. That way, damage done by a rogue CA can be mitigated by people signing the CA's key with zero trust allowed.
GPG isn't harder than any other crypto. It is just the fact that it is applied before everything else in the process makes users not want to deal with it, compared to a little push button that turns on a lock icon.
Tragedy of the commons. Best way for a place to mitigate this is QoS, but that would take some work on the Wi-Fi provider side.
Money. To a lot of companies, the top brass feels that security gives zero return to them, so they skimp as much as possible on it. In fact, the faster they can rush a product out the door, no matter how many odious show-stopping bugs, the better.
I wish we had something like Underwriter's Laboratories, except for computer product security, and security in the correct ways, as most companies only focus on security against the intended user, so a broken device can't be reflashed with custom firmware and made useful again. Or perhaps, take that one step further and go with a Sold Secure like system, where products are white-box tested, black box tested, source code is audited, chip supplies are audited, and so on. Of course, the downside here is regulatory capture, but if this is a multinational organization with people who are not beholden to one country, this could be an acceptable solution.
Until this, or some regulatory system is in place, these compromises will only happen more often, as one attack based on UEFI allows others to happen, and we have only seen the start persistant threats. Things like ransomware that quietly encrypts files via a transparant driver, so even backups have the files encrypted, then a certain date elapses, and the decryption keys are chucked, all drives are ATA locked and the machine puts up a message demanding whatever currency is in fashion (Bitcoins, e-Gold, etc.)
Physical attestation, or just a way to check that there is a layer 8 presence, can go a long way when it comes to security. This is why Google went with a Yubikey-like setup internally, since malware would have to get the user to physically jam in their physical device and hit the button to work for every action.
I wonder how this can be done in modern times. Perhaps repurpose the "Turbo" switch into a "firmware updates allowed after next power cycle" mode, where firmware stuff can happen when the button is pressed... but it requires a full power cycle to do so. This is similar to how ATA password protection commands are locked out on bootup to ensure some rogue program can't lock the HDDs, then demand a random notice.
This has been the case for a long time. At least you can deny permissions on Android, or on a rooted Android device, use a utility like XPrivacyLua to allow nosy apps to go slurping all the data they want, as it is fed to it from /dev/urandom.
Before this, it was commonplace for even a basic fleshlight app to require every permission under the sun, even ACCESS_SUPERUSER, and with Android's all or nothing permission approach, most people just allowed the app to install and start slurping data to its hearts content.
I would say SV people do "get" it. A lot of them know that their products are nightmares when it comes to security. But they don't care. To them, security is a cost center. Even more, if some scenario of every device they have has some major vulnerability, the top brass just short their stock, make the announcement, and all go to the local shipwright for new yachts from the money made from the fallout of the announcement.
There is absolutely zero incentive for privacy and security in most industry sectors. Especially IoT where an IoT company benefits from devices that can't be upgraded, as customers will happily buy a new 1.0.1 device because their 1.0 device can get them pwned, and it can't be fixed or firmware updates.
I have already this happen. A few years ago when I was working for a different employer, I had a friend of mine take a picture of me in a store's humidor. The pictures went on Facebook. Less than a week later, I got a demand from my health insurance company to take a physical with bloodwork or pay smoker's rates.
Already, location data from apps has been uses to spy on Tesla and other firms, tracking where employees are in the building. With tensions getting greater between nations, a person's location can potentially make or break a military initiative.
If I have to have an IoT device, there are precautions you can take. The best precaution is not to buy the device in the first place, or if it is a device like a smart TV, if it requires an internet connection to function, or it puts up a EULA, the TV goes back in the box and gets returned.
1: Put it on its own VLAN, with its own internal IP space and different NAT. If you use 192.168, chuck it in a 172.16.x.x subnet, or a 10.x.x.x subnet. Hell, make the IP space 9.x.x.x, so the device thinks it is in some lab at IBM, as that internal IP doesn't matter to anyone but the device itself, and its masters.
2: Firewall the living heck out of the VLAN. Geoblock everything. Log what the IoT device tries to communicate with. Does it need to have a constant outgoing tunnel to some site in Lower Elbonia? No, block it. In fact, it might be wise to buy a Raspberry Pi or another ARM based microcontroller and have that handle the ACLs so you can be sure nothing gets in or out that you don't explicitly want.
3: Ideally, put each device on its separate VLAN with separate ACLs. That, or use the tiny ARM based firewalls with two network ports to handle firewalling on each port. This borders on overkill, but the devices can provide some interesting logs, potentially worth making public.
4: It might be nice to have the router do a dedicated VPN link out just for that IoT VLAN, just so the IoT devices cannot geo-locate where they are accurately.
[Citation Needed]. China has things to disparage it, but banning encryption is something I have yet to actually see as a law. I personally prefer having IoT stuff made from other sources than China (the ye old China +1 methodology), but I'd rather aim criticism accurately.
Of course, in China, any venture on their soil has to be 51% or more owned by a domestic firm, and domestic firms have Chinese government officials on board, but I wouldn't say encryption is directly banned.
As someone who has worked for an IoT company, a lot of companies actually build in insecurity:
1: If there is a major show stopper that hits customers, causing lawsuits, the top brass shorts their stock the day before the announcements. They laugh all the way to the bank.
2: Unfixable security issues force customers to re-buy everything. The more issues that are unpatchable, the more revenue an IoT provider gets. Especially if the IoT devices are designed to be resistant to "jailbreaking", so they can't be patched via third parties.
3: IoT devices sending up a constant telemetry stream can make more cash than the device itself, especially to advertisers.
Want to know how to have IoT devices have a lot better security? Not hard:
1: Have a dedicated IoT firewall hub. This hub only allows communication as per signed manifest files. This way, if a device only communicates via HTTPS to a load balancer for updates, and suddenly starts phoning home to Lower Elbonia, that will be blocked. Of course, a lot of IoT providers will just do 0.0.0.0/255.255.255.255 for a netmask of permissive sites, but will be a cause of public humilation.
2: Have the IoT firewall hub communicate in an offline state, similar to UUCP forwarding. That way, the IoT hub grabs updates and offers them available for devices. Since there is no direct access to the devices, it becomes difficult to attack them without physical access.
3: Have something similar to UL, or Sold Secure, where devices get tested by an independent group and given a certification that they passed white box, black box, and other security attempts.
With genetic algorithms, you can come up with a solution in linear time (as in 100 seconds for 100 cities, 200 seconds for 200 cities, etc.) that is "good enough". It won't come out with the best one, proven mathematically, but if you are looking for a useful answer rather than _the_ answer, it works.
This work with the amoeba seems like it can give a passable solution, but it would be interesting if it did give the actual shortest out there.
Citing Wikipedia is a no-no. However, Wikipedia does point to links, otherwise one will find the page reverted [1] with a [[Citation Needed]] as the reason. What you then do is visit the pages cited, and use those (if relevant), and use the citations from those pages. Wikipedia is a good place to find authoritative works on a topic.
[1]: Assuming you don't find the page reverted anyway.
Even if someone does break it, I applaud Microsoft for having this in the first place. Running a Web browser in a VM, sandbox, or isolated environment, where it has no access to documents is a step forward.
This is already done. A lot of malware checks for drivers and won't run if it sees a VMWare driver, 3 CPU cores, or an oddball amount of RAM. This is a good thing, in a way, if one uses VMs for partitioning tasks (for example QuickBooks goes into its own virtual machine, so it is isolated and protected from malware for the most part. You can also add encryption, either in the VM via BitLocker or store the VM files somewhere secure (VeraCrypt volume), to ensure better protection when the machine isn't in use.
I'm hoping Microsoft starts moving more towards a QubesOS model.
If you are technical, you can build a VM, use Chrome Remote Desktop to remote in from anywhere you are to that VM, and have Facebook goodness anywhere. Plus, if Facebook compromises the VM via malvertising or some other means, a restore from a snapshot is a click away.
I can't think of any other company which could make the back of a Lucky Charms cereal box be animated when viewed with a smartphone.
I don't see how this can make big bucks though.
Facebook also created a compression standard, zStandard or zstd. This is being used as a mainstream compression algorithm, replacing LZMA/xz for a number of applications. It doesn't get as much compression as "xz -v9e", but it is a lot faster, so achieves a better balance, and decompression is also faster.
Working Scrum environments are rare in my experience. For example, when a daily standup meeting goes 4-6 hours minimum, with everyone whining, "I'm blocked! Blame him!" and pointing fingers at someone else for every thing in their swim lanes, it gets old. Or a manager demanding to keep the dev team always in sprint mode, because marketing demands their deliverables that were already sold to customers, and the devs are always in a fire-fighting mode, trying to code something in place to make the customer happy (and keep their job), the fix stuff later.
In fact, because of this daily push for deliverables, and when they are done, marketing heaps more, extreme shortcuts are taken. I have seen developers have all their production code run as root, with a DB user with full permissions (and doing a quick check... no full rights, code exits.) They feel that if a security hole gets exploited and made public, with lawsuits happening, they have layers of corporate bureaucracy protecting them, while failing to make a deliverable too often will get them to get pink-slipped, so security, readablity go out the window. Technical debt? That's for the next schmoe to deal with, because there is no time, ever, to refactor and fix the fact that code is a tangled mess of garbage.
Standup meetings are pointless, because they turn into blamestorming fests, and after lunch, little winds up getting done anyway other than finding another blocker to point at for tomorrow's kangaroo court.
One of the best things I've seen was IBM's ZTIC. The implementation was flawed, as it had to piggyback via USB onto the network. Instead, a cellular modem could be used. With a device like this, whose only function is to confirm transactions posted on it, it would go a long way to stop fraud, mainly because the attacker would have to have that device and be using it, as well as 2FA access into the account.
Of course, there are always Yubikeys, which also confirm physical presence.
To expand on the phone service analogy, there are plenty of paid-for robocalls as well, often times given higher priority than other people. To boot, the robocalls can be paid for and be on any topic, even if it is an overt lie.
It is funny looking at memes on FB, looking to see where the picture came from, and finding that it originated at some political campaign organization.
I don't have the time to fact check every single lie, and I can't really make a macro to automatically post a Snopes link when they pop up. Best thing to do is find another communications medium. MeWe is a decent alternative, and for private messaging, they even offer that, although it is a buck a month (worth it though... beats the FB ads.)
This is already happening. Look at your DOCSIS modem. For most ISPs, it has to be on an approved list, and they flash their firmware onto the device, even if is owned by you. I wouldn't be surprised to see "AV" software forced into all Internet connected devices, which scanned for pirated stuff and unlicensed movies, under the guide of "anti-terrorism".
The thing about the business love affair for monthly stuff is twofold:
1: Shareholders will sue if stuff gets charged off for other expenses, so companies have to minimize CAPEX costs (payroll, equipment, etc), and move to OPEX, so they can keep the same numbers as the previous quarter. Moving to the cloud means that they don't have to worry about having to buy new stuff every 3-5 years and lose profits. Even if a company does a "forklift", which costs them almost an order of magnitude more, because it is a monthly cost, and the trendy thing, they get a free pass. Plus, it allows for people (rackers/stackers, OS/Ops people, etc.) to be laid off, making them look better on Wall Street.
2: Businesses who sell stuff love monthly subscriptions. Companies highly feared lock-in with mainframes, but they are embracing a technology where they -have- to pay no matter what, or else they don't run. To boot, there is no real way to effectively port in or out of the cloud without major internal redesigns, and those can be impossible.
The good thing is that this has been moving people to open source software. For example, password programs like 1Password and mSecure require monthly commitments, whether or not you use their cloud offering, when in previous versions, you just bought the app and stored the databases yourself. Now, people move to KeePass and other F/OSS software, just because they are tired of the greed involved. Some companies even run completely on Linux now, desktop, directory, and all. When some company demands a SAM audit for a Microsoft true-up, they can laugh in the person's face, since nothing MS goes in the door, and machines are sent from the factory with no OS on them.
Very true. However, after all the fallout, even Outlook is up to par. Thunderbird isn't perfect, but decent. There are others out there that one can try. Worst case, there is always Mutt, which laughs at bogus HTML attacks.
This doesn't mean that 2FA is the culprit. Instead, what is one major problem, is the fact that we use web browsers for everything. With a decent mail program, the only time you really need a password is during the initial setup. From there on, it hands the authentication, forcing attackers to either attack the mail server or the endpoint.
We are starting to come to a point where a single application that has to handle anything and everything just cannot be made secure against every eventuality. Going back to a mail program for mail means that the images in the HTML file will not be displayed by default, even in Outlook.
Couple this with the lack of security in SMS, which telcos -could- remedy, but seem not to be interested, and it is no wonder why this happens.
Best protection? Read mail in a mail program.
Blockchains are so generic that I can call myself a "blockchain developer" because I use the -S option (e.g. "git commit -a -S -m 'same old crap`") when doing a push.