HN user
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.
Go to the left sidebar, open the dropdown menu labeled with your account email at the bottom, click Feature Preview, enable LaTeX Rendering.
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.
[0] https://github.com/w3c/webauthn/issues/865#issuecomment-3804...
[1] https://github.com/Yubico/webauthn-recovery-extension
[2] https://www.yubico.com/support/issue-rating-system/security-...
[3] https://security.googleblog.com/2019/05/titan-keys-update.ht...
Paste (https://pasteapp.io/) has this feature too.
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!
[0] https://www.macrumors.com/2022/06/06/macos-ventura-system-se...
Regenerative braking
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.
Source: https://developer.mozilla.org/en-US/docs/Web/Security/Certif....
The jobs.apple.com link appears to be broken :) It doesn't link to a specific job description, just an empty search form with 100s of results.
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!
It's a video with no transcript
While Apple only started posting transcripts of WWDC presentations last year, https://asciiwwdc.com has been around for a while and is a great searchable archive of WWDC transcripts. Here's the transcript for the presentation you referenced: https://asciiwwdc.com/2014/sessions/715?q=user%20privacy%20i....
“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-...
It's fiddly, but you can get good results in a consumer grade oven if you:
1. Use a preheated pizza stone or similar (e.g. cast iron pan) to get as much radiant heat into the crust as possible.
2. Position the pizza stone close to the upper heating element and/or switch to broil for the last few minutes of cooking.
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.
Update: they recently tweeted confirming they were not at risk, https://twitter.com/GitHubSecurity/status/105231733337972326...
For the love of god, please stop calling all cryptocurrencies and cryptocurrency-related projects "crypto."
I'm aware it's only 190 bits of keyspace. I mentioned this in my blog post[0], and would in fact be more likely to decrease it than increase it, in order to make the URLs shorter. I don't think it's a problem, but am interested in being proven wrong.
I understand that you're trying to balance the tradeoff between security and usability here, which is tricky. If quantum computers are part of your threat model, remember that Grover's algorithm provides a quadratic speedup for brute-forcing a symmetric key, so 2^190 would become 2^95 against a quantum adversary. Personally I prefer the margin of safety provided by using a full-strength 256-bit key :)
It's using CBC mode.
Phew! That would've been truly catastrophic.
A quick look at the source code shows the generate_key() function [0] to be insecure. It generates 32 random bytes (good, that's what you need for an AES-256 key), but then it uses those random bytes to sample from a distribution which only has 62 characters. This significantly reduces the security of the key, from 256 bits of entropy to ~190 bits (log2(62^32)). And that would be in the best case, if it were sampling uniformly from the distribution - it is not.
I recommend reading Section 9.7 of Cryptography Engineering [1] to understand why choosing random elements from a set is harder than it seems. A good example of a similar bug is the nasty bug in Cryptocat's PRNG from 2013 [2].
I assume this step was done so the AES key could be included in the URL fragment, since a set of random bytes may not be url safe. I recommend feeding the random bytes of the key directly into the underlying cryptographic functions, and using a urlsafe encoding at a higher level when necessary.
Also, it appears you are using AES [3], a block cipher, but I cannot figure out what block cipher mode you are using. I'll have to dig into the CryptoJS code a little more to see what it defaults to, but I have a sinking feeling that it's ECB, which is completely insecure. Dan Boneh's Crypto I course on Coursera is a good way to learn the basics of block cipher modes.
[0] https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b... [1]: https://www.amazon.com/Cryptography-Engineering-Principles-P... [2]: https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse... [3]: https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b...
Cryptography Engineering [0] is a great book that covers key topics in cryptography with a focus on best practices for implementors and system/protocol designers.
Matthew Green's blog, A Few Thoughts on Cryptographic Engineering [1], has a wealth of interesting posts that are often aimed at explaining cryptography to a "technical but non-cryptographer" audience, and tend to be motivated by recent events in security/cryptography news.
[0] https://www.amazon.com/Cryptography-Engineering-Principles-P... [1]: https://blog.cryptographyengineering.com/
I think it's a mistake to interpret the wave of stories about Uber's misbehavior as indicative of a "hit job" or "media bias" against Uber. Courage is contagious, and as people have started to speak out publicly against Uber's abuses, it appears current and former employees are becoming emboldened to share their experiences as well. I hope that this wave of public backlash will demonstrate to Uber, and the tech industry as a whole, that the market is not blind to unethical behavior, and cutthroat competition at the expense of your employees and the law is not necessarily a winning strategy.
Zeroing on malloc and/or free would not have prevented this type of error, since the information disclosure was due to an overflow into an adjacent allocated buffer.
However, zeroing on free is generally a useful defense-in-depth measure because can minimize the risk of some types of information disclosure vulnerabilities. If you use grsecurity, this feature is provided by grsecurity's PAX_MEMORY_SANITIZE [0].
[0] https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...
(SecureDrop developer here). Obviously we agree, using a SecureDrop-specific subdomain makes traffic analysis trivial. Our deployment best practices [0] warn folks not to use subdomains.
Sadly, since SecureDrop is decentralized, we cannot enforce this, and some organizations apparently find it very difficult to provision a separate path ("example.com/securedrop" instead of "securedrop.example.com"). for their SecureDrop landing page.
[0] https://docs.securedrop.org/en/stable/deployment_practices.h...
(SecureDrop developer here) That's why we created https://securedrop.org/directory (HTTPS, HSTS, preloaded, .onion available, etc.). Use that instead! Also, we have strong recommendations for the news organization's "landing pages" (e.g. https://theintercept.com/securedrop/), including requiring HTTPS, to prevent this and other obvious security issues.
My favorite is "monkey-patch," which came from engineers incorrectly reproducing an earlier term, "guerilla patch", as "gorilla patch": https://web.archive.org/web/20120730014107/http://wiki.zope.....
No, but they don't have to because (the vast majority of) users don't establish trust in website's TLS certificates themselves; instead, they use a trusted third party: the set of all trusted certificate authorities in their browser or operating system's root store. End-to-end encrypted messengers like Signal and WhatsApp don't rely on a trusted third party to establish trust, instead (rightly) leaving it up to users to establish trust between each other.
If the codes are time-based (TOTP), they are typically generated with a rolling window of 30 seconds (as you saw in Google Authenticator). The 30s rolling window is the recommended (and widely implemented) default value from the TOTP RFC [0].
It is common but not universal for sites to accept, at a given time, 1) the current U2F token, 2) the U2F token from the previous window, 3) the U2F token for the next window. This is done as a partial mitigation for potential clock skew issues on the client that's generating the TOTP codes (e.g. your phone). In practice this means every code is valid for 1m30s, although sites may customize this (with or without changing the window size, which is typically not done because that parameter must be consistent system-wide).
If I wait till the last few seconds before using the code, does that make me any safer?
Maybe, but this is not practicable security advice. The latency of a MITM attack on a 2-factor TOTP login depends on the attack infrastructure and design, but can easily be made to be on the order of tens or hundreds or milliseconds. Reducing the window seems like it might help your security, but it can never be perfect and there is a direct tradeoff with usability because users need time to look up the codes on one device and enter them on another.
Folks often say "enable 2FA" in response to news of new and sophisticated phishing attack campaigns, but it's critical to note that most commonly deployed 2FA (TOTP, HOTP, SMS) is trivially phish-able. 2FA is not an automatic defense against phishing, although some newer designs achieve this and were created specifically with this goal in mind: U2F is a good example.