Smartphones boggle my mind a whole lot – they’re pocket computers, with heaps of power to spare, and yet they feel like the furthest from it. As far as personal computers go, smartphones are surprisingly user-hostile.

In the last year’s time, even my YouTube recommendations are full of people, mostly millennials, talking about technology these days being uninspiring. In many of those videos, people will talk about phones and the ecosystems that they create, and even if they mostly talk about the symptoms rather than root causes, the overall mood is pretty clear – tech got bland, even the kinds of pocket tech you’d consider marvellous in abstract. It goes deeper than cell phones all looking alike, though. They all behave alike, to our detriment.

A thought-provoking exercise is to try to compare smartphone development timelines to those of home PCs, and see just in which ways the timelines diverged, which forces acted upon which aspect of the tech at what points, and how that impacted the alienation people feel when interacting with either of these devices long-term. You’ll see some major trends – lack of standardization through proprietary technology calling the shots, stifling of innovation both knowingly and unknowingly, and finance-first development as opposed to long-term investments.

Let’s start with a fun aspect, and that is hackability. It’s not perceived to be a significant driver of change, but I do believe it to be severely decreasing chances of regular people tinkering with their phones to any amount of success. In other words, if you can’t hack it in small ways, you can’t really make it yours.

Can’t Tinker, Don’t Own

In order to tinker with your personal computer, you need just that, the computer itself. Generally, you need a whole another computer to hack on your smartphone; sometimes you even need a custom cable, and it’s not rare you can’t do it at all. Phone tinkering is a path you explicitly set out to do, whereas computer-based hacking is something you can do idly.
A Nokia N900 in hands of a user (by Victorgrigas, CC BY-SA 3.0)
There’s good reasons for this, of course – first, a phone was generally always a “subservient” device not meant or able to be used as a development bench unto itself. Then – phones started really growing in an age and an environment where proprietary technology reigned supreme, with NDAs and utter secrecy (particularly for GSM modems with their inordinate amount of IP) being an especially prominent fixture in the industries surrounding phones. Even Android’s open-source technology was mostly for manufacturers’ benefit rather than a design advantage for users, as demonstrated by the ever-worsening non-open-source driver situation.

Only a few phones ever bucked these trends, and those that did, developed pretty devoted followings if the hardware was worthwhile. Just look at the Nokia N900 with its hardware capability and alt OS support combo, Pixel phones with their mainline kernel support letting alternative OSes flourish, or old keypad Motorolas with leaked baseband+OS source code. They’re remembered pretty fondly, and it’s because they facilitated hacking, on-device or even off-device.

Hacking starts by probing at a device’s inner workings, deducing how things work, and testing the boundaries, but it doesn’t happen when boundaries are well-protected and hidden away from your eyes. A typical app, even on Android, is surprisingly non-explorable, and unlike with PCs, again, if you want to explore it, you need a whole another device. Does it benefit app developers? For sure. I also have a strong hunch it doesn’t benefit users that we could otherwise see become developers.

Part of it is the need to provide a polished user experience, a respectable standard to have, especially so for producing pocket computers to be used by millions of people at once. However, I’d argue that modern phones are suffocating, and that the lack of transparency is more akin to encasing an already reliable device in epoxy for no reason. A device designed to never ever challenge you, is a device that can’t help you grow, and it’s not really a device you can grow attached to, either.

Of course, complaints are one thing, and actionable suggestions is another.

What Do?

If I were asked how to fix this, I wouldn’t limit myself to opening filesystems back up to a user’s exploration habits, beyond the way they were open even in early Android days. I think modern phones could use a pre-installed Python interpreter, with a healthy amount of graphics libraries, a decent amount of control over the system, snappy well-configured autocomplete, and a library of example scripts you could edit in place; essentially, an Arduino IDE-like environment.

