Nope, you're pretty much stuck with whatever drivers are in the version of the Linux kernel in use under the hood (5.10 I believe). There's no way to modify it to add drivers as the OS is quite locked down. It's an "it either works or it doesn't" situation.

You can test it before you install it through the installation USB however.

Creating the live USB install media is relatively simple: it uses the same Chrome extension that is used to make recovery media for Chromebooks. Annoyingly the Chromebook Recovery Extension doesn't work in Linux but there are .bin files you can download and flash if you look for them. It boots into a menu that gives you the option of installing it to the internal drive or trying it live from the USB first. Once installed, you sign into your Google account and you've got Chrome. You can turn on Linux app support from the settings afterwards but it really is intended to be used to access web apps and it's really what it excels at.

As long as the hardware is supported, it's something that shouldn't require as much maintenance or technical skills as a full Linux distro so it should be ideal for switching people off of old Windows installs.

Logging in does require the Google account password still. You can setup a different PIN to use to unlock the screen after locking it or when waking from sleep, but the initial login after it is powered off or rebooted still requires the password.

Github supports using security keys, which provide the benefits of public key crypto and phishing resistance that client certificates have without having to deal with installation and expiration of client certificates. Many devices such as phones and laptops have the capability built-in now.

The problem they see that they're trying to solve is that, based on their research, people incorrectly associate the lock icon with trustworthiness of the site rather than the security of the connection to the site. Removing it and only warning if there's an actual problem with the connection security solves that problem.

In my opinion, people shouldn't need to give a second thought to whether the connection is secure anymore. Secure connections should be the default. Other factors such as trustworthiness, phishing, etc are a different issue that the padlock never addressed (the chip in the address bar with the name of the company for EV certs on the other hand tried to solve that but people didn't pay attention to them).

I could maybe see it being useful in a minimalistic daisy chaining setup. What seems to be more popular though is the opposite, where the monitor powers/charges your device (typically a laptop).

Do you know when they changed those last two things back because right now for me it's two clicks to view the certificate from the omnibox chip and the "Close other tabs" option is in the context menu still?

It's probably more that Google has mechanisms in place to remove malicious extensions from a Chrome user's browser once they're identified, mechanisms that Edge may not have.

Currently Google's plans are to use your existing DNS servers, just over a secure medium:

https://www.chromium.org/developers/dns-over-https

Some carriers provide the ability to subscribe to things directly through your cell phone bill. This allows the cell service provider to stay in the middle of some transactions instead of just being relegated to being a dumb pipe of voice, text, and data. I imagine they are very jealous of Apple/Google's app and content store revenue and that they setup such a system to try to take a cut of the market.

The end of life will probably be sometime in 2024-2025 if they used one of the newer hardware platforms.

https://support.google.com/chrome/a/answer/6220366?hl=en

Except that certificate pinning is being deprecated in Chrome:

• https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ
• https://bugs.chromium.org/p/chromium/issues/detail?id=779166

Certification Authority Authorization (CAA) seems to be the replacement for preventing misissuance.

I agree with you on 2 and am pretty sure 4 is true since someone previous posted an example of www.example.www.example.com being stripped to example.example.com instead of example.www.example.com. I hope how it is displayed does not affect how the URL is actually used so I hope 1, 5, and 6 are not true.

I don't believe 3 will be an issue due to the changes they've been making in how they indicate secure connections. They got rid of the "Secure" text on https sites and just display the padlock but they explicitly say "Not secure" on all http sites so if a user is paying attention at all to the chip just a few pixels to the left of the URL, they will immediately be able to tell if they are on an insecure site. Eventually the plan is to warn on all insecure sites so eventually everything that is insecure will give a gigantic full page warning about being insecure and the default can be trusted, at least in terms of being encrypted to the other end of the connection.

If you actually read the first link in the article, you would see that this "Advanced Protection Program" is actually about disabling the ability to use SMS as the second factor and instead requiring a not-easily-spoofable security key.

To do that, you would first need to make sure that the programs could be built with deterministic compilation. I don't believe that many projects have put in the time necessary to do that. That also ignores any optimizations or other features different compilers may use on the source code when compiling it.

https://en.wikipedia.org/wiki/Deterministic_compilation