I couldn't quite figure out Lemmalog's latest benchmark stats from the README but it sounds cool!
I heard of Scallop, that also uses Datalog for neurosymbolic programming, I wonder where Lemmalog fits with Scallop? I know little about Datalog so sorry if this is a dumb question!
Using local models, usually means generating content on a more private, local device with the weights of the model stored on that device - a local LLM model could have helped write these posts. It only gets easier to self-host increasingly capable models for generation of text, images, video etc. E.g: Prism ML Bonsai have an older 27B text generating LLM model squashed down to a few GB at what they describe as 95% quality, which can run on a phone.
The cause of this is that the cost of creating plausible code contributions has gone down, so PR proposals can multiply, but flaws still threaten project security and LLMs can be confidently wrong. So human review is needed right now to maintain the integrity of the project, but it takes time and costs money. Ladybird's developers, and we as a community, can't easily evaluate "this is what we want" vs. "this is not what we want" without manual review, because we haven't settled upon a reliable representation of the meaning of our code and its side effects that is time-efficient, secure, and meaningfully interpretable at scale.
This is partly due to Ladybird building on low-level system-language primitives that make it harder to identify problems, and while they are porting to Rust it's not fair to say that C++ is single-handedly the cause of this, because regardless of the language, in a complicated interconnected codebase the complexity easily compounds. It's a real shame we don't have the option of a trust-graph filter stop-gap that can filter contributors with a social model of who is trusted for what, purely as a heuristic to reduce the risk of bad contributions (not as solid proof of soundness).
This whole situation shows the way that development has been done isn't nearly as transparent as just having the source code being available.
We haven't been able to say what we want the code to do in a way that can be tested robustly enough to make openly accepting contributions sustainable, and it's unfair to blame the team for that because on top of needing to develop and review their own changes, it's an incredibly difficult problem with only so many hours in the day. I hope we figure out the representation and social trust graph problems, and that people continue to build on their great work.
Bad actors pay good money for vulnerabilities and patient actors are invested in slowly introducing them. Agent loops like Codex or Claude, with Anthropic's Mythos model finding ~271 Firefox 0-days, and helping fix them shows both the problem and the promise.
It's bitter-sweet in a way that Ladybird is great at showing how the incidental complexity of web browsers could be vastly reduced. To protest being gagged, cryptographers made t-shirts with DeCSS DVD or RSA algorithms on them. Alan Kay suggests that t-shirt computing is actually a useful target, and STEPS by his Viewpoints Research Institute managed to really distill some parts of OS-level and desktop publishing software down into minimal, more understandable abstractions that encode the rules of the programs with more appropriate patterns for the problems at hand, that might more plausibly fit on a small wardrobe of t-shirts. Browsers really need this range of t-shirts making.
As a minority browser user (and someone wanting to build on them), I'm excited to see Ladybird get increasingly usable for real browsing, and I am hopeful that in time, the spec representation gaps, and social trust map heuristics are solvable problems that could restore the dream of open-source, or at least stop a trend of closing (with tldraw doing this much earlier, for a less risky but still thorny project).
I got a pocket-sized Bluetooth keyboard (also used for travel around Asia), 195mm x 85mm x 15mm, with a flap - NOT a foldable keyboard, though it does have a cover flap and a kickstand. Sold under a few brands, but the dimensions are quite specific. Mine was sold under a "Doohoeek" brand; "CACOE" is another. It doesn't have a touchpad, though.
Its size reminds me of my Psion Series 5 days many years ago. While it doesn't clamshell-mount my phone, my phone sits on the KB nicely, though it's still two things to carry around, not one (I miss the Psion still). I have bought loads of Bluetooth keyboards. Foldable keyboards have more parts to break and have to be unfolded to use them.
Previously I got the TECHGEAR Active Strike Pro MINI Slim (230mm x 149mm x 6mm), not pocket-sized, but it has a touchpad. The Geyes Foldable "tri-foldable" (223mm x 54mm x 18mm closed, 223mm x 170mm x 6mm open) got a broken hinge.
For comparison:
- Pocket keyboard ("Doohoeek", "CACOE", etc): 195 x 85 x 15 mm. Pocket-sized, flap/kickstand; no touchpad.
- TECHGEAR Active Strike Pro MINI Slim: 230 x 149 x 6 mm. Not pocket-sized; has touchpad.
- Geyes tri-foldable: 223 x 54 x 18 mm closed; 223 x 170 x 6 mm open. Foldable; hinge risk.
I'm not sure that copying a key after unlocking the system counts as a backdoor? If the OS promises to lock access to the key and fails to do so then I can see the logic that people might then call that a backdoor. But it's different from there being a key bypass, or a pre-shared key (or such), which it seems like the article suggests? For the record, I don't use Windows (so glad).
Right, this is a Windows auth bypass that works with Bitlocker enabled; using TPM-only Bitlocker you are vulnerable to _any_ postboot authentication bypass or memory content extraction technique, this is just a particularly stupid / weird auth bypass technique that has been spun really hard by the author and press.
For what it's worth, any OS using only hardware identity to unseal disk encryption is vulnerable to the same class of attack; there are all sorts of ways to misconfigure or exploit Linux FDE setups to enter a recovery shell as well. It's still a huge step above "no disk protection" (especially since it protects against every scenario where the disk is separated from the hardware), but the postboot surface area is enormous and nobody should be considering this class of protection as much more than a speed bump for a serious attacker.
Would ADS-B Exchange heatmap files would be accessible at even DEFCON 2? Which raises the question of what it would show when the data sources are not available.
Yeah, though it's not great marketing. Especially for hiring interpretability researchers. Their own alignment research has reward model interpretability, personality features and so on (see https://alignment.openai.com ).
It just seems like a different department wrote it, which is a shame because I'd love to read about goblin feature vectors and functional emotions.
It's a funny detail to skim, but what's more surprising is how mechanistic interpretability and alignment science have much better tools and research than the goblin blog post suggests, including from OpenAI's own alignment team:
But the "opt-out" will not prevent ecosystem effects caused by the default shutdown of convenient app installs due to the policy. Not even for GrapheneOS users. It's a global policy by a body we never voted for. You can't opt-out of that different world by waiting 24-hours, the ecosystem could have permanent effects. This is coming from a company that doesn't even bother to expose a permission to disable Internet access per app. It's there underneath, but they just ... don't expose the choice.
Is it really going to have ecosystem effects? Surely the small portion of power-users who are bothering to intentionally sideload apps can click a couple of buttons. Or just load via ADB and avoid the entire thing.
The entire point here is to prevent scam actors from using a false sense of urgency to defraud people. That is a serious vulnerability that needs to be addressed somehow, and I think this is a good compromise that doesn't impact people's ability to sideload.
I say this as someone who sideloads apps literally every day.
Will mandatory ID gatekeeping of developers have ecosystem effects? Surely the only question is how much? You may install apps over ADB every day, but APK installing is much more convenient and open-source F-Droid developers currently don't have to do a thing to be "allowed" to ship APKs.
`The entire point here is to prevent scam actors from using a false sense of urgency to defraud people.`
The proposed architecture is a general developer gate, it is not a proportionate response to the problem - it isn't even proposing to gate specific app permissions, it's being able to install the apps from APKs at all under a regime they administer, with users forced to have this change with no prior consent, only opt-out, and distribution limiting work-arounds (that harm reach).
If Android were to ask the user if they wanted to disable installing downloaded apps from developers who haven't shown Google IDs for their own safety, and let end users give informed consent about what self-protection behaviour level they want for their system, at the point of roll-out, or device setup, that would be quite different.
Why should Google be trusted to gate what apps can be easily shared, when stock Android won't even allow users to toggle Internet access per-app? It isn't proportionate compared to other permissions they could mediate, and worse, it's a centralised architecture vulnerable to authoritarian pressure, and afterwards they will be well positioned to lock it down more.
> The entire point here is to prevent scam actors from using a false sense of urgency to defraud people. That is a serious vulnerability that needs to be addressed somehow
Does it, and if it does, does it need to be addressed by an OS vendor creating a mechanism to ban developers for most users? I'm not convinced of the former, and I'm certain the latter is bad. I predict within ten years, we will see this used against something that is not malware.
What do you mean "ban developers for most users"? Most users get their apps through the play store, which will still exist here. Some users sideload apks, which is also a functionality that will still exist.
> we will see this used against something that is not malware.
See what exactly used against something that is not malware? The Play Store already has requirements other than "don't be malware". If you're talking about the sideloading requirements, all of these requirements apply to every app, not just malware.
Recently, both Apple and Google banned apps for reporting immigration raids in the USA from their respective stores. Android users can still trivially download such apps from other sources. After the verification requirement, nothing changes as long as the developer has a permission slip from Google. If they don't, users have a waiting period that could be a critical delay in an emergency like a crackdown by an oppressive government.
Google has stated that it will only withhold such permission from developers who distribute malware. I imagine they'll stick to that promise at first, but long-term I think they won't. Once it's possible for them to impose partial bans on developers, governments have every incentive to pressure them to do it.
I heard of Scallop, that also uses Datalog for neurosymbolic programming, I wonder where Lemmalog fits with Scallop? I know little about Datalog so sorry if this is a dumb question!