6 ms·

>Security is of secondary concern than that Machine A actually works... I don't think this is true, but of course, it depends on the use case too. Security and

>Security is of secondary concern than that Machine A actually works... I don't think this is true, but of course, it depends on the use case too. Security and safety are usually pretty important to me, to a point where I don't use something if I deem it unsafe or insecure. It's not putting the cart before the horse, it's having a bar of standard, and keeping behavior to it. With regards to security, I agree with the dependency that you describe. Because the browser depends on the OS, if the OS is insecure, I consider the browser insecure as well. So, let me rephrase the original argument: because the OS dead, it doesn't make sense for developers to support it, because no matter how secure they make their software, the dead, insecure OS will render that insecure as well. >We do, at minimum, know that there were groups of people I agree, this is my exact point. No person ever truly understood anything. What we actually do is trust, and we manage that trust in ways. >Terry A. Davis, the creator of TempleOS, deserves to be praised for his effort, not shamed We're not shaming Terry here. What I did was that I mentioned his vertical understanding of the system that he created. >Consider looking into Dilbert I know Dilbert. Management have faults, as they are people too, and so, fallible. But coming from a pure technology background, it has been a revelation to me to understand some of their frameworks of thinking. The reason I suggest this is because many of the happenings are not understandable from a technological standpoint, as the decisions are technologically inferior. But they make sense from a service, or product standpoint. Please consider the original argument. It's not a huge conspiracy for internet connected software to not support insecure underlying systems. And yes, power is shifting, maybe now away from the OS, and towards Chrome, but also consider that even the browser itself is secondary to what device people actually use the browser on, which is the smartphone and not the PC. And what you can see is that Google browser is used on Google phones, and Apple browser is being used on Apple phones. What they are all doing, and Microsoft wanted too, but failed (but did in the past on the PC), is vertically integrating, and trying to control the market by controlling the standards. Which is as old as a person yelling at their partner that they won't find anyone else besides them, so they should appreciate them more. Just with products and services and large corporations.

peter_d_sherman 3y ago
>I agree with the dependency that you describe. Because the browser depends on the OS, if the OS is insecure, I consider the browser insecure as well. Yes -- if you have a secure Browser running on an insecure OS, your secure Browser is insecure. If you have a secure Browser running on a secure OS on insecure hardware, then your "secure" OS is insecure, and your "secure" Browser -- is also insecure! "A chain is only as strong as the weakest link" -- as the old saying goes! A software security chain (multiple dependent components) that must run on a hardware security chain (again, multiple dependent components) that must communicate over the Internet (another security chain, again, multiple multiple dependent components) is only as strong/secure as its weakest link. >So, let me rephrase the original argument: because the OS dead, it doesn't make sense for developers to support it, because no matter how secure they make their software, the dead, insecure OS will render that insecure as well. Our debate (if we actually have one!) is not so much about security (secondary aspect!) so much as it is about the simplicity/understandability/controllability/transparency/public auditability aka the "democratization" -- of systems. We need simple! "As simple as possible, and not simpler!" -- as Einstein famously said! Chrome/Chromium (more generally "The Web Browser" -- complex ones that support all known modern day Web features) and the OS'ses that support those browsers need to be "cleaned up" -- radically refactored and documented into the simplest, most-understandable pieces of software that will still support those features... Think of it this way... if those systems grow in complexity over time, and if humanity's knowledge of them correspondingly shrinks over time, then eventually the time will come in Earth's future when those systems can no longer be maintained, cause more problems then they solve, and will eventually have to be abandoned for lower technological levels. >Please consider the original argument. The original "argument", which I made, in my original post, was as follows: >>"I wish to award massive kudos to the Author, because it's about time that somebody began the onerous (yet absolutely necessary!) task of backporting Chrome/Chromium to older simpler/more understandable -- systems." and >>"In the future, it would be great to see the simplest (least amount of lines of code) OS that could successfully run Chrome/Chromium -- but even going a step farther than that, it might be an idea to freeze the Chrome/Chromium source at a certain point, then simplify Chrome/Chroumium such that its dependencies on an underlying OS were minimized! In other words, develop a fork of Chrome/Chromium in lock-step with developing the simplest OS that Chrome/Chromium could possibly run on, with the corresponding idea of refactoring all of that software into the simplest, cleanest, most documented, most modular piece of software that is or could exist." The Author of Supermium deserves massive kudos, massive thanks -- for taking the first hard step in that process... Security, if it exists, is a side-aspect (an effect, not a cause!) of the simplicity/clarity/transparency/auditability of a given software stack, a given software chain. If parts of that chain are opaque and/or "black boxes", then those may have problems in the future! I prefer completely transparent, completely auditable software chains, if they are available, and if I can get them (some vendors force opaque, black-box binary blobs down their customers' throats, and sometimes there isn't anything a customer can do about it...)... Anyway, you're welcome to select whatever software stack you want on top of whatever hardware stack you want, with whatever degree of opacity/transparancy you want (as is everybody else!) -- but I prefer transparent and auditable (open source software, open source hardware) whenever I can get it...

