They’ve been around for a decade and have always focused on speed, simplicity, and security. Plus, Chromebooks have continuously improved from a basic browser-only device to something far more capable than many people realize.

We’ve been talking about Fuchsia for years now, and Google has confirmed its existence without revealing what it can do or when it’ll be here. Fuchsia would run on any device, no matter its size or display type — it would also run on gadgets that don’t have screens. Fuchsia would support instant software updates just like iOS and macOS, as well as better privacy and security protections, again, like what’s available on iPhone and Mac. And Fuchsia will still run all of the existing Android apps so that transitioning from Android (and Chrome) to Fuchsia shouldn’t be a hassle. That’s the gist of Fuchsia rumors, although it’s unclear what Google’s vision is for Fuchsia.

Google has fired the founder and co-head of its artificial intelligence ethics unit, claiming she violated the company's code of conduct.

In a statement, Google said an investigation found Margaret Mitchell had moved files outside the company.

Deliberations are at a very early stage and the company may opt not to pursue a deal, said the person, who asked not to be identified discussing private talks. IBM is exploring a range of alternatives, from a sale to a private equity firm or a merger with a blank-check company, according to The Wall Street Journal, which earlier Thursday reported the possibility of a deal.

IBM has been trying to boost its share of revenue from hybrid-cloud software and services, which lets customers store data in private servers and on multiple public clouds, including those of rivals Amazon.com Inc. and Microsoft Corp. IBM bought RedHat for $34 billion in 2018 to boost this effort.

The leader of Mexico’s Green Party has been removed from office following allegations that he received money from a Romanian ATM skimmer gang that stole hundreds of millions of dollars from tourists visiting Mexico’s top tourist destinations over the past five years. The scandal is the latest fallout stemming from a three-part investigation into the organized crime group by KrebsOnSecurity in 2015.

Implementing owner-controlled secure boot. Moreover, it should also be noted that you don't actually need to use keyfusing to implement (1). For example, the “secure boot” functionality on x86 PCs allows users to change their own trust roots at any time. The way this is implemented is by having a region of a nonvolatile storage device reserved for boot firmware and trust configuration, which can be locked against mutation after boot. The only way to make this region writeable again is by resetting the system, restoring execution to said boot firmware.3 Thus, absent physical intervention, any mutation to the boot firmware or configuration must be approved by said boot firmware.

Although most SoC vendors design their SoCs to support keyfusing as their officially supported means of “secure boot”, it is actually possible to implement this owner-controlled secure boot design on most SoCs via only a small amount of additional board components. This takes advantage of the fact that

1. SoC-class devices almost never have onboard flash, and instead boot from an external flash device;
2. external flash devices usually have a “Write Protect” pin; and
3. many classes of flash device allow the “Write Protect” pin to be configured to write-protect some, but not all, of the device's memory.

New details have emerged about an unpatched security vulnerability in Microsoft’s Internet Explorer that was recently used in a complex campaign against security researchers. A fresh analysis from 0patch offers further insight into where the bug exists and how it can be triggered in real-world attacks — notably, by just visiting a website.

In early February, cybersecurity researchers at South Korean consultancy ENKI identified a zero-day exploit that it said was used in the researcher attack. The vulnerability in question exists in Microsoft Internet Explorer, and at the time of writing remains unpatched, though Microsoft said it was looking into the bug report.

Masslogger is a spyware program, which is written in .NET and steals browser, email and instant-messaging credentials. The trojan was released in April and has since been sold on underground forums.

“Masslogger is a commodity malware that has been in development and circulation for almost a year now,” Svajcer told Threatpost. “It is sold on underground forums for relatively modest amount of money and it can be used by any malicious actor. We wanted to emphasize that these campaigns with these particular spreading techniques can likely be linked to a single actor, based on the exfiltration server domain used in all campaign for exfiltrating credentials.”

Zero-knowledge (ZK) proofs are gaining popularity, and exciting new applications for this technology are emerging, particularly in the blockchain space. So we’d like to shine a spotlight on an interesting source of implementation bugs that we’ve seen—the Fiat Shamir transformation.

