EVs are heavier than similar ICE vehicles, but they also have regenerative braking, which greatly reduces wear on the brake pads. I suspect EVs produce much less particulate pollution from brake pads, but somewhat more from their tires.
w.r.t SQLite, the only horrifying revelation I’ve had is that it allows NULLs in composite primary keys, which I’ve seen lead to some nasty bugs in practice.
Exporting is purposefully made impossible in many implementations of Passkeys (aka Webauthn authenticators) other than Apple's. For example, Yubikeys are designed so private keys can never leave the authenticator [0]. Enabling the export of private keys from an authenticator greatly increases the attack surface of an authenticator.
This is a long-standing security/usability tradeoff in the Webauthn spec. Various solutions have been proposed, but as far as I know most of them are still just drafts, e.g. [1]. The best practice has been and, as far as I know, continues to be to register multiple authenticators, e.g. a primary and a backup authenticator. This practice has a variety of benefits:
1. Avoids lockout if an authenticator is lost.
2. If you use multiple authenticators from different vendors (e.g. Yubico and Google) you:
1. Avoid vendor lock-in
2. Can rapidly respond in case a security vulnerability is discovered in one of your authenticators, as has occurred for both Yubico [2] and Google [3].
One could use Apple's Passkeys as one's day-to-day "personal" authenticator, and use an authenticator from a different vendor (e.g. Yubico Yubikey or Google Titan Security Key) as their backup key. I don't see how Apple's implementation increases the risk of lock-in beyond that of any of the other major Webauthn authenticator providers.
There's a striking similarity between the author's mockups from Feb 15 and the redesigned System Settings announced in the beta of macOS Ventura and last week's WWDC [0]. I guess they got their wish!
There are numerous Firefox add-ons that provide this feature, e.g. https://addons.mozilla.org/en-US/firefox/addon/leechblock-ng.... IMHO, the main benefit of using Safari/Screen Time for this is that it automatically syncs the same limits across all of your iCloud-connected devices, which is great. I know Firefox has a Sync feature but I'm not sure if any of the add-ons leverage it to provide a similar seamless cross-device experience.
> I don't know what you mean by "Firefox doesn't enforce [CT]".
They mean Firefox, unlike Chrome and Safari, doesn't require proof of inclusion in a CT log for recently issued TLS certificates to be considered valid.
Project Zero also regularly publishes on flaws in Google's own products. Check out https://googleprojectzero.blogspot.com: they do a fair amount of reports on Chrome, ChromeOS, Android, etc.
I was recently asked by a friend who teaches 5th graders to do something similar for their school's "career month." I tried a few different things, and found the most successful was showing them how to use a web browser's built-in developer tools to inspect the source of and make live modifications to web pages.
My reasoning behind this exercise was:
- I checked in with their teacher ahead of time and confirmed that all of these kids had a least some experience using a web browser. Generally it seems like a likely "lowest common denominator" of tech experience for kids.
- Most web browsers have powerful developer tools that can be used to inspect and modify source and will display the results of many types of changes in real time. It is easy to get kids to understand the relationship between HTML/CSS code and the webpage that results from rendering it when you can make live changes to the code and see it immediately reflected in the rendered page.
- Web browsers are freely available. I gave them a handout with instructions on how to access the developer tools in web browsers that are either free (Chrome, Firefox) or readily available to them (Safari, since their school computer lab had a few Macs). I specifically wanted them to be inspired and continue experimenting after I left.
I concluded by spending 10 minutes taking student's requests for the modifications to nytimes.com. It ended up with a bizarro color scheme, comic sans on all the things, and pictures of dinosaurs and Pixar characters at the top of every article. Everyone had a blast, myself included!
I think the demonstration tickled the kid's innate predisposition towards mischief. An immediate question was "can everyone in the world see this changes? are you hacking right now?," which allowed me to naturally give a high-level explanation of the server-client architecture of the web. A few kids came up to me afterwards and asked me to specifically walk them through finding and opening the developer tools so they could continue experimenting at home, and that was the best outcome I could've hoped for!
“What this does is free your co-worker to be 100% honest. They don't know which parts of the interview were really you trying to perform well.”
Since there was no mention of it in the post, this is called “randomized response,” and is a building block for modern privacy-preserving protocols e.g. RAPPOR, which is used in Google Chrome: https://security.googleblog.com/2014/10/learning-statistics-...
Good point. I'm pretty sure this component of resistFingerprinting is derived from Project Fusion, which uplifts privacy/anonymity-related changes from Tor Browser into Firefox. In the Tor Browser threat model, the idea is that you can't avoid looking like a Tor user, so the goal is to make all Tor users indistinguishable from each other. Flipping this pref as a regular Firefox user is incompatible with its primary intent/threat model, so it fails to deliver and may even make you _more_ identifiable in some circumstances.
This is a great example of why I'm generally skeptical of these scattershot approaches to making users more secure by changing default settings in mainstream browsers. Security and privacy features always entail tradeoffs and should be designed and implemented holistically for best results.
Windows’ OS keychain API is pretty weak, accessing secrets does not require user authorization. macOS and some Linux desktops environments do it slightly better, but there’s only so much you can do to defend against an attacker with the same privileges as the user.
This a nice practical technique for extracting Chrome cookies, and is slightly less work than the alternative of writing a cookie db decyptor based on Chromium’s publicly available source code.
On platforms that have a decent OS-level keychain API (not Windows), this technique does not actually bypass password encryption and may trigger a password prompt/require the user to enter their password. This depends on whether the user previously granted permanent access to a given secret by a given application (e.g. by clicking “Always Allow” in the macOS keychain prompt). The author of the exploit probably did this at some point and forgot about it, which is why this appears to be a bypass of Chrome’s cookie db encryption.
Ultimately, encrypting the cookie DB provides limited protection anyway and if you have user privileges then you’ll eventually be able to access their data. This is not news, although it was the topic of some controversy back when Chrome resisted making changes to support this specific threat model, which is impossible to completely defend in the general case from the POV of a typical application developer on a modern desktop OS.
As pronoiac has already said, libssh != OpenSSH, which is far more widely used. According to the footer on https://www.libssh.org/, projects using LibSSH include KDE's sftp implementation, X2Go, and... GitHub: "GitHub uses libssh in production to power its git SSH infrastructure, serving millions of requests daily." If the footer text is still accurate, that's probably the most concerning potential issue with this vuln, although it's also possible GitHub has mitigated this risk in other ways. It would be nice to see GitHub publish something about this, one way or the other.