Hugging Face's logo
Wayne Workman's picture

Wayne Workman PRO

wayneworkman2012
1 2 21
PhysiQuanty's profile picture
Ā·
https://wayne.theworkmans.us/

AI & ML interests

LLMs

Recent Activity

reacted to scthornton's post with ā¤ļø about 17 hours ago
SecureCode update: we went back and fact-checked our own security dataset and corrected what didn't hold up. The original claim was "complete incident grounding, every example ties to a documented CVE." An adversarial re-audit found that it was overstated: many CVEs were misattributed, and many "incidents" were representative scenarios carrying invented statistics. So we fixed it. - Grounding: re-verified every reference. Removed 802 misattributed CVEs on the web side, corrected or honestly relabeled the incident narratives, and confirmed the AI/ML conversation CVEs are real (EchoLeak CVE-2025-32711, EmailGPT CVE-2024-5184, and others). - Fix-correctness: reviewed whether each "secure" example actually eliminates the vulnerability. Removed 28 that did not (a "secure" secret scanner whose entropy check always returned zero, an Angular example still using bypassSecurityTrustHtml, and more). - Leakage: re-split so near-duplicates stay on one side. Test contamination went from 11.6% to zero. - Viewer, schema, and metadata: rebuilt as parquet under a shared schema. All three viewers are live. - Models: retrained the whole family on the corrected data so the fix reaches the weights, not just the cards. Now ten open models (3B to 26B), including two new Gemma 4 variants, refreshed locally on a DGX Spark GB10. The paper (arXiv:2512.18542) was revised to match. Counts moved from 2,185 to 2,372 unified (web 1,625 + AI/ML 747). A slightly smaller, fully-checked dataset beats a larger one you have to take on faith. Full writeup and links in the article. Datasets: scthornton/securecode, scthornton/securecode-web, scthornton/securecode-aiml
reacted to NatalieY's post with šŸ”„ 5 days ago
Aiden: a physical AI agent that controls phones over USB HID Most GUI agent work assumes the agent lives inside the device or drives it through a debugging interface. We went the other way. Aiden is a small board that sits outside the host. It captures the screen over HDMI-to-CSI, runs the agent loop on-device, and sends actions back as a standard USB HID device ā€” the host sees a keyboard and a mouse, nothing else. No app install, no root, no ADB, no cloud. Runtime is Go. Frame capture, full-duplex audio with VAD, the agent loop, and HID output all run as independent goroutines. There's no backend ā€” nothing leaves the device, which is the only defensible design when the input is a live feed of someone's phone screen. Open questions we haven't solved: Ā· Action verification ā€” inferring success from a re-read of the screen breaks when loading states lie Ā· Prompt injection ā€” an agent that reads screens reads whatever an attacker puts on them Ā· iOS pointer control requires AssistiveTouch Repo, including the HID gadget config and capture pipeline: github.com/AidenAI-IO/aiden-hardware-demo Wrote up how this differs from cloud-based computer use agents here: https://aidenai.io/blog/mobile-ai-agent-vs-computer-use-agent-whats-the-difference/ Note: current hardware is a dev board, not a finished product.
updated a dataset 10 days ago
wayneworkman2012/ww2-synthetic-corpus
View all activity

Organizations

None yet