Anyone know how this works? My guess was that Google dropped support for older versions of Windows because Chromium needed libraries that only worked on newer versions, guess that isn't the case?
But why have fallbacks for unsupported OSes, which are hard to even test (as the OSes themselves probably shouldn’t be attached to the internet due to possible security issues).
True, but that tends to require a bunch of extra code, and adds complexity since now you have two different paths to test. Which is manageable, but definitely cuts against the goal of keeping the project “light”. (Of course, it depends on the feature and the language/environment you’re using. Sometimes the fallback is trivial, or can be neatly encapsulated in a third-party polyfill you never have to look at.)
It is the case, but this project seems to be backporting Chrome to the older APIs or restoring original Chrome code which has since been removed. For example modern Chrome always uses DirectWrite for font rendering, which debuted in Windows 7, but Supermium can fall back to the legacy GDI font renderer that's available on XP.
This definitely gets a nerd award, I like doing that myself when working on win32 code (i.e. if possible and not to cumbersome, try to use functions that have been around in old windows versions). But it begs the obvious question if there's a legitimate use case for this, other than having a modern browser when spinning up your retro machine for that nostalgia once a year. And even then, unless you're visiting vogons, any modern website probably chokes your machine to death if it's a period-correct XP/7.
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
A period correct Windows 7 era machine is something like a Core 2 Quad with 4-8 gigs of RAM, I'd hope that even the worst modern web abomination runs on that.
I was using a Core2 Duo with 4GB as my main home computer until about a year ago, and while some sites made it run slowly (mostly recipe sites and others with a lot of video ads) it was certainly still usable. The trick was to keep the browser down below 10 or so tabs and close it when I needed to use some other heavy piece of software.
Interesting, maybe it actually is Firefox being slower than chromium, but incidentally a few days ago I was trying to make an old core 2 duo laptop a browser-only machine for a friend's kid, and with debian 12 and Firefox, the start page of YouTube with no video playing had both cores hover at around 70%. The page worked but was notably slow. Videos played smoothly. So I guess if you don't mind the fans spinning constantly it's usable, but eh...
But as said, that was on the landing page with no video playing. What is it even doing there that can load up the CPU like that? I was rather surprised then that playback was actually smooth at least at 480p. Otoh I doubt core2duo had any sort of hardware acceleration for video decoding, but don't quote me on that...
> I doubt core2duo had any sort of hardware acceleration for video decoding
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.
Make sure to use an ad blocker and turn off that weird Ambient mode graphical effect that just kills framerate. Videos should play fine after that on a Core 2 Duo if you have hardware accelerated decoding enabled.
Our first computer was an MS-Dos machine that our local high school were getting rid of back in 1994. I learned a lot from playing around on the machine, trying to understand the command line.
Some people like computers but don't like half-assed Control Panel replacements, a task bar/start menu filled with msn.com tabloid contents, Copilot search bars, Microsoft 365 nagware and advertising
If that's a concern for you, there are themes for GTK3 and GTK4 that replicate classic 3D widgets and remove much of the excess padding in modern apps. https://github.com/B00merang-Project/Windows-95https://github.com/grassmunk/Chicago95 (You should install both; Chicago95 is more actively developed, but B00merang gives you a GTK+4 theme that's currently missing from Chicago95.) Works reasonably well as a daily-driver, giving you a similar look to the modern SerenityOS GUI on a standard Linux system. Even the modern GTK+4 "responsive" apps work as designed, though with some non-critical graphical quirks.
Windows XP is the last version of Windows that's generally thought to be free of backdoors and US spyware. This is possibly why Putin seems to still use it (a photo of Putin was all over the internet a few months ago https://www.google.com/search?client=firefox-b-1-lm&q=putin+...).
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.
> Windows XP is the last version of Windows that's generally thought to be free of backdoors and US spyware. This is possibly why Putin seems to still use it
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.
Intel IME, AMD PSP, have both long been thought of as hardware backdoors.
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.
The Intel Management Engine was introduced 2008 (2013 for AMD). XP was introduced in 2001 and was succeeded by Vista in 2007. The dates for the ME and Vista introduction seem close enough that if there was some sort of secret plan, that concurrent development would have been happening.
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.)
> That said, I have read many times that Putin does not use any computer or the Internet.
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.
Legend has it that he was giving money to his intelligence service to bribe the Ukrainian army generals to surrender at first sight of the invasion. They noticed "You're giving me money that you don't need a receipt in return, in preparation for something that's never going to happen? Let me call you back, I need to call the Bentley dealership.". And when asked they just reported "Yeah, the Ukrainian army will surrender, no problem!"...
That would be where private companies, and presumably foreign governments, providing patches come in. I've never worked with any of these companies, so I don't know the details. They say a lot of Win7/8 patches work on XP, possibly with some patching of the patches.
>Windows XP is the last version of Windows that's generally thought to be free of backdoors and US spyware. This is possibly why Putin seems to still use it
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.
>But it begs the obvious question if there's a legitimate use case for this, other than having a modern browser when spinning up your retro machine for that nostalgia once a year.
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.
If old OS's have been air gapped since they've gone EOL, then shouldn't the last browser version they already had be able to support everything they can access?
Maybe offline web development on old, perhaps proprietary, hardware platforms? Security and the risks of running untrusted code wouldn't matter so much.
I guess as long as daily driving (regarding online activities) isn't much more than browsing reddit and Facebook that might work, but wouldn't using Online-Banking/PayPal/Amazon on a system that hasn't been patched in years make you nervous? I mean the browser is a good sandbox but still...
The opposite I would say. Facebook and Reddit are the worst hogs you can find. Advanced productivity software and most websites have no problems running on old machines.
Ah that was worded poorly I guess; I was saying that in regards to security, but that sentence got awful long now that I re-read it. As in, you're probably not doing anything too critical on there.
The recent Reddit frontend update is insanely bad for both UX and performance. I had no idea further enshitification was even possible but holy crap they knocked it out of the park this time.
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?
Reddit, Facebook, Paypal, Amazon are all the only sites this computer connects to.
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.
The ROI on targeting older machines in Western countries is so asymmetrical, that I only fear targeted attacks - given my personal risk assessment, I'd rather allow a targeted attack and be alerted when my honeypot accounts get compromised, then join the ranks of Win11 botnets and a juxtapositionally genuine false sense of security.
I think you're miscalculating here. Most of the 'hacks' taking place are scripts scanning the entire internet looking for non-patched machines running knows vulnerabilities.
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.
I have a use case. I keep a Windows 7 laptop solely for dealing with old microcontroller boards (flashing, reconfiguring, sometimes coding whole chunks). A browser like this is going to come in really handy.
Why? I have a Windows XP laptop online only for that exact same use case and I don't do any banking on it, nor am I signed in any accounts whatsoever, so what's the risk?
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.
I wouldn't compare it to actual diseases. As an European, the anti-vaxxer movement provokes profound disillusionment in me, and that last sentence... Apologies, I had to say this.
(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)
You likely don’t do a lot of hardware development. VMs cannot talk TTL and even low-level USB properly without a significant amount of hassle. Typically unplugging peripherals (or rebooting an MCU) will disconnect the device from the host, and then you usually have to reconnect them to the VM and lose logging output.
Windows XP64 (amd64) supports multiple cores and up to 128GB physical memory (maybe 8 years till that is standard on laptops?) Is the problem the website or the browser? Do modern web sites need all that spyware crap added e.g modern media sites, YouTube? Or is it the frame works that slow it down.
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.
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.
If the browser is properly sandboxed, and you're only accessing the internet through the browser, you should reasonably safe, no? Obviously it's better to have defense in depth, but I don't see the immediate danger.
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.
My understanding is that Chromium renders fonts and other graphics primitives via Skia. Video and audio uses ffmpeg. And all of these libraries are statically linked.
Supermium in specific will let you render text with GDI (for performance, probably?), videos are played with FFMPEG but that still means hauling untrusted footage outside of the sandbox for hardware decoding, and there's still countless other potentially-pierceable membranes in the sandbox.
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]
If ffmpeg is statically linked then code isn't leaving the sandbox.
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.
It does leave the sandbox. How else are you going to get hardware acceleration? That means talking to the hardware, which means talking to the OS, which is outside of the sandbox.
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.
> It does leave the sandbox. How else are you going to get hardware acceleration?
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.
> 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).
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.
> 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.
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.
Sorry, I think is misunderstood. I've edited GP to remove the note about GDI.
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.
Does GDI/non-GDI distinction really matter if the only job for GDI is to blit already rendered framebuffer after Skia library (up-to-date part of browser) to the hardware? I.e. when GDI is actually not exposed to the fonts and vector graphics downloaded from the web, just pixels? To me it seems highly unlikely that GDI can be exploited via colors of pixels.
Doesn't chrome use harfbuzz for the glyph shaping, which ends up calling into coretext? It may use skia for the drawing, but (at least in the past) text rendering (in the sense of font parsing and gyph shaping) is then ultimately still done by coretext. So it seems like it would still be vulnerable to CoreText exploits, of which there was a notable recent 0-day. This is why I think it is prudent to disable remote fonts (PDFs are still an issue, but you can at choose to not auto-render them).
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.
Hi! Note that this thread is about Windows, which definitely doesn't use Coretext. ;)
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.
Most people these days sit behind a firewall on their router. This wasn't nearly as common in 2003. So the only way the OS is exposed is via the browser.
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.
>But assuming the Browser is secure, the browser communicates to the internet "hey here is an IP" that fact alone is a security risk as the attack may come directly to the OS not the browser. Heck, this Browser may even send a user agent that actually says it's some old windows that is no longer supported, lol.
Can you sketch how you're going to hack a windows XP SP3 that's behind a NAT firewall?
Take a moment to think about this please. I get this is a topic you're passionate about but you're making a number of false assumptions.
> NOPE, some "firewall" in a consumer router does not suddenly make a 20+ year old OS secure.
That wasn't the claim. The claim was it eliminates a chunk of risk (ie someone connecting to you from outside). So the risk is now "just" code you import and run.
> The OS accesses the internet, not the browser
Which part of the "OS" are you concerned about? Please be specific.
> It's funny how you just mention some 20-year-old technique that even grandma knows about.
I don't recall seeing you comment on any techniques. If you're so much wiser than the rest of us, then please do share these techniques that we've all missed.
> But assuming the Browser is secure, the browser communicates to the internet "hey here is an IP" that fact alone is a security risk as the attack may come directly to the OS not the browser.
How does it? A buffer overflow in the TCP/IP stack? Maybe. Have you got an CVEs to back that claim up?
Maybe DNS? But the Browser can easily bypass the hosts DNS resolver so this is a solvable problem.
Beyond that, the browser manages the rest.
> Heck, this Browser may even send a user agent that actually says it's some old windows that is no longer supported, lol.
User agent string is trivial to change. It's literally just a HTTP header and there are numerous browser plugins that support doing just this.
---
As I commented in another reply, we need to be clear about attack surface and threat model.
In the case of the former, most (nobody said "all") of the security concerns are sandboxed by the browser.
In the case of the latter, if your threat model includes targetted attacks then this browser on an older OS would clearly be the wrong choice. But for most people this would appeal to, that isn't a risk worth accounting for. ie this is safe enough for anything not important.
Let's say I was running VirtualBox† on top of a bare-metal Windows XP host. Inside of Virtualbox is a modern Linux distro with Chromium installed, which I'm using to browse the web. Would you still consider this a major security risk?
If so, fair, I'd like to hear more about why you would be concerned! But if not, how is this situation inherently different from running Chromium, which has a strong sandbox and statically links basically everything? I realize that in the virtualization case, Chromium is running on a separate kernel, but does that really make a difference in practice?
---
† I can't figure out from a quick Google search exactly when Virtualbox dropped support for Windows XP hosts, but it appears to have have happened relatively recently. It probably wouldn't be too hard to build the latest version from source with some patches for XP compatibility.
> But if not, how is this situation inherently different from running Chromium, which has a strong sandbox and statically links basically everything? I realize that in the virtualization case, Chromium is running on a separate kernel, but does that really make a difference in practice?
This is just not how static linking works. You're not suddenly running on a modern, secure OS because all your web browser dependencies are up to date. And your up-to-date, statically-linked browser is still interacting with your OS, not just the kernel but the OS and userland and everything.
Static linking is not typically a security measure because you would assume the host system's libraries are equally if not more up to date.
In the case of modern software designed for Windows XP, I absolutely consider static linking to be a very significant security measure, because every statically linked library decreases the amount of vulnerable userland code in use. For example, Chromium literally doesn't use the Windows SSL stack—it brings its own—so any and all SSL vulnerabilities on the Windows side are irrelevant.
On Linux, you could decide to statically link everything and create a binary which literally doesn't touch userland—but I don't know if it's possible to go this far on Windows. Regardless, it's true that at some point Chromium will need to tell the OS to e.g. blit pixels on the screen—as does VMWare, which was the point of that comparison—and you could attack the OS via the pixel blitting function. However, this would be considered a Chromium zero day.
A zero-day which is non-exploitable in Windows 11 might be exploitable in Windows XP—this is what you loose by forgoing defense in depth—but it would be fixed in due time regardless.
The browser is a bloated beast that incorporates and reimplements so much of the OS. But not that much. The OS still interacts with the OS far too much for static linking to make much of a difference. And even if there is a modern Chromium 0day, like the Skia exploit I mentioned, sure, that's a Chrome bug. That's still a bigger problem for older OSes that have absolutely no protection once something escapes the sandbox.
> The browser is a bloated beast that incorporates and reimplements so much of the OS. But not that much. The OS still interacts with the OS far too much for static linking to make much of a difference.
The thing is, we don't actually care about the whole OS, we care about the bits that interact with untrusted remote data, i.e. web content. I really don't think there are many opportunities for Chromium web content to interact with the host OS. Everything goes through Chromium's renderer. If web content is able to affect things on the other side of that renderer, that's a zero day!
> And even if there is a modern Chromium 0day, like the Skia exploit I mentioned, sure, that's a Chrome bug. That's still a bigger problem for older OSes that have absolutely no protection once something escapes the sandbox.
We agree on this point! A zero day is vastly more dangerous to a Windows XP user than a Windows 10 user. This is the benefit of defense in depth, which you loose by blatantly removing a major layer of defense.
However, for regular consumers, I still believe the risk of being hit with a zero day is vanishingly small. A person who daily drives Windows XP but browses the web in Supermium, installs new versions of Supermium within 24 hours of release, keeps his or her passwords in Bitwarden behind a strong master password, and uses a good home router with updated firmware is less vulnerable to cyber threats than the vast majority of the population!
Zero days aren't used to create botnets, they're used to launch targeted attacks on high-stakes targets. No one uses them in automated attacks because (A) people would see the attack and patch the vulnerability and (B) it's so much easier to take over insecure wifi routers.
Please do share if you think there is a specific attack surface I am overlooking. As I've said, this is directly relevant to me as a user of OS X 10.9, which hasn't been updated by Apple since 2015. If I am currently exposed in a way that leaves me vulnerable to an automated attack (!), I need to either patch the OS myself—I have done this before—or, if I absolutely must, take more drastic measures such as moving all of my web browsing inside VMWare Fusion or migrating off of my favorite platform.
Ok recent example we had a bunch of 0 days targeting Android where attackers sidestepped basically all of Chrome’s security features because of bugs in Mail GPU drivers. A fully-patched Chrome can only assume that these were written correctly and dutifully calls into them as appropriate (from userspace, of course). If these legitimate calls end up triggering the bug then you have attack surface that is exposed to web content.
You can configure and even turn off external url handlers in Chromium.
But even if you didn’t, the attack becomes even more difficult and niche here because now you’re looking for a machine running a specific version of $email_client on a specific version of Windows. This is something that you can’t even use browser fingerprinting to detect.
Let me throw the same question to you that I had to redder23:
What part of the OS are you specifically concerned about?
"Operating system" is a pretty broad description and there isn't a whole lot of surface area between this specific sandbox and the OS-owned APIs.
Font rendering is one concern that has already been raised; and by those defending this browser too. But literally no-one who's opposed to this browser has named a single specific vulnerable API in this thread.
This is the problem we're having in this conversation. Claims are being made that this is insecure -- made in absolute terms. Yet zero attempts have been made to back up those claims. Just handwavey comments about "the OS is out-of-date".
> "Operating system" is a pretty broad description
That's the problem, and the concern.
I've given several concrete examples (both of actual exploitable surface area and more abstract kinds of exploitable surface areas) in this thread already, feel free to refer back to them.
A lot of what you're complaining about as handwavy is just common knowledge. Ask questions if you're interested, but out-of-date OSes are factually insecure in known-unfixable and unknown-unfixable ways.
With all possible respect, I don't think you have given concrete examples. You have given general examples, and hnlmorg and I have explained why we don't think there are concrete problems to be found there.
The exception is font rendering. I haven't used Supermium specifically and I don't know enough about how it works, but if Supermium is passing remote web fonts directly to the OS for rendering, that needs to stop immediately, and until it does all Supermium users should disable webfonts!
As an aside, if there is in fact something like an exploitable buffer overflow in Windows XP's TCP/IP stack, that is something enthusiasts could probably patch.
But the point you keep missing is that browser do not interface with the entirety of the OS. Just because code exists, it doesn't mean the browser calls that code. For example notepad.exe was used as a UAC bypass in early versions of Vista. But there isn't any way a website running in Supermium can elevate itself to run as Administrator, let alone use notepad.exe to bypass the UAC, without exploiting a serious zero-day in Chromium. And if attackers have a zero-day that serious in Chromium, then they're not going to burn it on infecting the 10 people who run Supermium.
> I've given several concrete examples (both of actual exploitable surface area and more abstract kinds of exploitable surface areas) in this thread already, feel free to refer back to them.
You've given one and even that was impossibly vague.
> A lot of what you're complaining about as handwavy is just common knowledge.
Nobody is disputing that you should keep your OS fully patched. But what's being said here is that the age of the system ironically actually works in its benefit: it's now a small enough market share that it isn't worth burning a Chromium zero day on.
That all said, advise of not running XP / Vista for work is wise. And not connecting them to untrusted networks is wise too. Nobody is disputing that either. What is being said is that having an XP / Vista machine at home (likely for retro gaming or other niche use case) isn't automatically catastrophic.
Things don't have to be boolean :)
> Ask questions if you're interested, but out-of-date OSes are factually insecure in known-unfixable and unknown-unfixable ways.
I have quite a lot of experience hacking Windows and even wrote my own hobby browser a while back. I'm pretty well versed on the topic. The one question I asked is examples of how you would exploit "the OS" from the browser.
Yes, it does. To be fair I wouldn’t really trust some old version of VirtualBox that runs on XP (it probably has bugs of its own) but it’s way better than sharing a kernel that is known to be full of bugs.
VirtualBox on XP would still be sharing the XP kernel.
If you're concerned about bugs and age of code then Supermium would actually be better than VirtualBox:
1. VirtualBox doesn't support XP hosts, so you'd have to use an older version.
2. Whereas Supermium is current Chromium. So you will get the latest patches.
3. Chromium also has more maintainers than VirtualBox. Google and Microsoft invest far more resources into Chromium than Oracle does into VirtualBox. And that's without factoring in all the other contributors outside of G&M. VirtualBox just isn't nearly as cool. The fact that there still isn't a stable VBox release for Apple Silicon speaks volumes for just how stark the contrast is with regards to developer resources.
What virtualisation extensions in XP? There’s extensions on the intel and AMD COUs. And Windows Server has a product called hyper-v. But there’s nothing provided by Microsoft to support XP being a virt host.
VirtualBox manages that itself.
Plus, like with Chrome, VBox still needs to write to the display, and hook into the hosts TCP/IP stack. And like with Chrome, a zero day in the hypervisor could allow sandboxed code to escape the confines of the virtual machine.
I use a XP VM on a ARM Mac as it's a handy way to run most Win16/32 exes that won't run properly in Wine. Old random utilities, random OEM software required to upgrade old devices' firmware, silly Win16 apps, the works. Anything more recent than XPis too heavy for x86 VM emulation on ARM and Win 10/11 ARM come with their own quirks that are not worth dealing with for my purposes.
It's handy to have a modern browser at hand to not have to shuffle files around between the host and the VM, so you can do Google -> website of the tool in question (plus uBlock, so the main source of infection, ad networks, is taken care of). The likelihood of either Google or whatever very focused and targeted website I happen to visit to be serving XP malware is negligible.
And if it does get infected, congrats, you infected a VM with no connection to the host or shared folders that has no personal files and is powered up maybe 30 minutes per year.
It's not zero, no, but to say there's no use case and it's the same as running around in scissors blindfolded is a huge simplification.
Not that I recommend using such an old operating system or not getting current patches, what is the likely ways a hacker would own the user is they were otherwise using a host blocker combined with unlock origin and not running any other executables except chrome on their system?
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.
You're welcome! If you use this, please consider sponsoring the developer if you can. I daily drive Chromium Legacy and I'm perpetually terrified its one very talented developer will abandon the project. As of this writing, the project only has two sponsors, one of which is me.
Working executable is not the target, a reasonably secure system is the target, and so, it doesn't make sense to support an EOL platform, as that's insecure by default.
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.
> For this reason, this website does not enforce HTTPS/SSL
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.
I've only ever been inconvenienced by HTTPS/SSL 99% of the time because 99% of my browsing doesn't involve transmitting sensitive information like my credit cards.
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.
Get ready for getting downvoted, these people want to get hacked! I made a comment about how unsecure it is to run a 20+ year old OS and I got downvoted. These people hate facts, just like on Reddit.
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:
They do have SSL on the website, but it's optional. But assuming MITM, the only defense against MITM a site owner has is getting preloaded on the HSTS list. Refusing to serve content in HTTP doesn't help, because the MITM can upgrade the request on the backend. Redirecting from HTTP to HTTPS is window dressing.
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.
I've been thinking, just for fun, which browsers still would support Windows XP. The answer was that nothing current or even half decent really did and I had to go back quite a bit in time to find anything. So this actually fills a niche! If you for some reason want this. I for one probably need to try run an XP VM with this soon! :D Looking forward to the future Windows 2000 support!
In the trade, we used to call it "GameOS". I deployed it and attempted to support the wretched thing, and I always thought it was one of the worst ever.
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.
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.
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 Pr...
Browser is central, but an OS is more than just a host for the browser. It's a separate system, and thus, a separate attack vector. Backporting the browsers are not as crucial as keeping the security updates flowing - those are what really make or break any connected piece, software and hardware alike.
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.
>Browser is central, but an OS is more than just a host for the browser. It's a separate system
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)
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...
>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.
>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 hardwar...
Thanks for elaborating, I actually understand the point now. I agree that it would be nice to have simpler hardware, and I also prefer open source. I'm not sure how the porting to old Windows helps this goal, as it's complex and also closed source. I do the spirit of the project though, the hacking, the making possible the seemingly impossible. And I consider this a right of the people, the right to tinker with the software that they have.
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.
>I'm not sure how the porting to old Windows helps this goal, as it's complex and also closed source.
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...
> 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!
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.
Vulnerability patches -- while fixing some vulnerabilities -- can be the source of future vulnerabilities...
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...
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.
While theoretically true, we live in practicality. Out of support means that when a vulnerability is discovered, it's not going to get patched, so people for example write automated means to detect and exploit them, joining the computer to a botnet. And nobody ever is going to do anything against this at the source of the problem: the vulnerability.
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.
In 2024, I prefer older operating systems that do not get updates. First, hackers have long moved away from creating exploits and second, OEMs and the OS maintainer no longer create software to log activity.
Third, it just runs quickly on newish hardware given that it installs.
This is exactly what DDOS hackers are looking for. Older unpatched vulnerability, that allows either remote execution or full take over. Please do not do that. A better alternative is to just move over to other os distribution such as Linux arch, chromium or something similar. Linux desktops are lot more capable these days.
I don't want to re-hash the discussion from down-thread [1], but I think this is important. If XP is behind a NAT firewall and the user is browsing the web via a modern build of Chromium, how exactly would a hacker take over the machine without a zero day?
A quick search led me to CVE-2010-2568, which isn’t in TCP/IP[1], but is an RCE vulnerability that could be triggered by a website triggering a file download and the user later opening the folder with the downloaded file in Windows Explorer. Windows XP with Service Pack 3 is vulnerable.
[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.)
Downloading a file is something that happens automatically when you e.g. navigate (or are automatically redirected) to a link which is served with Content-Type of application/octet-stream. Example: <https://0x0.st/H7bb.bin>. If you don’t modify your browser somehow, it’s not something you as a user can protect yourself against.
Not that I'd recommend browsing on an older, unpatched OS, but the modification in question is easy, and IMO worth the extra single click or keypress it introduces in exchange for eliminating "drive-by downloads" from questionable sites.
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).
It sounds so dumb on surface that someone would go such a great length to try protect a vulnerable operating system for browsing by building a forked browser and not use a modern os such as arch/linux.
If you need access to legacy Windows software, this may not be an option. I know Wine has gotten a lot better in recent years, but it still isn't 100%. There are other options as well such as virtual machines, but these often come with worse hardware requirements.
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.
If Windows 10 LTSC is good enough for submarines and ATMs with an EOL of 2032-01-13 it should be great for consumers but nope, we can't have it (unless pirated)
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)
A modern Linux distro with an older generation desktop environment like MATE or xfce is incredibly snappy, has modern hardware support and is maintained with security updates and up to date crypto stack.
> hackers have long moved away from creating exploits
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.
Not sure if dumb question but how do they actually build it? I don't mean the commands, I mean Chromium needs quite a few machines to build in a reasonable amount of time. Do they have their own build farm? Or does some dude just leave it to build overnight or something on his personal machine every release?
The problem with all the new stuff (OS, Apps etc) is that you are no longer own them. They are lend to you, and so, it can be easly rendered unusuable by companies by simply pushing special update. I hate auto updated with passion. It all looks cool on paper, but if we talk about security and control its big fail. Why? Because all those companies have their own agendas.
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.
Some folks prefer Debian as vm host as it’s considered stable. 2003/xp or even dos can be considered a stable host for browser. Why not? These days I don’t have to manually install many apps a browser meets most my needs.
198 comments
[ 4.8 ms ] story [ 221 ms ] threadDeveloping 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)
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
which isnt all that difficult, btw :)
good to point out that it's not enabled by default.
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
https://github.com/intel/intel-vaapi-driver/issues/544
One was an Athlon; the other was a Core Duo. They both had 1GB RAM.
but I don't think they take old socks.
https://www.washingtonpost.com/archive/lifestyle/1993/12/28/...
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].
[1] https://en.wikipedia.org/wiki/NSAKEY
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.
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...
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.
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 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.
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.
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.
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.
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.
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!
1: https://github.com/blueboxd/chromium-legacy
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]
[0] https://nvd.nist.gov/vuln/detail/CVE-2023-6345
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.
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.
Can you sketch how you're going to hack a windows XP SP3 that's behind a NAT firewall?
> NOPE, some "firewall" in a consumer router does not suddenly make a 20+ year old OS secure.
That wasn't the claim. The claim was it eliminates a chunk of risk (ie someone connecting to you from outside). So the risk is now "just" code you import and run.
> The OS accesses the internet, not the browser
Which part of the "OS" are you concerned about? Please be specific.
> It's funny how you just mention some 20-year-old technique that even grandma knows about.
I don't recall seeing you comment on any techniques. If you're so much wiser than the rest of us, then please do share these techniques that we've all missed.
> But assuming the Browser is secure, the browser communicates to the internet "hey here is an IP" that fact alone is a security risk as the attack may come directly to the OS not the browser.
How does it? A buffer overflow in the TCP/IP stack? Maybe. Have you got an CVEs to back that claim up?
Maybe DNS? But the Browser can easily bypass the hosts DNS resolver so this is a solvable problem.
Beyond that, the browser manages the rest.
> Heck, this Browser may even send a user agent that actually says it's some old windows that is no longer supported, lol.
User agent string is trivial to change. It's literally just a HTTP header and there are numerous browser plugins that support doing just this.
---
As I commented in another reply, we need to be clear about attack surface and threat model.
In the case of the former, most (nobody said "all") of the security concerns are sandboxed by the browser.
In the case of the latter, if your threat model includes targetted attacks then this browser on an older OS would clearly be the wrong choice. But for most people this would appeal to, that isn't a risk worth accounting for. ie this is safe enough for anything not important.
If so, fair, I'd like to hear more about why you would be concerned! But if not, how is this situation inherently different from running Chromium, which has a strong sandbox and statically links basically everything? I realize that in the virtualization case, Chromium is running on a separate kernel, but does that really make a difference in practice?
---
† I can't figure out from a quick Google search exactly when Virtualbox dropped support for Windows XP hosts, but it appears to have have happened relatively recently. It probably wouldn't be too hard to build the latest version from source with some patches for XP compatibility.
This is just not how static linking works. You're not suddenly running on a modern, secure OS because all your web browser dependencies are up to date. And your up-to-date, statically-linked browser is still interacting with your OS, not just the kernel but the OS and userland and everything.
Static linking is not a security measure.
In the case of modern software designed for Windows XP, I absolutely consider static linking to be a very significant security measure, because every statically linked library decreases the amount of vulnerable userland code in use. For example, Chromium literally doesn't use the Windows SSL stack—it brings its own—so any and all SSL vulnerabilities on the Windows side are irrelevant.
On Linux, you could decide to statically link everything and create a binary which literally doesn't touch userland—but I don't know if it's possible to go this far on Windows. Regardless, it's true that at some point Chromium will need to tell the OS to e.g. blit pixels on the screen—as does VMWare, which was the point of that comparison—and you could attack the OS via the pixel blitting function. However, this would be considered a Chromium zero day.
A zero-day which is non-exploitable in Windows 11 might be exploitable in Windows XP—this is what you loose by forgoing defense in depth—but it would be fixed in due time regardless.
This is where you lose me.
The browser is a bloated beast that incorporates and reimplements so much of the OS. But not that much. The OS still interacts with the OS far too much for static linking to make much of a difference. And even if there is a modern Chromium 0day, like the Skia exploit I mentioned, sure, that's a Chrome bug. That's still a bigger problem for older OSes that have absolutely no protection once something escapes the sandbox.
The thing is, we don't actually care about the whole OS, we care about the bits that interact with untrusted remote data, i.e. web content. I really don't think there are many opportunities for Chromium web content to interact with the host OS. Everything goes through Chromium's renderer. If web content is able to affect things on the other side of that renderer, that's a zero day!
> And even if there is a modern Chromium 0day, like the Skia exploit I mentioned, sure, that's a Chrome bug. That's still a bigger problem for older OSes that have absolutely no protection once something escapes the sandbox.
We agree on this point! A zero day is vastly more dangerous to a Windows XP user than a Windows 10 user. This is the benefit of defense in depth, which you loose by blatantly removing a major layer of defense.
However, for regular consumers, I still believe the risk of being hit with a zero day is vanishingly small. A person who daily drives Windows XP but browses the web in Supermium, installs new versions of Supermium within 24 hours of release, keeps his or her passwords in Bitwarden behind a strong master password, and uses a good home router with updated firmware is less vulnerable to cyber threats than the vast majority of the population!
Zero days aren't used to create botnets, they're used to launch targeted attacks on high-stakes targets. No one uses them in automated attacks because (A) people would see the attack and patch the vulnerability and (B) it's so much easier to take over insecure wifi routers.
https://xkcd.com/538/ is also relevant here.
---
Please do share if you think there is a specific attack surface I am overlooking. As I've said, this is directly relevant to me as a user of OS X 10.9, which hasn't been updated by Apple since 2015. If I am currently exposed in a way that leaves me vulnerable to an automated attack (!), I need to either patch the OS myself—I have done this before—or, if I absolutely must, take more drastic measures such as moving all of my web browsing inside VMWare Fusion or migrating off of my favorite platform.
But even if you didn’t, the attack becomes even more difficult and niche here because now you’re looking for a machine running a specific version of $email_client on a specific version of Windows. This is something that you can’t even use browser fingerprinting to detect.
What part of the OS are you specifically concerned about?
"Operating system" is a pretty broad description and there isn't a whole lot of surface area between this specific sandbox and the OS-owned APIs.
Font rendering is one concern that has already been raised; and by those defending this browser too. But literally no-one who's opposed to this browser has named a single specific vulnerable API in this thread.
This is the problem we're having in this conversation. Claims are being made that this is insecure -- made in absolute terms. Yet zero attempts have been made to back up those claims. Just handwavey comments about "the OS is out-of-date".
That's the problem, and the concern.
I've given several concrete examples (both of actual exploitable surface area and more abstract kinds of exploitable surface areas) in this thread already, feel free to refer back to them.
A lot of what you're complaining about as handwavy is just common knowledge. Ask questions if you're interested, but out-of-date OSes are factually insecure in known-unfixable and unknown-unfixable ways.
The exception is font rendering. I haven't used Supermium specifically and I don't know enough about how it works, but if Supermium is passing remote web fonts directly to the OS for rendering, that needs to stop immediately, and until it does all Supermium users should disable webfonts!
As an aside, if there is in fact something like an exploitable buffer overflow in Windows XP's TCP/IP stack, that is something enthusiasts could probably patch.
But the point you keep missing is that browser do not interface with the entirety of the OS. Just because code exists, it doesn't mean the browser calls that code. For example notepad.exe was used as a UAC bypass in early versions of Vista. But there isn't any way a website running in Supermium can elevate itself to run as Administrator, let alone use notepad.exe to bypass the UAC, without exploiting a serious zero-day in Chromium. And if attackers have a zero-day that serious in Chromium, then they're not going to burn it on infecting the 10 people who run Supermium.
> I've given several concrete examples (both of actual exploitable surface area and more abstract kinds of exploitable surface areas) in this thread already, feel free to refer back to them.
You've given one and even that was impossibly vague.
> A lot of what you're complaining about as handwavy is just common knowledge.
Nobody is disputing that you should keep your OS fully patched. But what's being said here is that the age of the system ironically actually works in its benefit: it's now a small enough market share that it isn't worth burning a Chromium zero day on.
That all said, advise of not running XP / Vista for work is wise. And not connecting them to untrusted networks is wise too. Nobody is disputing that either. What is being said is that having an XP / Vista machine at home (likely for retro gaming or other niche use case) isn't automatically catastrophic.
Things don't have to be boolean :)
> Ask questions if you're interested, but out-of-date OSes are factually insecure in known-unfixable and unknown-unfixable ways.
I have quite a lot of experience hacking Windows and even wrote my own hobby browser a while back. I'm pretty well versed on the topic. The one question I asked is examples of how you would exploit "the OS" from the browser.
So maybe it's better we agree to disagree
If you're concerned about bugs and age of code then Supermium would actually be better than VirtualBox:
1. VirtualBox doesn't support XP hosts, so you'd have to use an older version.
2. Whereas Supermium is current Chromium. So you will get the latest patches.
3. Chromium also has more maintainers than VirtualBox. Google and Microsoft invest far more resources into Chromium than Oracle does into VirtualBox. And that's without factoring in all the other contributors outside of G&M. VirtualBox just isn't nearly as cool. The fact that there still isn't a stable VBox release for Apple Silicon speaks volumes for just how stark the contrast is with regards to developer resources.
VirtualBox manages that itself.
Plus, like with Chrome, VBox still needs to write to the display, and hook into the hosts TCP/IP stack. And like with Chrome, a zero day in the hypervisor could allow sandboxed code to escape the confines of the virtual machine.
It's handy to have a modern browser at hand to not have to shuffle files around between the host and the VM, so you can do Google -> website of the tool in question (plus uBlock, so the main source of infection, ad networks, is taken care of). The likelihood of either Google or whatever very focused and targeted website I happen to visit to be serving XP malware is negligible.
And if it does get infected, congrats, you infected a VM with no connection to the host or shared folders that has no personal files and is powered up maybe 30 minutes per year.
It's not zero, no, but to say there's no use case and it's the same as running around in scissors blindfolded is a huge simplification.
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.
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
I don't think anyone still using Windows 7 cares
Its readme is worth reading.
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.
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.
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.
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.
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.
https://github.com/Feodor2/Mypal68
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 Pr...
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
https://www.google.com/search?q=dilbert&tbm=isch
https://scottadams.locals.com/
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 hardwar...
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...
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.
Third, it just runs quickly on newish hardware given that it installs.
1: https://news.ycombinator.com/item?id=39580985
[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.
So it can't be done silently. Although, I do wish the type was marked "DANGEROUS" a la dll files.
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).
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.
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.
Interesting project though
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.
Sounds like Athlon XP users are out of luck.
https://support.google.com/chrome/thread/18818459/chrome-tak...
https://issues.chromium.org/issues/40770130
Wherever possible (not too many places due to HTTPS)
Or even Netscape Communicator