WebP-decoder wpd kiest voor Rust met smalle assemblylaag; pi pod isoleert coding agents in eigen VM’s

wpd is een nieuwe, BSD-2-gelicentieerde WebP-decoder in Rust die naast veiligheid ook performance als inzet kiest. pi pod biedt intussen een zelf te hosten laag om Pi-codingagents per sessie te isoleren. Beide zijn interessant, maar vragen nog om een eigen security- en compatibiliteitstoets voordat ze een bestaande productiecomponent vervangen.

wpd wil WebP veiliger én sneller decoderen

Halide Compression publiceert wpd, een Rust-decoder voor lossy en lossless WebP, inclusief animaties, metadata, incrementele decoding en een C-ABI. De aanleiding is herkenbaar: beelddecoders verwerken onbetrouwbare invoer op heel veel plaatsen; de projectpagina verwijst naar het actief misbruikte libwebp-lek CVE-2023-4863.

De makers houden handgeschreven SIMD-assembly bewust apart. Die is volgens hen uit te schakelen; zonder die code blijft slechts gecontroleerde unsafe in de dependency zerocopy over. Dat is een duidelijker aanvalsoppervlak dan een decoder in C, maar geen absoluut bewijs van geheugenveiligheid: assembly en dependencies verdienen nog steeds review.

De prestatiecijfers zijn eigen metingen op een subset van de testset: tegenover een specifieke libwebp-commit claimt wpd 1,19× snellere single-threaded lossy decoding en 2,74× lossless; bij multithreading loopt dat op tot 2,68× en 3,19×. Vooral die parallelle cijfers profiteren ook van parallelle animatie-frameverwerking. Vergelijk daarom vóór vervanging met de eigen afbeeldingen, animaties, CPU’s en foutpaden — en controleer FFI-gedrag als je vanuit C/C++, Python of een andere runtime komt.

De HN-discussie brengt een bruikbaar alternatief naar voren: Wuffs kan als C worden getranspileerd en legt andere veiligheidsbeperkingen op. De wpd-maker antwoordt dat de assembly alleen via veilige wrappers bereikbaar is en dat er guard-page-tests zijn. Dat is inhoudelijke tegenspraak tussen betrokken ontwikkelaars, geen onafhankelijke audit. Projectaankondiging met featurematrix en benchmarks · broncode · HN-discussie

pi pod zet Pi-sessies in containers binnen een eigen VM

pi pod is een vroeg, zelf te hosten project rond de Pi-harness voor coding agents. De projectpagina belooft sandboxing, sessiedeling met rollen en automatisering, met een toekomstige hosted variant. De concreetste technische verduidelijking staat in de HN-discussie: bij self-hosting draaien alle Pi-sessies in een VM die je zelf beheert, en iedere sessie daarbinnen in een eigen container.

Dat is nuttig voor teams die Pi willen gebruiken zonder een agent direct op een ontwikkelmachine te laten werken: de VM vormt een extra grens en containers scheiden sessies onderling. Maar die opzet zegt op zichzelf nog niets over mounts, netwerk-egress, doorgestuurde secrets, image-updates of escape-risico’s. Ook is dit geen Kubernetes-project, ondanks de naam.

Behandel pi pod daarom als een interessante uitvoeringslaag, niet als een kant-en-klare securitygarantie. Begin met wegwerpcredentials, beperkte repository-mounts, een expliciet netwerkbeleid en test of een sessie werkelijk niet bij hostbestanden of andere sessies kan. pi pod: opzet en self-hostingpositie · HN-discussie met VM/containerverduidelijking

Rechter onderdrukt bewijs na Flock-zoekopdracht zonder bevel

Een federale rechter in Oklahoma oordeelde dat een sheriffmedewerker de Fourth Amendment-rechten van een vrouw schond door zonder bevel haar kenteken in de Flock Safety-database op te zoeken. Volgens TechCrunch was de enige zichtbare aanleiding dat het voertuig een Californisch kenteken had. Het daaropvolgende doorzoeken van de auto leverde volgens het verslag drugs op, maar de rechter onderdrukte het na de Flock-zoekopdracht verkregen bewijs.

De uitspraak gaat verder dan dit ene dossier in haar taal over een netwerk dat voertuigen voortdurend vastlegt en de reisgeschiedenis op aanvraag aan opsporing aanbiedt: de rechter noemt dat ongerichte massasurveillance. Toch is de juridische reikwijdte beperkt: dit is volgens de bron geen bindend precedent. Het is dus geen algemeen verbod op automatische kentekenlezers of een vaststaand oordeel over iedere Flock-zoekopdracht.

Voor leveranciers en publieke organisaties is het desondanks een concreet signaal dat databewaring, zoekrechten, doelbinding en bevelvereisten niet pas na de camera-installatie kunnen worden ingevuld. Verslag van de uitspraak · HN-discussie

Harde bestedingslimieten worden relevanter nu agents diensten kunnen aanzetten

Simon Willison pleit voor budgetplafonds die een dienst echt pauzeren of fouten laten teruggeven, in plaats van alleen een waarschuwing te sturen. Zijn concrete aanleiding: coding- en persoonlijke agents maken het eenvoudiger om API-verbruik, opslag en compute zonder veel handwerk op te starten. Hij wijst op een recent AWS-projectlimietpad dat nog beperkt wordt uitgerold en op Googles maandelijkse caps voor specifieke diensten.

Dit is vooral een product- en ontwerpdiscussie, geen bewijs dat AWS of Google al overal een harde cap aanbieden. De eigen AWS-documentatie waarnaar de bron verwijst zou een gepauzeerd project na 90 dagen kunnen verwijderen als de gebruiker niets doet. En een harde grens kan een productieapp op een slecht moment offline halen; in de HN-discussie wordt bovendien genoemd dat verbruiksmetering niet altijd direct is.

De praktische consequentie is daarom niet: zet blind een bedrag op nul. Splits omgevingen en budgetten, definieer welk werk bij overschrijding mag stoppen, meet vertraging in billingdata, en zorg voor alerts vóór de grens. Juist bij agenten horen ook limieten per credential, project, tool en actie naast een financiële grens. Artikel met AWS- en GCP-verwijzingen · HN-discussie

Verder nog

• Rust-derives kunnen binarygrootte ongemerkt verhogen: #[derive(Debug)], Clone en vergelijkbare standaardderives genereren momenteel vaak #[inline]. In een diepe errorhiërarchie kan dat zich volgens een uv-ontwikkelaar opstapelen; een eigen derive-macro met #[inline(never)] bespaarde daar ongeveer 160 KB. Dit is geen algemene regel om derives uit te schakelen — inlining is vaak juist nuttig — maar een reden om expansie en binarygrootte te meten als een Rust-CLI onverwacht groeit. Uitleg en voorbeeld · Lobsters-discussie