[Serge Vaudenay] and [Martin Vuagnoux] released a video yesterday documenting a privacy-breaking flaw in the Apple/Google COVID-tracing framework, and they’re calling the attack “Little Thumb” after a French children’s story in which a child drops pebbles to be able to retrace his steps. But unlike Hänsel and Gretl with the breadcrumbs, the goal of a privacy preserving framework is to prevent periodic waypoints from allowing you to follow anyone’s phone around. (Video embedded below.)
The Apple/Google framework is, in theory, quite sound. For instance, the system broadcasts hashed, rolling IDs that prevent tracing an individual phone for more than fifteen minutes. And since Bluetooth LE has a unique numeric address for each phone, like a MAC address in other networks, they even thought of changing the Bluetooth address in lock-step to foil would-be trackers. And there’s no difference between theory and practice, in theory.
In practice, [Serge] and [Martin] found that a slight difference in timing between changing the Bluetooth BD_ADDR and changing the COVID-tracing framework’s rolling proximity IDs can create what they are calling “pebbles”: an overlap where the rolling ID has updated but the Bluetooth ID hasn’t yet. Logging these allows one to associate rolling IDs over time. A large network of Bluetooth listeners could then trace people’s movements and possibly attach identities to chains of rolling IDs, breaking one of the framework’s privacy guarantees.
This timing issue only affects some phones, about half of the set that they tested. And of course, it’s only creating a problem for privacy within Bluetooth LE range. But for a system that’s otherwise so well thought out in principle, it’s a flaw that needs fixing.
Why didn’t the researchers submit a patch? They can’t. The Apple/Google code is mostly closed-source, in contrast to the open-source nature of most of the apps that are running on it. This remains troubling, precisely because the difference between the solid theory and the real practice lies exactly in those lines of uninspectable code, and leaves all apps that build upon them vulnerable without any recourse other than “trust us”. We encourage Apple and Google to make the entirety of their COVID framework code open. Bugs would then get found and fixed, faster.
After recent talks, Microsoft has now officially confirmed that it will be merging GitHub to master. The acquisition will cost $7.5 billion, and has received mixed reactions so far. A staple of the open source community, GitHub is well known to Hackaday readers, and has played a key role in developing an incredible amount of the software we use on a daily basis.
Microsoft has embarked on a community crusade of late, seemingly trying to win some respect from developers and makers. Under the encouragement of Satya Nadella, we’ve had Visual Studio Code, Typescript, the Ubuntu-on-Windows saga, and many more. It’s hard to tell whether these endeavours have succeeded in winning the hearts of the community or not, but those who distrust Microsoft may be looking to make a move away from GitHub. In fact, since murmurs started about the possibility of the acquisition, GitLab, one of GitHub’s major competitors, has reported 10x the number of normal repositories moving to GitLab.
How does GitHub make money? Mainly through paid private repositories plans, and GitHub Enterprise for businesses. This provides GitHub with enough cash to allow free public repositories for the community. It will be interesting to see what changes in business and culture are made (if any) by Microsoft’s Nat Friedman (founder of Ximian) who will be taking the role of GitHub CEO.
This looks like the end of the road for Intel’s brief foray into the “maker market”. Reader [Chris] sent us in a tip that eventually leads to the discontinuation notice (PCN115582-00, PDF) for the Arduino 101 board. According to Intel forum post, Intel is looking for an alternative manufacturer. We’re not holding our breath.
We previously reported that Intel was discontinuing its Joule, Galileo, and Edison lines, leaving only the Arduino 101 with its Curie chip still standing. At the time, we speculated that the first wave of discontinuations were due to the chips being too fast, too power-hungry, and too expensive for hobbyists. Now that Intel is pulling the plug on the more manageable Arduino 101, the fat lady has sung: they’re giving up on hardware hackers entirely after just a two-year effort.
According to the notice, you’ve got until September 17 to stock up on Arduino 101s. Intel is freezing its Curie community, but will keep it online until 2020, and they’re not cancelling their GitHub account. Arduino software support, being free and open, will continue as long as someone’s willing to port to the platform.
Who will mourn the Arduino 101? Documentation was sub-par, but a tiny bit better than their other hacker efforts, and it wasn’t overpriced. We’re a little misty-eyed, but we’re not crying. You?
Keyloggers are nasty little things that have the potential to steal the credit card numbers of you and everyone you care about. Usernames and passwords can be easily stolen this way, so they’re a useful tool for the black hats out there. One would generally expect to find a keylogger in a dodgy movie torrent or perhaps a keygen for pirated software, but this week a keylogger was found in an audio driver for an HP laptop.
The logger was found by Swiss security researchers modzero. The Conexant HD Audio Driver Package version 126.96.36.199 and earlier apparently logs keystrokes in order to monitor things like the laptop’s volume up and down keys. The real killer here is that it feels the need to log all keystrokes detected to a readily accessible file, for reasons we can’t possibly fathom. It’s a huge security risk, but it doesn’t stop there – the driver also exposes the keystrokes through an API as well, creating an even wider attack surface for malicious actors. One can in principle access the keystroke log remotely.
There’s no word from the company yet, but we really want to know – why save the keystrokes to a file at all? Code left over from debugging, perhaps? Speculate in the comments.
If you’ve been reading the news lately, you doubtless read about the find of a really big new helium gas field in Tanzania. It’s being touted as “life-saving” and “game-changing” in the popular media, but this is all spin. Helium is important for balloon animals, scientists, and MRI machines alike, but while it’s certainly true that helium prices have been rising steadily since 2000, this new field is unlikely to matter all that much in the grand scheme of things.
The foundation of every news story on helium is that we’re running out of the stuff. As with most doomsday scenarios, the end of the world’s supply of helium is overstated, and we don’t just mean in light of the new Tanzanian field. Helium is the second-most abundant element, making up 24% of the total mass of the universe. And while the earth has a disproportionate amount of heavier elements, helium is in rocks everywhere. It’s just a question of getting it out, and at what price that’s viable.
So while we’re stoked that the era of (relatively) cheap helium can continue onwards for a few more years, we’re still pretty certain that the price is going to continue to rise, and our children’s children won’t be using the stuff for something so frivolous as blowing up party balloons — it’ll be used primarily, as it is now, where it’s more valuable: in science, medicine, and industry.
Let’s take this moment to reflect on the economics of second-lightest element. Here’s to you, Helium!
According to this article in the Guardian, Premier Farnell, the electronics parts distributor who is also a UK manufacturer of the Raspberry Pi, is going to be sold to Dätwyler. Their share price immediately rose 50%, closing at just under the Swiss firm’s offer price.
Farnell itself had been on a binge, according to Wikipedia anyway, buying up electronics distributorships in Poland, India, and the US. In 2009, they bought Cadsoft, the makers of Eagle CAD software. Now they’re being sold to another distributor.
Bloomberg writes this up as being just more consolidation in an already consolidating market. What any of this will mean for the hacker on the street is anyone’s guess, but we’re putting our money on it amounting to nearly nothing. But still, now’s the time to stock up on your genuine UK-owned, made-in-UK Pis before they become Swiss-owned and made who knows where.
We never have enough peripherals on a microcontroller. Whether it’s hardware-driven PWM channels, ADCs, or serial communication peripherals, we always end up wanting just one more of these but don’t really need so many of those. Atmel’s new version of the popular ATmega328 series, the ATmega328PB, seems to have heard our pleas.
We don’t have a chip in hand, but the datasheet tantalizes. Here’s a quick rundown of the new features:
Two more 16-bit timer/counters. This is a big deal when you’re writing code that’s not backed up by an operating system and relies on the hardware for jitter-free timing.
Two of each USART, SPI, and I2C serial instead of one of each. Good when you use I2C devices that have limited address spaces, or when you need to push the bits out really fast over SPI.
Ten PWM channels instead of six. This (along with the extra 16-bit timers) is good news for anyone who uses PWM — from driving servos to making music.
Onboard capacitive sensing hardware: Peripheral Touch Controller. This is entirely new to the ATmega328PB chip, and looks like it’ll be interesting for running capacitive sense buttons without additional ICs. It relies on Atmel’s QTouch software library, though, so it looks like it’s not a free-standing peripheral as much as an internal multiplexer with maybe some hardware-level filtering. We’ll have to look into this in detail when we get our hands on one of the chips.
So what does this mean for you? A quick search of the usual suspects shows the chips in stock and shipping right now, and there’s an inexpensive dev kit available as well. If you write your own code in C, taking advantage of the new features should be a snap. Arduino folks will have to wait until the chips (and code support) work their way into the ecosystem.