The original promise of streaming was simple. Everything would be available whenever you wanted it. You could sit down in the evening and binge an entire season without waiting a week for the next episode. Well... weekly releases seem to be making a comeback. I've forgotten more than one show simply because I had to wait a week for the next episode. I still remember recording TV shows because otherwise you'd miss them, or waiting until 8:15 p.m. because that's when the big movie of the week started. Today you just lie down in bed, open an app, and watch whatever you're in the mood for. Broadcast schedules don't matter anymore. One of the most annoying things about television was the ad breaks every fifteen minutes. Early streaming didn't have that. You paid for a Netflix subscription and that was it. It was usually cheaper than cable or pay TV too. Whether that's still true today is debatable (I don't know the current prices of cable or pay TV). Back then, one streaming service was enough to watch most of the movies people cared about.

Then everything started to fragment. Over time, it felt like every major studio launched its own service. Then Netflix proved just how profitable streaming subscriptions could be. Instead of licensing their movies to Netflix, studios realized they could keep the content, launch their own platform, and collect the subscription fees themselves. From a business perspective, it made perfect sense. From a viewer's perspective, it was the beginning of the mess. Disney made Disney+, Warner launched (HBO) Max, Paramount created Paramount+, and so on. I remember reading about the Transformers films moving to Paramount+. I ended up binge-watching all of them before they disappeared. Each company wants to keep its own movies and shows exclusive to its own platform. It's what convinces people to subscribe. The downside is that movies disappear from other services once the licensing rights move back to their original owners. And it's not just movies and TV. Sports have become just as fragmented. The Champions League is on one platform, Formula 1 on another, the NBA somewhere else. And even if you're lucky enough to subscribe to the right service, the movie you want might be on Hulu in the US, Disney+ in Germany or simply unavailable where you live.

As a student I (sadly) don't have unlimited money. Three streaming subscriptions at around €8 or €10 each already add up. If you want 4k or need more than one device, that's another extra charge. Then came the ad-supported plans. Subscription growth eventually slowed down, so streaming companies started looking for new ways to increase revenue. The cheaper plans include ads, while the ad-free versions keep getting more expensive. The goal is simple: make the more expensive plan look like the better deal. And sports subscriptions are even worse. If you want to follow everything related to your favorite sport, spending €50 a month isn't unusual. Add regular price increases on top of that, and suddenly streaming isn't the affordable alternative it used to be.

Let's say you've accepted that this is just how streaming works now. Now you have to figure out where your movie actually is. Every app has its own interface, its own search function, and its own way of organizing content. Personally, I've never liked how clunky TV apps often feel. I'm looking at you, Prime. Eventually you find your movie. After it's over, another interesting recommendation pops up, so you save it to your watchlist. Except every platform has its own watchlist. Sure, every company wants you to stay in its own ecosystem. Before you know it, you've got movies saved across six different apps. Video quality isn't consistent either. One service includes 4K, while another only offers HDR or Full HD unless you pay more. And sometimes it's almost ridiculous: you watch the first movie on Disney+, then have to switch to another service just to watch the sequel.

There are more movies available than ever before, yet it's somehow harder to find one to watch. At least for me, it's not unusual to spend twenty minutes scrolling through different apps just to watch a ninety-minute movie. Sometimes, after all that searching, I don't even feel like watching anything anymore. And the recommendation algorithms. I mean, they've suggested some genuinely great movies to me so I don't want to pretend that they're completely useless. But a lot of the time they keep pushing the same popular titles. Smaller films and independent productions rarely get the same visibility.

Ironically, streaming is starting to look a lot like TV again. Ads are back unless you pay for the expensive tier. FAST channels with fixed schedules are becoming more common, because they're cheap to operate and generate advertising revenue 24/7. Bundles like Disney+, Hulu and ESPN+ feel a lot like cable TV all over again. Exclusive licensing means certain shows only exist on one platform. And live events, like boxing on Netflix or exclusive sports broadcasts elsewhere, are bringing appointment viewing back.