peter_d_sherman 3y ago

>I agree with the dependency that you describe. Because the browser depends on the OS, if the OS is insecure, I consider the browser insecure as well. Yes -- if you have a secure Browser running on an insecure OS, your secure Browser is insecure. If you have a secure Browser running on a secure OS on insecure hardware, then your "secure" OS is insecure, and your "secure" Browser -- is also insecure! "A chain is only as strong as the weakest link" -- as the old saying goes! A software security chain (multiple dependent components) that must run on a hardware security chain (again, multiple dependent components) that must communicate over the Internet (another security chain, again, multiple multiple dependent components) is only as strong/secure as its weakest link. >So, let me rephrase the original argument: because the OS dead, it doesn't make sense for developers to support it, because no matter how secure they make their software, the dead, insecure OS will render that insecure as well. Our debate (if we actually have one!) is not so much about security (secondary aspect!) so much as it is about the simplicity/understandability/controllability/transparency/public auditability aka the "democratization" -- of systems. We need simple! "As simple as possible, and not simpler!" -- as Einstein famously said! Chrome/Chromium (more generally "The Web Browser" -- complex ones that support all known modern day Web features) and the OS'ses that support those browsers need to be "cleaned up" -- radically refactored and documented into the simplest, most-understandable pieces of software that will still support those features... Think of it this way... if those systems grow in complexity over time, and if humanity's knowledge of them correspondingly shrinks over time, then eventually the time will come in Earth's future when those systems can no longer be maintained, cause more problems then they solve, and will eventually have to be abandoned for lower technological levels. >Please consider the original argument. The original "argument", which I made, in my original post, was as follows: >>"I wish to award massive kudos to the Author, because it's about time that somebody began the onerous (yet absolutely necessary!) task of backporting Chrome/Chromium to older simpler/more understandable -- systems." and >>"In the future, it would be great to see the simplest (least amount of lines of code) OS that could successfully run Chrome/Chromium -- but even going a step farther than that, it might be an idea to freeze the Chrome/Chromium source at a certain point, then simplify Chrome/Chroumium such that its dependencies on an underlying OS were minimized! In other words, develop a fork of Chrome/Chromium in lock-step with developing the simplest OS that Chrome/Chromium could possibly run on, with the corresponding idea of refactoring all of that software into the simplest, cleanest, most documented, most modular piece of software that is or could exist." The Author of Supermium deserves massive kudos, massive thanks -- for taking the first hard step in that process... Security, if it exists, is a side-aspect (an effect, not a cause!) of the simplicity/clarity/transparency/auditability of a given software stack, a given software chain. If parts of that chain are opaque and/or "black boxes", then those may have problems in the future! I prefer completely transparent, completely auditable software chains, if they are available, and if I can get them (some vendors force opaque, black-box binary blobs down their customers' throats, and sometimes there isn't anything a customer can do about it...)... Anyway, you're welcome to select whatever software stack you want on top of whatever hardware stack you want, with whatever degree of opacity/transparancy you want (as is everybody else!) -- but I prefer transparent and auditable (open source software, open source hardware) whenever I can get it...