In other words, let people easily program phones to flash the screen every time an SMS from a specific person is received, or start audio recording when the user taps the touchscreen three times as the phone’s locked, or send accelerometer movements into a network socket as fast as the OS can receive them. Then, let them wrap those programs into apps, share apps easily with each other, and, since the trend of fast obsolescence requires regular collectie infusions of cash, transfer them from phone to phone quickly.

By the way, if days of Bluetooth and IrDA transfers evaded you, you missed out. We used to stand next to each other and transfer things from one phone to another, a field previously handled, but nowadays these things are somehow relegated to proprietary technologies like Airdrop. This isn’t a problem for personal computers, in fact, they somehow keep getting better and better at it; just recently, I transferred some movies between two laptops using a Thunderbolt cable during a flight, and somehow, this was one of the few “wow” moments that I’ve had recently with consumer-grade tech.

The idea is pretty simple on its own – if phones are to be personal computers, they should be very easy to program.

The Doohickey Port

What about a bonus suggestion, for hardware customization? USB-C ports are really cool and powerful, but they’re relatively bespoke, and you only ever get one, to be unplugged every time you need to charge or sync. Plus, even if you have OTG, all that 5V step-up action isn’t great for the battery, and neither are USB hardware/firmware stacks.

I like I2C. Do you like I2C? I know most of you do. I enjoy I2C a lot, and I like how it’s decently well standardized, to the point things tend to just work. It’s not as great at as many things as USB can be, but it’s also comparably low-frills, you don’t need a software stack or a hefty bespoke board. For the most part, with I2C, you can just send bytes back and forth. It’s a low-bandwidth yet high-impact bus, with a healthy amount of devices you can attach to it. Also, CPUs tend to have plenty of I2C ports to go around, often leaving a good few to spare.

What else? Keeping up with the times, these days, you can manufacture flex PCBs decently quickly, with stiffener at no extra cost, and for dirt cheap, too. On a physical level, phones tend to come with cases, overwhelmingly so. In a way, there’s suddenly plenty of free space on the back of a phone, for those with the eyes to see, and that’s after accounting for the ever-increasing camera bump, too.

My bonus idea to make phones more customizable at low entry level, would be an I2C accessory port. In effect, a latch-less FFC socket with exposed I2C, and some 3.3V at non-negligible power. Of course, protect all lines electrically, current-limit the 3.3V and make its power switchable. With modern tech, you don’t need to compromise waterproofing, either, and you can add a whole bunch of protection to such a port.

From there, you can get GPIOs, you can get PWM, and so much more. You could have a reasonably simple GPIO expansion, but also a fully-fledged board with DACs and ADCs bolted on, or a servo control board, or an extra display of the kind phone designers like to add once in a generation, only to find it never be used by third-party apps as sales numbers never really reach the point of wider adoption. Experimental chording keyboards, touch surfaces, thermal pixel sensors,

Does it feel like you’ve seen that implemented? Of course, this resembles the PinePhone addon scheme, with FPCs wedged between the back cover and a set of pogo pins. Notably though, this kind of standard is about having compatibility between models and even manufacturers. You also shed a lot of Bluetooth cruft generally required when developing accessories for modern phones. It requires a flex PCB, sure, but so do pogopin schemes, and there’s barely any mechanics compared to a pogopin array. Is it more fragile than a pogopin array? Yes, but it’s fragile addon-side, not as much phone-side, whereas pogopin arrays tend to be the opposite.

A Sketch And A Dream

Of course, this also relies on the aforementioned Python interpreter, and a decent exposed I2C API. If the only way to tinker with yours and others’ accessories is through bespoke intransparent apps you need a whole different device to make (or modify, if you’re lucky), the hackability aspect wanes quick. In essence, what I’m proposing is a phone-contained sandbox, not in a security sense, but in an educational sense. Personal computers have been serving as sandboxes for decades now, and yet, phones could never really fulfill such a niche.

