Also, hiding the fact it’s a tweet behind your redirection (for tracking purpose?) makes it really shallow.
It’s so I can update the redirect in the future in case I need to edit the tweet or choose to create a longer article. I don’t see how I’m “hiding” anything. It’s a public unauthenticated link…
Correct. I’m simplifying the terminology for the end-result, which is that users now must now pay for a feature they previously already had if they wish to keep it.
because every fork will keep the features
There are not any popular forks of Octotree. Most users are on the official distribution, hence the need to publicize this issue.
I hope the value you personally derive from the fork is more than the effort you put in. It seems like a lot of work to take away someone else’s living.
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.
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.
You realize it’s OK to agree with someone on one topic and disagree with them on another? A single opinion cannot invalidate everything a person has to contribute. I see a lot of people doing that these days. It’s dangerous and unhealthy.
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:
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.
Sounds like someone is disappointed because they won’t get the stuff for free anymore.
Also, hiding the fact it’s a tweet behind your redirection (for tracking purpose?) makes it really shallow.
$ curl -sI https://research.eligrey.com/status/1117537047084879872 | grep loc
location: https://twitter.com/sephr/status/1117537047084879872
“But why don’t you opensource your stuff” they asked
It’s so I can update the redirect in the future in case I need to edit the tweet or choose to create a longer article. I don’t see how I’m “hiding” anything. It’s a public unauthenticated link…
The link currently points to an invalid (deleted?) tweet.
If I read this correctly the real story isn’t the “charging” it’s the “proprieterizing”.
Luckily as you also point out, they can’t anyway because every fork will keep the features in freedom respecting versions.
Correct. I’m simplifying the terminology for the end-result, which is that users now must now pay for a feature they previously already had if they wish to keep it.
There are not any popular forks of Octotree. Most users are on the official distribution, hence the need to publicize this issue.
I hope the value you personally derive from the fork is more than the effort you put in. It seems like a lot of work to take away someone else’s living.
https://eligrey.com
The URL should be changed to the latest version at https://tools.ietf.org/html/rfc8391
Does anyone have a sense of the level of effort required to port something like this to run on Firefox?
Porting this would make for a great starter project if you’re just getting into Firefox extension development!
Depending on your level of experience it would take a competent developer anywhere from 1 to 4 days to complete the port.
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:
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.
The main issue brought up is that this device allows firmware updates without user authorization or clearing user data.
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:
I2C can transmit realtime audio quite easily using Opus.
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.
You realize it’s OK to agree with someone on one topic and disagree with them on another? A single opinion cannot invalidate everything a person has to contribute. I see a lot of people doing that these days. It’s dangerous and unhealthy.
Sean Blanchfield and Johnny Ryan are the same person? Could you elaborate on that?
It’s a conspiracy I tell you.
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:
https://www.youtube.com/watch?v=F8sZRBdmqc0
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.