But it has consequences. Some people end up turning back to piracy. It's not just because they don't want to pay. A lot of them are already paying for several streaming services. The bigger issue is the convenience. Spotify showed that if legal streaming is more convenient than piracy, most people are happy to pay. Illegal platforms usually put everything into one interface. There's no jumping between apps, no wondering who owns the rights this month and regional restrictions often disappear. Of course there's a reason it's called piracy. These sites can disappear overnight and you might get fined, but yeah, you get me.

There are probably a few ways to improve things. Cross-platform search should be standard by now. A shared watchlist across services would help. You can track movies with Letterboxd or one of the other apps, but then you're relying on yet another app to organize your entertainment. Bundled subscriptions where you choose three services for a discounted price could also make things simpler. Those are just a few ideas, but they're probably easier said than done.

Streaming is still great, don't get me wrong. The flexibility is unmatched, and the picture quality has never been better. The problem isn't with streaming itself. It's just that the ecosystem became too fragmented. Streaming solved TV's biggest problems. But over time, it slowly recreated most of them. And that's why I'll probably keep asking myself the same question for a while longer: Wait… which streaming service was that on again?

When you hear a new song, your brain immediately starts trying to predict what comes next. Since it doesn't know the structure yet, almost every part of the song is a small surprise. Those surprises activate your brain's reward system, which leads to the release of dopamine. The result is that feeling of excitement that makes you want to hit replay the moment the song ends.

Another reason is something called the mere-exposure effect. People tend to like things more simply because they become familiar with them. The first listen might even feel confusing. By the fifth listen, though, your brain has started recognizing the patterns, making the song much easier to follow. Of course this differs from song to song, but it's also why (at least for me) my favorite songs are almost never my favorites after the very first listen.

With every replay, your brain notices new details. At first you might only focus on the lead vocal. Then you suddenly hear the bass line. Then the background vocals. Then some tiny production detail you've somehow missed ten times already. Every listen adds another layer to your mental model of the song. You're not just hearing the same song over and over again. You're hearing more and more of it.

Another point on my list is the situation you're in when you hear a song. For me, it could be a song I heard at a festival while my friends and I were having the time of our lives. For someone else, it could be a song they listened to during a breakup or while studying for exams. The song becomes linked to those emotions. Later, hearing it again can bring back parts of that emotional state almost instantly.

But if that's true, why can't I listen to the same song every day forever?

One of the brain's most basic learning processes is habituation. Repeated exposure to the same stimulus reduces the brain's response over time. Your brain simply gets used to the song. It already knows what's coming. As a result the emotional reaction gradually becomes weaker.

There are also other factors. Dopamine isn't released simply because something is enjoyable. It's closely tied to anticipation, learning, prediction errors, and uncertainty. Once you know every note, every lyric, and every transition by heart, there aren't many surprises left. The brain has very little left to learn, so the reward signal becomes smaller.

The same thing happens with positive experiences in general. Think about buying a new phone or going on vacation. Eventually those things stop feeling extraordinary because we adapt to them. Our baseline shifts. What once felt exciting eventually feels normal. This phenomenon is called hedonic adaptation.

So if you want your brain to experience that reward again, the best thing you can do is take a break. Try not to listen to the song for a while, maybe a few weeks or even months. During that time, you'll forget some of the small details as well, your predictions won't be on the spot, and those emotional connections might feel new and fresh again. The song feels a little uncertain again. It probably won't sound like the very first listen but it'll sound better than it did after the twentieth replay in a row, trust me. At least for me, when I go back and listen to my most listened to songs from past years, I always find one that I forgot and start loving again.

But why do some songs lose their "magic" after twenty listens while others stay exciting after a hundred?

