How would they get a kernel-level virus onto the boot sector/partition? If a user has some method that would let them modify the boot volume, they have a way to modify passwd/shadow/SAM. Either the enduser runs something as admin (which admittedly full disk encryption would do nothing to stop) or an offline attack is required with or without secureboot (which full disk encryption can stop).
My point is it only works against a subset of boot sector virus: ones that run a modified kernel or stage before the kernel. Malware can do plenty in userspace, and in many cases it's impossible for a generic subsytem to tell whether a userspace customization is authentic or malicious.
Contrast this with disk encryption sealed to TPMs. This would ideally be modified such that there is a PCR mutated by fingerprints of efi executables. This would enable a shim.efi to do unsealing and have that particular OS vendor's chain of trust rooted without the firmware having to manage central keys and also providing meaningful protection against offline attacks.
The other problem I have is that SecureBoot, practically speaking, makes MS the gatekeeper to the PC platform. You want to boot your OS on user systems, go talk to Microsoft. This has two effects: 1) Gives MS too much control and a nice anti-competitive lever to use if they wanted. 2) To do this without being perceived as anti-competitive and given resources, they probably have had to sign more than they should. This means there is likely some vulnerable stack that is signed floating about. In theory MS could revoke keys, but I don't think they ever have for one, and for another the chances that a user gets an update with an updated revocation database is far from guaranteed.
I would have much preferred a spec that had the install media do a vendor-specific key install, and a mandatory baked in option to remove the key and revocation db. This would have given much more fine grained control for verification of vendor provided assets. At the end of the day though, full disk encryption is a mandatory part of your strategy if you really want to protect from offline attacks.
The point is that DKMS/akmod type packages make out-of-tree drivers auto-handle updates, and any system can just be applying updates from vendor with no effort required to stage it, on each server.
Here, you must vet every single kernel update and prepare your matching kmods prior to letting systems apply the fix.
I didn't say you couldn't build your kernel as you describe, just that deploying akmods/dkms type driver packages to your systems becomes a non viable approach, and that a more tedious approach (as you describe).
Actually, I recall that time I held back my boot volume, so I knew they couldn't have modified it. I am trusting that the TPM is acting as advertised, but at some level that becomes unavoidable.
Of course, this can't play well with akmods/dkms and still be secure, since for that to work you'd need the signing key easily available. So you will have to take a more tedious approach for out-of-distro drivers than before.
Secure Boot protects against malware and malicious hardware, as well as teenagers with Linux on USB thumb drives bypassing security altogether.
Actually, it does none of that. This is one of my peeves with secureboot, it is annoying *and* largely ineffectual.
On malware, yes, it would protect against a certain class of malware: boot sector virus. But then again, a subset. Sure you can't be a kernel, and that does hypothetically give the OS creators a foundation to have some layer that is intact. What if your malware is a patched gdm, sshd, pam, or agetty? Yeah, those would be fine. Windows still has plenty of malware despite being 'Secureboot'. What about replacing/etc/shadow in linux or the SAM db in Windows? Sure, that is also fair game, go ahead and insert your backdoor account with admin privilege.
On malicious hardware, it doesn't do anything, though related technologies can cause UEFI drivers to not execute if not signed. The OS asks the platform if it is secureboot enabled and takes the answer at face value (there's no secure mechanism to vlaidate that the platform isn't lying to you).
As far as Linux or Windows PE on USB thumb drives, again it doesn nothing. A windows or linux install disk can also be a 'rescue' disk. For that matter, secureboot covers neither the initramfs nor the wim file, so make your own privileged install media, it's all good as far as secureboot is concerned. You don't need a custom kernel to make a boot disk.
With that, what are the protections against the general class of replacement hardware/boot configuration/boot media?
Well, the weakest is a BIOS/UEFI/bootloader passwords, which in theory mitigates the chances someone can select their bootable media. In BIOS systems, it is common for USB disk to boot preferentially, so this might not pan out. The typical UEFI boot setup on the otherhand is a bit more specific by usually having a single boot item and that boot item being the machine specific boot partiion GUID and file. However even then I suspect you could probably discern the boot volume guid as non-admin user, and I don't know what UEFI will do if you have removable media with the same GUID as the boot volume. Also, none of this does a damn thing if the attacker could remove the boot media and mess with it offline.
So now we have SED/BitLocker/dm-crypt soultions, which are more hardened. However, by themselves these make automatic reboots impossible, and are thus highly annoying. For another, the keyphrase prompt can be emulated and phished if an attacker has two cracks at your system (one to install a fake prompt using a valid kernel, another to go and glean the captured secret.
At last we come to the most relevant security approach: Trusted Boot. Here you use SED/BitLocker/dm-crypt as above, but rather than prompting for password, you seal the key to TPM PCRs. This allows the system to boot and unlock automatically, but only if the user didn't do anything different (like boot form a different device, or enter f1 setup, or replaced the motherboard). Again at least one potential hole is whether you can spoof a GUID to trick the platform to boot with the same PCR state. another limitation is that generally you have a backup password, and a user could assume if they see the prompt, something innocuous went wrong rather than malicious (e.g. I had a device that went in for warranty repair, and the PCR state was lost forever and so I had to take it on faith the repair center nor the mail system did anything to phish the recovery prompt).
I have not undergone the training, but I wouldn't be 100% certain the tone of the person conducting the training would be/has been that grave on the matter, particularly when the person doing the training I assume is the same salesman that had previously been chatting up autopilot and how powerful it is.
I did watch a video of the warning, and it is very unobtrusive and only demands that you touch the wheel once every three minutes or so. Everything about this seems consistent with Musk's general attitude that autopilot is good enough and all these warnings are crap (he doesn't say it, but his attitude is clearly that people are being too critical of autopilot and too worried and they have to put in warnings to placate people).
While it is the correct thing for users of a product to understand things better, the situation remains that from a responsible marketing perspective, Tesla is doing the wrong thing.
You can't even play the "Tesla is technically correct, the best kind of correct" card and say the plebes should just get over it, as nothing "pilots" a car. It doesn't resemble the methods of airplane autopilot enough to say they are bringing over the technology either. So it's a technology given a misleading name for the sake of marketing. If anything, calling something that drives your car 'autopilot' is fostering layman misuse of a word, not being technically correct the layman has to learn to be 'proper'.
This does not seem to be a concept that any of Tesla's competitors have trouble with.
Also, how many of those 86 million miles *could have been autopilot (since autopilot can opt out of conditions the driver cannot)* and how many of those if you remove cars that mechanically break (old cars, Tesla's aren't old enough yet to exhibit this), and adjust for various safety technologies (from anti-lock brakes, to airbags, to just having braking, to competitor systems that do have some sort of lane keep assist, but only for accident avoidance and otherwise doesn't help someone drive with their hands off the steering wheel).
Just need a cosmetic replacement, doesn't even need to be a functional chip.
After all, the cards will look right, but they still won't work if they have an old, mismatched chip. In fact it may be even better if it seems like it doesn't work because of malfunction rather than having a key mismatch, might buy you a few more days before the cardholder gets it fixed (assuming the POS equipment flags an obviously wrong chip more clearly than chip malfunction).
The marketing ploy certainly contributes, but also the design decision to basically work when the person is completely inattentive. Contrast this with other systems that offer steering assist only in an exceptional scenario, and create an unacceptable driving experience when the steering has to intervene for lane keeping, requiring the human to generally be the one steering, with machine intervention only when it detects a dangerous scenario.
This all misses the point: the vast majority of people are not pilots, everything they think about 'autopilot' comes from tv shows and media and every thing they deal with that is 'auto' in their lives meaning not having to worry about it.
Pilots can debate the accuracy of the term given the reality of the situation, but what matters is the lay man's perspective (which is precisely what Tesla is trying to take advantage of).
Additionally, they assert safety of AP relative to *all other vehicles* in *all conditions*. It is in fact highly likely that systems with auto braking and lane alarms (without just doing all the steering for you) are safer than autopilot. Such systems don't really allow for a driver to stop paying attention compared to autopilot's system (there's nagging and then there's "your car simply doesn't go unless you actively are steering it").
This is one of the things that royally aggravates me about Tesla, they are so smug about their belief that autopilot is unambiguously the most safe answer, and are dangerously reckless in that belief.
External GPU has 40 Gbit/s, versus that same GPU getting 128 gbit/s of throughput internally. In the 2019 timeframe, that PCIe number will jump to 256 gbit/s with PCIe gen 4. There has been very little information on Thunderbolt 4, but even the most optimistic speculation has it at 80 gpbs and after pcie gen 4.
One can argue that a fair number of applications settle for x8 PCIe (64 gbit/s) to get to SLI, but even then you are ahead of thunderbolt 3 and you also have a second GPU.
Additionally, serdes and encapsulation mean that latency is significantly impacted.
This may not matter for a great chunk of the market, but it still has an impact for some.
Even if you strip off the microcode and the instruction decode (which is intrinsic to the platform an dI would argue you cannot strip away), you'd still be left with a behemoth that most would not call RISC, except for religious adherents to the hype of RISC as a way to claim victory.
Of course, everything has dramatically changed since the m68k CISC v. Berkeley RISC days, and this whole debate is silly. Just because something is CISC, it doesn't vindicate the m68k design that spawned the architectural exploration that would be called RISC..
Well, pretty much all modern SIMD instructions are not RISC.
For specifics, here's an ARM document about instructions in the pipeline and how many cycles the different instructions are: http://infocenter.arm.com/help...
RISC was supposed to be that any given instruction was simplistic and would use no more than a single cycle, and that the processing units would be utterly generic. Now we have something of a hybrid of that philosophy and CISC philosophy, with people 'rooting' for the relatively meaningless 'CISC v RISC' designations as they would their favored sports team.
The issue being that RISC was a technical feature that became a marketing bullet point. As the original bet of RISC architecture was lost (that complex hardware could not scale up, and that compiler optimization would close the gap of CISC), surviving high performance "RISC" families started embracing instruction set extensions to include multi-cycle instructions.
However, marketing material continued to beat the old dead horse of how RISC was better, despite their own designs seemingly saying otherwise.
RISC v. CISC deteriorated from a technical discussion to a sports team sort of affair. The reality is far more nuanced than that nowadays, and the strategic differnece was eroding a lot in the mid 90s and has gone away by now.
First step, find a prominent RISC platform that doesn't just have RISC in the name for historical reasons. At this point, everything with any performance is CISC (whether by the inaccurate concept of count of available instructions, or in terms of how many instructions per memory cycle as was the original intent).
If I were a technology company, I wouldn't want to go anywhere near other people's future without something like a license to use the patents.
I would be in great fear that someone in my company would do something that resembles a private draft of a patent one of those users is working on. This happens all the time by coincidence, but having access to customer research/draft prior to patent application just raises a lot more suspicion if you happen to do the same or similar thing as that research goes to.
If you want a service to help you with patents and you want to keep control of it, you go to a legal company, not a technology company that is likely to have a conflict of interest.
The only thing that is fundamentally better about old systems is having physical controls instead of touch control. The main problem on the mobile gaming front is the signal to noise ratio is terrible, and crappy games dominate because they are so much easier to make and anyone can churn out software now.
I don't know if you have revisited shows from your youth, but when I did, I discovered pretty quickly they were a lot crappier than I remember. I would say that on this front, my child watches shows that are hands down better written than what I watched as a child. It is painfully obvious in hindsight that people who produced the shows I watched were phoning it in and just wanted to get toy ads out there. It may still be the case that companies are mostly trying to advertise toys, but I think there are more people involved that actually care about their work.
In the consumer space, Microsoft brand strength is pretty weak. In corporate, it's exceedingly strong. In many corporate environments, it is heresy to even suggest that possibly a non-microsoft solution would work as well or better for the same or lesser money. MS is a religion of much of corporate IT.
Of course there was a time when Microsoft was the joke of a consumer grade device, and for real work you would have a mainframe or solaris worksation or AIX. Now, well your identity management is probably microsoft, your business pc is probably MS and servers at least have to play nice with MS services and clients. One could imagine the same occurring with Google ecosystem, wokring from daily consumer experience into the workplace. It's one reason I really don't want to see Google compute engine do very well in the hosting space.
Windows 10 with secureboot in S mode is pretty much the same thing. It has been a flop, as from a functional perspective all it does is prevent things you want to use from working. ChromeOS is in pretty much the same boat, if you want to do anything interesting you need Google's blessing, but Google somehow doesn't catch as much flak for that as MS did.
It takes a team of security experts, plus outside researchers and security audit firms working together to make a system secure
I refer to indivduals using a decently capable platform on their personal device. It can't be the case that an individual needs a team of security experts to use their own laptop securely.
I agree with your sentiment, but it seems "anyone with a clue" is practically no one on the web.
I will say while front end development need not be complex, it does require design sensibilities that I simply do not possess. Sure, if someone knows what they want, I know how to do it. However if I'm left to my own devices to figure out what to do, I'm not going to produce a very good user experience. I have no idea if such sensibilities can really be taught, though there are probably some matters of human factors that are part of a curriculum that would be valuable. Agreed about restyling OS native widgets, but I hope UX degrees are deeper than styling controls.
To me, backend and frontend have some different sensibilites.
On the backend, you are most benefited by being a solid programmer, very good at abstraction. You get to dictate terms, to some extent, of how the network is utilized.
On the frontend, your job is more of design/human factors. You have to worry about accessibility and the psychology of the user. You certainly need programming skill, but design dominates.
For conext, personally I *can* be a full stack developer in a pinch, I know how to do a lot of complex things in a web browser and interact with APIs. However, I don't have a good mind for design, so I produce ugly UIs., or UIs that don't make a lot of sense. This is good enough to draft some proof of concept example client code for someone with those sensibilities to pick up and run with, or to help collaborate and understand the code of the frontend better to help them fix theirs and/or understand how the backend can make their jobs easier, but it isn't really acceptable for a good experience.
I've not yet met anyone who was superb at both. I've seen some people that can do good frontend work try to do backend and spew out some horrific nodejs stuff. I have seen backend developers produce frontends that bear no small resemblance to the work o a geocities "webmaster" from the late 90s.
Slashdot Mirror
How would they get a kernel-level virus onto the boot sector/partition? If a user has some method that would let them modify the boot volume, they have a way to modify passwd/shadow/SAM. Either the enduser runs something as admin (which admittedly full disk encryption would do nothing to stop) or an offline attack is required with or without secureboot (which full disk encryption can stop).
My point is it only works against a subset of boot sector virus: ones that run a modified kernel or stage before the kernel. Malware can do plenty in userspace, and in many cases it's impossible for a generic subsytem to tell whether a userspace customization is authentic or malicious.
Contrast this with disk encryption sealed to TPMs. This would ideally be modified such that there is a PCR mutated by fingerprints of efi executables. This would enable a shim.efi to do unsealing and have that particular OS vendor's chain of trust rooted without the firmware having to manage central keys and also providing meaningful protection against offline attacks.
The other problem I have is that SecureBoot, practically speaking, makes MS the gatekeeper to the PC platform. You want to boot your OS on user systems, go talk to Microsoft. This has two effects:
1) Gives MS too much control and a nice anti-competitive lever to use if they wanted.
2) To do this without being perceived as anti-competitive and given resources, they probably have had to sign more than they should. This means there is likely some vulnerable stack that is signed floating about. In theory MS could revoke keys, but I don't think they ever have for one, and for another the chances that a user gets an update with an updated revocation database is far from guaranteed.
I would have much preferred a spec that had the install media do a vendor-specific key install, and a mandatory baked in option to remove the key and revocation db. This would have given much more fine grained control for verification of vendor provided assets. At the end of the day though, full disk encryption is a mandatory part of your strategy if you really want to protect from offline attacks.
The point is that DKMS/akmod type packages make out-of-tree drivers auto-handle updates, and any system can just be applying updates from vendor with no effort required to stage it, on each server.
Here, you must vet every single kernel update and prepare your matching kmods prior to letting systems apply the fix.
I didn't say you couldn't build your kernel as you describe, just that deploying akmods/dkms type driver packages to your systems becomes a non viable approach, and that a more tedious approach (as you describe).
Actually, I recall that time I held back my boot volume, so I knew they couldn't have modified it. I am trusting that the TPM is acting as advertised, but at some level that becomes unavoidable.
Of course, this can't play well with akmods/dkms and still be secure, since for that to work you'd need the signing key easily available. So you will have to take a more tedious approach for out-of-distro drivers than before.
Secure Boot protects against malware and malicious hardware, as well as teenagers with Linux on USB thumb drives bypassing security altogether.
Actually, it does none of that. This is one of my peeves with secureboot, it is annoying *and* largely ineffectual.
On malware, yes, it would protect against a certain class of malware: boot sector virus. But then again, a subset. Sure you can't be a kernel, and that does hypothetically give the OS creators a foundation to have some layer that is intact. What if your malware is a patched gdm, sshd, pam, or agetty? Yeah, those would be fine. Windows still has plenty of malware despite being 'Secureboot'. What about replacing /etc/shadow in linux or the SAM db in Windows? Sure, that is also fair game, go ahead and insert your backdoor account with admin privilege.
On malicious hardware, it doesn't do anything, though related technologies can cause UEFI drivers to not execute if not signed. The OS asks the platform if it is secureboot enabled and takes the answer at face value (there's no secure mechanism to vlaidate that the platform isn't lying to you).
As far as Linux or Windows PE on USB thumb drives, again it doesn nothing. A windows or linux install disk can also be a 'rescue' disk. For that matter, secureboot covers neither the initramfs nor the wim file, so make your own privileged install media, it's all good as far as secureboot is concerned. You don't need a custom kernel to make a boot disk.
With that, what are the protections against the general class of replacement hardware/boot configuration/boot media?
Well, the weakest is a BIOS/UEFI/bootloader passwords, which in theory mitigates the chances someone can select their bootable media. In BIOS systems, it is common for USB disk to boot preferentially, so this might not pan out. The typical UEFI boot setup on the otherhand is a bit more specific by usually having a single boot item and that boot item being the machine specific boot partiion GUID and file. However even then I suspect you could probably discern the boot volume guid as non-admin user, and I don't know what UEFI will do if you have removable media with the same GUID as the boot volume. Also, none of this does a damn thing if the attacker could remove the boot media and mess with it offline.
So now we have SED/BitLocker/dm-crypt soultions, which are more hardened. However, by themselves these make automatic reboots impossible, and are thus highly annoying. For another, the keyphrase prompt can be emulated and phished if an attacker has two cracks at your system (one to install a fake prompt using a valid kernel, another to go and glean the captured secret.
At last we come to the most relevant security approach: Trusted Boot. Here you use SED/BitLocker/dm-crypt as above, but rather than prompting for password, you seal the key to TPM PCRs. This allows the system to boot and unlock automatically, but only if the user didn't do anything different (like boot form a different device, or enter f1 setup, or replaced the motherboard). Again at least one potential hole is whether you can spoof a GUID to trick the platform to boot with the same PCR state. another limitation is that generally you have a backup password, and a user could assume if they see the prompt, something innocuous went wrong rather than malicious (e.g. I had a device that went in for warranty repair, and the PCR state was lost forever and so I had to take it on faith the repair center nor the mail system did anything to phish the recovery prompt).
I have not undergone the training, but I wouldn't be 100% certain the tone of the person conducting the training would be/has been that grave on the matter, particularly when the person doing the training I assume is the same salesman that had previously been chatting up autopilot and how powerful it is.
I did watch a video of the warning, and it is very unobtrusive and only demands that you touch the wheel once every three minutes or so. Everything about this seems consistent with Musk's general attitude that autopilot is good enough and all these warnings are crap (he doesn't say it, but his attitude is clearly that people are being too critical of autopilot and too worried and they have to put in warnings to placate people).
While it is the correct thing for users of a product to understand things better, the situation remains that from a responsible marketing perspective, Tesla is doing the wrong thing.
You can't even play the "Tesla is technically correct, the best kind of correct" card and say the plebes should just get over it, as nothing "pilots" a car. It doesn't resemble the methods of airplane autopilot enough to say they are bringing over the technology either. So it's a technology given a misleading name for the sake of marketing. If anything, calling something that drives your car 'autopilot' is fostering layman misuse of a word, not being technically correct the layman has to learn to be 'proper'.
This does not seem to be a concept that any of Tesla's competitors have trouble with.
Also, how many of those 86 million miles *could have been autopilot (since autopilot can opt out of conditions the driver cannot)* and how many of those if you remove cars that mechanically break (old cars, Tesla's aren't old enough yet to exhibit this), and adjust for various safety technologies (from anti-lock brakes, to airbags, to just having braking, to competitor systems that do have some sort of lane keep assist, but only for accident avoidance and otherwise doesn't help someone drive with their hands off the steering wheel).
Just need a cosmetic replacement, doesn't even need to be a functional chip.
After all, the cards will look right, but they still won't work if they have an old, mismatched chip. In fact it may be even better if it seems like it doesn't work because of malfunction rather than having a key mismatch, might buy you a few more days before the cardholder gets it fixed (assuming the POS equipment flags an obviously wrong chip more clearly than chip malfunction).
The marketing ploy certainly contributes, but also the design decision to basically work when the person is completely inattentive. Contrast this with other systems that offer steering assist only in an exceptional scenario, and create an unacceptable driving experience when the steering has to intervene for lane keeping, requiring the human to generally be the one steering, with machine intervention only when it detects a dangerous scenario.
This all misses the point: the vast majority of people are not pilots, everything they think about 'autopilot' comes from tv shows and media and every thing they deal with that is 'auto' in their lives meaning not having to worry about it.
Pilots can debate the accuracy of the term given the reality of the situation, but what matters is the lay man's perspective (which is precisely what Tesla is trying to take advantage of).
Additionally, they assert safety of AP relative to *all other vehicles* in *all conditions*. It is in fact highly likely that systems with auto braking and lane alarms (without just doing all the steering for you) are safer than autopilot. Such systems don't really allow for a driver to stop paying attention compared to autopilot's system (there's nagging and then there's "your car simply doesn't go unless you actively are steering it").
This is one of the things that royally aggravates me about Tesla, they are so smug about their belief that autopilot is unambiguously the most safe answer, and are dangerously reckless in that belief.
They'd need intel and AMD's blessing and to pay them royalties to do AMD64.
External GPU has 40 Gbit/s, versus that same GPU getting 128 gbit/s of throughput internally. In the 2019 timeframe, that PCIe number will jump to 256 gbit/s with PCIe gen 4. There has been very little information on Thunderbolt 4, but even the most optimistic speculation has it at 80 gpbs and after pcie gen 4.
One can argue that a fair number of applications settle for x8 PCIe (64 gbit/s) to get to SLI, but even then you are ahead of thunderbolt 3 and you also have a second GPU.
Additionally, serdes and encapsulation mean that latency is significantly impacted.
This may not matter for a great chunk of the market, but it still has an impact for some.
Even if you strip off the microcode and the instruction decode (which is intrinsic to the platform an dI would argue you cannot strip away), you'd still be left with a behemoth that most would not call RISC, except for religious adherents to the hype of RISC as a way to claim victory.
Of course, everything has dramatically changed since the m68k CISC v. Berkeley RISC days, and this whole debate is silly. Just because something is CISC, it doesn't vindicate the m68k design that spawned the architectural exploration that would be called RISC..
Well, pretty much all modern SIMD instructions are not RISC.
For specifics, here's an ARM document about instructions in the pipeline and how many cycles the different instructions are:
http://infocenter.arm.com/help...
RISC was supposed to be that any given instruction was simplistic and would use no more than a single cycle, and that the processing units would be utterly generic. Now we have something of a hybrid of that philosophy and CISC philosophy, with people 'rooting' for the relatively meaningless 'CISC v RISC' designations as they would their favored sports team.
The issue being that RISC was a technical feature that became a marketing bullet point. As the original bet of RISC architecture was lost (that complex hardware could not scale up, and that compiler optimization would close the gap of CISC), surviving high performance "RISC" families started embracing instruction set extensions to include multi-cycle instructions.
However, marketing material continued to beat the old dead horse of how RISC was better, despite their own designs seemingly saying otherwise.
RISC v. CISC deteriorated from a technical discussion to a sports team sort of affair. The reality is far more nuanced than that nowadays, and the strategic differnece was eroding a lot in the mid 90s and has gone away by now.
First step, find a prominent RISC platform that doesn't just have RISC in the name for historical reasons. At this point, everything with any performance is CISC (whether by the inaccurate concept of count of available instructions, or in terms of how many instructions per memory cycle as was the original intent).
future patents I meant.
If I were a technology company, I wouldn't want to go anywhere near other people's future without something like a license to use the patents.
I would be in great fear that someone in my company would do something that resembles a private draft of a patent one of those users is working on. This happens all the time by coincidence, but having access to customer research/draft prior to patent application just raises a lot more suspicion if you happen to do the same or similar thing as that research goes to.
If you want a service to help you with patents and you want to keep control of it, you go to a legal company, not a technology company that is likely to have a conflict of interest.
The only thing that is fundamentally better about old systems is having physical controls instead of touch control. The main problem on the mobile gaming front is the signal to noise ratio is terrible, and crappy games dominate because they are so much easier to make and anyone can churn out software now.
I don't know if you have revisited shows from your youth, but when I did, I discovered pretty quickly they were a lot crappier than I remember. I would say that on this front, my child watches shows that are hands down better written than what I watched as a child. It is painfully obvious in hindsight that people who produced the shows I watched were phoning it in and just wanted to get toy ads out there. It may still be the case that companies are mostly trying to advertise toys, but I think there are more people involved that actually care about their work.
In the consumer space, Microsoft brand strength is pretty weak. In corporate, it's exceedingly strong. In many corporate environments, it is heresy to even suggest that possibly a non-microsoft solution would work as well or better for the same or lesser money. MS is a religion of much of corporate IT.
Of course there was a time when Microsoft was the joke of a consumer grade device, and for real work you would have a mainframe or solaris worksation or AIX. Now, well your identity management is probably microsoft, your business pc is probably MS and servers at least have to play nice with MS services and clients. One could imagine the same occurring with Google ecosystem, wokring from daily consumer experience into the workplace. It's one reason I really don't want to see Google compute engine do very well in the hosting space.
Windows 10 with secureboot in S mode is pretty much the same thing. It has been a flop, as from a functional perspective all it does is prevent things you want to use from working. ChromeOS is in pretty much the same boat, if you want to do anything interesting you need Google's blessing, but Google somehow doesn't catch as much flak for that as MS did.
It takes a team of security experts, plus outside researchers and security audit firms working together to make a system secure
I refer to indivduals using a decently capable platform on their personal device. It can't be the case that an individual needs a team of security experts to use their own laptop securely.
I agree with your sentiment, but it seems "anyone with a clue" is practically no one on the web.
I will say while front end development need not be complex, it does require design sensibilities that I simply do not possess. Sure, if someone knows what they want, I know how to do it. However if I'm left to my own devices to figure out what to do, I'm not going to produce a very good user experience. I have no idea if such sensibilities can really be taught, though there are probably some matters of human factors that are part of a curriculum that would be valuable. Agreed about restyling OS native widgets, but I hope UX degrees are deeper than styling controls.
To me, backend and frontend have some different sensibilites.
On the backend, you are most benefited by being a solid programmer, very good at abstraction. You get to dictate terms, to some extent, of how the network is utilized.
On the frontend, your job is more of design/human factors. You have to worry about accessibility and the psychology of the user. You certainly need programming skill, but design dominates.
For conext, personally I *can* be a full stack developer in a pinch, I know how to do a lot of complex things in a web browser and interact with APIs. However, I don't have a good mind for design, so I produce ugly UIs., or UIs that don't make a lot of sense. This is good enough to draft some proof of concept example client code for someone with those sensibilities to pick up and run with, or to help collaborate and understand the code of the frontend better to help them fix theirs and/or understand how the backend can make their jobs easier, but it isn't really acceptable for a good experience.
I've not yet met anyone who was superb at both. I've seen some people that can do good frontend work try to do backend and spew out some horrific nodejs stuff. I have seen backend developers produce frontends that bear no small resemblance to the work o a geocities "webmaster" from the late 90s.