Which might actually have been a dire warning for the people at Intel behind the Galileo and Edison devices: Both were x86; but violated enough legacy-PC expectations that the OS(es, did anyone aside from Intel's Linux branch get interested?) had to be ported; and any of the old 'basically uses DOS as an RTOS by ignoring it for time critical stuff' x86 applications were unlikely to work; plus reports on the quality of the documentation range from 'frustrating' to 'dire'.
386s, by contrast, are markedly slower; but are pretty exhaustively documented and supported at this point; and their behavior hasn't changed in ages, so your expensive legacy software and/or system design doesn't have to either.
These offerings were too novel to just inherit support by carefully copying a prior design(or at least its software facing behavior); didn't have a solid attempt to compensate for that with quality support and documentation; and once those factors dragged it down into the morass of eccentric SoCs with slightly shaky Linux BSPs, just being able to run x86 code in userspace applications wasn't enough of an advantage to offset the relatively high price and areas of mediocrity(reasonably high speed GPIO, in particular, was...not impressive).
They might have actually done better if they had offered a 'DOSbox SoC' or something that, from the software side, slavishly replicated the behavior of a Pentium Pro and whatever chipset was most popular in a single chip, just faster. Instead, they broke with the past far enough to require a fair amount of support; then didn't provide it; which doesn't exactly command a premium price among random application processor SoCs.
I am a trifle surprised to see the Joule among the dead.
The others were hopeless: too cut down(in terms of 'IBM PC' stuff), for x86 compatibility to be of much use, notably lousy at GPIO twiddling compared to microcontrollers or devices like the TI ARM part in the Beaglebone; but at least they were expensive!
The 'Joule', though was a stock Atom part, plus some RAM, Flash, and a NIC in a little computer on module. Not based on some weirdo part; and allowed you to drop a more or less standard Atom based system into something without consuming much space. I'd be curious to know if it died because existing SoM vendors do it better, and Intel decided to stop flailing around and upsetting them; or because lack of interest in x86 for anything that doesn't either involve a small off the shelf motherboard(for onceoffs) or 10 zillion custom motherboards (for laptops and such) is just that dismal.
Instead of Kockblocking this; just try to remember that a fiber buildout is basically dumping chemically doped glass fibers into populated areas. Doesn't that feel so much better? Don't think about the service, think about the emissions.
Even with the schedule that was actually used; cellphones went through a fair period of being rather pricey "I'm-basically-Gordon-Gekko" status symbols that tended to indicate either nontrivial disposable income or a job where being able to contact you on short notice was worth a lot of money to someone.
Given the vastly more limited options(both for handsets and for making efficient use of spectrum) in 1947, I find it rather hard to imagine how such phones would have been anything but stratospherically expensive. TV is kind of a festering wasteland of a use; but getting broadcast to work well for as many users as can afford receivers is vastly easier than getting transceivers working for more than a modest number of users in a given area
Plus, we don't have to speculate: the US had MTS in 1946; and it was indeed both expensive and capable of supporting only a small number of users because most of the cool tricks for spectrum sharing were either not developed or known in principle but not feasible to implement on real hardware.
This is one of those situations where the 'best practices' both look bad and are hard to get rid of because they(often) are the locally optimal approach in a situation that is unlikely to go well.
If you follow those "best practices"; you are basically doing what you can to act like a contract or outsourced IT service provider despite being an internal unit. If that's the best relationship the department can have with the rest of the company, yeah, odds are that it isn't going to go all that well. Best case, you'll be an efficient and largely inoffensive closer of tickets and deliverer of legalistic written-to-spec 'solutions'; worst cases go down from there.
However, unless you really are dreadful at this; odds are that the IT department is acting like an external contract break/fix shop because the rest of the organization views them as one; more or less irrelevant unless something has stopped the email from flowing or a specific buzzword needs implementing. Organizations that view IT as a basically homogeneous support mechanism for the status quo probably aren't going to be doing anything terribly elegant with it; but not because they are hamstrung by IT billing for helpdesk time; but because they don't really want to have IT, except the bare minimum required to keep stuff from being broken all the time.
Which is why I didn't describe it as one; though the case of grabbing plaintext that is leaked before link encryption because of a design flaw is pretty close to 'attack'; and requires no modification of the target system, which is handy.
Some really fancy cameras may be good enough; but the latter approach is the more practical one: if all you care about is one LED's flickering, you are basically just building an optocoupler with an unfortunately suboptimal gap between the transmitter and receiver. Suitable optics, stabilized mount, filtering noise from ambient light sources, etc. are all potential problems; but photodetectors with ample bandwidth are very much available.
This looks like a contemporary attempt to revive a classic.
Back in the Before Times; you could get serial modems that did DES(maybe 3DES? my memory grows fuzzy) in hardware, to allow systems without built in line security measures to be run over phone lines(ATMs, that sort of thing). It was cleartext on the RS-232 link between the device and the modem; but that was supposed to be physically secured inside the chassis; then encrypted between the modems on each end of the line; and decrypted at the far end, presumably in a secure location.
Some designs, whether out of lack of imagination, incompetence, or sneaky malice, had LEDs that were more or less directly tied to the cleartext serial input; and the LEDs and drive circuitry were quite capable of blinking at the rates of at least the slower serial links; so you could read the unencrypted serial traffic right off the fancy 'secure' modem's blinkenlights(at a fair distance, with magnification).
This study tested ethernet gear as well; but found that(if unmodified) it was of relatively limited use: data rates were far too high for LEDs to be driven directly by high/low values in the data stream; and instead blinked in ways only indirectly associated with traffic activity, mostly for diagnostic convenience.
This new one requires that the system be maliciously modified, so it lacks the charm of the original; but takes advantage of the fact that indicator LEDs can still blink pretty fast(and some are GPIO controlled) so they can still be shoved into transmitting information; but now you have to handle that yourself, rather than having the vendor do it for you.
Aside from the 'researchers were looking for publication; not a practical exfiltration strategy' issue; I imagine that it would be most useful in a comparatively complex network where you can't necessarily do anything excessively shady looking over the network interfaces without the risk of being caught by the IDS or similar.
For your basic "router is what turns the cable into wifi, right?" network setup, sure, this is absurdly perverse: you own the router, just use their own internet connection for whatever you want to exfiltrate; and do assorted other nasty things to their traffic, just because you can.
If you have a toehold on a device buried in a better policed network, on the other hand, a channel of this sort is ample for sneaking out switch/router configs, crypto keys, and so on; and doesn't generate any unusual patterns on the parts of the network that are likely being monitored for suspicious behavior.
(Sensors might be trickier: even switch closets not designed with any paranoia in mind tend not to get luxurious window views. Though, you probably wouldn't want to leave any unused fiber runs uncapped; be rather embarrassing if you end up piping the malicious signal out of the secure area for want of a cheapo little rubber insert.)
I'm sure Office 365 and Azure customers will be...heartened and encouraged...by this sort of expertise in operations and system management on the part of their cloud service provider.
Users of their client software, by contrast, can think happy thoughts about how robust and well supervised the release process for Windows updates is.
Doesn't really make their point wrong; does make them a bit too late in a lot of cases where the legacy infrastructure looks like it still exists.
Some of the old stuff should be easier to just dust off(point-to-point microwave links, say, were crushed by fiber on bandwidth; but refurbishing a limited number of transceiver stations is going to cost a lot less and be a lot faster than repairing or rebuilding the old school copper network.
The bigger issue seems like one of "and what are we going to plug into it?" Using legacy systems to cope with viruses or the like will only work if people are ready to cope with how we did things back then. If everyone just tunnels TCP/IP over whatever so that they can plug their stuff back in, you'll be just as vulnerable and a lot slower.
It's this part that I really have my doubts about: people can still organize on a small scale to do locally sensible things; but knowledge of old large-scale procedure is rather scarce; which will leave you standing around like British Airways with an IT problem if the current large-scale procedures aren't available.
Having a pet CA seriously weakens SSL(and definitely makes relying on it downright crazy for anyone who could get in trouble for going to the wrong sites); but there has been some, not terribly adequate, work to ameliorate the worst of 'Yeah! Any CA is just as trusted as any other!'. Deployment of pinning is deeply patchy, and essentially only open to vendors who have some other mechanism(usually a pet software updater) to push their pinned settings; and 'SSL Observatory' type stuff can only catch attacks after the fact; but it can be tricky to do SSL MiTM on a large scale without breaking some things, throwing some scary warnings, and being detected.
If you just want to do it on a LAN, to a bunch of machines that obey your Group Policy, that's a lot easier.
Nothing Snowden released was unsuspected; but there is a fair difference between "Yeah, I strongly suspect that my TLAs have some scary capabilities and enjoy using them." and actually seeing the slide decks outlining the 'and this is how we capture a genuinely impressive percentage of traffic; including more flavors of VPN and the like than you might hope."
Even when history gives one little reason to trust the spooks; the kooks always have a bad time getting taken seriously, even when they have good evidence; and much more so when they can only speculate.
It is completely delusional to think this effectively prevents government censorship as if they can't selectively block content they simply take the sledgehammer approach and ban the site altogether.
That is an option; but only if you want to (quite visibly) be caught interfering with your citizen's access to intriguing trivia, fun facts; and the best friend of last-minute-'researchers' everywhere.
Sure, against somebody who doesn't give a damn, at all; and has no domestic opposition even close to being able to make him do so, "You'll have to ban it all to ban any of it!" will just get you a "Challenge Accepted." and a ban. That cuts down on the list of potential censors, and raises the cost they pay with their constituents, if they choose to try. Even members of the public who are in favor of banning 'immorality' or whatever generally like access to lolcats and innocuous articles. That's where forcing the adversary to make all-or-nothing choices pays off.
Using encryption has the added benefit of making it harder to do 'silent' censorship. If you have http, you can do very granular blocking or even selective rewriting and your censored version will only be distinguishable from the real thing by people willing to do a lot of tedious testing from multiple connections in different jurisdictions and look for changes. If it's either 'blocked' or 'not blocked', you can't really deny what you are doing. You may be able to do it anyway; but you'll have to deal with whatever fallout emerges.
Aside from a human likely remaining in the loop; TFA seems to overstate the urgency of the 'who screwed up?' question.
In practice(literally and figuratively in this case), mistakes are considered a bad thing; but getting medical diagnosis error-free(especially if you include things like "patient has multiple conditions contributing to their reported symptoms; doctor correctly diagnoses one of them; but that correct diagnosis delays treatment for the other one") is sufficiently difficult that mere error isn't generally considered a matter of culpability unless it's accompanied by negligence or recklessness; or so egregious that it counts as malpractice no matter how earnestly you did it.
Expert systems 'feel' wrong, since assigning blame(in the moral sense, we blame machines in practical terms all the time) to them doesn't feel right; but it's not as though the current state of things actually involves moral blame for every mistake. Unless egregious or accompanied by aggravating factors, there are a lot of just plain mistakes; no moral blame assigned, just technical Q/A or process-evaluation type blame, which isn't terribly foreign to computers and expert systems.
There's also the fact that, unless a doctor more or less straight up murders a patient; the 'blame' in a financial sense tends to get kicked up the chain to whoever allowed the doctor to practice(either 'implicitly allowed', if the doctor is sued personally and their malpractice insurance eats the bill; since the insurer effectively deems the doctor fit to practice by being willing to provide malpractice coverage at remotely affordable rates; or explicitly allowed; if the hospital/medical group/etc. that employs the doctor, allows them to use the OR, etc. is taken to court over the qualify of care in the facility). If the blame is ultimately falling on an organization for having a lousy doctor on staff; it wouldn't be terribly alien to blame the organization in much the same way for bad outcomes produced by relying on a dodgy expert system.
Also, has WiFi security been breached since the bad old days of WEP?
That was a disaster, no arguing otherwise(though earlier cellular standards are also a mess); but it was my understanding that WPA2 only gets 'breached' because they include the consumer-friendly PSK option and a lot of lousy passwords are used; while PSK with good passwords, or the annoying-to-set-up, but actually robust, 'enterprise' flavors have been pretty solid.
Telcos deserve credit for being one of the few network environments where cryptographic smart card authentication is actually routine(SIMs haven't mechanically been smartcards in ages; but logically and electrically they are); but wifi security if you actually care is quite robust, it's just that the spec includes options intended to be trivial to set up.
This proposal appears to be an attempt to change that; but the original LTE-in-ISM-bands spec has a really nasty, though admittedly rather clever, trick: this"LTE-U" moves some or all of the data channel into unlicensed spectrum; but the spec mandates that the control channel be in a licensed band. Probably not entirely without technical reason(a control channel subject to fewer sources of interference is likely more reliable and predictable); but means that only someone who controls at least some licensed spectrum can play; while the bulk of the noise produced lands right in the unlicensed bands. As originally specified, running the control channel in ISM was not an option, period, which made it look an awful lot like a deliberate move to lock out smaller players.
This spec, while immature, attempts to at least let you try to run an all-ISM implementation.
As always, unlimited amount of magic financial instrument money are just 'productivity'; but any rise in real wages means that we are just days away from Wiemar hyperinflation. I'm totally shocked that the Wall Street Journal might hold this opinion.
Perhaps some abstract concept of 'Democracy'(probably represented by a topless marble statue, as abstract classical concepts always seem to be) doesn't; but isn't it fairly silly to say that "Democracy doesn't give a shit about the comment forms on a website" when that website and comment forms exist because of the public comment section of the structure of the FCC rulemaking process; as determined in accordance with the FCC's congressional authorization?
What exactly does 'democracy giving a shit' look like?
The annoying bit isn't the absolute amount of maintenance required, which is fairly low; but the fact that it's required more or less entirely because somebody thought that coating the parts of the laptop that you touch with fabric(among the more efficient materials for removing crud from your hands, which is why we make washclothes and towels out of it) would be cooler than boring old plastic or metal.
Even small inconveniences are galling when they are for stupid, pointless, reasons. When the person in charge of defending those reasons tries to insist that the inconvenience is just part of the product being 'luxurious' that doesn't help at all.
The massive blind spot (or possibly rhetorical sleight-of-hand) here is the casual conflating of "The Windows Store" with "a new Windows packaging mechanism".
It's pretty easy to make a case that today's combination of mostly MSI files with some vendors still shipping in-house or legacy.exe installers isn't great; and that the ability of win32 applications to, unless very, very, carefully kept on a leash, scribble all over one another is a risk. If so; an improved installer format and some sort of application isolation(ideally not hacked on with a bunch of virtualization layers; like the "App-V" stuff designed to let enterprise users take legacy applications and isolate them whether they like it or not).
However, none of this has any relationship whatsoever with Microsoft's precious "App Store"; and their desire to be the sole gatekeeper for cryptographically blessed software and get their 30% cut. And this aspect of the deal is not something that is of plausible value to anyone who isn't Microsoft. It's unlikely that MS will be able to get rid of 'legacy' Windows entirely; because Corporate would scream; but they would love for this 'Windows S' to become the de-facto 'Home Edition', with anyone who wants to go outside the walled garden paying an upgrade fee for the privilege.
This seems like a fatal flaw in the argument. If this were just about a fight between MSI loyalists and APPX fanboys; it would be easy to make the case that the legacy tech isn't good enough. That, however, is a relatively minor part of the issue; with the 'Store' being placed front and center by Microsoft's decision to effectively link UWP/APPX with the store(yes, there is a 'sideload' switch, at least for now; but the only remotely preferred configuration involves everyone with a Microsoft account, buying software, from any vendor, through the Microsoft store.
I'd agree that "firewalling" can be a nontrivial exercise(and, as in the situation you note, frequently cannot just involve a "drop everything" rule and a satisfied expression); but in a situation like that you would presumably restrict their SMB access so that they could only interact with SMB on a single, actually supported, system you control that would effectively act as an SMB proxy(in the inelegant sense of having the same directory(s) available over SMB on one interface to the 98 boxes; and over another to the outside world; I don't think that there's any sort of 'rewrite SMB for safety" proxy option).
Definitely ugly; and (while being willing to do it can pay the bills) part of why dealing with legacy systems isn't considered a joyful hobby; but also exactly the sort of situation where "You can add a relatively low end Windows Server(possibly even desktop, depending on volume and what, if any, other features you need) SKU and some network adjustments to the situation and keep the 98 machines safely away from everything else" sounds a lot more attractive than "Well, there's this cool alpha/maybe-beta-ish OS we can try installing..." Win98 is certainly no marvel of uptime; but "30k scanner" is one of those things where downtime displeases people.
How closely are video standards tied to mains frequencies these days? There was obviously a strong technical reason for it back when video transmission was analog; and quality timebases were rather hard to come by; and technology has a considerable amount of inertia; but with contemporary hardware if anything except the PSU can even detect the mains frequency, you probably have a hardware problem; and essentially everything(aside from PSUs) is low voltage DC gear with very, very, accurate and fairly versatile clocks that keep whatever time the designers want them to.
Is it just about legacy compatibility/compatibility with video encoded for broadcast on systems that require legacy compatibility? Are there any other reasons for the historical frame rates?
Slashdot Mirror
I think that SiS' old 486-to-pentium-ish designs are carrying on as Vortex86. If they aren't now; they were until comparatively recently.
On the FPGA side, there is ao486. Don't know much about it; but seems similar to what you have in mind.
Which might actually have been a dire warning for the people at Intel behind the Galileo and Edison devices: Both were x86; but violated enough legacy-PC expectations that the OS(es, did anyone aside from Intel's Linux branch get interested?) had to be ported; and any of the old 'basically uses DOS as an RTOS by ignoring it for time critical stuff' x86 applications were unlikely to work; plus reports on the quality of the documentation range from 'frustrating' to 'dire'.
386s, by contrast, are markedly slower; but are pretty exhaustively documented and supported at this point; and their behavior hasn't changed in ages, so your expensive legacy software and/or system design doesn't have to either.
These offerings were too novel to just inherit support by carefully copying a prior design(or at least its software facing behavior); didn't have a solid attempt to compensate for that with quality support and documentation; and once those factors dragged it down into the morass of eccentric SoCs with slightly shaky Linux BSPs, just being able to run x86 code in userspace applications wasn't enough of an advantage to offset the relatively high price and areas of mediocrity(reasonably high speed GPIO, in particular, was...not impressive).
They might have actually done better if they had offered a 'DOSbox SoC' or something that, from the software side, slavishly replicated the behavior of a Pentium Pro and whatever chipset was most popular in a single chip, just faster. Instead, they broke with the past far enough to require a fair amount of support; then didn't provide it; which doesn't exactly command a premium price among random application processor SoCs.
I am a trifle surprised to see the Joule among the dead.
The others were hopeless: too cut down(in terms of 'IBM PC' stuff), for x86 compatibility to be of much use, notably lousy at GPIO twiddling compared to microcontrollers or devices like the TI ARM part in the Beaglebone; but at least they were expensive!
The 'Joule', though was a stock Atom part, plus some RAM, Flash, and a NIC in a little computer on module. Not based on some weirdo part; and allowed you to drop a more or less standard Atom based system into something without consuming much space. I'd be curious to know if it died because existing SoM vendors do it better, and Intel decided to stop flailing around and upsetting them; or because lack of interest in x86 for anything that doesn't either involve a small off the shelf motherboard(for onceoffs) or 10 zillion custom motherboards (for laptops and such) is just that dismal.
Instead of Kockblocking this; just try to remember that a fiber buildout is basically dumping chemically doped glass fibers into populated areas. Doesn't that feel so much better? Don't think about the service, think about the emissions.
Yup. If you want a picture of the future, imagine a pile of strawmen reduced to absurdity after falling down a slippery slope. Forever.
Even with the schedule that was actually used; cellphones went through a fair period of being rather pricey "I'm-basically-Gordon-Gekko" status symbols that tended to indicate either nontrivial disposable income or a job where being able to contact you on short notice was worth a lot of money to someone.
Given the vastly more limited options(both for handsets and for making efficient use of spectrum) in 1947, I find it rather hard to imagine how such phones would have been anything but stratospherically expensive. TV is kind of a festering wasteland of a use; but getting broadcast to work well for as many users as can afford receivers is vastly easier than getting transceivers working for more than a modest number of users in a given area
Plus, we don't have to speculate: the US had MTS in 1946; and it was indeed both expensive and capable of supporting only a small number of users because most of the cool tricks for spectrum sharing were either not developed or known in principle but not feasible to implement on real hardware.
This is one of those situations where the 'best practices' both look bad and are hard to get rid of because they(often) are the locally optimal approach in a situation that is unlikely to go well.
If you follow those "best practices"; you are basically doing what you can to act like a contract or outsourced IT service provider despite being an internal unit. If that's the best relationship the department can have with the rest of the company, yeah, odds are that it isn't going to go all that well. Best case, you'll be an efficient and largely inoffensive closer of tickets and deliverer of legalistic written-to-spec 'solutions'; worst cases go down from there.
However, unless you really are dreadful at this; odds are that the IT department is acting like an external contract break/fix shop because the rest of the organization views them as one; more or less irrelevant unless something has stopped the email from flowing or a specific buzzword needs implementing. Organizations that view IT as a basically homogeneous support mechanism for the status quo probably aren't going to be doing anything terribly elegant with it; but not because they are hamstrung by IT billing for helpdesk time; but because they don't really want to have IT, except the bare minimum required to keep stuff from being broken all the time.
Which is why I didn't describe it as one; though the case of grabbing plaintext that is leaked before link encryption because of a design flaw is pretty close to 'attack'; and requires no modification of the target system, which is handy.
Some really fancy cameras may be good enough; but the latter approach is the more practical one: if all you care about is one LED's flickering, you are basically just building an optocoupler with an unfortunately suboptimal gap between the transmitter and receiver. Suitable optics, stabilized mount, filtering noise from ambient light sources, etc. are all potential problems; but photodetectors with ample bandwidth are very much available.
This looks like a contemporary attempt to revive a classic.
Back in the Before Times; you could get serial modems that did DES(maybe 3DES? my memory grows fuzzy) in hardware, to allow systems without built in line security measures to be run over phone lines(ATMs, that sort of thing). It was cleartext on the RS-232 link between the device and the modem; but that was supposed to be physically secured inside the chassis; then encrypted between the modems on each end of the line; and decrypted at the far end, presumably in a secure location.
Some designs, whether out of lack of imagination, incompetence, or sneaky malice, had LEDs that were more or less directly tied to the cleartext serial input; and the LEDs and drive circuitry were quite capable of blinking at the rates of at least the slower serial links; so you could read the unencrypted serial traffic right off the fancy 'secure' modem's blinkenlights(at a fair distance, with magnification).
This study tested ethernet gear as well; but found that(if unmodified) it was of relatively limited use: data rates were far too high for LEDs to be driven directly by high/low values in the data stream; and instead blinked in ways only indirectly associated with traffic activity, mostly for diagnostic convenience.
This new one requires that the system be maliciously modified, so it lacks the charm of the original; but takes advantage of the fact that indicator LEDs can still blink pretty fast(and some are GPIO controlled) so they can still be shoved into transmitting information; but now you have to handle that yourself, rather than having the vendor do it for you.
Aside from the 'researchers were looking for publication; not a practical exfiltration strategy' issue; I imagine that it would be most useful in a comparatively complex network where you can't necessarily do anything excessively shady looking over the network interfaces without the risk of being caught by the IDS or similar.
For your basic "router is what turns the cable into wifi, right?" network setup, sure, this is absurdly perverse: you own the router, just use their own internet connection for whatever you want to exfiltrate; and do assorted other nasty things to their traffic, just because you can. If you have a toehold on a device buried in a better policed network, on the other hand, a channel of this sort is ample for sneaking out switch/router configs, crypto keys, and so on; and doesn't generate any unusual patterns on the parts of the network that are likely being monitored for suspicious behavior.
(Sensors might be trickier: even switch closets not designed with any paranoia in mind tend not to get luxurious window views. Though, you probably wouldn't want to leave any unused fiber runs uncapped; be rather embarrassing if you end up piping the malicious signal out of the secure area for want of a cheapo little rubber insert.)
I'm sure Office 365 and Azure customers will be...heartened and encouraged...by this sort of expertise in operations and system management on the part of their cloud service provider.
Users of their client software, by contrast, can think happy thoughts about how robust and well supervised the release process for Windows updates is.
Doesn't really make their point wrong; does make them a bit too late in a lot of cases where the legacy infrastructure looks like it still exists.
Some of the old stuff should be easier to just dust off(point-to-point microwave links, say, were crushed by fiber on bandwidth; but refurbishing a limited number of transceiver stations is going to cost a lot less and be a lot faster than repairing or rebuilding the old school copper network.
The bigger issue seems like one of "and what are we going to plug into it?" Using legacy systems to cope with viruses or the like will only work if people are ready to cope with how we did things back then. If everyone just tunnels TCP/IP over whatever so that they can plug their stuff back in, you'll be just as vulnerable and a lot slower.
It's this part that I really have my doubts about: people can still organize on a small scale to do locally sensible things; but knowledge of old large-scale procedure is rather scarce; which will leave you standing around like British Airways with an IT problem if the current large-scale procedures aren't available.
Having a pet CA seriously weakens SSL(and definitely makes relying on it downright crazy for anyone who could get in trouble for going to the wrong sites); but there has been some, not terribly adequate, work to ameliorate the worst of 'Yeah! Any CA is just as trusted as any other!'. Deployment of pinning is deeply patchy, and essentially only open to vendors who have some other mechanism(usually a pet software updater) to push their pinned settings; and 'SSL Observatory' type stuff can only catch attacks after the fact; but it can be tricky to do SSL MiTM on a large scale without breaking some things, throwing some scary warnings, and being detected.
If you just want to do it on a LAN, to a bunch of machines that obey your Group Policy, that's a lot easier.
Nothing Snowden released was unsuspected; but there is a fair difference between "Yeah, I strongly suspect that my TLAs have some scary capabilities and enjoy using them." and actually seeing the slide decks outlining the 'and this is how we capture a genuinely impressive percentage of traffic; including more flavors of VPN and the like than you might hope."
Even when history gives one little reason to trust the spooks; the kooks always have a bad time getting taken seriously, even when they have good evidence; and much more so when they can only speculate.
It is completely delusional to think this effectively prevents government censorship as if they can't selectively block content they simply take the sledgehammer approach and ban the site altogether.
That is an option; but only if you want to (quite visibly) be caught interfering with your citizen's access to intriguing trivia, fun facts; and the best friend of last-minute-'researchers' everywhere.
Sure, against somebody who doesn't give a damn, at all; and has no domestic opposition even close to being able to make him do so, "You'll have to ban it all to ban any of it!" will just get you a "Challenge Accepted." and a ban. That cuts down on the list of potential censors, and raises the cost they pay with their constituents, if they choose to try. Even members of the public who are in favor of banning 'immorality' or whatever generally like access to lolcats and innocuous articles. That's where forcing the adversary to make all-or-nothing choices pays off.
Using encryption has the added benefit of making it harder to do 'silent' censorship. If you have http, you can do very granular blocking or even selective rewriting and your censored version will only be distinguishable from the real thing by people willing to do a lot of tedious testing from multiple connections in different jurisdictions and look for changes. If it's either 'blocked' or 'not blocked', you can't really deny what you are doing. You may be able to do it anyway; but you'll have to deal with whatever fallout emerges.
Aside from a human likely remaining in the loop; TFA seems to overstate the urgency of the 'who screwed up?' question.
In practice(literally and figuratively in this case), mistakes are considered a bad thing; but getting medical diagnosis error-free(especially if you include things like "patient has multiple conditions contributing to their reported symptoms; doctor correctly diagnoses one of them; but that correct diagnosis delays treatment for the other one") is sufficiently difficult that mere error isn't generally considered a matter of culpability unless it's accompanied by negligence or recklessness; or so egregious that it counts as malpractice no matter how earnestly you did it.
Expert systems 'feel' wrong, since assigning blame(in the moral sense, we blame machines in practical terms all the time) to them doesn't feel right; but it's not as though the current state of things actually involves moral blame for every mistake. Unless egregious or accompanied by aggravating factors, there are a lot of just plain mistakes; no moral blame assigned, just technical Q/A or process-evaluation type blame, which isn't terribly foreign to computers and expert systems.
There's also the fact that, unless a doctor more or less straight up murders a patient; the 'blame' in a financial sense tends to get kicked up the chain to whoever allowed the doctor to practice(either 'implicitly allowed', if the doctor is sued personally and their malpractice insurance eats the bill; since the insurer effectively deems the doctor fit to practice by being willing to provide malpractice coverage at remotely affordable rates; or explicitly allowed; if the hospital/medical group/etc. that employs the doctor, allows them to use the OR, etc. is taken to court over the qualify of care in the facility). If the blame is ultimately falling on an organization for having a lousy doctor on staff; it wouldn't be terribly alien to blame the organization in much the same way for bad outcomes produced by relying on a dodgy expert system.
Also, has WiFi security been breached since the bad old days of WEP? That was a disaster, no arguing otherwise(though earlier cellular standards are also a mess); but it was my understanding that WPA2 only gets 'breached' because they include the consumer-friendly PSK option and a lot of lousy passwords are used; while PSK with good passwords, or the annoying-to-set-up, but actually robust, 'enterprise' flavors have been pretty solid. Telcos deserve credit for being one of the few network environments where cryptographic smart card authentication is actually routine(SIMs haven't mechanically been smartcards in ages; but logically and electrically they are); but wifi security if you actually care is quite robust, it's just that the spec includes options intended to be trivial to set up.
This proposal appears to be an attempt to change that; but the original LTE-in-ISM-bands spec has a really nasty, though admittedly rather clever, trick: this"LTE-U" moves some or all of the data channel into unlicensed spectrum; but the spec mandates that the control channel be in a licensed band. Probably not entirely without technical reason(a control channel subject to fewer sources of interference is likely more reliable and predictable); but means that only someone who controls at least some licensed spectrum can play; while the bulk of the noise produced lands right in the unlicensed bands. As originally specified, running the control channel in ISM was not an option, period, which made it look an awful lot like a deliberate move to lock out smaller players. This spec, while immature, attempts to at least let you try to run an all-ISM implementation.
As always, unlimited amount of magic financial instrument money are just 'productivity'; but any rise in real wages means that we are just days away from Wiemar hyperinflation. I'm totally shocked that the Wall Street Journal might hold this opinion.
Perhaps some abstract concept of 'Democracy'(probably represented by a topless marble statue, as abstract classical concepts always seem to be) doesn't; but isn't it fairly silly to say that "Democracy doesn't give a shit about the comment forms on a website" when that website and comment forms exist because of the public comment section of the structure of the FCC rulemaking process; as determined in accordance with the FCC's congressional authorization?
What exactly does 'democracy giving a shit' look like?
The annoying bit isn't the absolute amount of maintenance required, which is fairly low; but the fact that it's required more or less entirely because somebody thought that coating the parts of the laptop that you touch with fabric(among the more efficient materials for removing crud from your hands, which is why we make washclothes and towels out of it) would be cooler than boring old plastic or metal.
Even small inconveniences are galling when they are for stupid, pointless, reasons. When the person in charge of defending those reasons tries to insist that the inconvenience is just part of the product being 'luxurious' that doesn't help at all.
The massive blind spot (or possibly rhetorical sleight-of-hand) here is the casual conflating of "The Windows Store" with "a new Windows packaging mechanism".
.exe installers isn't great; and that the ability of win32 applications to, unless very, very, carefully kept on a leash, scribble all over one another is a risk. If so; an improved installer format and some sort of application isolation(ideally not hacked on with a bunch of virtualization layers; like the "App-V" stuff designed to let enterprise users take legacy applications and isolate them whether they like it or not).
It's pretty easy to make a case that today's combination of mostly MSI files with some vendors still shipping in-house or legacy
However, none of this has any relationship whatsoever with Microsoft's precious "App Store"; and their desire to be the sole gatekeeper for cryptographically blessed software and get their 30% cut. And this aspect of the deal is not something that is of plausible value to anyone who isn't Microsoft. It's unlikely that MS will be able to get rid of 'legacy' Windows entirely; because Corporate would scream; but they would love for this 'Windows S' to become the de-facto 'Home Edition', with anyone who wants to go outside the walled garden paying an upgrade fee for the privilege.
This seems like a fatal flaw in the argument. If this were just about a fight between MSI loyalists and APPX fanboys; it would be easy to make the case that the legacy tech isn't good enough. That, however, is a relatively minor part of the issue; with the 'Store' being placed front and center by Microsoft's decision to effectively link UWP/APPX with the store(yes, there is a 'sideload' switch, at least for now; but the only remotely preferred configuration involves everyone with a Microsoft account, buying software, from any vendor, through the Microsoft store.
I'd agree that "firewalling" can be a nontrivial exercise(and, as in the situation you note, frequently cannot just involve a "drop everything" rule and a satisfied expression); but in a situation like that you would presumably restrict their SMB access so that they could only interact with SMB on a single, actually supported, system you control that would effectively act as an SMB proxy(in the inelegant sense of having the same directory(s) available over SMB on one interface to the 98 boxes; and over another to the outside world; I don't think that there's any sort of 'rewrite SMB for safety" proxy option).
Definitely ugly; and (while being willing to do it can pay the bills) part of why dealing with legacy systems isn't considered a joyful hobby; but also exactly the sort of situation where "You can add a relatively low end Windows Server(possibly even desktop, depending on volume and what, if any, other features you need) SKU and some network adjustments to the situation and keep the 98 machines safely away from everything else" sounds a lot more attractive than "Well, there's this cool alpha/maybe-beta-ish OS we can try installing..." Win98 is certainly no marvel of uptime; but "30k scanner" is one of those things where downtime displeases people.
How closely are video standards tied to mains frequencies these days? There was obviously a strong technical reason for it back when video transmission was analog; and quality timebases were rather hard to come by; and technology has a considerable amount of inertia; but with contemporary hardware if anything except the PSU can even detect the mains frequency, you probably have a hardware problem; and essentially everything(aside from PSUs) is low voltage DC gear with very, very, accurate and fairly versatile clocks that keep whatever time the designers want them to.
Is it just about legacy compatibility/compatibility with video encoded for broadcast on systems that require legacy compatibility? Are there any other reasons for the historical frame rates?