As I mentioned earlier, not every song works the same way. Research suggests that the more musical layers, harmonic complexity, emotional depth, evolving dynamics, and subtle details a song contains, the longer it tends to stay rewarding. Simpler songs can deliver a huge initial dopamine hit, but they often run out of surprises much faster. So keep this in mind before clicking the "Skip back" key.

A monitor is storage.

A keyboard is storage.

A BIOS splash screen is (maybe) storage.

A favicon is storage.

And yes, here we are.

Every website has a favicon. It's that little icon in your browser tab. Usually you upload it once and then never think about it again. But. A favicon is just an image. An image is just pixels. And pixels are just bytes.

So of course I wondered if I could store something inside one.

The idea

My first thought was steganography. 

Steganography is basically about hiding data in an image without making it obvious. You take a perfect normal photograph and modify a few bits so it secretly contains a message.

The favicon itself (at least in my demo) doesn't need to look like an icon. It could become pure storage.

Every pixel has red, green and blue values. That's three bytes. If I wanted to store text, I could just take the UTF-8 bytes of the text and write them directly into the RGB channels.

The browser doesn't care what those bytes represent. To the browser they're colors. To me in this case they're HTML.

Building a favicon website

I started with a tiny HTML payload:

<h1>Website in a Favicon</h1> 
<p>
	Everything you're reading right now was decoded from favicon pixels.
</p>

The process is pretty straightforward.

First I convert the HTML into bytes using TextEncoder.

Then I prepend four bytes containing the payload length.

The length header is important because the image itself may contain unused pixels at the end. If there's no length value, there's no way to know where the real payload stops.

Then I just start filling pixels: the first byte becomes the red channel of the first pixel, the second becomes the green, the third becomes blue, and then the next pixel, and the next, and the next, until the whole HTML document exists as colored pixels. The result looks like visual noise.

Very small

What surprised me most wasn't that it worked, to be honest. It was how small the resulting image was.

The payload ended up being 208 bytes.

Adding the 4-byte header brings the total to 212 bytes.

Since every pixel stores three bytes, I needed:

• 212 bytes total
• 71 pixels
• A square image large enough to contain them

The smallest square that works is 9x9 pixels.

That's only 81 pixels.

The final stats looked like this:

• Payload: 208 bytes
• Image size: 9x9 pixels
• Capacity: 239 bytes
• Used: 87%

Somehow a whole little website (okayy, html with some styling) fits inside an image that's smaller than the usual favicon.

Reading the website back out

Storing data is only half the problem. The other half is getting it back.

Browsers already have everything needed for this.

1. The favicon gets loaded as image.
2. The image gets drawn onto a canvas.
3. The canvas API lets JavaScript read every pixel.

Once I have the pixel data, I simply reverse the process.

1. Read the RGB values.
2. Reconstruct the byte array.
3. Read the first four bytes to determine the payload length.
4. Extract the payload.
5. Decode the UTF-8 text.

At that point I have the original HTML again.

The browser read a website out of its own favicon.

The important catch

The favicon doesn't actually contain the whole website itself.

It contains the content of a website.

You still need a tiny bootstrap loader to decode the image.

Without the JavaScript the favicon is just a PNG (which contains your website content).

For showing this scenario the site includes a "Render Website" button. It reads the favicon, decodes the HTML, and replaces the page with the reconstructed content.

Is this useful?

No, of course not.

The amount of data you can store is tiny. The page needs JavaScript to bootstrap itself. There are dozens of better ways to distribute a small HTML document.

But at the end its about testing the boundaries, right?

A favicon feels like a very specific thing. It's supposed to be an icon.

But at the end it can just be a PNG.

And a PNG file is basically just bytes.

And this is probably the smallest website I've built…

Alternative approaches

• Store markup directly in SVG favicon and read it on page load.
• Use PNG comment chunks like tEXt, zTXt and iTXt.
• Use the ico file format since it allows multiple icons with different resolutions.

Here is the link to the site: https://www.timwehrle.de/labs/favicon-site/

And if you want to see how it works: https://github.com/timwehrle/favicon

