The Most Annoying Thing On The Internet Isn’t Really Necessary

March 29, 2024 by Jenny List 31 Comments

We’re sure you’ll agree that there are many annoying things on the Web. Which of them we rate as most annoying depends on personal view, but we’re guessing that quite a few of you will join us in naming the ubiquitous cookie pop-up at the top of the list. It’s the pesky EU demanding consent for tracking cookies, we’re told, nothing to do with whoever is demanding you click through screens and screens of slider switches to turn everything off before you can view their website.

Now [Bite Code] is here to remind us that it’s not necessary. Not in America for the somewhat obvious reason that it’s not part of the EU, and perhaps surprisingly, not even in the EU itself.

The EU does have a consent requirement, but the point made in the article is that its requirements are satisfied by the Do Not Track header standard, an HTTP feature that’s been with us since 2009 but which almost nobody implemented so is now deprecated. This allowed a user to reject tracking at the browser level, making all the cookie popups irrelevant. That popups were chosen instead, the article concludes, is due to large websites preferring to make the process annoying enough that users simply click on the consent button to make it go away, making tracking much more likely. We suspect that the plethora of cookie popups also has something to do with FUD among owners of smaller websites, that somehow they don’t comply with the law if they don’t have one.

So as we’d probably all agree, the tracking cookie situation is a mess. This post is being written of Firefox which now silos cookies to only the site which delivered them, but there seems to be little for the average user stuck with either of the big browsers. Perhaps we should all hope for a bit more competition in the future.

Cookies header: Lisa Fotios, CC0.

This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256

March 29, 2024 by Jonathan Bennett 1 Comment

The Linux command wall is a hold-over from the way Unix machines used to be used. It’s an abbreviation of Write to ALL, and it was first included in AT&T Unix, way back in 1975. wall is a tool that a sysadmin can use to send a message to the terminal session of all logged-in users. So far nothing too exciting from a security perspective. Where things get a bit more interesting is the consideration of ANSI escape codes. Those are the control codes that moves the cursor around on the screen, also inherited from the olden days of terminals.

The modern wall binary is actually part of util-linux, rather than being a continuation of the old Unix codebase. On many systems, wall runs as a setgid, so the behavior of the system binary really matters. It’s accepted that wall shouldn’t be able to send control codes, and when processing a message specified via standard input, those control codes get rejected by the fputs_careful() function. But when a message is passed in on the command line, as an argument, that function call is skipped.

This allows any user that can send wall messages to also send ANSI control codes. Is that really a security problem? There are two scenarios where it could be. The first is that some terminals support writing to the system clipboard via command codes. The other, more creative issue, is that the output from running a binary could be overwritten with arbitrary text. Text like:
Sorry, try again. [sudo] password for jbennett:

You may have questions. Like, how would an attacker know when such a command would be appropriate? And how would this attacker capture a password that has been entered this way? The simple answer is by watching the list of running processes and system log. Many systems have a command-not-found function, which will print the failing command to the system log. If that failing command is actually a password, then it’s right there for the taking. Now, you may think this is a very narrow attack surface that’s not going to be terribly useful in real-world usage. And that’s probably pretty accurate. It is a really fascinating idea to think through, and definitively worth getting fixed. Continue reading “This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256” →

Art Exhibit Lets You Hide From Self-Driving Cars

March 29, 2024 by Maya Posch 16 Comments

In the discussions about how dangerous self-driving cars are – or aren’t – one thing is sorely missing, and that is an interactive game in which you do your best to not be recognized as a pedestrian and subsequently get run over. Even if this is a somewhat questionable take, there’s something to be said for the interactive display over at the Asian Art Museum in San Francisco which has you try to escape the tyranny of machine-vision and get recognized as a crab, traffic cone, or something else that’s not pedestrian-shaped.

The display ran from March 21st to March 23rd, with [Stephen Council] of SFGate having a swing at the challenge. As can be seen in the above image, he managed to get labelled as ‘fire’ during one attempt while hiding behind a stop sign as he walked the crossing. Other methods include crawling and (ab)using a traffic cone.

Created by [Tomo Kihara] and [Daniel Coppen], it’s intended to be a ‘playful, engaging game installation’. Both creators make it clear that self-driving vehicles which use LIDAR and other advanced detection methods are much harder to fool, but given how many Teslas are on the road using camera-based systems, it’s still worth demonstrating the shortcomings of the technology.

There’s no shortage of debate about whether or not autonomous vehicles are ready to share the roads with human drivers, especially when they exhibit unusual behavior. We’ve already seen protesters attempt to confuse self-driving systems with methods that aren’t far removed from what [Kihara] and [Coppen] have demonstrated here, and it seems likely such antics will only become more common with time.

LoRA, With No Radio

March 29, 2024 by Jenny List 28 Comments

A LoRa project has traditionally required a dedicated radio module, because it’s a commercially licenced protocol. But as the way it works has been progressively reverse engineered, it’s become ever more possible to produce a LoRA radio for yourself. But what about a LoRA radio without a radio at all? [CNLohr] has managed just that, by driving a microcontroller pin and relying on one of its harmonics to provide enough RF to be received by a LoRA gateway.

