Supermium – Chromium fork for Win 2003/XP and newer
win32subsystem.live
win32subsystem.live
Old POS terminals for example? But I think they would just display an ancient website in an ancient browser anyways, and again if the hardware is as old as the rest of the system, this will probably just add slowness with no actual benefit.
Oh and yeah, nice job with the name, I misread it the first time. :-D
That would be the job of the GPU anyway, but H.264 decoding was pretty much standard back then. That's why plugins like h264ify[0] exist for old hardware.
[0] https://chromewebstore.google.com/detail/h264ify/aleakchihdc...
Which the intel GMA GPU's did not support in core2duo era. Those features were added by their gen5 (ironlake) GPU, the first intel HD gpu.
https://web.archive.org/web/20120620155937/http://intellinux...
edit: turns out this was never merged and attempts to get the old code running on a modern stack were not successful
which isnt all that difficult, btw :)
good to point out that it's not enabled by default.
One was an Athlon; the other was a Core Duo. They both had 1GB RAM.
https://www.washingtonpost.com/archive/lifestyle/1993/12/28/...
but I don't think they take old socks.
I guess to use winXP 64 you need to be a driver coder as well to create drivers for latest internal gfx hardware built into intel cpus.
Good on them for getting it to compile and work. I miss WinXP and Win7 with classic UI theme.
If some malware were to compromise it somehow, there's absolutely no credentials or valuable info on there to steal or encrypt for ransom, and the machine is on it's own VLAN, so if it were to hypothetically get infected with something, the malware has nowhere else to pivot in my network just in case someone made some ultra-specific malware that can target both Windows XP machines and Amazon Alexa devices together as if I'm running Iranian nuclear centrifuges or something and have state actors targeting me.
Plus, is there any Windows XP malware still circulating in the wild online mainstream? Feels like worrying about catching smallpox today.
(You are correct in that using a XP machine is likely less risky today if you're only doing so in a LAN and with minimal access to the Internet)
Why? It was just a silly example, not a anti-vax promotion.
The attack vector of malicious ads on these sites are the largest attack vector - which is nearly abysmally small since Chrome is a better sandbox than windows is.
Aside from 0-days, which are basically/practically out of scope, the only thing to worry of is automated scans and 3 letter agencies.
I am behind a NAT, and the 3 letter agencies are inescapable - but a defense of "my computer is old and insecure" may retro-actively be the only plausible deniability that the "layman" such as myself can muster.
Hypothetically. Similar to having an open wifi network for the sole purpose of muddying the waters and adding noise to a signal.
I wonder at what point having a company with a terrible product like that on your resume ruins your chances of being hired somewhere that actually cares about quality products?
The risk of being targeted by one of these is near 100% on a long enough timeline.
I'd _seriously_ advice you to never put a WinXP machine on the internet, even with a firewall in between.
At least get the extended support thingy.
There are lots of Windows 2008 / 2012 servers out there. Not internet facing hopefully. But that still may need something better than Internet Explorer to display webpages.
Also lab machines that are still on XP or 7.
There are private companies that claim backport security updates, although I don't know how effective they are. Their customers are primarily government and defense.
On what basis? Depending on your crankiness level you could argue that "backdoors" far predate that[1].
Despite every major news outlet reporting this back in 2019, this is actually fake news. People saw that the taskbar appeared blue in a low-res photo, and concluded that it must be Windows XP. Very sloppy journalism.
If you look at the full-resolution version of that 2019 photo, it's clear that it's Windows 7 (or maybe 8 with a Start menu mod): http://static.kremlin.ru/media/events/photos/big2x/W2kaDAtDz...
Although it is very possible that more recent proprietary OSes contain spyware, Putin showing himself using XP is almost certainly propaganda to fuel distrust towards Microsoft and western governments/corporations in general. They have top notch FOSS developers in Russia, and I'm sure he can obtain a 100% spyware free Linux/BSD/whatever PC, unless he doesn't trust the hardware itself which can be bugged just like OSes and software (firmware, binary blobs etc.) so that he uses very old iron that most certainly don't contain malware but can run only ancient OSes. If that's the case, then it could make sense.
AMD's licensed zen1 chips that China makes, whose name excapes me at the moment, have the AES instructions and PSP removed. They're also banned from being imported by the state dept, so, that's either because they're also backdoored by china somehow, or, they aren't backdoor-able, maybe both.
Suffice to say however, modern computers (and smartphones) are chock full of potentially spooky SoC's and someone like ol'vlad might just be paranoid enough to not trust them.
That said, I have read many times that Putin does not use any computer or the Internet.
(For those unfamiliar with it, the ME is an inaccessible second CPU running Minix and is network-aware.)
I wouldn't be surprised no. He's got flunkies to do everything for him. And he does seem pretty out of touch with reality, which might be because they tell him only what he wants to hear. For example consider the war on Ukraine, it seems he really expected to overrun them in a day or two.
Hardly. He probably has more important matters to think about. That would be a world record in propaganda with the least impact.
There's no reason for him or anybody else to use inferior FOSS software when an old OS does just fine.
People should wake up, or we will end up in place similar to China, where few clicks from gov official will exclude person from society.
Third, it just runs quickly on newish hardware given that it installs.
I also think it's perfectly valid to just prefer the feel of one OS over another. We live so much of our lives in front of a computer, it is meaningful whether or not that OS brings you joy.
[1]: The CVE database has to have the worst search out of all bug trackers I’ve ever used.
(I think using older versions of Windows is fine. But under no circumstances would I connect them to the internet.)
I really don't think there's anything wrong with browsing the internet.
Chrome: Settings → Downloads → check "Ask where to save each file before downloading".
Edge: Settings → Downloads → check "Ask me what to do with each download".
Firefox: Settings → General → under "Files and Applications", check "Always ask you where to save files".
Safari (macOS): Settings → General → as "File download location", choose "Ask for each download". While you're here, uncheck "Open “safe” files after downloading" (Apple scare quotes "safe" appropriately, yet AFAIK still enables this option by default, even after it's been a factor in multiple exploits over the years).
So it can't be done silently. Although, I do wish the type was marked "DANGEROUS" a la dll files.
There is supposedly a loophole to owning it with EU software laws but not sure if applicable to USA
(and even then, some rare software detects it and refuses to install)
That's not because they're not targeting old operating systems anymore (they are). It's because they already have so many exploits that will never be patched that there's not really a point to coming up with more.
I'm jealous. GDI with MacType was so much better than the default DirectWrite rendering.
There are 3rd party patches to install 120+ but needs safety audit (and unfortunate name)
https://github.com/Blaukovitch/GOOGLE_CHROME_Windows_7_CRACK
Considering there are critical vulnerabilities in 109 you'd think Google might consider the non-evil thing to release an ESR
Its readme is worth reading.
I don't think anyone still using Windows 7 cares
https://support.google.com/chrome/thread/18818459/chrome-tak...
It had the deeply stupid and crappy "Active Desktop", turning the good solid Win95/NT 4 Explorer into a slow and unstable POS that rendered via IE4 so that MS wouldn't get sued or split up by the Department of Justice for illegal restraint of trade in bundling IE with Windows.
A disastrous UI and its broken design contaminates every later release.
Underneath there were good changes: >4 IP addresses, multihead graphics and things.
But bundling IE meant it was broken junk, and that was unforgiveable.
Wherever possible (not too many places due to HTTPS)
Or even Netscape Communicator
I think the few remaining browser makers are too eager to not support OSes that are just a few years old. It is done under the guise of 'security' but executables using older APIs would work perfectly well on new OS versions.
In fact, the browser explicitly not supporting it is a benefit for the user, as they now feel added pressure to use something up to date.
Well, I think if you're running win 2003/XP and actually dare to go into the internet with the machine, you openly and proudly do not give a flying fuck about any security. The amount of open holes is insane, and some Chromium project that some dude ported is not going to save you.
Projects like this never made any sense to me.
I'd hope (expect even) this port to include it's own libraries for things like TLS, JPEG, PNG, PDF, etc. Which I'm pretty sure Chromium does anyway. But type-faces might still be an issue. TTF is Turing complete and I wouldn't be surprised if that was handed by the OS. So there might be an issue there.
What is the attack vector you are concerned about?
---
I daily drive a 2013-era version of OS X, using a similar modified version of Chromium[1] to browse the web. I'm pretty sure I've plugged the holes I need to plug in order to be reasonably safe, but if you have a specific concern I'd like to hear about it!
No, just as an example, Windows has had multiple kernel exploits that only required crafted fonts to be loaded by the victim computer. Any interaction with the world outside of the sandbox leaves room for a foot in the door, and there's necessarily a lot. Images, video, audio, the multitude of device APIs, and like the font exploits show, even the most basic page rendering.
This (probably) isn't a practical vector for a browser, but kernel exploits have been crafted out of scrollbars in the past. Any time the sandbox calls out to the OS in any capacity it's trusting that the surface it's touching isn't vulnerable, and sometimes it is. For a sandbox to solve this, it's not good enough to just prevent people from misusing the APIs that exist on paper, you have to verify that the API itself isn't bugged and exploitable.
And it's not just OS surface, either, Skia's just as penetrable as any other membrane in the sandbox.[0]
Browsers don't use the OS's scrollbars because browser scrollbars are themeable in ways that the system scrollbars are not.
I do agree with you in principle but in practice, we aren't talking about a wide attack surface if you're using an older OS + modern browser vs a modern OS + modern browser. It's certainly drifting into the realm of a targetted attack. And if you're the kind of individual that is likely to be targetted in this kind of way, then you'd have a lot more secure defaults than just "modern OS + modern browser".
So it all boils down to what your threat model is. If you're Satya Nadella then this would be stupid. But if you're just some random Joe Bloggs who plays a few retro games, then realistically this should be safe enough to load GOG.
I already said scrollbars weren't a practical example, just an example of how benign APIs can be exploited.
I heavily disagree about the threat model. It costs next to nothing to cast the net out for users neglecting their computer (and there are very many), and the payout is a hefty botnet.
Depends on what you're hardware accelerating and how you want to "accelerate" it. In the case of video decoding, ffmpeg would talk directly to the hardware. There wouldn't be an "OS" component to that (if there were, then ffmpeg wouldn't exist in the first place).
The rendering part of video playback would be owned by the browser. So whatever graphics libraries Supermium uses. There is already a conversation about GDI elsewhere in this conversation.
At least with the rendering part, the browser owns the API interaction. Which does reduce the attack surface significantly. Though that's not to say that there isn't the possibility of someone carefully crafting a zero day that exploits the latest builds of ffmpeg to purposely to attack an unpatched bug in an older rendering library. However this comes back to my earlier point that such an attack would be highly specific to this exact browser fork running on a specific version of Windows. ie you're now talking about nation state actor level of targetted attack. If that's your threat model, then you definitely shouldn't run this. But I doubt that's a concern for most people
> I already said scrollbars weren't a practical example, just an example of how benign APIs can be exploited.
I don't think anyone is confused about the fact that APIs can be exploited :)
> I heavily disagree about the threat model. It costs next to nothing to cast the net out for users neglecting their computer (and there are very many), and the payout is a hefty botnet.
Actually it costs a great deal of time and effort to craft an exploit that would target a zero day on a modern browser even if the underlying OS API vulnerability is already known. And how many people would be vulnerable? It's not worth the effort for the tens of people vulnerable. That is unless you're intentionally targetting one specific individual with this known configuration....and now we're back to my point about your threat model.
FFmpeg does not talk directly to hardware. That's the job of the OS and the drivers. They exist outside of the sandbox. So does the hardware itself.
> Actually it costs a great deal of time and effort to craft an exploit that would target a zero day on a modern browser even if the underlying OS API vulnerability is already known. And how many people would be vulnerable? It's not worth the effort for the tens of people vulnerable. That is unless you're intentionally targetting one specific individual with this known configuration....and now we're back to my point about your threat model.
You missed a step. More like two, actually. First, it costs almost nothing to include exploits for known out-of-date OSes (and browsers, but that's separate to this particular point). Second, if a modern browser is exploited, it needs a payload to deal with the OS on the outside. It, again, costs almost nothing to see if there's any low hanging fruit on the outside. And plenty of modern vulnerabilities affect older OSes, so you may just get it for actually free instead of nearly free.
Nobody who cares about their threat model is running an out-of-date OS. And yet, out-of-date OSes are vacuumed up in mass amounts for botnets. They're worth going after, even if the people running those machines don't even know what "threat model" means. They have an internet connection? That's plenty to make it worth the minimal effort.
It depends how you run (and build ffmpeg). ffmpeg supports a plethora of different hardware and software configurations. I don't know how Chromium runs ffmpeg -- likely different on each platform -- but Supermium could easily fallback to software decoding.
> You missed a step. More like two, actually. First, it costs almost nothing to include exploits for known out-of-date OSes
I haven't missed anything. We aren't talking about software that directly interfaces with the OS. We are talking about software that needs to escape the browser sandbox first.
It's all good and well saying "it costs nothing to include exploits for known out-of-date OSes" but how do you execute that payload? That's the hard part.
> Second, if a modern browser is exploited, it needs a payload to deal with the OS on the outside. It, again, costs almost nothing to see if there's any low hanging fruit on the outside. And plenty of modern vulnerabilities affect older OSes, so you may just get it for actually free instead of nearly free
> Nobody who cares about their threat model is running an out-of-date OS.
Exactly!! This browser is only going to be used on systems that aren't important. So the risk isn't as serious.
> And yet, out-of-date OSes are vacuumed up in mass amounts for botnets.
Indeed. And having an up-to-date browser will help those 0.29% of people still running XP: https://www.statista.com/statistics/993868/worldwide-windows...
> They have an internet connection? That's plenty to make it worth the minimal effort.
Assuming including any payload for XP doesn't prevent the attacker for also bundling a payload for Win10. ;)
But that would be a Chromium CVE, wouldn't it?
Zero days of course happen, but I think it's reasonable for a normal consumer to leave them out of their threat model.
Direct2D, DirectWrite, et al. are all technologies introduced with NT6, aka Windows Vista and 7.
Is Supermium passing webfonts directly to the Windows font renderer instead of going through Skia? A good test for this might be whether emojis render properly in Windows XP, which doesn't natively support colored fonts.
So you don't really need to fall back to GDI. Though I wouldn't say older versions of DirectX would be any more secure than GDI.
Edit: This may not be the case, seems like CoreText was only invoked by Harfbuzz for some specific fonts, and newer versions of Harfbuzz can handle those too.
See https://issues.chromium.org/issues/40597670, it was only ever AAT fonts that invoked coretext and that too since 2019 it's handled natively. Webfonts never allowed AAT in the first place (https://issues.chromium.org/issues/41475337).
If anyone actually has an XP machine handy, I really am curious whether colored emojis work in Supermium. If they do, I would assume Chromium (or at least Supermium) isn't using the OS font renderer.
And I'd honestly be pretty surprised if emojis didn't work. Passing web fonts off to be handled by the OS (in anything above the most trivial way) just doesn't seem to fit how Chromium does things, for the security reasons we are discussing if nothing else.
Interesting project though
Sounds like Athlon XP users are out of luck.
Developing for old technologies in general (especially hardware) can help make your code and project lighter in general.
(see: alternative frontends for YouTube and Twitter, YouTube circa. 2005-2011, even 2012-2016)
No SSL on the website means someone could easily MITM the connection and serve something else. That’s a very bad decision short of providing a different form of cryptographic authentication.
SSL isn’t just for encryption, friends.
For a site like this, I might version sniff and send modern browsers to a favicon served over HTTPS with HSTS headers; future accesses will get upgraded to HTTPS (unless the MITM drops these requests), and older browsers don't understand HSTS anyway. But I wouldn't put that favicon on generally, because it's not likely possible to get a certificate older browsers will like, and older browsers like to throw popups when they can't negotiate https on subresoures, which ruins everyone's day.
Older browsers are likely to require SHA1 certificates, and have a more limited selection of CAs. CA/Browser rules prohibit issuing new SHA-1 certificates, so you're pretty much out of luck there. Even if you can get a SHA-1 certificate that older browsers like, you have to also have a certificate that newer browsers like and get your server to distinguish between the two and serve the right certificate. Helpfully, Client Hello does not provide user-agent information, so you have to kind of guess at age of the browser / capability by what version, ciphers, and extensions they suggest. But really, all of that is moot unless you can get a trusted CA to issue a usable cert, which I'm pretty sure you can't.
They are so delusional they think some "sandbox" in the Browser that some dude ported back is fixing 20+ years of security holes in the OS, this is so funny.
I don't want to ban you because you've also posted some good things, but we've already warned you once, and you've unfortunately been continuing to break the rules quite badly—not just in this thread but in others. To mention a couple recent examples:
https://news.ycombinator.com/item?id=39467401
https://news.ycombinator.com/item?id=39458160
If this keeps up, we're going to have to ban you. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
Passwords? I couldn't care less if someone were to waylay 99% of my passwords.
For the remaining 1% HTTPS/SSL definitely serve a legitimate purpose, but as for the other 99% it's a fucking nuisance and I find websites that don't force the issue a breath of fresh air.
I don't think that everyone truly understands the nature of the larger problem, so I'll briefly explain it here...
You see, a long time ago in computer history, OS adoption -- drove corresponding software development.
That was the case with various versions of Microsoft Windows -- for many years.
These days, it's not the Operating System but the Browser -- of which (Google) Chrome (and its open-source counterpart, Chromium) -- which drives corresponding OS adoption...
Basically,
if a given OS can't run the latest version of Chrome / Chromium -- then it's basically a dead OS!
That's a huge problem because by way of this, Chrome/Chromium unintentionally forces adoption of increasingly complex newer OS'es on the general public...
That's a problem because these increasingly complex newer OS'es are orders of magnitude more lines of code (LOC) than their predecessors.
If the complaint is that older OS'es are not secure, then guess what? That complaint also applies at least doubly (and perhaps exponentially!) to newer OS's as well, which comprise exponentially more lines of code than the older OS'es!
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.
It is not in that form now.
That is because Chrome/Chromium has incorporated source code from a lot of third party software.
Does any single person, much less a single person at Google (as bright as everyone is at Google?) truly understand ALL of those lines of code?
?
Based on the source code hierarchy -- I highly doubt it.
That's because if they truly did -- then all repeated functionality in all third party libraries would be merged in the most minimum form necessary.
Don't get me wrong, I love Google, I love everyone that works for Google, I love their products -- but I have to believe after looking at the Chromium source that there isn't a single person (compare to Linus Torvalds and the BDL concept) "running the show"...
In other words, Chrome/Chromium is a "diffusion of responsibility" system, with multiple parties taking responsibility for different parts of Chrome/Chromium at different times...
Compare that concept to that of a Maintenance Programmer Vs. a Chief Architect...
A Maintenance Programmer typically changes a few lines of code at a time in a system in response to support tickets and customer requests.
A Maintenance Programmer might very well implement the change or feature requested -- but with their changes they also might introduce subtle future bugs into the system because their view is local in scope, and they lack full global awareness of all of the rules and constraints that the entirety of the system must obey.
A Chief Architect on the other hand -- will have that global knowledge -- and will harmonize any changes they make with the broader rules, constraints, goals and caveats of the entire system...
In other words, the changes they make to a system, should they make them -- will be more finessed, more nuanced, more filled with understanding -- than those made by a Maintenance Programmer in response to a support ticket, customer request, or bug fix...
Anyway, great job (so far!) with Supermium!!!
We need Chrome/Chromium on those older OS'es!
This is wrong because the reason that older operating systems are insecure is that vulnerabilities in them are no longer being patched, but in newer ones, they still are.
One might ask themselves why constant "security" patches are needed...
Did the security patchers not fix all of the security vulnerabilities in the OS they are patching with a single patch?
Self-evident truth:
If an OS ever has more than one security patch -- then the second (or Nth) security patch is a self-evident proof/truth -- that the OS vendor did not fix all OS security vulnerabilities in the first (or (N-1)th patch.
Self-evident truth!
But that's no fair you say!
You're going to say something like: "Oh no, OS vendors didn't know about the security vulnerabilities until after they were discovered later in time, that's why they needed to deploy multiple patches later in time, and that's why there's many of them!"
And that may be true...
But it is also equal-and-oppositely the self-evident proof/truth that what was assumed to be secure at one point in time -- turned out not to be so secure, in hindsight, at a future point in time!
Point is: The fact that there are security updates, multiple ones of them -- is a self-evident proof/truth that the viewpoint that a given OS is secure at one point in time (directly after the latest patch) and was not secure prior to that patch -- means that at the point in time that the prior to the latest patch was deployed, that is, directly after the N-1 patch was deployed (where N is the latest patch), it was thought that the system was "secure"... until the latest patch was then required... and then that point in time (as all of the other post-patch times in the history of the chain of patches) -- would have been shown as myopic (flawed) thinking -- about the matter...
Conclusion: By virtue of the self-evident proof / perceptual contradiction pre and post patches I have laid out above, newer OS'es are not secure.
The simpler (and the older) the OS -- the greater the chance it has of being actually secure...
I am not wrong.
Your conclusions about the security of a given OS pre and post patch at every point in the patch chain.
Post previous patch, but before the next patch comes out: "Now it's secure!"
New patch comes out, but before applying it: "Oops, I guess it wasn't secure after all -- let's apply this patch!"
Post applying the latest patch: "Now it's secure!"
Then the cycle repeats again and again, ad infinitum, ad naseaum...
Self-contradiction.
1. Security is not a binary. One system can be more secure than another even if it's not totally secure.
2. It's impossible in practice for any nontrivial system to be completely free of all vulnerabilities. When people talk about systems being secure, they generally mean free of known vulnerabilities.
If you're interested in actual conspiracy, then I think that there is a bigger story. Many of the vulnerabilities of the current systems are actually already known (and exploited), just not by the creators of the systems. These exploits are either collected by state agents, or private entities that sell them as services to state agents - as they are basically munition, and so, of highest interest for people in power.
Getting back to the original point, I don't think any software is ever secure. You take the risk the first time you fire it up. But the difference between using a recent iPhone, and an old PC with Windows 7 is that in the first case, you open yourself up to the NSO group, and in the second, that you open yourself up to hundred thousands of script kiddies and botnet recruiters out there. That is why it's recommended to use an up to date anything - or, if one likes to stay safe, not use any such thing at all.
And when talking about keeping the lights on, consider that support is not cheap. As things progress, the supported platform diversifies naturally, so you have to actively remove from it too, so that the resources are not spread too thin. This means stopping to support older platforms, especially those that themselves are EOL, and diversify the platforms by not supporting X new function, requiring a shim or other such complexity.
Another thing is the understanding. Why would anyone need to understand the entirety of X? Suppose a person understands every line of Chromium code. Do they also understand the compiler? The x64 CPU that the software runs on? I don't think anyone ever did. The closest people come to this when they write everything themselves, like how Terry did with TempleOS. But even then, understanding stops at the hardware level. At a point, you have to let go, and trust, and manage.
Consider looking into management. The issues you describe are not technological, but rather stem from product management, project management.
A Browser is a piece of software that has dependencies on the underlying Operating System.
If you have a mechanical Machine A and Machine A depends on Machine B to function -- then Machine A's working is dependent that Machine B work.
Security is of secondary concern than that Machine A actually works...
If Machine A doesn't work -- well, what's the point of security in that scenario? Putting security before Machine A working -- is like proverbially "putting the cart before the horse" (possessing a working horse is a higher priority than possessing a cart, because without the horse, the cart cannot work as intended -- it cannot move!)
A Browser is a complex machine.
An OS is a complex machine.
But you see, if the Browser increases in complexity and that increased complexity forces the dependency on an increasingly complex OS -- then what we've done is evolved a machine that may have been understandable and controllable by some people in society (mechanics) -- to something so unwieldy and complex that fewer and fewer people can work with it, much less control it (compare to the current AI debate).
>Another thing is the understanding. Why would anyone need to understand the entirety of X? Suppose a person understands every line of Chromium code. Do they also understand the compiler? The x64 CPU that the software runs on? I don't think anyone ever did.
We do, at minimum, know that there were groups of people who worked on all of those things; that is, to have been created the collective knowledge must have existed in some form somewhere.
If anyone sought such understanding, then I would suggest a quote by the esteemed (and very learned!) Software Engineer, Grady Booch, who wisely stated:
"Complex systems evolve from simpler ones"
While it may be impossible or impractical for someone to rigorously study all of the systems you have mentioned, if someone did want an understanding of all of them, yes, all of them -- what they first might do is recognize that "Complex systems evolve from simpler ones", and then seek to find the simplest working example of such systems, i.e.:
Chromimum Code -> First version of NCSA Mosaic (whose soure code later became Netscape, which later became Firefox, which later became Chrome/Chromium...)
Compiler -> Simplest of simple C compilers.
x64 CPU -> Simplest RISC CPU on an FPGA (then study VAX or other early CPU's microcode for the microcode aspect)
X11 -> Simplest earliest graphical window manager / GUI.
etc., etc.
Also, Terry A. Davis, the creator of TempleOS, deserves to be praised for his effort, not shamed because he was not a member of the "I'll let other people do it for me" managerial class...
>Consider looking into management.
Consider looking into Dilbert:
https://en.wikipedia.org/wiki/Dilbert
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.
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...
With regard to freezing the chromium in place, I'm not sure if I get the point. If I could freeze something, or get something completely out to the open, are the standards that we communicate on, not the anything that consumes it. In this, I love to see that many of the standards are now actually open to begin with. For example with video, the landscape was pretty horrible in the early 2000s, but now, the major players are actually collaborating on open standards, like the av1, and the result is that we all win.
Back to simplicity, I'd love it if we had a popular, lo-fi version of the internet, like how the Gemini protocol is. It would be a great thing if, for example, one such spec would be governed by law, and government services, banking, email and other such things would be accessible by it. If done well, this would be something that really uplifts the people, well, at least as much as access to digital services can.
If something works on old Windows, then chances are that it will also work on ReactOS, which is open source.
In other words, if new Chromium can work on old Windows and then on ReactOS, then when it completely and successfully works on ReactOS, now you've got open source for the OS and the Browser.
But, we shouldn't stop at ReactOS... Full ReactOS compatibility with no issues is just a step on the path of getting it to still older/simpler Operating Systems, like Minix 3 -- which in turn is a much simpler open source Operating System than even ReactOS.
And even that isn't enough... the code for the whole Browser, in conjunction with the code for the underlying OS -- need to be refactored down much further, I'm guessing at least a 10x LOC reduction -- with no loss in functionality -- and a probable upgrade in speed... and much better documentation...
By "Freezing" Chromium -- I mean "don't add any more features until the aforementioned refactoring has taken place".
In other words, stop adding lines of code -- and start subtracting.
>"For example with video, the landscape was pretty horrible in the early 2000s, but now, the major players are actually collaborating on open standards, like the av1, and the result is that we all win."
Agreed totally!
>"Back to simplicity, I'd love it if we had a popular, lo-fi version of the internet, like how the Gemini protocol is. It would be a great thing if, for example, one such spec would be governed by law, and government services, banking, email and other such things would be accessible by it. If done well, this would be something that really uplifts the people, well, at least as much as access to digital services can."
Nothing prevents the government, any government, local or federal, foreign or domestic -- from creating their own protocols (as many of them as they want) and legislating those protocols as they see fit.
Of course, there may be issues with cross-border, cross-jurisdiction, cross-country compatibility between a protocol created in one region by one government of a certain scale and used in another region by another government of a different scale...
Then you have to ask who is legally bound by what, when, where, and why...
Of course, governments that are free to enter into legally binding agreements with other governments -- are always free to enter legally binding agreements with other governments to legislate how/what/when/where/why their protocols are used...
In other words, they're more than free to implement their own protocols, and subsequently legislate their usage (subject to their own Constitutions and sets of laws, parlimentary procedures, law approval processes, etc.), if they should so wish...