I think one of the big problems with modern phones is that a phone is barely ever a sandbox, all for mostly historic reasons. Now, if that’s the case, we should make it one. If it’s a sandbox, then it can be molded to your needs through hacking and tinkering. If it can be molded to your needs, then it belongs to you in a whole different way. Will this happen? Quite unlikely, though, I do feel like making some prototypes. Instead, it’s about highlighting a significant aspect that contributes to tech alienation, and imagining how we could solve it given enough market buy-in.

hackaday.com/2025/08/11/smartp…

Una falla di sicurezza recentemente individuata nel noto software per la compressione di file 7-Zip ha destato considerevoli timori all’interno della comunità dedicata alla sicurezza informatica. Tutte le versioni di 7-Zip antecedenti alla 25.01 sono interessate da tale vulnerabilità, la quale scaturisce da una gestione non appropriata dei collegamenti simbolici nel corso dell’estrazione dei file.

Si trattaCVE-2025-55188, scoperto e segnalato dal ricercatore di sicurezza Landon il 9 agosto 2025, consente agli aggressori di eseguire scritture arbitrarie di file durante l’estrazione dell’archivio, portando potenzialmente all’esecuzione di codice su sistemi vulnerabili. Quando gli utenti estraggono un archivio creato in modo dannoso contenente link simbolici non sicuri, 7-Zip segue questi link durante l’estrazione, consentendo agli aggressori di scrivere file in posizioni esterne alla directory di estrazione prevista.

La vulnerabilità sfrutta il meccanismo di elaborazione dei link simbolici di 7-Zip. Secondo l’avviso di sicurezza, l’attacco richiede condizioni specifiche per avere successo. Una volta soddisfatte queste condizioni, gli aggressori possono creare archivi dannosi contenenti link simbolici che puntano a file di sistema sensibili. Una volta estratti, 7-Zip segue questi link simbolici, consentendo agli aggressori di sovrascrivere file critici come chiavi SSH, file .bashrc o altre configurazioni di sistema.

Per i sistemi Linux, gli aggressori necessitano che l’obiettivo utilizzi una versione vulnerabile di 7-Zip durante l’estrazione di un formato di archivio che supporti i link simbolici, come file ZIP, TAR, 7Z o RAR. Il processo di sfruttamento è più semplice negli ambienti Linux. Sui sistemi Windows, è necessario soddisfare requisiti aggiuntivi per uno sfruttamento efficace. Il processo di estrazione 7-Zip deve disporre di privilegi elevati o operare in modalità sviluppatore Windows per creare collegamenti simbolici. Questo rende i sistemi Windows meno vulnerabili, ma non immuni all’attacco.

Nonostante abbia ricevuto un punteggio CVSS di 2,7, che lo classifica come di bassa gravità, gli esperti di sicurezza avvertono che l’impatto pratico potrebbe essere molto più significativo. La vulnerabilità consente agli aggressori di ottenere accessi non autorizzati ed eseguire codice prendendo di mira file sensibili che controllano il comportamento del sistema. La vulnerabilità è particolarmente preoccupante perché 7-Zip visualizza i percorsi dei file prima della risoluzione del collegamento simbolico, consentendo agli aggressori di nascondere la vera destinazione delle loro scritture dannose.

La versione 25.01 di 7-Zip, rilasciata il 3 agosto 2025, risolve questa vulnerabilità con una gestione avanzata dei link simbolici. L’aggiornamento include significativi miglioramenti alla sicurezza per impedire la creazione di link simbolici non sicuri durante l’estrazione degli archivi.

L'articolo Nuova falla in 7-Zip: link simbolici trasformano un’estrazione in un hack proviene da il blog della sicurezza informatica.

IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I'm having some serious FOMO about missing out on the Oasis reunion concerts touring the United Kingdom. In honor of that, I give you this banger.

— Everything you need to know about the upcoming AI Impact Summit to be hosted by India early next year.

— Ahead of Donald Trump's meeting with Vladimir Putin on Aug. 15, Russia's state-based media is in a full-court propaganda press.

