vLLM krijgt een endpoint voor getypeerde beslissingen; Android-dialers houden MMI-risico

vLLM heeft een eerste route voor getypeerde beslissingen gemerged, zodat lokale modellen keuzes met kansverdelingen kunnen teruggeven zonder vrije tekst te parsen. Tegelijk beschrijft een Android-onderzoek hoe een kwetsbare dialer via een web-link carriercommando’s kan uitvoeren; de betrokken app heeft een fix voor de volgende release toegezegd, terwijl de platformkant open blijft.

vLLM voegt een eerste structured-decision-endpoint toe

De gemergede vLLM-pullrequest voegt POST /v1/systemone toe. Die route stelt getypeerde vragen over een meegegeven toestand en retourneert per toegestaan antwoord een kansverdeling. Onder de motorkap prefilleert de server de chatprompt en toestand één keer, leest daarna per vraag één token plus logprobs van de antwoordlabels, en kan zo de gedeelde prefixcache benutten.

Dat is praktisch voor lokale triage, routering of een controle vóór een toolcall: een client hoeft niet langer gegenereerde JSON te ontleden als de uitkomst alleen een keuze is. De implementatie heeft bewust nog smalle grenzen. Alleen het vraagtype choice is geregistreerd; velden of vormen zoals depends_on, ask_if en alone worden geweigerd. Ook werkt de huidige next-tokenstrategie niet voor diffusiemodellen, en een niet-ondersteund model krijgt een 501.

Opvallend is dat de code antwoordlabels per vraag kan schudden om labelvoorkeuren niet stilzwijgend als inhoudelijke keuze te verwarren. De PR laat tegelijk zien dat een Qwen3-0.6B-model bij sommige semantische vragen sterk positiegevoelig was. Zie dit endpoint daarom als serving-infrastructuur, niet als bewijs dat een model nu gekalibreerd beslist. Test op eigen gelabelde gevallen, onduidelijke categorieën en foutkosten; gebruik kansscores niet zonder aparte actiedrempel voor onomkeerbare stappen. vLLM-PR met route, tests en beperkingen · Reddit-signaal

Android-dialer kan MMI-commando vanaf een web-link uitvoeren

Securityonderzoeker Karan Saini beschrijft een keten waarbij een app met de gewone Android-permissie CALL_PHONE én een browserbereikbare deeplink een MMI- of USSD-code kan autodialen. Zulke codes zijn geen gewone telefoonnummers: sommige vragen informatie op, andere wijzigen carrierinstellingen. Als voorbeeld demonstreert de auteur dat voorwaardelijke call forwarding bij een kwetsbaar pad na één tik geregistreerd kan worden.

De voorwaarde op Android 14–16 is een dialer die de aangeleverde tel:-invoer zonder bevestiging direct belt. De auteur meldt een live reproductie met ACR Phone/Cube ACR op een Samsung-toestel en carrier-SIM. Dat betekent niet dat elke app met CALL_PHONE kwetsbaar is: een manifestscan vond vooral kandidaten; het feitelijke risico hangt af van de deeplink-afhandeling. De onderzochte app moet bovendien in de demonstratie de dialerrol hebben.

De disclosure bevat ook een zorgwekkende Android-17-observatie: volgens de auteur kan een TelecomUI-doorstuurpad de oorspronkelijke caller identity verliezen, waardoor een app met alleen CALL_PHONE een MMI-code zou laten uitvoeren zonder kwetsbare externe dialer. Dit is uitsluitend op een emulator vastgesteld, dus geen bewijs dat een provider op een fysiek toestel de forwarding ook registreert. Google sloot de platformmelding volgens de auteur als Won’t Fix (Infeasible) voor het VRP en kwalificeerde hardening als toekomstige verbetering; een afzonderlijke Android-17-melding is als duplicaat van een interne issue gesloten.

De ACR-ontwikkelaar zou op 9 oktober een fix naar de volgende release hebben gecommit; de publicatie via Play hangt nog van review af. Voor gebruikers is de veilige, concrete actie beperkt: update dialerapps zodra een patch beschikbaar is, wees terughoudend met CALL_PHONE voor apps die geen telefoonfunctie nodig hebben, en controleer bij een onverwacht doorschakelicoon of -gedrag de instellingen bij provider en toestel. Een factory reset zou volgens de auteur carrier-side forwarding niet zelf opheffen. Volledige technische disclosure en tijdlijn · Lobsters-discussie

REA geeft coding agents gereedschap om software te inspecteren

REA positioneert zich als gereedschapslaag voor een coding agent die programma’s moet begrijpen door ze te inspecteren. De projectsite noemt native binaries en libraries, JavaScript-/Electron-bundels en browser- of runtimeactiviteit als doelen. In de voorbeelden krijgt een agent onder meer gedecompileerde code, instructies, aanroeprelaties of geladen scripts terug en gebruikt die om gedrag te verklaren of een kleine herimplementatie te maken.

Dat is interessanter dan een agent alleen een binary laten samenvatten: de demonstraties koppelen een conclusie aan onderzochte code en een gecontroleerde gedragscheck. Toch blijft het een maker-demo. Correcte reconstructie hangt af van de gebruikte tooling, symbolen, obfuscatie, dynamisch gedrag en de vraag of de agent de bevindingen juist interpreteert. Controleer dus elke securityrelevante conclusie en de licentie- of gebruiksgrenzen van het doelprogramma zelfstandig.

De HN-discussie levert geen onafhankelijk kwaliteitsbewijs. Daar wordt juist betwist of zulke tooling vooral softwarepreservatie en aanpasbaarheid versnelt, of ook laagdrempelige, half-afgewerkte decompilaties oplevert. Voor ontwikkelaars is de nuchtere inzet: gebruik het als onderzoeksassistent met reproduceerbare artefacten en tests, niet als autoriteit over wat een executable doet. REA en analysepaden · HN-discussie

Verder nog

• carrier-explode 2.0 inventariseert providerprofielen: de nieuwe backend ontsluit carrierinstellingen uit iPhone-, Pixel- en Galaxy-firmware als vergelijkbare data. Je kunt onder meer APN, VoLTE, wifi-bellen en 5G per provider en firmwareversie vergelijken; de site biedt ook een API en dagelijkse CC0-dataset. Handig voor diagnose en onderzoek naar verschillen tussen providerbundels, maar het bewijst niet dat een bepaalde instelling de oorzaak is van een concreet verbindingsprobleem. carrier-explode · HN-discussie
• eros experimenteert met samenstelbare Rust-fouttypen: de library modelleert een Result met een unie van mogelijke fouttypen, zodat een functie bijvoorbeeld io::Error en ParseIntError kan opsommen zonder voor elke combinatie een nieuwe enum te schrijven. De interessante eigenschap is dat recover een afgehandeld fouttype uit de retourwaarde verwijdert. Het blijft een crate en ontwerpkeuze, geen Rust-taalfeature; houd semantische fouten lokaal ingekapseld in plaats van zonder context lage-niveaufouten door de hele API te lekken. Uitleg en voorbeelden · Lobsters-discussie