The video below the break goes into the process in great detail, revealing some of the tricks. Undersampling to create intentional aliasing for example allows subharmonic peaks to be produced in unexpected places. Most of the development is performed on Espressif microcontrollers, but as the code is optimised it becomes possible to use it on much more modest silicon. The dirt cheap CH32V003 RISC-V microcontroller for example can be a LoRA transmitter able to talk to a gateway at a range of hundreds of metres with the CH32 and 2.5km with the ESP32. The code can be found in this GitHub repository.

The CH32 can’t receive of course, and it relies on barfing harmonics all over the spectrum to work. But on the other hand its total RF output is so tiny that we’re guessing a filter for the LoRA band might even make it almost legal. He’s got a little way to go before beating the record though.

Continue reading “LoRA, With No Radio” →

The Intel 8088 And 8086 Processor’s Instruction Prefetch Circuitry

March 28, 2024 by Maya Posch 15 Comments

The 8088 die under a microscope, with main functional blocks labeled. This photo shows the chip's single metal layer; the polysilicon and silicon are underneath. (Credit: Ken Shirriff) — The 8088 die under a microscope, with main functional blocks labeled. This photo shows the chip’s single metal layer; the polysilicon and silicon are underneath. (Credit: Ken Shirriff)

Cache prefetching is what allows processors to have data and/or instructions ready for use in a fast local cache rather than having to wait for a fetch request to trickle through to system RAM and back again. The Intel 8088 (and its big brother 8086) processor was among the first microprocessors to implement (instruction) prefetching in hardware, which [Ken Shirriff] has analyzed based on die images of this famous processor. This follows last year’s deep-dive into the 8086’s prefetching hardware, with (unsurprisingly) many similarities between these two microprocessors, as well as a few differences that are mostly due to the 8088’s cut-down 8-bit data bus.

While the 8086 has 3 16-bit slots in the instruction prefetcher the 8088 gets 4 slots, each 8-bit. The prefetching hardware is part of the Bus Interface Unit (BIU), which effectively decouples the actual processor (Execution Unit, or EU) from the system RAM. While previous MPUs would be fully deterministic, with instructions being loaded from RAM and subsequently executed, the 8086 and 8088’s prefetching meant that such assumptions no longer were true. The added features in the BIU also meant that the instruction pointer (IP) and related registers moved to the BIU, while the ringbuffer logic around the queue had to somehow keep the queueing and pointer offsets into RAM working correctly.

Even though these days CPUs have much more complicated, multi-level caches that are measured in kilobytes and megabytes, it’s fascinating to see where it all began, with just a few bytes and relatively straight-forward hardware logic that you easily follow under a microscope.

Is Your Mental Model Of Bash Pipelines Wrong?

March 28, 2024 by Donald Papp 11 Comments

[Michael Lynch] encountered a strange situation. Why was compiling then running his program nearly 10x faster than just running the program by itself? [Michael] ran into this issue while benchmarking a programming project, pared it down to its essentials for repeatability and analysis, and discovered it highlighted an incorrect mental model of how bash pipelines worked.

Here’s the situation. The first thing [Michael]’s pared-down program does is start a timer. Then it simply reads and counts some bytes from stdin, then prints out how long it took for that to happen. When running the test program in the following way, it takes about 13 microseconds.

$ echo '00010203040506070809' | xxd -r -p | zig build run -Doptimize=ReleaseFast
bytes: 10
execution time: 13.549µs

When running the (already-compiled) program directly, execution time swells to 162 microseconds.

$ echo '00010203040506070809' | xxd -r -p | ./zig-out/bin/count-bytes
bytes: 10
execution time: 162.195µs

Again, the only difference between zig build run and ./zig-out/bin/count-bytes is that the first compiles the code, then immediately runs it. The second simply runs the compiled program. Continue reading “Is Your Mental Model Of Bash Pipelines Wrong?” →

Saving A Clock Radio With An LM8562

March 28, 2024 by Bryan Cockfield 10 Comments

Smart phones have taken the place of a lot of different devices especially as they get more and more powerful. GPS, music and video player, email, and of course a phone are all functions tied up in these general-purpose devices. Another casualty of the smart phone revolution is the humble bedside alarm clock as its radio, alarm, and timekeeping functionalities are also provided by modern devices. [zst123] has a sentimental attachment to the one he used in the 00s, though, and set about restoring it to its former glory.

Most of the issue with the clock involved drift with the timekeeping circuitry. Since it wasn’t accurately keeping the time anymore, losing around 10 minutes a day, the goal to save it was to use NTP to get the current time and a microcontroller to make the correction automatically. Rather than replace everything in the clock except the display, [zst123] is using the existing circuit board and adding an ESP8266 to grab the time from the Internet. A custom driver board reads the current time displayed on the clock directly from the display itself and then the ESP8266 can adjust it by using the existing buttons through a relay wired in parallel.

Using the existing circuitry was certainly a challenge especially since the display was multiplexed, but the LM8562 that came with these clock radios is a common and well-documented chip for driving displays like this, giving [zst123] a leg up over something unlabeled or proprietary. Using NTP is certainly a reliable and straightforward way of getting the current time too but there are a few other options for projects like these like using GPS or even a radio signal.