-
eligrey
28 days ago
|
link
| on:
draft-irtf-cfrg-xmss-hash-based-signatures-12 - XMSS: eXtended Merkle Signature Scheme
The URL should be changed to the latest version at https://tools.ietf.org/html/rfc8391
-
blake
1 month ago
|
link
| on:
Favioli - A Chrome extension that replaces blank favicons with unique per-site emoji
Does anyone have a sense of the level of effort required to port something like this to run on Firefox?
-
-
Indeed, should be quite easy.
-
-
-
The culprit in question tried to do the same thing to a Voice Search Chrome extension in the past.
-
Wow, what a rant. I’m very sympathetic to “people should be able to control their devices”, but this rant is missing a number of key factors:
- The author’s assertion that this has to be inserted as an NSA backdoor is a link to them ranting about NSA backdoors on IRC. Yes, “just because you’re paranoid doesn’t mean noone is out to get you”. But it also doesn’t prove they necessarily are…
- The author ignores the fact ChromeOS has a security model (and actual, real, historical consumer-level threats to desktop computer users that they are trying to mitigate).
- They also seemingly ignore the fact that a 100% open device belongs to everyone who wants to own it, not just everyone with access to Google’s signing keys. The current device requires you to trust Google, their ideal seems to require you to trust everyone.
- The author ignores the fact that a quick look at the published cr50 firmware source shows that there are a number of things a Rockchip-based laptop needs from some external microcontroller of this kind, aside from TPM-like functionality (power sequencing, battery gas gauge, etc).
In other words, there are clear and obvious reasons (security and basic functionality) why a small management microcontroller like this needs to exist in a laptop (without requiring an NSA conspiracy to insert it.)
At the same time, I totally agree that it would have been great & less problematic if Google had provided a way for advanced users (who understand the associated risks and loss of security) to disable the TPM-like functionality of this chip (ie Android bootloader unlock or older ChromeOS style). Or even better to provision their own signing key. It’s a shame they didn’t do this[*], although not too surprising given the market demand.
[*] It’s worth noting that even if they had done this, the OP wouldn’t be happy because they still can’t audit the rest of the H1 chip’s firmware, build their own, etc. This is a fair enough concern, but it’s hard to see how Google can mitigate that without either finding a TPM-like chip with a fully open source SDK (…), or provisioning two microcontrollers so it’s possible to physically disable the TPM chip entirely but still have a chip to monitor the battery voltage, make the power button work, etc.
-
-
Honestly, part of me would like to see more open-sourcing of these types of security/management chips and ways for knowledgeable users to disable these things. However, it seems that for every user who is genuinely qualified to do these things and decides to do them, there are from 10 to 100 users who can be convinced to go through the unlock process to see some dancing bunnies or something. For every user who is mad that someone else can unlock their system somehow through some Corporate-controlled process, there are 100 users who will forget all of their passwords and get mad that their hardware is now a brick because nobody can help them unlock it. Possibly including the original user mad at corporate backdoors.
-
One more piece of paranoia still annoying me:
master the I2C bus, on which, among other things, are to be found the sound card’s microphone
- The cr50 driver they link doesn’t support multi-master, so any I2C bus that the H1 is on is not shared with the main CPU. If the digital microphone is controlled from the main CPU’s i2c bus, it’s on a different physical bus.
- I2C (at least the 400kHz version here) doesn’t have a high enough data rate to carry real-time audio. So even if the H1 chip was on the same I2C bus and the H1 could send a control command to turn it on, something would have to be listening in the Linux CPU to capture the audio. And if you’ve already owned the Linux CPU to the point you can enable audio capture, you can probably turn the mic on without separately owning the H1 chip…
-
-
Streaming data via I2C (especially on a shared bus with other devices) would still be a massively inefficient way to do this. I’d be surprised if there’s a digital microphone manufacturer who has chosen this over I2S.
-
-
Also, I recommend this video that explains a classic paper:
John Myles White on “Fundamental Concepts in Programming Languages” by Strachey:
https://www.youtube.com/watch?v=cO41uoi5cZs
Summary: there’s a lot of stuff we take for granted around the ideas of values and references in programming languages.
If you don’t know about the ARC caching policy, it has the notable distinction of being both relatively recent and also highly deployed. (Usually CS concepts take a long time to be deployed, and I trust deployed concepts more than undeployed ones). This explanation by Bryan Cantrill is nice and entertaining:
-
Can you cite a source on the high deployment of ARC? https://en.wikipedia.org/wiki/Adaptive_replacement_cache#Deployment seems pretty sparse.
-
-
This is entertaining and a technically solid job, but at some point you have to stop calling things like this a DoS attack. 44cm distance with over 100dbA acoustic pressure on an exposed HDD is simply not any real life scenario - you can as well smash it with your boot.
-
You can get ~130 dBA acoustic pressure at 1m with parametric ultrasonic speakers similar to Soundlazer. Your point stands, but we should be aware of the actual attack distance.
-
https://eligrey.com