It wasn't a big project. He was annoyed by a repetitive task, so he spent a few hours building a tool that made his workflow much easier.

To be honest, I liked it.

It's satisfying to see someone remove a piece of friction from their day instead of just complaining about it.

The funny thing is, he wanted to share the tool with a colleague.

So he sent him the source code.

He was happy with that. His colleague would open it and everything would work just like it did on his machine, with no extra steps. 

Of course, it didn't.

I don't think he had really thought about what was happening behind the scenes. I mean, why would he? The app worked. The problem was solved. That's usually where people stop thinking about software.

He realized that there's a difference between software that works for one person and software that works for multiple people. Yeah, for people who know what they're doing, this was pretty easy to see coming.

I liked his approach to the problem, though.

A few hours earlier, he was struggling.

A few hours later, he had found a solution.

The more I thought about it, the more it reminded me of discussions about shadow IT. For those who aren't tech-savvy, it's basically a term companies use when employees start using their own software, tools, or processes without going through the IT department.

Which, if I'm honest, is pretty much what my colleague had done.

People often ask why employees keep building their own tools, spreadsheets, scripts, databases, and now AI-generated applications.

But I'm not sure that's the most interesting question.

Most people don't wake up wanting to maintain software. They don't dream about version control, backups, access management, support requests, compliance reviews, or documentation. Well, maybe someone dreams about documentation, but I've never met them.

People usually just want to get their work done.

Some people will (understandably) do it themselves if it seems faster than going through the official process. I'm not a fan either. It's frustrating to wait for a simple process to finish (and then there are 20 more of them).

That doesn't mean the IT department is wrong, though.

As soon as my colleague tried to share his application, he ran into the kind of problem IT departments are supposed to solve.

How does someone install it?

Where does it run?

What happens when it breaks?

Who maintains it?

What happens when the person who built it leaves?

None of this was an issue when it was just his personal tool. But as soon as someone else wanted to use it, the answers suddenly mattered a lot.

That's probably why I have a hard time seeing shadow IT as the real problem.

It often feels more like a symptom.

People don't build their own solutions because they secretly want to become software developers.

Most of the time they build them because waiting feels more expensive. Maybe not financially. But in terms of time, frustration and actually getting work done.

The department wants a solution now.

Meanwhile, IT wants security, governance, maintenance, support, backups, access controls, and all the other boring things that only become important after something is successful.

Both sides are acting rationally.

They're just focusing on different things.

One side is trying to solve today's problem.

The other is trying to make sure today's solution doesn't become next year's problem.

Maybe that's why shadow IT never really goes away.

It feels uncomfortable to me to say that I'm good at my job. It feels like bragging. It makes it seem like I'm trying to make myself sound more important than I am. At the same time, it wouldn't have been honest to talk down my work. I stood there, realizing that a simple question didn't have a simple answer.

I kept (over-)thinking about it for a while afterwards.

Not about the question itself, but about why he had to ask it in the first place.

My colleague works on a different team. He doesn't see what I work on every day. He doesn't see the problems I solve. He doesn't see the decisions I make or the things I've built. So how would he know if I'm good at my job? On top of that, he obviously has no idea what I actually do all day.

The answer is pretty obvious. If I never talk about it, there's no way he could know.

I think many people know this feeling. You want to do good work, but you don't want to constantly talk about it. You don't want to put every small achievement on display. You don't want to be the person in every meeting bragging about their latest accomplishment. I wouldn't enjoy being that person either.

So you just work and work.

You do your tasks. You solve problems. You help colleagues. You make sure things keep working, and often before they stop working.

At some point, you realize that a large part of that work is basically invisible to everyone else.

For a long time, I thought that good work speaks for itself. It's a nice idea. If you're good at your job, the right people will notice.

But this only works sometimes in small teams.

The bigger an organization gets, though, the less true it becomes.

