Unless you’ve got an especially small lap, calling the Toshiba Libretto a laptop is a bit of a stretch. The diminutive computers from the mid-1990s had a lot of the usual laptop features, but in an especially compact and portable case that made them a great choice for anyone with an on-the-go lifestyle.

Fast-forward thirty years or so, and the remaining Librettos haven’t fared too well. Many of them have cases that crumble at the slightest touch, which is what led [polymatt] to undertake this meticulous case replacement. The effort started with a complete teardown; luckily, the lower aluminum-alloy shell was in fine shape, but the upper case parts were found to be almost too deteriorated to handle. Still, with a little patience and the judicious application of tape, [polymatt] was able to scan the case pieces on a flatbed scanner and import them into his CAD package. Great tip on the blue-tack for leveling the parts for accurate scanning, by the way.

After multiple rounds of printing and tweaking, [polymatt] had a case good enough to reassemble the Libretto. Unfortunately, the previous owner left an unwanted gift: a BIOS password. Disconnecting the CMOS battery didn’t reset it, but a little research told him that shorting a few pins on the parallel port on the machine’s dock should do the trick. It was a bit involved, requiring the design and subsequent bodging of a PCB to fit into the docking port connector, but in the end he was able to wake up a machine to all its Windows 95 glory. Better get patching.

In a time when laptops were more like lap-crushers, the Libretto was an amazing little machine, and thirty years on, they’re well worth saving from the scrap heap. Hats off to [polymatt] for the effort to save this beauty, and if he needs tips on reading data from any PCMCIA cards that may have come with it, we’ve got him covered.

youtube.com/embed/AdeswJreJ98?…

hackaday.com/2025/03/11/tiny-l…

In the world of programming languages it often feels like being stuck in a Groundhog Day-esque loop through purgatory, as effectively the same problems are being solved over and over, with previous solutions forgotten and there’s always that one jubilant inventor stumbling out of a darkened basement with the One True Solution to everything that plagues this world beset by the Unspeakable Horror that is the C programming language.

As the latest entry to pledge its fealty at the altar of the Church of the Holy Memory Safety, TrapC promises to fix C, while also lambasting Rust for allowing that terrible unsafe keyword. Of course, since this is yet another loop through purgatory, the entire idea that the problem is C and some perceived issue with this nebulous ‘memory safety’ is still a red herring, as pointed out previously.

In other words, it’s time for a fun trip back to the 1970s when many of the same arguments were being rehashed already, before the early 1980s saw the Steelman language requirements condensed by renowned experts into the Ada programming language. As it turns out, memory safety is a miniscule part of a well-written program.

It’s A Trap

Pretty much the entire raison d’être for new programming languages like TrapC, Rust, Zig, and kin is this fixation on ‘memory safety’, with the idea being that the problem with C is that it doesn’t check memory boundaries and allows usage of memory addresses in ways that can lead to Bad Things. Which is not to say that such events aren’t bad, but because they are so obvious, they are also very easy to detect both using static and dynamic analysis tools.

As a ‘proposed C-language extension’, TrapC would add:

• memory-safe pointers.
• constructors & destructors.
• the trap and alias keywords.
• Run-Time Type Information.

It would also remove:

• the goto and union keywords.

The author, Robin Rowe, freely admits to this extension being ‘C++ like’, which takes us right back to 1979 when a then young Danish computer scientist (Bjarne Stroustrup) created a C-language extension cheekily called ‘C++’ to denote it as enhanced C. C++ adds many Simula features, a language which is considered the first Object-Oriented (OO) programming language and is an indirect descendant of ALGOL. These OO features include constructors and destructors. Together with (optional) smart pointers and the bounds-checked strings and containers from the Standard Template Library (STL) C++ is thus memory safe.

So what is the point of removing keywords like goto and union? The former is pretty much the most controversial keyword in the history of programming languages, even though it derives essentially directly from jumps in assembly language. In the Ada programming language you also have the goto keyword, with it often used to provide more flexibility where restrictive language choices would lead to e.g. convoluted loop constructs to the point where some C-isms do not exist in Ada, like the continue keyword.

The union keyword is similarly removed in TrapC, with the justification that both keywords are ‘unsafe’ and ‘widely deprecated’. Which makes one wonder how much real-life C & C++ code has been analyzed to come to this conclusion. In particular in the field of embedded- and driver programming with low-level memory (and register) access the use of union is widely used for the flexibility it offers.

Of course, if you’re doing low-level memory access you’re also free to use whatever pointer offset and type casting you require, together with very unsafe, but efficient, memcpy() and similar operations. There is a reason why C++ doesn’t forbid low-level access without guardrails, as sometimes it’s necessary and you’re expected to know what you’re doing. This freedom in choosing between strict memory safety and the untamed wilds of C is a deliberate design choice in C++. In embedded programming you tend to compile C++ with both RTTI & exceptions disabled as well due to the overhead from them.

Don’t Call It C++

