AmiMoJo writes: Google announced an extension of the deadline to remove support for Manifest V2 extensions in the company's Chrome browser and the open source Chromium core. The change does not impact the core decision of removing support for Manifest V2 extensions in favor of Manifest V3. Dubbed, the adblocker killer initially, due to limitations imposed on content blocking and other types of browser extensions, Google made concessions that allows content blockers to run on Chrome after the final switch is made. Extensions are still limited in comparison to Manifest V2, especially if multiple that use filtering functionality are run simultaneously, or if lots of filters are activated in a single extension. Google's initial plan was to stop supporting Manifest V2 extensions in Chrome by June 2023. For most users, support would run out in January 2023, but an Enterprise policy would enable users to extend the deadline by six months.

Martin Brinkmann writes via gHacks: From next year onward, extensions for Google Chrome and most other Chromium-based browsers, will have to rely on a new extension manifest. Manifest V3 defines the boundaries in which extensions may operate. Current Chromium extensions use Manifest V2 for the most part, even though the January 2023 deadline is looming over the heads of every extension developer. Google is using its might to push Manifest v3, and most Chromium-based browsers, including Microsoft Edge, will follow. [...]

Mozilla announced early on that it will support Manifest v3 as well, but that it would continue to support important APIs that Google limited in Manifest v3. Probably the most important of them all is the WebRequest API. Used by content blockers extensively to filter certain items, it has been replaced by a less powerful option in Manifest v3. While Manifest v3 does not mean the end for content blocking on Chrome, Edge and other Chromium-based browsers, it may limit abilities under certain circumstances. Users who install a single content blocker and no other extension that relies on the same relevant API may not notice much of a change, but those who like to add custom filter lists or use multiple extensions that rely on the API, may run into artificial limits set by Google.

Mozilla reaffirmed this week that its plan has not changed. In "These weeks in Firefox: issue 124," the organization confirms that it will support the WebRequst API of Manifest v2 alongside Manifest v3. Again, a reminder that Mozilla plans to continue support for the Manifest v2 blocking WebRequest API (this API powers, for example, uBlock Origin) while simultaneously supporting Manifest v3.

Windows' "Defender" software is supposed to detect malware. But its Microsoft team is now investigating reports that it's mistakenly flagging Electron-based or Chromium-based applications — as malware.

"It's a false positive, and your computer is OK," wites the blog Windows Central: This morning, many people worldwide experienced Microsoft Defender warning them of a recurring virus threat.... People on Reddit are "freaking out" over not just a reported threat from Microsoft Defender but one that keeps popping up and recurring despite the alleged threat being blocked.

The threat is revealed in a pop-up message noting that "Behavior:Win32/Hive.ZY" has been detected and is listed as "severe." However, after taking action to rectify the issue, it does not go away, and the user will keep receiving the same prompt. The reminder may return after 20 seconds, with the cycle repeating endlessly.

This detection appears to be a false positive, according to a Microsoft Support forum... From DaveM121, an Independent Advisor: [I]t is a bug currently being reported by hundreds of people at the moment, it seems to be related to all Chromium based web browsers and Electron based apps like Whatsapp, Discord, Spotify, etc....
Also affected are Google Chrome and even Microsoft Edge, as well as "anything that runs Visual Studio Code," according to the article.

"The problem seems to originate from Defender's Definition/Update Version 1.373.1508.0, meaning Microsoft needs to update that file, and the issue should be resolved."

An anonymous reader quotes a story from the Linux/Open Source news site It's FOSS: While Firefox is still the default web browser in Debian, you can find the Chromium browser in the repositories. Chromium is the open source project upon which Google has built its Chrome web browser. It is also preferred by many Linux users as it provides almost the same features as Google Chrome.

Earlier, Chromium used Google as the default search engine in Debian. However, Debian is going to use DuckDuckGo as the default search engine for Chromium.

It all started when bug report #956012 was filed in April 2020, stating to use DuckDuckGo as the default search engine for the Chromium package. You can see the decision was not taken in any hurry, as the maintainers took more than two years to close the bug report.

The reason for the change goes as stated in the official package update announcement.