CEOs don't see eight hours of your workday (and they don't have to care, to be honest). Department heads don't either. Most of the time, they don't see even 1% of it. They only see the results (and that's probably the only thing they want to see). They see the final output of a long chain of work.

All the small decisions you made on the way usually disappear.

Nobody sees the bug you caught in time. No one sees the discussion that prevented a problem. No one sees the hour you spent simplifying something complicated. No one sees the ten things that didn't go wrong because you were paying attention.

And that's not even criticism.

It would be impossible to see everything.

In a company with hundreds or thousands of employees it's impossible to keep track of everyone's work. Sometimes I can't even keep track of my own work. Instead, people form their opinions based on what they can see and hear.

In that scenario, it's not only what you do that matters. It also matters what others know about your work.

In my opinion, that idea just feels wrong.

The work itself should matter, not the story around it.

Eventually, though, I had to admit that the two are connected.

If you never talk about your work you can't really be surprised when people know very little (or nothing) about it.

That doesn't mean you have to become a self-promoter. It doesn't mean celebrating every completed task or constantly marketing yourself.

There's a lot of space between bragging and being completely invisible.

You can talk about what you're working on. You can explain the problems you've solved. You can share things that nobody else gets to see.

Maybe that's actually part of the job even if many of us (or just me) don't like it.

The interesting thing is that we usually notice bragging much faster in ourselves than in other people. When someone explains what they've been working on in an easy-to-understand way, I usually don't think they're showing off. Well, it depends on how they say it, but usually I just think: Oh, that's interesting. I didn't know that.

It still feels different when it's me.

That said, I suppose you sometimes have to step outside your comfort zone and talk to people about your work.

It had its purpose and I would've made the same choice, maybe. But I recognised a pattern where systems introduce a new responsibility, and then, "new responsibility" started sounding suspiciously like "new service".

I like microservices. Which is probably why this stuck with me. Once a team has a few of them, every new idea begins to orbit the architecture. Need a feature? Service. Need a small extension point? Service. Need to store three values and call an API twice? Obviously, service. Preferably with its own repository, wait… We already have a monorepo. Then just a new folder, pipeline and a name that sounds like a Marvel character. I'm looking at you, Galactus.

The uncomfortable part is that microservices are not bad. That would be too easy. They solve real problems: independent scaling, isolated deployments, clearer ownership, fault boundaries. At the right size, with the right team, under the right pressure, they make sense.

But sometimes we seem to skip the boring question: do we actually need this?

A modular component could be enough. A clean boundary inside the existing app could be enough. A plugin-style extension point could be enough. Build it so it can grow later, sure. But maybe don't immediately give it its own infrastructure passport and send it into production as a tiny nation-state.

There is this fantasy that everything will scale massively one day. The classic "when we have millions of users" argument. Which is technically possible, in the same way that I am technically one viral GitHub repo away from becoming a conference keynote speaker. Possible, yes. Planning your entire architecture around it today, questionable.

Modern software has a tendency to confuse seriousness with complexity. If a thing has message queues, distributed tracing, and twelve dashboards, it feels important. A simple module feels almost suspicious.

Maybe that is what bothers me: overengineering often looks responsible from a distance. Nobody gets blamed for choosing the architecture that sounds scalable. "We made it a microservice" has a professional smell to it. "We kept it simple because the problem was simple" sounds almost naive, even when it is probably the more thoughtful decision.

Still, I get the temptation. Microservices are satisfying. They create neat boxes. They promise separation.

Maybe the better question is not "Should this be a microservice?" but "What pain are we trying to avoid?". If the pain is deployment coupling, team ownership, scaling, or reliability boundaries, then maybe yes. If the pain is simply that the codebase feels a bit untidy, maybe the answer is a refactor, not a new distributed system. And yes, I hate refactors as well.

I did not learn anything new today. More like I re-noticed something old: software usually gets complicated one reasonable decision at a time.

I have a Logitech MX Vertical, which travels between my home machine, work laptop and other devices constantly. At some point I looked at it and thought: this thing has a flash memory. It has to, otherwise how does it remember the DPI setting between plugs. So what if I stored something in it?

Yea, I was bored.

The idea was to treat the mouse like a little USB drive. Since it physically travels between computers, it could technically carry data with it.

Logitech mice communicate using something called HID++, a protocol that they built on top of standard USB HID. It's partially documented by Logitech themselves and partly reverse engineered by the open source community. I wrote a Rust tool to enumerate every feature the mouse exposes. There are 33.

HID++ 2.0 works like this: every device has a feature table. Each entry maps a stable feature ID to a device-specific index. The ID is consistent across all Logitech devices. The index varies per model. So you first ask the device "where is feature 0x2201?" and it tells you "index 0x12 on this mouse". Then you use that index for all subsequent calls. Every call is a short packet: report ID, device index, feature index, function ID, and up to 3 bytes of params. The response comes back in the same shape.

Most are undocumented. There are names like EnableHiddenFeatures and TemplateBytesNVS. That second one sounds exactly like what I wanted: non-volatile storage, index 0x1eb0. I couldn't find any info on it in the docs, but I'm guessing it's something to do with configuration blobs for macros or button templates. Unfortunately, the mouse wouldn't respond to anything, so I couldn't find out.

I spent a while on 0x1c00 (the PersistentRemappableAction) first. Six slots, read/write flags, and so on. Turns out macOS's IOHIDManager blocks the longer HID++ report format you need to actually write to it. The OS just drops the packets. There was no error, no explanation, nothing. I found this out after writing a pile of probe code and staring at empty responses for longer than I'd like to admit. Yes, there are ways around IOHIDManager, like talking directly to the USB device via IOKit, but that's a different story.

Then I looked at the device name register. It looked promising and the write calls were accepted. But the mouse kept saying "MX Vertical" regardless of what I sent. It was just ghosting me.

What did worked was the DPI register (0x2201).

You can read two values from it:

• the current (active) DPI
• a fallback/default DPI

Setting DPI works via function 0x03, and reading via 0x02.

Here's the important (and updated) part:

• Writing DPI only updates the active DPI
• The fallback/default DPI remains unchanged
• On power cycles, the device restores the fallback value

So while the DPI register accepts arbitrary u16 values, they are not persisted across power cycles.

However, there is one interesting property:

As long as the mouse stays powered, the value survives switching computers. You can write a value on one device, move the receiver to another, and read it back.

So the "storage" is only:

2 bytes of cross-computer, session-scoped storage (while the mouse remains powered)

So the original idea: "using DPI as persistent storage" doesn't actually hold up. The only solution would be to "cache" and rewrite it on the mouse on power cycles, but that would defeat the idea.

I also tested a range of other features and write paths (including 0x1e, 0x1f, and several 0x18xx config features). None of them affected the fallback DPI or exposed writeable persistent storage.

At this point, it looks like the default DPI is either:

• stored in a part of firmware not exposed via HID++, or
• only writeable through vendor tooling / signed commands

Even though the original goal didn't work out, the process was still worth it.

I learned how HID++ works. I learned how macOS manages HID devices at kernel level and where it draws lines. I learned that "feature table" and "feature index" are different things and that the IFeatureSet reverse lookup is apparently broken on this device. I learned that the device name register will politely accept your writes and then completely ignore them, which is a deeply relatable response.

None of the knowledge came from reading docs. The Logitech hidpp20 docs exist, but half the features are missing, so I had to try it out. It all was trial and error until it worked. But maybe don't do that with your BIOS.

The result is objectively useless. No hidden storage, no secret USB drive in a mouse. But that wasn't really the point. The point was seeing how far I could get.

The 2 bytes are still there. You just have to keep the mouse alive…

I will dig deeper tho, because the default DPI has to be somewhere in my mouse.

Code is here if you want to explore it yourself: https://github.com/timwehrle/mouse-fs.