Effectively, TrapC adds RTTI, exceptions (or ‘traps’), OO classes, safe pointers, and similar C++ features to C, which raises the question of why it’s any different, especially since the whitepaper describes TrapC and C++ code usually looking the same as a feature. Here the language seems to regard itself as being a ‘better C++’, mostly in terms of exception handling and templates, using ‘traps’ and ‘castplates’. Curiously there’s not much focus on “resource allocation is initialization” (RAII) that is such a cornerstone of C++.

Meanwhile castplates are advertised as a way to make C containers ‘typesafe’, but unlike C++ templates they are created implicitly using RTTI and one might argue somewhat opaque (C++ template-like) syntax. There are few people who would argue that C++ template code is easy to read. Of note here is that in embedded programming you tend to compile C++ with both RTTI & exceptions disabled due to the overhead from them. The extensive reliance on RTTI in TrapC would seem to preclude such an option.

Circling back on the other added keyword, alias, this is TrapC’s way to providing function overloading, and it works like a C preprocessor #define:
void puts(void* x) alias printf("{}n",x);
Then there is the new trap keyword that’s apparently important enough to be captured in the extension’s name. These are offered as an alternative to C++ exceptions, but the description is rather confusing, other than that it’s supposedly less complicated and does not support cascading exceptions up the stack. Here I do not personally see much value either way, as like so many C++ developers I loathe C++ exceptions with the fire of a thousand Suns and do my utmost to avoid them.

My favorite approach here is found in Ada, which not only cleanly separates functions and procedures, but also requires, during compile time, that any return value from a function is handled, and implements exceptions in a way that is both light-weight and very informative, as I found for example while extensively using the Ada array type in the context of a lock-free ring buffer. During testing there were zero crashes, just the program bailing out with an exception due to a faulty offset into the array and listing the exact location and cause, as in Ada everything is bound-checked by default.

Memory Safety

Much of the safety in TrapC would come from managed pointers, with its author describing TrapC’s memory management as ‘automatic’ in a recent presentation at an ISO C meeting. Pointers are lifetime-managed, but as the whitepaper states, the exact method used is ‘implementation defined’, instead of reference counting as in the C++ specification.

Yet none of this matters in the context of actual security issues. As I noted in 2024, the ‘red herring’ part refers to the real-life security issues that are captured in CVEs and their exploitation. Virtually all of the worst CVEs involve a lack of input validation, which allows users to access data in ‘restricted’ folders and gain access to databases and other resources. None of which involve memory safety in any way or form, and thus the onus lies on preventing logic errors, solid input validation and preventing lazy or inattentive programmers from introducing the next world-famous CVE.

As a long-time C & C++ programmer, I have come to ‘love’ the warts in these languages as well as the lack of guardrails for the freedom they provide. Meanwhile I have learned to write test cases and harnesses to strap my code into for QA sessions, because the best way to validate code is by stressing it. Along the way I have found myself incredibly fond of Ada, as its focus on preventing ambiguity and logic errors is self-evident and regularly keeps me from making inattentive mistakes. Mistakes that in C++ would show up in the next test and/or Valgrind cycle followed by a facepalm moment and recompile, yet somehow programming in Ada doesn’t feel more restrictive than writing in C++.

Thus I’ll keep postulating that the issues with C were already solved in 1983 with the introduction of Ada, and accepting this fact is the only way out of this endless Groundhog Day purgatory.

hackaday.com/2025/03/11/trapc-…

Si sa, il settore sanitario si conferma essere decisamente fuzzy per quanto riguarda l’aspetto della gestione dei dati personali. Soprattutto quando si parla di sicurezza, pressoché ogni istruttoria del Garante Privacy si trova ad affrontare l’affermazione all’interno delle memorie difensive relative a delle “difficoltà organizzative”. Le quali sono più che comprensibili durante il corso dell’emergenza Covid, ma oramai non è che possono fondare una scusa sempiterna, distorcendo il tempo alla pari di un wormhole a comando simile al buco portatile della ACME.

Eppure, il sottotesto drammatico ricorrente è un qui salviamo vite, non c’è tempo per la privacy. Falsa argomentazione, perpetrata per ignoranza o malafede, ma terribilmente suadente. E stavolta rivela una capacità di gestione del tempo pari a quella del Bianconiglio. Gran parte del settore sanitario – pubblico o privato che sia – ha coltivato l’abitudine di porre la protezione dei dati in secondo piano. Anzi: in un piano che forse non può nemmeno ambire al podio.

Si può auspicare che nel caso di interventi sanzionatori da parte del Garante Privacy nel settore pubblico l’attenzione alla responsabilizzazione degli apicali venga rilevata da opportune indagini della magistratura contabile, mentre per il settore privato saranno gli stakeholder a formulare i rilievi del caso.

Se questo porterà, nel tempo, ad una maggiore attenzione agli aspetti della privacy da parte di chi decide, resterà sempre il problema di fondo: una cultura della privacy incompiuta o distorta. In pratica, quella che induce l’utenza dei servizi a sottostimare le conseguenze di un data breach ed è effetto di una narrazione da parte di chi ovviamente ha voluto far passare proprio l’idea che in fondo una violazione dei dati sanitari possa essere un niente di che in quanto non si tratta di segreti di Stato.

