2022-08-31.01
Discover more from hrbrmstr's Daily Drop
Wren
One of the best aspects of being a "programming language collector" is that you can spend all your time learning new languages and never get any real work done in any of them!
Yes, that's right; the sinking feeling you just started having is justified as, today, I'm distracting your already short attention spans with yet-another programming language (YAPL?).
The Wren [GH] programming language is:
small: the VM is under 4,000 semicolons of readable and lovingly-commented C.
fast: a smart, single-pass compiler produces tight, efficient byte-code.
class-based: classes and objects are front and center.
concurrent: lightweight fibers are built into the language.
made for scripting: embeddable, no dependencies, a small standard library, and an easy-to-use C API.
Here’s the obligatory “hey there, world” in Wren:
System.print("Hello, World!")I think I concur with Wren's creator that it feels like a mish-mash of Smalltalk in a Lua-sized package with a dash of Erlang and wrapped up in a familiar, modern syntax.
Unlike Lua, Wren has proper classes, and has a concurrency framework they call "fibers". Unlike other languages which hand off the job of running sections of code concurrently (i.e. threading) to the system, Wren's VM manages fibers directly.
You can try Wren out right in your browser, thanks to Emscripten:
The Wren Q&A does a superb job justifying the existence of the language, and more than a few folks have invested time and effort into the Wren ecosystem.
There are hints all over the Wren website that one goal of the language is to usurp Lua's place in the gaming industry (Lua scripts power a ton of games). My gut call is that I doubt such usurpance will take place, but I do find Lua to be a bit "ugh" (and I have to use it more, now, thanks to Quarto), and would love to see it used in place of Lua when it comes to Pandoc filters (I guess there is nothing technically stopping me from submitting a PR and converting all the existing Lua filters to Wren).
Before you decided to dive in, a caveat: Wren does seem very much made for embedding vs general use. Not as many batteries are included as you are likely used to (if you code things), so you will be doing a bit of work to wire up things you take for granted in other language ecosystems, like networking.
If you build something (anything!) with Wren, drop a note in the comments!
MSWasm
Despite my 💙 for WebAssembly (Wasm), it is still hard to fully embrace it due to how insecure it really is.
Oh, wait. You thought Wasm was safe because it runs isolated in various contexts (such as browsers)?
LOL!
While a useful, direct sandbox escape may be nigh impossible to cause, you can do tons of evil within Wasm boxes, since — unless you write safe Wasm code manually — you're likely going to be using an insecure/unsafe source language to compile down to Wasm, which leaves the Wasm box open to attacks that:
write arbitrary memory
overwrite sensitive data, and
trigger unexpected behavior by diverting control flow or manipulating the host environment
If you don't want to take my word for it, then listen to a seriously talented Wasm security researcher:
Wasm doesn't have to be unsafe, and a group of researchers has set out to make what they call "memory-safe Wasm" (MSWasm) in a paper titled, "MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code". The abstract does a fantastic job with the setup:
Most programs compiled to WebAssembly (Wasm) today are written in unsafe languages like C and C++. Unfortunately, memory-unsafe C code remains unsafe when compiled to Wasm -- and attackers can exploit buffer overflows and use-after-frees in Wasm almost as easily as they can on native platforms. Memory-Safe WebAssembly (MSWasm) proposes to extend Wasm with language-level memory-safety abstractions to precisely address this problem. In this paper, we build on the original MSWasm position paper to realize this vision. We give a precise and formal semantics of MSWasm, and prove that well-typed MSWasm programs are, by construction, robustly memory safe. To this end, we develop a novel, language-independent memory-safety property based on colored memory locations and pointers. This property also lets us reason about the security guarantees of a formal C-to-MSWasm compiler -- and prove that it always produces memory-safe programs (and preserves the semantics of safe programs). We use these formal results to then guide several implementations: Two compilers of MSWasm to native code, and a C-to-MSWasm compiler (that extends Clang). Our MSWasm compilers support different enforcement mechanisms, allowing developers to make security-performance trade-offs according to their needs. Our evaluation shows that the overhead of enforcing memory safety in software ranges from 22% (enforcing spatial safety alone) to 198% (enforcing full memory safety) on the PolyBenchC suite. More importantly, MSWasm's design makes it easy to swap between enforcement mechanisms; as fast (especially hardware-based) enforcement techniques become available, MSWasm will be able to take advantage of these advances almost for free.
and the paper itself is a pretty straightforward read.
We'll follow up with MSWasm once the tooling is released. For now, hit up the video and paper to see how we keep making the same safety mistakes repeatedly, despite the daily shouting into the wind on these topics by cranky folks like yours truly.
Tranco
This last section is quick, and could be useful if you like to measure aspects of the internet by poking at it, as I used to do in my former job (and will be doing more of in my new one — we don't just listen passively at GreyNoise!).
Before socially engineering you to install creepy surveillance devices with the same moniker in your abodes, Amazon's first "Alexa" was an internet measuring service, metadata repository, and list of the "top one-million sites". They've stopped and started the service and list distribution a few times, but it's dead as a door-knocker as of the time of this post.
Other contenders came in to fill the void, but — as some researchers noted — there are problems and cautions associated with "top sites" lists:
In order to evaluate the prevalence of security and privacy practices on a representative sample of the Web, researchers rely on website popularity rankings such as the Alexa list. While the validity and representativeness of these rankings are rarely questioned, our findings show the contrary: we show for four main rankings how their inherent properties (similarity, stability, representativeness, responsiveness and benignness) affect their composition and therefore potentially skew the conclusions made in studies. Moreover, we find that it is trivial for an adversary to manipulate the composition of these lists. We are the first to empirically validate that the ranks of domains in each of the lists are easily altered, in the case of Alexa through as little as a single HTTP request. This allows adversaries to manipulate rankings on a large scale and insert malicious domains into whitelists or bend the outcome of research studies to their will. To overcome the limitations of such rankings, we propose improvements to reduce the fluctuations in list composition and guarantee better defenses against manipulation.
Instead of dropping the mic and moving on to bigger and better things, the folks behind the paper started Tranco [GH], which is: "A Research-Oriented Top Sites Ranking Hardened Against Manipulation.”
There's not much more to say that the website doesn't explain succinctly and well. There are multiple sources for the list, the data is free (you can customize it if you sign up for an account), and is used by many researchers to assess the state of various aspects of the internet.
If you decide to give the internet a poke with said list, let us know what you discovered!
FIN
I am still reeling a bit that it is the end of August already. If you take part in capitalism's annual ritual currency sacrifice (a.k.a. holiday shopping), best to get your orders in now, given the looks of the domestic and global supply chains. ☮