— Who's who in the recent shake-up in the European Commission's Directorate-General for Communications Networks, Content and Technology.

Let's get started:

digitalpolitics.co/newsletter0…

Sometimes, you build a thing because you need a thing. Sometimes, you do it just to see if you can. This project is in category two: [polymatt] didn’t need to create a floppy disk from scratch-– plenty of old disks still exist– but we’re glad he made the attempt because it makes for a fascinating video that’s embedded below.

Some of you are going to quibble with the terminology [polymatt] uses in this video: first of all, he didn’t begin by creating the universe, so is he really starting “from scratch”? Secondly, the “floppy” format he’s attempting to copy is a 3½” diskette, which does not flop at all. Alas, the vernacular has decided that “stiffy” means something totally different that you ought not to hand a co-worker, and “floppy” is the word in use now.

Choosing newer stiff-walled medium does allow him to practice his CNC skills and make the coolest-looking floppy enclosure we’ve ever seen. (It turns out brushed aluminum is even cooler-looking than the translucent neon ones.) On the other hand, we can’t help but wonder if a lower-density format 5¼” disk might have been an easier hurdle to jump. The diskette that was built does magnetize, but it can’t read or write actual files. We wonder if the older format might have been more forgiving of grain size and composition of his ferrite coating. Even more forgiving still would be to use these techniques to make magnetic tape which is a perfectly viable way to store data.

Instead of storing data, you could make your own cleaning floppy. It’s not like data storage was really the point here, anyway– its not the destination, but the journey. So whatever you call this DIY diskette, please don’t call it a flop.

Thanks to [Anonymous] for the stiff tip! If you want to slip us your tip, rest assured we will grab on and milk it for all it is worth to our readers.

youtube.com/embed/TBiFGhnXsh8?…

hackaday.com/2025/08/11/dont-s…

Running out of filament mid-print is a surefire way to ruin your parts and waste a lot of time. [LayerLab] was sick of having this problem, and so sought to find a proper solution. Unfortunately, between off-the-shelf solutions and homebrew attempts, he was unable to solve the problem to his satisfaction.

[LayerLab] had a simple desire. He wanted his printer to swap to a second spool of filament when the first one runs out, without ruining or otherwise marring the print. It sounds simple, but the reality is more complicated. As an Australian, he couldn’t access anything from InfinityFlow, so he first attempted to use the “auto refill” features included on the Bambu Labs AMS 2. However, it would routinely make filament changes in outside wall areas of a print, leaving unsightly marks and producing poorer quality parts.

His next effort was to use the Wisepro Auto Refill Filament Buffer. It’s a feeder device that takes filament from two spools, and starts feeding the backup spool in to your printer when the primary spool runs out. Unfortunately, [LayerLab] had a cavalcade of issues with the device. It would routinely feed from the secondary spool when there was still primary filament available, jamming the device, and it didn’t come with a proper mounting solution to work with consumer printers. It also had bearings popping out the top of the housing. Attempts to rework the device into a larger twin-spool rig helped somewhat, but ultimately the unreliability of the Wisepro when changing from one spool to another meant it wasn’t fit for purpose. Its feeder motors were also to trigger the filament snag cutters that [LayerLab] had included in his design.

Ultimately, the problem remains unsolved for [LayerLab]. They learned a lot along the way, mostly about what not to do, but they’re still hunting for a viable automatic filament changer solution that suits their needs. Filament sensors help, but can only do so much. If you reckon you know the answer, or a good way forward, share your thoughts in the comments. Video after the break.

youtube.com/embed/zvCZANVXaKw?…

hackaday.com/2025/08/11/the-tr…

Quel partito ha la caratteristica di riuscire a sparire completamente dalla scena per mesi, per anni, tra un'elezione (persa) e l'altra.

O governa, e sappiamo come, o sparisce completamente dalla circolazione.