I principali artefici di questa narrazione sono però gli stessi soggetti che hanno tutto da guadagnare dall’effetto di una deresponsabilizzazione diffusa, dal momento che il conto di una mancata o pessima gestione della sicurezza sarà pagato per lo più dagli interessati coinvolti. I quali avranno anche meno critiche da porre in caso di illeciti o violazioni, e potranno accettare di buon grado di riqualificare il tutto come disguidi o burocrazie.

Eppure, l’opera di svilire l’autorità di controllo o ridurre privacy e sicurezza come meri adempimenti burocratici ha contribuito ad aumentare la frequenza delle violazioni e ad aggravarne le conseguenze negative.

Cosa succede quando vengono violate le proprie analisi del sangue

Prendiamo infatti il caso di un data breach che ha coinvolto delle analisi del sangue. L’argomento fantoccio impiegato per minimizzare l’accaduto è: che problema c’è se il cybercriminale conosce il mio emocromo?

Peccato però che siano presenti dati personali che:

• identificano l’interessato (nome, cognome, codice fiscale);
• consentono di contattarlo (solitamente e-mail e telefono);
• rivelano informazioni relative allo stato di salute (esito delle analisi);

ma non solo. Infatti, è possibile trarre informazioni dal semplice fatto di aver svolto delle analisi in quella determinata struttura sanitaria e prevedere, ad esempio, che l’interessato stia attendendo una comunicazione da parte della struttura.

Questo è un elemento di valore per un cybercriminale il quale se ne potrà giovare per organizzare campagne mirate di phishing e confidare in una maggiore efficacia delle leve impiegate. L’elemento dell’aspettativa espone infatti l’interessato a ritenere come maggiormente affidabile una comunicazione contraffatta per conto della struttura sanitaria presso cui ha svolto delle analisi e non farsi troppe domande a riguardo

In pratica: quel non essere sorpreso nel ricevere quella comunicazione comporta minori cautele da parte del destinatario. E questo è noto al cybercriminale. Così, la comunicazione sarà impiegata come vettore d’attacco, potendo contare proprio su una maggiore probabilità che degli interessati poco accorti o inconsapevoli – poiché non allertati o anestetizzati dalla narrativa del ma che vuoi che sia – vadano a cliccare un link o un allegato malevolo.

Beninteso, questo è solo uno dei molti esempi possibili perché occorre sempre pensare al peggiore utilizzo dei dati violati da parte di un malintenzionato (*) per essere in grado di adottare le cautele più adeguate ed essere così in grado di mitigare le conseguenze negative di una violazione. Motivo per cui una comunicazione di data breach ai sensi dell’art. 34 GDPR è un adempimento fondamentale.

(*) l’unico limite è la fantasia e la motivazione dell’attaccante. Nulla toglie che questi possa avvalersi dell’indirizzo dell’abitazione, o altrimenti spacciarsi per un operatore sanitario (è sufficiente una ricerca online per avere alcuni nomi utili a tale scopo) che deve dare una comunicazione molto urgente per acquisire facilmente la fiducia di qualche familiare particolarmente preoccupato e farsi aprire ogni porta. O consegnare altri documenti. O chissà cosa. Ricorda nulla il “So cosa hai fatto”?

Solo andando oltre la narrazione di un’anticultura della privacy è però possibile alimentare una maggiore sensibilità diffusa da parte di tutti gli stakeholder coinvolti, primi fra tutti gli interessati i quali dovranno pretendere un approccio responsabile alla protezione dei propri dati personali in ambito sanitario.

Attenzione, però: la consapevolezza rende immuni alle scuse di deresponsabilizzazione.

Anche a quelle che ci siamo raccontati o a cui vorremmo tanto credere.

A ciascuno il suo

Tutto qui? Non proprio. In fondo quando c’è un problema diffuso – e questo è il caso – si può sempre scegliere se essere parte del problema, o altrimenti operarsi per risolverlo. Beninteso: nel caso si opti per la comodità dell’inerzia, si è comunque parte del problema.

Bisogna quindi fare i conti con la realtà dei fatti: se lo stato dell’arte piace, ben vengano attacchi e ogni conseguenza negativa ulteriore. Accettando anche tutte quelle ipotesi in cui sono colpiti o i propri interessi o quelli dei propri cari.

Per coerenza, che lo si dichiari senza problemi a questo punto. In fondo non sono queste le persone che si vantano di non avere niente da nascondere? Che facciano di conseguenza un bel virtue signaling sulla pelle delle vittime di una violazione di sicurezza dicendo che in fondo quel data breach non è niente di che così come non è niente di che l’esporsi a tutti i pericoli che ne derivano.

Chissà se si capirà prima o poi che la privacy riguarda chi non ha nulla da nascondere ma tutto da proteggere.

L'articolo Ma che data breach, mi hanno solo fregato le analisi del sangue! proviene da il blog della sicurezza informatica.