Simone Bellavia's Web Page

Apple presented the iPhone Air, the thinnest iPhone ever. This is the only new release from Apple that got my interest during their presentation event.

Its design is interesting: the entire logic board and A19 Pro chip are compacted into the camera bump (which includes both front and rear cameras). This iPhone is all battery and screen. IMHO, it seems like a strategic move for the coming years, for which this iPhone Air will serve as an experiment or a launchpad for ultra-thin devices, or simply as a research and development testbed for similar designs that enable powerful yet ultra-compact technologies.

Remarkable factor, iPhone Air has A19 Pro, which is Apple’s latest SoC. More in detail: it is built on TSMC’s N3P process node, and benefits from a 20% increase in transistor density compared to its predecessor, the N3E node, according to a 2023 IEEE study on semiconductor scaling. The A19 Pro features a six-core CPU with two high-performance cores and four efficiency cores, and 5-core GPU. Each GPU core has its own Neural Accelerators, which Apple claimed allows for MacBook Pro-level performance in an iPhone. On the new iPhone Pro, they are even more powerful. If the M5 chip will get this GPU upgrade… well, NVIDIA should start to feel some pressure.

To summarize: local AI to the Max. Next year, I want local LLMs on my phone.

Yesterday, a lot of npm packages have been compromised with malicious code. Following, a list of affected packages:

• ansi-styles@6.2.2
• debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST)
• chalk@5.6.1
• supports-color@10.2.1
• strip-ansi@7.1.1
• ansi-regex@6.2.1
• wrap-ansi@9.0.1
• color-convert@3.1.1
• color-name@2.0.1
• is-arrayish@0.3.3
• slice-ansi@7.1.1
• color@5.0.1
• color-string@2.1.1
• simple-swizzle@0.2.3
• supports-hyperlinks@4.1.1
• has-ansi@6.0.1
• chalk-template@1.1.1
• backslash@0.2.1

and more, I think. I suggest to read the original post published on aikido.dev[1] and related HN discussion[2], both links are reported below.

All packages appear to contain a piece of code that would be executed on the client of a website, which silently intercepts crypto and web3 activity in the browser, manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user (as shared from Aikido).

You can run grep or rg to check if your codebase has been impacted – thanks to sindresorhus for this suggestion:

rg -u --max-columns=80 _0x112fa8

This one requires ripgrep, but you can do the same with grep (ripgrep its Rust equivalent redesign).

My thoughts about this: dependency hell is real and these are the results. I agree with Mitchell Hashimoto when he says that npm should adopt some strategies to mitigate these risks, such as rejecting all dependencies tha have less than 1k LoC. I mean, let’s just avoid using external packages to determine if an object can act like an array.

Also, I would like to share one insight reported by DDerTyp on HN:

One of the most insidious parts of this malware’s payload, which isn’t getting enough attention, is how it chooses the replacement wallet address. It doesn’t just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker’s address that is visually most similar to the original one. This is a brilliant piece of social engineering baked right into the code. It’s designed to specifically defeat the common security habit of only checking the first and last few characters of an address before confirming a transaction.

Needs a little bit of more investigation, for which I don’t have enough time, but looks interesting.

[1] Original post

[2] Hacker News discussion

I decided to change the template and layout of this site. I often find myself writing short notes very quickly during the day, which don’t always fit the traditional blog post format, since they are very brief. Also, I don’t always have the time to write long posts. For this reason, I modified the template to allow me to publish and share short Notes (like the one you are reading right now). Of course, I will continue to write and publish blog Posts when I have time.

On top of that, kinoroll.com no longer exists: the domain expired and I don’t intend to renew it. I preferred to move it here, onto my personal site! This way I can centralize everything and not have to manage different sites and domains. So the Kinoroll section will show the old kinoroll.com, but from now on I’ll share the links I like, along with some thoughts when possible, in the Link section, creating my own personal blogroll.

I hope my blog is easier to navigate now. I was strongly inspired by Simon Willison.

Yesterday, Fil-C popped up to the top of Hacker News. This time the submission got a fair amount of traction, sparking a lot of interest in the community, including a comment from Andrew Kelley. In fact, I’ve been interested in Fil-C for about a year already: my first submission on Hacker News was eight months ago. So I can say I’ve been actively following the project’s progress, also thanks to the activity of its creator, @filpizlo, on Twitter.

Fil-C is a compiler that implements the C and C++ languages with a memory-safe approach. Recently, Filip has published more documentation about the Garbage Collector and about the capabilities he calls “InvisiCaps”, which are more related to pointer safety.

Well, for me this is kind of a dream. I love the C language, it’s my favorite, but I admit I have some skill issues when it comes to memory management, though not because of the language itself, but rather due to my own code-writing proficiency, which could definitely be better. Recently, I’ve been exploring Rust and Zig precisely for this reason, and I’ve found myself appreciating Zig more than Rust because of its minimalism. Having a memory-safe implementation of C would therefore resolve a lot of the headaches caused by memory management.

Fil-C seems like the sweet spot between academic research and pragmatic work. Beyond the documentation, there’s also a list of programs already ported to Fil-C, showing that sometimes no code changes are required, and when they are, the effort is moderate.

So, the next step for me is to dig deeper into the topic and try it out myself! In the meantime, I thought it would be fair to personally share what Filip is doing, because the project deserves much more attention than it’s currently getting, imo.

Nothing fancy. I just dumped the Divina Commedia into a contiguous u16 slice.

const path = "commedia.txt";
const buf = try tok.tokenizeFile(allocator, path);
defer allocator.free(buf.data);

Running it:

$ zig run src/main.zig -- commedia.txt
tokens: 300682 (expected 300682)
head: { 10, 32, 32, 78, 101, 108, 32, 109, 101, 122 }

Just 300682 u16s waiting for an embedding matrix :)

There is a very interesting law that I think is worth sharing:

I will apply it more often.