Change default search engine to DuckDuckGo for privacy reasons. Set a different search engine under Settings -> Search Engine (closes: #956012).

joshuark writes: Microsoft has found a bug in ChromeOS and given it a high vulnerability 9.8 out of 10. The bug was promptly fixed and, about a month later, merged in ChromeOS code then released on June 15, 2022. This is a reversal in that Google usually finds security bugs in software from Microsoft and other vendors after typically 90 days -- even if a patch had not been released -- in the interest of forcing companies to respond to security flaws more quickly. [...] The ChromeOS memory corruption vulnerability -- CVE-2022-2587 -- was particularly severe. As Jonathan Bar Or, a member of the Microsoft 365 Defender research team, explains in his post, the problem follows from the use of D-Bus, an Inter-Process-Communication (IPC) mechanism used in Linux. A D-Bus service called org.chromium.cras (for ChromiumOS Audio Server) provides a way to route audio to newly added peripherals like USB speakers and Bluetooth headsets. The service includes a function called SetPlayerIdentity, which accepts a string argument called identity as its input. And the function's C code calls out to strcpy in the standard library. Yes, strcpy, which is a dangerous function.

An anonymous reader quotes a report from Motherboard: A group of security researchers found a series of vulnerabilities in the software underlying popular apps like Discord, Microsoft Teams, Spotify and many others, which are used by tens of millions of people all over the world. At the Black Hat cybersecurity conference in Las Vegas on Thursday, the researchers presented their findings, detailing how they could have hacked people who use Discord, Microsoft Teams, and the chat app Element by exploiting the software underlying all of them: Electron, which is a framework built on the open source Chromium and the cross-platform javascript environment Node JS. In all these cases, the researchers submitted vulnerabilities to Electron to get them fixed, which earned them more than $10,000 in rewards. The bugs were fixed before the researchers published their research.

Aaditya Purani, one of the researchers who found these vulnerabilities, said that "regular users should know that the Electron apps are not the same as their day-to-day browsers," meaning they are potentially more vulnerable. In the case of Discord, the bug Purani and his colleagues found only required them to send a malicious link to a video. With Microsoft Teams, the bug they found could be exploited by inviting a victim to a meeting. In both cases, if the targets clicked on these links, hackers would have been able to take control of their computers, Purani explained in the talk. For him, one of the main takeaways of their research is that Electron is risky precisely because users are very likely to click on links shared in Discord or Microsoft Teams.

Longtime Slashdot reader HnT shares a report from Ars Technica: Microsoft said on Wednesday that an Austria-based company named DSIRF used multiple Windows and Adobe Reader zero-days to hack organizations located in Europe and Central America. Members of the Microsoft Threat Intelligence Center, or MSTIC, said they have found Subzero malware infections spread through a variety of methods, including the exploitation of what at the time were Windows and Adobe Reader zero-days, meaning the attackers knew of the vulnerabilities before Microsoft and Adobe did. Targets of the attacks observed to date include law firms, banks, and strategic consultancies in countries such as Austria, the UK, and Panama, although those aren't necessarily the countries in which the DSIRF customers who paid for the attack resided.

"MSTIC has found multiple links between DSIRF and the exploits and malware used in these attacks," Microsoft researchers wrote. "These include command-and-control infrastructure used by the malware directly linking to DSIRF, a DSIRF-associated GitHub account being used in one attack, a code signing certificate issued to DSIRF being used to sign an exploit, and other open source news reports attributing Subzero to DSIRF." Referring to DSIRF using the work KNOTWEED, Microsoft researchers wrote: In May 2022, MSTIC found an Adobe Reader remote code execution (RCE) and a 0-day Windows privilege escalation exploit chain being used in an attack that led to the deployment of Subzero. The exploits were packaged into a PDF document that was sent to the victim via email. Microsoft was not able to acquire the PDF or Adobe Reader RCE portion of the exploit chain, but the victim's Adobe Reader version was released in January 2022, meaning that the exploit used was either a 1-day exploit developed between January and May, or a 0-day exploit. Based on KNOTWEED's extensive use of other 0-days, we assess with medium confidence that the Adobe Reader RCE is a 0-day exploit. The Windows exploit was analyzed by MSRC, found to be a 0-day exploit, and then patched in July 2022 as CVE-2022-22047. Interestingly, there were indications in the Windows exploit code that it was also designed to be used from Chromium-based browsers, although we've seen no evidence of browser-based attacks.

The CVE-2022-22047 vulnerability is related to an issue with activation context caching in the Client Server Run-Time Subsystem (CSRSS) on Windows. At a high level, the vulnerability could enable an attacker to provide a crafted assembly manifest, which would create a malicious activation context in the activation context cache, for an arbitrary process. This cached context is used the next time the process spawned.

CVE-2022-22047 was used in KNOTWEED related attacks for privilege escalation. The vulnerability also provided the ability to escape sandboxes (with some caveats, as discussed below) and achieve system-level code execution. The exploit chain starts with writing a malicious DLL to disk from the sandboxed Adobe Reader renderer process. The CVE-2022-22047 exploit was then used to target a system process by providing an application manifest with an undocumented attribute that specified the path of the malicious DLL. Then, when the system process next spawned, the attribute in the malicious activation context was used, the malicious DLL was loaded from the given path, and system-level code execution was achieved. Microsoft recommends a number of security considerations to help mitigate this attack, including patching CVE-2022-22047, updating Microsoft Defender Antivirus to update 1.371.503.0 or later, and enabling multifactor authentication (MFA).

The source code for an information-stealing malware coded in Rust has been released for free on hacking forums, with security analysts already reporting that the malware is actively used in attacks. BleepingComputer reports: The malware, which the author claims to have developed in just six hours, is quite stealthy, with VirusTotal returning a detection rate of around 22%. As the info-stealer is written in Rust, a cross-platform language, it allows threat actors to target multiple operating systems. However, in its current form, the new info-stealer only targets Windows operating systems.

Analysts at cybersecurity firm Cyble, who sampled the new info-stealer and named it "Luca Stealer," report that the malware comes with standard capabilities for this type of malware. When executed, the malware attempts to steal data from thirty Chromium-based web browsers, where it will steal stored credit cards, login credentials, and cookies. The stealer also targets a range of "cold" cryptocurrency and "hot" wallet browser addons, Steam accounts, Discord tokens, Ubisoft Play, and more. Where Luca Stealer stands out against other info-stealers is the focus on password manager browser addons, stealing the locally stored data for 17 applications of this kind. In addition to targeting applications, Luca also captures screenshots and saves them as a .png file, and performs a "whoami" to profile the host system and send the details to its operators.

In an upcoming update, Chromebooks equipped with mobile data will be able to serve as a Wi-Fi hotspot for other devices, just like Android and iOS devices can today. 9to5Google reports: The work-in-progress feature has made its first appearance in ChromeOS code in the form of a new flag coming to chrome://flags. The details are quite slim at the moment, with little more than the flag description available today. That said, it's easy to imagine how a mobile hotspot would work on ChromeOS, based on how the same feature works on Android phones today.

Presumably, you would be able to choose the name and password for your Chromebook's hotspot through the Settings app in ChromeOS, where you can also toggle the hotspot on and off. If it truly follows the example of Android, there would also be an easy way to turn on your hotspot through a Quick Settings toggle.

An anonymous reader quotes a report from BleepingComputer: Security researchers found that Adobe Acrobat is trying to block security software from having visibility into the PDF files it opens, creating a security risk for the users. Adobe's product is checking if components from 30 security products are loaded into its processes and likely blocks them, essentially denying them from monitoring for malicious activity. [...] In a post on Citrix forums on March 28, a user complaining about Sophos AV errors due to having an Adobe product installed said that the company "suggested to disable DLL-injection for Acrobat and Reader.

Replying to BleepingComputer, Adobe confirmed that users have reported experiencing issue due to DLL components from some security products being incompatible with Adobe Acrobat's usage of the CEF library: "We are aware of reports that some DLLs from security tools are incompatible with Adobe Acrobat's usage of CEF, a Chromium based engine with a restricted sandbox design, and may cause stability issues." The company added that it is currently working with these vendors to address the problem and "to ensure proper functionality with Acrobat's CEF sandbox design going forward." Minerva Labs researchers argue that Adobe chose a solution that solves compatibility problems but introduces a real attack risk by preventing security software from protecting the system.

Browser maker Vivaldi's email client has finally hit version 1.0, seven years after it was first announced. From a report: Vivaldi Mail, which includes a calendar and feed reader as well as an email client, first arrived in technical preview in 2020. A slightly wobbly beta arrived last year alongside version 4 of the Chromium-based browser. After another year of polish and tidying of loose ends, the company has declared the client ready.

As before, the client is built into the browser, meaning it is unlikely to appeal to many beyond Vivaldi's existing user base. Enabling it is a simple matter of dropping into Settings pages and wading through until the option to enable Mail, Calendar, and Feeds can be selected. Vivaldi has a lot of settings -- delightfully customizable for some and downright baffling for others. That said, for users still pining for a good old-fashioned email client that doesn't require wading through a web page festooned with adverts, there's a lot to like. It supports multiple accounts, will sort messages and create folders automatically (locally, rather than on a mystery server in the cloud), and permits searching (with indexing performed offline). IMAP and POP3 are supported, making adding a provider relatively straightforward, and the company also claims that users can log into their Google accounts from Mail and Calendar.

"C++ allows for writing high-performance applications but this comes at a price, security..." So says Google's Chrome security team in a recent blog post, adding that in general, "While there is appetite for different languages than C++ with stronger memory safety guarantees, large codebases such as Chromium will use C++ for the foreseeable future."

So the post discusses "our journey of using heap scanning technologies to improve memory safety of C++." The basic idea is to put explicitly freed memory into quarantine and only make it available when a certain safety condition is reached. Microsoft has shipped versions of this mitigation in its browsers: MemoryProtector in Internet Explorer in 2014 and its successor MemGC in (pre-Chromium) Edge in 2015. In the Linux kernel a probabilistic approach was used where memory was eventually just recycled. And this approach has seen attention in academia in recent years with the MarkUs paper. The rest of this article summarizes our journey of experimenting with quarantines and heap scanning in Chrome.
In essence the C++ memory allocator (used by new and delete) is "intercepted." There are various hardening options which come with a performance cost:


- Overwrite the quarantined memory with special values (e.g. zero);

- Stop all application threads when the scan is running or scan the heap concurrently;

- Intercept memory writes (e.g. by page protection) to catch pointer updates;

- Scan memory word by word for possible pointers (conservative handling) or provide descriptors for objects (precise handling);

- Segregation of application memory in safe and unsafe partitions to opt-out certain objects which are either performance sensitive or can be statically proven as being safe to skip;

- Scan the execution stack in addition to just scanning heap memory...


Running our basic version on Speedometer2 regresses the total score by 8%. Bummer...

To reduce the regression we implemented various optimizations that improve the raw scanning speed. Naturally, the fastest way to scan memory is to not scan it at all and so we partitioned the heap into two classes: memory that can contain pointers and memory that we can statically prove to not contain pointers, e.g. strings. We avoid scanning memory that cannot contain any pointers. Note that such memory is still part of the quarantine, it is just not scanned....

[That and other] optimizations helped to reduce the Speedometer2 regression from 8% down to 2%.
Thanks to Slashdot reader Hari Pota for sharing the link

Microsoft has updated the Windows Subsystem for Android (WSA) to Android 12.1 and shipped improvements to Android integration with Windows, networking, the camera in apps, the Settings app, and more. ZDNet reports: Current limitations aside, Microsoft is continuing to invest in bringing Android to Windows 11, as seen in its update to the WSA on Windows 11 (version 2204.40000.15) to Android 12.1, which is available to Insiders on the Dev Channel, according to a Microsoft blogpost. WSA launched with Android 11. Microsoft has improved networking on the Windows Subsystem for Android, so that Android apps can connect to devices on the same network as a Windows PC. Advanced networking allows users to set up smart home devices such as speakers and security cameras with a compatible Android app. This feature is available in Windows 11 preview builds 22621 and higher, with advanced networking on by default for new x64 Windows builds.

Android-Windows integration has also been improved. Windows taskbar icons now show which Android apps are currently using hardware features like the mic and location in the system tray. The taskbar now also correctly appears or disappears when apps are running or stopped. Android notifications also show as Windows notifications and the Windows title of an Android app now reflects the Android activity title. Android apps won't restart afresh after exiting connected standby mode, but instead will recommence where the app was paused.

Of the "many camera updates" in this release, Microsoft highlights that camera orientation is fixed to natural orientation, and that it's fixed incorrect camera previews, letterboxing (where the app window is wider than it is high, or horizontally longer), and a "squishing of the camera feed." Mouse and keyboard inputs in Windows Subsystem for Android have been improved. Microsoft also improved scroll-wheel support, fixed the onscreen keyboard focus, and ensured the Android soft keyboard displays correctly. The updated Windows Subsystem for Android Settings app gained redesigned UX and diagnostics data viewer. As of this update, telemetry collection is off by default. However, Microsoft is encouraging users to enable the setting, so it can collect data about Android app usage. "Other important updates include reduced flicker when apps are restored from a minimized state, the addition of VP8 and VP9 video hardware decoding, and the addition of Chromium WebView 100 to the Windows Subsystem for Android," adds ZDNet.

vm shares the blogpost of Mozilla releasing Firefox 100, and outlines some of thoughts: Out of the ashes of Netscape/AOL, Firebird rose as a promising new browser. A significant name change and a hundred releases later, Firefox 100 is still the underdog that keeps on fighting. With my mounting annoyance at all the Google services underpinning Chrome, I've since discovered and used Ungoogled Chromium, Waterfox, LibreWolf, and a handful of other lesser known spins on Chrome or Firefox. On mobile, Brave really does the best job at ad blocking whether you're on iOS or Android but the Mozilla Foundations is probably still the largest dev group fighting the good fight when it comes to both privacy and security enhancements.That's not to say that the Chromium team isn't security savvy -- I only wish they were just a little less Google. Anyhow, tell us about your favorite browser in the comments and have a look at Mozilla's latest release while you're at it.

Fedora project leader Matthew Miller spoke to TechRepublic's Jack Wallen this week, sharing some thoughts on the future of Linux — and on open source in general: Matthew Miller: I think it's a lost cause to try to "sell" our quirky technology interest to people who don't see it already. We need to take a different approach.... I think our message, at its root, has to be around open source.... [W]ith Linux, when you install an open-source distro, you're not just part of a fan community. You're part of a colossal, global effort that makes software more available to everyone, makes that software better and better, and makes the whole world better through sharing... Just by using it you're sharing in this amazing undertaking, part of a move away from scarcity to an economy based on abundance....

Jack Wallen: What's the biggest difference in Linux today vs. Linux of 10 years ago?

Matthew Miller: I think first we have to start with just the amazing ubiquity of it. Ten years ago, it was cute to find a TV that ran Linux. Now, not only is it definitely powering your TV, you've probably got Linux running on your lightbulbs! It's everywhere. And while Linux had pushed proprietary Unix from the server room, ten years ago Windows-based servers were pushing back. The cloud changed that — now, the cloud is Linux, almost completely. (Anything that isn't is a legacy app that it was too much trouble to port!) From tiny devices to the most powerful mainframes and supercomputers: Linux, Linux, Linux....

Jack Wallen: If Linux has an Achilles' heel, what is it?

Matthew Miller: Linux and the whole free and open-source software movement grew up with the rise of the internet as an open communication platform. We absolutely need that to continue in order to realize our vision, and I don't think we can take it for granted.

That's more general than an Achilles' heel, though, so right now let me highlight one thing that I think is troubling: Chrome becoming the dominant browser to the point where it's often the only way to make sites work. Chromium (the associated upstream project) is open source, but isn't really run as a community project, and, pointedly, very very few people run Chromium itself. I'd love to see that change, but I'd also like to see Firefox regain a meaningful presence.
Miller also said Fedora's next release is focused on simplicity. ("When the OS gets in the way, it drops from the conversation I want to have about big ideas to ... well, the boring technical details that people never want to deal with")

And he also shared his thoughts on what Linux needs most. "What I'd really like to see more of are more non-technical contributors. I mean, yes, we can always benefit from more packagers and coders and engineers, but I think what we really need desperately are writers, designers, artists, videographers, communicators, organizers and planners. I don't think big companies are likely to provide those things, at least, not for the parts of the Linux world which aren't their products."

"We need people who think the whole grand project I've been talking about is important, and who have the skills and interests to help make it real."

Google is issuing fixes for two vulnerabilities in its Chrome web browser, including one flaw that is already being exploited in the wild. From a report: The emergency updates the company issued this week impact the almost 3 billion users of its Chrome browser as well as those using other Chromium-based browsers, such as Microsoft Edge, Brave and Vivaldi. It is the third such emergency update Google has had to issue for Chrome this year. One of the flaws is a type confusion vulnerability tracked as CVE-2022-1364, a high-severity, zero-day bug that is actively being used by attackers. With a type confusion flaw, a program will allocate a resource like a pointer or object using one type but later will access the resource using another, incompatible type. In some languages, like C and C++, the vulnerability can result in out-of-bounds memory access. This incompatibility can cause a browser to crash or trigger logical errors. However, if exploited, it could enable a hacker to execute arbitrary code.

slack_justyb writes: After the failure of the Chrome user-tracking system that was called FLoC, Google's latest try at topic tracking to replace the 3rd party cookie (that Chrome is the only browser to still support) is FLEDGE and the most recent drop of Canary has this on full display for users and privacy advocates to dive deeper into. This recent release shows Google's hand that it views user tracking as a mandatory part of internet usage, especially given this system's eye-rolling name of "Privacy Sandbox" and the tightness in the coupling of this new API to the browser directly.

The new API will allow the browser itself to build what it believes to be things that you are interested in, based on broad topics that Google creates. New topics and methods for how you are placed into those topics will be added to the browser's database and indexing software via updates from Google. The main point to take away here though is that the topic database is built using your CPU's time. At this time, opting out of the browser building this interest database is possible thus saving you a few cycles from being used for that purpose. In the future there may not be a way to stop the browser from using cycles to build the database; the only means may be to just constantly remove all interest from your personal database. At this time there doesn't seem to be any way to completely turn off the underlying API. A website that expects this API will always succeed in "some sort of response" so long as you are using Chrome. The response may be that you are interested in nothing, but a response none-the-less. Of course, sending a response of "interested in nothing" would more than likely require someone constantly, and timely, clearing out the interest database, especially if at some later time the option to turn off the building of the database is removed.

With 82% of Google's empire based on ad revenue, this latest development in Chrome shows that Google is not keen on any moves to threaten their main money maker. Google continues to argue that it is mandatory that it builds a user tracking and advertising system into Chrome, and the company says it won't block third-party cookies until it accomplishes that -- no matter what the final solution may ultimately be. The upshot, if it can be called that, of the FLEDGE API over FLoC, is that abuse of FLEDGE looks to yield less valuable results. And attempting to use the API alone to pick out an individual user via fingerprinting or other methods employed elsewhere seems to be rather difficult to do. But only time will tell if that remains true or just Google idealizing this new API. As for the current timeline, here's what the company had to say in the latest Chromium Blog post: "Starting today, developers can begin testing globally the Topics, FLEDGE, and Attribution Reporting APIs in the Canary version of Chrome. We'll progress to a limited number of Chrome Beta users as soon as possible. Once things are working smoothly in Beta, we'll make API testing available in the stable version of Chrome to expand testing to more Chrome users."

As Google announced today, version 99 of Chrome on macOS manages to score 300 points on the Speedometer benchmark, which was originally developed by Apple's WebKit team. This, Google points out, is the fastest performance of any browser yet. TechCrunch: Speedometer 2.0 tests for responsiveness, which makes it a good proxy for user experience. It's been a while since competition in the browser market focused on speed, especially now that most vendors bet on the same Chromium codebase to build their browsers (with the exception of Mozilla's Firefox and Apple's WebKit-based Safari). But that doesn't mean that the various development teams stopped thinking about how to speed up the user experience. As with a lot of mature technologies, we're just not seeing major breakthroughs these days. That doesn't mean the rivalry between the different vendors has stopped, even as they are now getting together as part of Interop 2022 to better align their browsers with web standards.

HP, Lenovo, Acer, and Asus are expected to be among the first companies to release gaming Chromebooks. From a report: A code change in the Chromium Gerrit suggests the vendors are working on Chrome OS devices that will support Steam. In January 2020, Google said it would bring Steam to Chromebooks, and the plan may be starting to take shape. 9to5Google spotted a code change on Saturday showing a list of what appears to be Chromebook models that will support Steam:

Acer Chromebook 514 (CB514-1H)
Acer Chromebook 515
Acer Chromebook Spin 713 (CP713-3W)
Asus Chromebook Flip CX5 (CX5500)
Asus Chromebook CX9 (CX9400)
HP Pro c640 G2 Chromebook
Unknown Chromebook from Lenovo.

"The OS/2 community is getting close to obtaining a modern browser on their platform," writes Slashdot reader martiniturbide. In an announcement article on Monday, president of the OS/2 Voice community, Roderick Klein, revealed that a public beta of the new Chromium-based Otter Browser will arrive "in the last week of February or the first week of March." XDA Developers reports: OS/2 was the operating system developed jointly by IBM and Microsoft in the late 1980s and early 1990s, with the intended goal of replacing all DOS and Windows-based systems. However, Microsoft decided to focus on Windows after the immense popularity of Windows 3.0 and 3.1, leaving IBM to continue development on its own. IBM eventually stopped working on OS/2 in 2001, but two other companies licensed the operating system to continue where IBM left off -- first eComStation, and more recently, ArcaOS.

BitWise Works GmbH and the Dutch OS/2 Voice foundation started work on Otter Browser in 2017, as it was becoming increasingly difficult to keep an updated version of Firefox available on OS/2 and ArcaOS. Firefox 49 ESR from 2016 is the latest version available, because that's around the time Mozilla started rewriting significant parts of Firefox with Rust code, and there's no Rust compiler for OS/2. Since then, the main focus has been porting Qt 5.0 to OS/2, which includes the QtWebEngine (based on Chromium). This effort also has the side effect of making more cross-platform ports possible in the future.