A ZK proof can be either interactive, where the prover and verifier communicate via challenges in a multi-step process, or non-interactive, where a prover computes a proof once and sends it to the verifier. The non-interactive ZK proof is preferred over the multi-step interactive process, but most ZK schemes are interactive by default.

Enter the Fiat-Shamir transformation. It transforms interactive ZK proofs into non-interactive ones. Easier said than done. This can be a tricky implementation and has led to several bugs, including one discovered in a Swiss voting system.

Security updates patch vulnerabilities in your computer. They protect you from local attacks (people with physical access to your computer and people who have an account on it) but also remote ones (attackers targeting your computer through your Internet connection).

Other than directed attacks security updates also protect you from malicious software. When you ask your computer to execute external content (software you downloaded, email attachments, a link you click or even just a webpage you visit in your Web browser) you also take the risk to open a door into your computer and invite attackers in.

When a vulnerability is found developers fix it as soon as possible and distributions ship it as an update so you can apply it in a timely fashion. These vulnerabilities then become public and known by potential attackers. This means an outdated system isn’t just vulnerable, it is known to be vulnerable.

The issue of having a beginner/easy-to-use focused desktop Linux distribution but not installing new security updates by default without user intervention is that for many users they fall behind in applying often important security fixes.

The Linux Mint blog posted a notice today encouraging its users to install security updates as they are "very important" while the internal statistics indicate significant numbers of users are not doing so. "Apply updates right now!" the notice reads and also warning users to not run end-of-life (EOL) versions of the Ubuntu/Debian-based distribution.

One of the most important tasks of the distribution packager is to ensure that the software shipped to our users is free of security vulnerabilities. While finding and fixing the vulnerable code is usually considered upstream’s responsibility, the packager needs to ensure that all these fixes reach the end users ASAP. With the aid of central package management and dynamic linking, the Linux distributions have pretty much perfected the deployment of security fixes. Ideally, fixing a vulnerable dependency is as simple as patching a single shared library via the distribution’s automated update system.

Of course, this works only if the package in question is actually following good security practices. Over the years, many Linux distributions (at the very least, Debian, Fedora and Gentoo) have been fighting these bad practices with some success. However, today the times have changed. Today, for every 10 packages fixed, a completely new ecosystem emerges with the bad security practices at its central point. Go, Rust and to some extent Python are just a few examples of programming languages that have integrated the bad security practices into the very fabric of their existence, and recreated the same old problems in entirely new ways.

The root issue of bundling dependencies has been discussed many times before. The Gentoo Wiki explains why you should not bundle dependencies, and links to more material about it. I would like to take a bit wider approach, and discuss not only bundling (or vendoring) dependencies but also two closely relevant problems: static linking and pinning dependencies.

[...]

Now, for the worst of all — one that combines all the aforementioned issues, and adds even more. Bundling (often called vendoring in newspeak) means including the dependencies of your program along with it. The exact consequences of bundling vary depending on the method used.

In open source software, bundling usually means either including the sources of your dependencies along with your program or making the build system fetch them automatically, and then building them along with the program. In closed source software, it usually means linking the program to its dependencies statically or including the dependency libraries along with the program.

The baseline problem is the same as with pinned dependencies — if one of them turns out to be buggy or vulnerable, the users need to wait for a new release to update the bundled dependency. In open source software or closed source software using dynamic libraries, the packager has at least a reasonable chance of replacing the problematic dependency or unbundling it entirely (i.e. forcing the system library). In statically linked closed source software, it is often impossible to even reliably determine what libraries were actually used, not to mention their exact versions. Your distribution can no longer reliably monitor security vulnerabilities; the trust is shifted to software vendors.

However, modern software sometimes takes a step further — and vendor modified dependencies. The horror of it! Now not only the packager needs to work to replace the library but often has to actually figure out what was changed compared to the original version, and rebase the changes. In worst cases, the code becomes disconnected from upstream to the point that the program author is no longer capable of updating the vendored dependency properly.