My first "contributions" were 2004, I was 10 years old and supposed to write a text about Mozart. Somehow I noticed the edit button and started vandalizing the page, as I didn't understood what Wikipedia was meant to be. Some patient wikipedian kept reverting and reporting my IP addresses during that day. It's both incredible to see how old and young Wikipedia is, if we'd say there was a "World Wide Web Heritage" project, Wikipedia and the contributors are truly the first thing that comes to mind.
I did not mean to suggest that the outage in Spain and Portugal were caused by wind power or just renewables.
It's more related to me in terms of when you look at the economical impact of energy, what sizes are in play. Just reading 4.6B Euro is a bit vague to understand to me, at least without having that put into perspective.
Another topic that has been surfacing every now and then is Electricity theft, partially for in-door cannabis plantation in occupied apartments. Which Endesa is valued 2B Euro per year.
Generally renewables do pose new challenges onto the grid, unfortunately conservatives/fascists are using that for FUD - making a technical conversation harder on that topic.
Even in the hypothetical scenario that renewable energy being more expensive than fossil energy (in production), the climate catastrophe and the impact of that on the economy is undeniable magnitudes bigger than any investment we could currently do to shift quicker stronger to renewable resources.
Spain will need to make some very hard choices, they have a relatively - by European standards - fragile grid and some weak interconnects. This situation has been flagged years ago but so far priorities have been to do other things first. The outage has definitely given people food for thought and I expect that when the final report is presented that it will come with some recommendations on how to prevent future recurrence. In particular the voltage / frequency regulation aspect of some of the local grids will become a focal point because these have the potential to destabilize much larger sections than just their own. The real puzzler to me is that there were multiple signals of pending grid instability and no action was taken when they easily could have, this is the bit that I'm most interested in learning about.
I look at energy companies about twice every year in some detail and I know that the typical grid operator is extremely careful and pro-active on this subject (at least, in NL and Germany, my work area, they are), the energy market has introduced some potential for abuse and for instability but so far that seems to be under control. Which makes me quite curious about what the root cause here was.
I've followed "expert testimonials" in the Austrian news over the past years, and even there the importance of grid safety is a common theme - there seems to be some gap, even in the networks that on the surface level appear to be tolerant.
> I know that the typical grid operator is extremely careful and pro-active on this subject
That's really good to hear, unfortunately standardization is extremely slow moving and even though a potentially "safe grid" may be much more at risk during "hybrid-war times" (or other civil unrest, as seen in Berlin this year).
Seems `session/:id/shell` was also `session/:id/bash` and originally `session/:id/command` in some commits.
Maybe I'm using GitHub code search wrongly, but it appears this was just never part of even a pull request - the practice of just having someone pushing to `dev` (default branch) which then will be tagged should perhaps also be revisited.
(Several more commits under `wip: bash` and `feat: bash commands`)
As a close follower of Boston Dynamics since my high-school years, I feel like in hindsight that was a good call, they've managed to progress everything else seemingly very well - which now gives them a head-start for an industry that surpasses any amount of money Boston Dynamics could ever get by many times. The data and capabilities around data would unlikely have brought similar scale of innovation, as other companies could now come up with.
Now instead, they're ahead of end2end integration of their section of robotics - especially with actual business customers that gave them a great head-start in figuring out how to integrate them as a product.
Reading through this makes me realize that I wonder what will come after "energy wars"? Like if around ~2040-2050 almost 100% of electricity demand is hopefully renewable, that means a completely new area of power.
Till then, fossil energy has been the strongest dominator on which establishment is holding power - once that's becoming the past - what will happen on the world table?
Of course, mining etc. is part of the answer; but I feel like there is much more flexibility around working around refined material availability, than it is with access to energy to start with. Also, contrary to Energy, almost anything that's mined will stay in recyclable economy - so the dominance/control one country can exercise is limited.
If you assume the rosiest scenario: a linear rampdown of _all_ emissions (not just from electricity generation) to zero by 2040, we still blow post our carbon budget to stay below 1.5C warming: 42 Gt/yr * (15 years / 2) = 315 Gt (compared to our "remaining balance" of 170 GtCO2 before >50% of 1.5C warming). Needless to say even this optimistic scenario has no chance of happening.
So the answer is that for your children, wars of imperialism will be replaced by wars for water, arable land, fisheries, etc. along with varying levels of violence that will meet the mass migration of refugees. How bad it will be will depend.
Unfortunately, some of the convertors for électrification depend on minerals which, if not "rare", are unevenly distributed.
That leave plenty of room for "battery wars", "motor wars", Even "solar panel" wars if we need to.
I do not believe Putin and Trump are eying Dumbass and Groenland only because of the scenery - and the general historical lesson of the 2020s is that brute force _is_ worth it.
China only is self sufficient, as far as I understand it.
Europe could use minerals from its soil, if we accepted mining. But we don't want that either, any more.
(And given what is about to happen to Groenland, it may be a blessing in disguise not to be too resource-rich. Again: pray the Emperor may ignore you.)
Funnily enough, one of the big reasons for Ukraine invasion was to block our gas extraction, it happened right after Shell did a discovery research on the Donbass, and for many years the occupation had been contained precisely to the two regions where Ukraine had some deposits - Donbass and Black Sea. It's only later mental decline caused him to expand the attack.
And vice versa, while there are some rare earths in the Donbass, they are not very convenient to extract. Trump's mining deal was more like throwing a useless toy to a kid throwing a tantrum. It's notable that no one even remembers that "deal" lately.
> If you are forced to use encryption to report security problems, please reconsider this policy as it feels counterproductive (UK government, this means you…)
Glad this submission is finally receiving upvotes.
This was just shown at the 39C3 in Hamburg, few days back.
Common (unpached) Bluetooth headsets using Airoha's SoCs can be completely taken over by any unauthenticated bystander with a Linux laptop. (CVE-2025-20700, CVE-2025-20701, CVE-2025-20702)
This includes firmware dumps, user preferences, Bluetooth Classic session keys, current playing track, ...
> Examples of affected vendors and devices are Sony (e.g., WH1000-XM5, WH1000-XM6, WF-1000XM5), Marshall (e.g. Major V, Minor IV), Beyerdynamic (e.g. AMIRON 300), or Jabra (e.g. Elite 8 Active).
Most vendors gave the security researchers either silent treatment or were slow, even after Airoha published fixes. Jabra was one of the positive outlier, Sony unfortunately negatively.
What is exciting, even though the flaws are awful, that it is unlikely for current generation of those Airoha bluetooth headsets to change away from Aiorha's Bluetooth LE "RACE" protocol. This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
I feel like this should receive state-level attention, the remote audio surveillance of any headset can be a major threat. I wonder what the policies in countries official buildings are when it comes to Bluetooth audio devices, considering that Jabra is a major brand for conference speakers, I'd assume some actual espionage threats.
One of the researchers here.
Many people seem to prefer text to videos, which I sympathize with.
So please excuse me hijacking the top comment with links to our blog post and white paper:
Did you look into whether the spoofed device can also be "upgraded" to be used as an HID device, like a mouse or keyboard? That upgrade would be several CVEs against the OS vendors.
That would make the attacks potentially silent, since the attacked could simulate keypresses to dismiss notifications, or can at least keep the target unable to respond by spamming home/back or pressing power and simulating a swipe to shutdown.
I believe this would in any case require repairing and the new functionality would be visible in the pairing UI? I would be surprised if a device once paired as a headset can suddenly start acting like a keyboard if it feels like it.
EDIT: Covered in the talk at 33min. No keyboard but the Hands-Free Profile would allow you to place calls and interact with a voice assistant if one is enabled.
Kamala Harris, citing seemingly classified intelligence, famously raised the alarm on Bluetooth earphones to Stephen Colbert:
“I know I've been teased about this, but I like these kinds of earpods that have the thing [pointing to the wire] because I served on the Senate Intelligence Committee. I have been in classified briefings, and I'm telling you, don't be on the train using your earpods thinking somebody can't listen to your conversation.”
I doubt this was ever classified information. It's written all over DoD and NSA requirements and best practices for staff and diplomats.
She was probably briefed repeatedly about this as a member of that committee.
Here's one example:
> Headphones are wired headphones (i.e. not wireless) which can be plugged into a computing device to listen to audio media (e.g. music, Defense Collaboration Services, etc.).[0]
> This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
Fun fact: There are at least two applications that reverse engineered AirPods' communication protocol for custom controls - AndroPods from 2020 [1] and LibrePods from 2024 [2].
But... mainstream Android has a bug open in their Bluetooth stack for well over a year now that prevents issuing the commands, meaning to actually use the app you need root rights [3].
Is this an unintentional vulnerability or is it one of those "we left it open because it's easier and we hoped nobody would notice" kind of things. I mean can you just send a "update to this firmware" command completely unauthenticated and it's like "yep sure"? No signing or anything?
IMO, it's plausible that Airoha and the OEMs did not know about this. The tooling may have been written in a pseudo-secure manner, i.e. requiring pairing (on the client side) before attempting all the debugging/firmware update commands. The tools may simply assume that pairing is required or only list targets from those that are paired and connected, which gives the illusion that the air protocol requires this.
All it really takes is some engineer missing an if-statement to check that the connection is bonded before processing the packets.
According to the details in their whitepaper, firmware is signed, but the management protocol allows reading arbitrary memory, so you can read out the keys and sign your own payload.
I'm not sure anyone intentionally did this, but there were several poor decisions involved. It sounds like the upstream vendor shipped sample code without auth, assuming implementers would know they needed to secure a privileged device management interface, and said implementers just copied the sample and shipped it.
> Most vendors gave the security researchers either silent treatment or were slow, even after Airoha published fixes. Jabra was one of the positive outlier, Sony unfortunately negatively.
While I don't recall Sony issuing an advisory, I believe the users of their app would have started getting update notifications since they (quietly) released firmware updates.
> This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
I think most vendors are using custom services with their own UUIDs for settings such as this.
Regardless, I believe there are open client implementations for some of the more popular devices. Gadgetbridge comes to mind in regards to Android, not sure about any Linux equivalent.
These (and others?) actually have a wired option (even provide the cable) for listening. Sadly the built-in microphone doesn't work in 'wired mode' (though ANC does).
You could get at at "cable boom microphone", e.g.:
They also demonstrated how this could be used to silently find out someone’s phone number and then hijack a TFA validation call from an app like WhatsApp to take over their account with no user interaction.
Right, but isn't it noisy ... at the headphone level? (i.e. not heard when not wearing them?).
What I'm getting at is that I think the risk varies depending on how often you leave the headset paired; for example, if the headphones are over-ear, those are more prone to not be turned off --- and remain connected; thus, a greater chance of success for establishing a BlueTooth classic connection without getting noticed and performing the WhatsApp account take-over until they listen to "I'm gonna take a shower, honey!" in the distance.
the session (or pairing key) means you can both connect to the headphone or impersonate it.
It can toggle the hands-free mode and listen to whatever is being talked, you'd notice that it has switched to the mode though - but if you're headphones are powered on and you're not listening to in they can be used for eavesdropping.
During the talk they both demonstrate listening to the microphone and also receiving a WhatsApp 2FA call.
If you have a Bluetooth analyzer (e.g. Ellisys), then the link key and a directional antenna is all you need to passively eavesdrop on a conversation at a distance.
Of course, even regular omnidirectional Bluetooth antennas are plenty to eavesdrop through a hotel room door, from the hallway outside a conference room, etc.
An attacker can also passively record all the packets in an area (Ellisys allows recording all channels at the same time), and then actively gather link keys using this attack at any time to decrypt the stored conversations.
Remote audio surveillance probably be accomplished on wired headphones with TEMPEST [0]/Van Eck phreaking [1]. Not sure about which has a better range and which would be stealthier - TEMPEST or the Bluetooth attack. The Bluetooth attack just requires a laptop. Not sure if the TEMPEST attack would require a big antenna.
Even if the TEMPEST were easier, it's significantly less powerful, as it's not going to get you the ability to write malicious firmware to the audio device nor a persistent connection to the host device when the audio device isn't connected.
I doubt that audio-spectrum RF/magnetic frequencies emanate strongly from wired headphones. They are simply not a long enough antenna at 200-3,000 Hz. Also, the loop area is quite low. The ground wire runs parallel to the L/R wires, so the only loop to receive is the magnetic coils in the headphones, which are small. Only near field would work, IMO.
Wonderful website!
reply