Defenders don't rest. They wake up every day thinking about how to protect the systems that they are charged to protect. Meanwhile, attackers are also looking for crafty ways to infect a system or break into computer networks. In the end, it's good for everyone if defenders are always one step ahead of the attackers. EvilTokens: A phishing attack that doesn’t steal your password A phishing attack that does not require creating fake login pages or stealing your passwords. I was speechless when I read the article's title and deservedly so when I read how the attackers executed the attack. The following should get you started: EvilTokens is a phishing-as-a-service (PhaaS) kit built to compromise Microsoft 365 accounts by abusing the OAuth 2.0 device authorization grant flow. As attacks that use the kit rely on device code phishing, they sidestep the need for convincing replicas of genuine login pages where the victims would hand over their passwords. Instead, attackers get the victim to complete a legitimate authentication process – including two-factor authentication (2FA) – on a real Microsoft login page. One-Click Microsoft 365 Copilot Flaw Could Have Let Attackers Steal Emails, Files, and MFA Codes The good news is that MSFT mitigated the flaw. What's left for tenant admins is to watch and contain. The interesting thing is how the researchers pulled off the attack. Here is what they did: Researchers at Varonis Threat Labs chained three bugs into a one-click exfiltration path they call SearchLeak. Because the link pointed to a real microsoft.com domain, traditional anti-phishing and URL filtering tools were unlikely to flag it. The entry point is the q parameter in the Copilot Enterprise Search URL. It is meant for a natural-language query, but Copilot reads whatever sits there as instructions, not just a search string. Varonis calls this Parameter-to-Prompt injection. Low-skilled attacker used Claude, Codex to breach 14 companies The barrier to entry into cybercrim

Nothing's next budget phone is the latest victim of RAMageddon. As 9to5Google reports, Nothing co-founder Akis Evangelidis announced in a post on X that a follow-up to the CMF Phone 2 Pro won't be coming this year: We were working on a successor but with memory prices where they are right now, we can't build […]

The Runbook That Lied to Me at 3am The pager went off at 3:14am for a wedged OpenStack Neutron agent. I did what any tired engineer does: I opened the runbook. It told me to restart a service that had been renamed eighteen months earlier, pointed at a Grafana dashboard that 404'd, and assumed a network topology we'd migrated off of two quarters back. The runbook wasn't just unhelpful. It was actively lying to me, and I burned twenty minutes trusting it before I gave up and went to read the source. That's the real problem with documentation. It isn't that we don't write it. It's that the moment we finish writing it, it starts rotting, and the cost of keeping it fresh is high enough that nobody pays it until the document has already betrayed someone at 3am. A runbook your team doesn't trust is worse than no runbook, because no runbook at least forces you to think. This is where AI actually earns its keep in a platform org, and not in the way the marketing decks suggest. AI is not going to own your documentation. It's going to do the tedious first-draft labor — turning a resolved incident, a chunk of shell history, or a deploy diff into a structured skeleton — so a human engineer can spend their scarce attention on the part that matters: verifying the commands, marking what's unproven, and editing the robotic tone out so the team actually reads it. AI drafts. You verify and sign off. That distinction is the whole game. Why "Humanizing" AI Is the Job, Not a Slogan Let me be precise about what I mean by "humanizing AI," because the phrase gets abused. I don't mean making AI sound human to fool a reader. I mean keeping a human in the loop as the editor and owner of record, and doing the unglamorous work of turning a competent-but-soulless machine draft into something a colleague trusts. Two things break trust in AI-drafted docs, and both are fixable by a human pass: Unverified claims stated with confidence. An LLM will happily tell you to run systemctl restart neutron-l3-

Ekehi platform has moved from hand-written HTML/CSS/JS pages to a typed, component-driven React 19 client and a module-based TypeScript Express/Node.js API. 0. Where we started and where we landed Before. A static client built from per-page folders ( landing/ , contributors/ , login/ , signup/ , admin/ ), each shipping its own index.html , a shared styles.css , and vanilla ES module scripts under client/shared/ . The server was an Express API written in plain JavaScript. After. Layer Before After Client Static HTML + CSS + vanilla JS React 19 + Vite 8 + TanStack Router + TypeScript 6 Styling One global styles.css Tailwind CSS 4 with @theme design tokens Data fetch scattered per page TanStack Query over a typed lib/api client Server Express in JavaScript Express + TypeScript, module-per-domain Repo Two loose folders pnpm workspace with shared git hooks Quality gate None ESLint 9, Prettier 3, Husky, commitlint, Vitest The migration ran in two phases on separate branches: **Phase 1 — client rewrite. **Phase 2 — server rewrite. 1. Why this framework? Choice: React 19 , rendered as a client-side SPA through Vite 8 , routed by TanStack Router . TanStack Router was chosen rather than React Router because it gives fully type-safe routes, first-class search-param typing, built-in code-splitting, and file-based route generation that pairs cleanly with Vite. 2. The folder and component structure The client uses a feature-sliced layout: code is grouped by domain, not by technical type. client/src/ ├── components/ │ ├── layout/ navbar.tsx, footer.tsx │ └── ui/ button, input, modal, select, dropdown, ... (design system) ├── config/ env.ts, env-schema.ts, endpoints.ts ├── features/ one folder per domain │ ├── auth/ auth.query.ts, auth.service.ts, auth.types.ts, components/, pages/ │ ├── opportunities/ pages/ │ ├── resources/ pages/ │ ├── submissions/ pages/ │ ├── admin/ pages/ │ └── site/ pages/ (landing, contributors) ├── lib/ │ ├── api/ request.ts, errors.ts, refresh.ts, types.t

YINI Specification RC 6 is now released The YINI configuration format has reached Specification Release Candidate 6 . YINI is a configuration format designed to feel familiar if you like INI-style files, but designed to bring more explicit structure, clarity, useful data types, and predictable parsing rules to real-world configuration needs.. The short version: @yini ^ App name = "Example" version = "1.0.0" debug = false ^^ Server host = "127.0.0.1" port = 8080 ^^ Features enabled = [ "auth", "logging", "metrics", ] YINI tries to sit somewhere between classic INI, JSON, TOML, and YAML: More structured than traditional INI. Less punctuation-heavy than JSON. Indentation-insensitive unlike YAML. Explicit about parsing rules and validation behavior. RC 6 is an important release because it tightens several parts of the language and moves the format closer to a stable 1.0 specification. What changed in RC 6? RC 6 includes a number of syntax and behavior updates. The main theme is the same as before: Make the format clear for humans, but deterministic for parsers. Here are some of the notable updates. Clearer section markers YINI uses section markers to define structure. ^ App name = "MyApp" ^^ Server host = "localhost" ^^^ TLS enabled = true The number of section markers defines the nesting level. This keeps hierarchy visible without relying on indentation. The primary section marker is: ^ YINI also supports alternative section markers, but ^ remains the recommended default for most files and examples. Strict and lenient mode behavior is more clearly defined YINI has two parsing modes: Lenient mode — practical, forgiving, and intended as the default. Strict mode — validation-focused and intended for stricter tooling, CI checks, and production-sensitive configuration. A file can declare its intended mode: @yini strict or: @yini lenient RC 6 clarifies how these declarations should behave when the file is parsed in a different mode. The goal is to avoid silent surprises. If

Every developer who has ever muttered "there is a bug in this" is repeating a word with a surprisingly literal origin. On September 9, 1947, the operators of the Harvard Mark II, an early electromechanical computer, traced a malfunction to its source and found something they did not expect: a moth wedged inside Relay #70. They removed the insect, taped it into the operations logbook, and wrote a now-famous line beside it: "First actual case of bug being found." That page, moth and all, survives today in the collection of the Smithsonian's National Museum of American History. It is one of the best-loved stories in computing, and like most good stories it is a little more complicated than the popular version. Worth getting right, because the discipline it gave us is the same one behind every connected device we build. What actually happened in 1947 The Mark II was a room-sized machine built from relays, switches, and thousands of moving parts. When a moth flew into one of those relays, it physically interfered with the contacts and caused a fault. The technicians who found it had a sense of humor: calling it the "first actual case of bug being found" was a joke precisely because engineers had already been using "bug" for years to describe mysterious faults in machinery. Thomas Edison used the term in his notebooks back in the 1870s. So the 1947 moth did not invent the word "bug." What it did was give the term a perfect, photographable origin story, and it cemented the companion word that really matters: debugging. The act of removing that moth was, quite literally, de-bugging the computer. The Grace Hopper connection The story is almost always told with Grace Hopper at its center, and that deserves a small correction. Hopper, a pioneering computer scientist who later helped develop COBOL, was part of the Mark II team in 1947, but the evidence suggests she did not personally find the moth or write the logbook entry. What she did do was tell the story, brilliantly and o

Modern collaboration needs more than documents and chat messages. Teams need a shared visual space where ideas can be created, organized, and refined together in real time. That's why I built SyncCanvas — an AI-powered collaborative whiteboard that combines real-time multiplayer collaboration, infinite canvas drawing, and AI-assisted brainstorming into one modern workspace. The Problem Most collaboration tools focus on only one aspect of teamwork. Some are great for drawing. Others are excellent for documentation. AI tools often live in separate windows, disconnected from the creative workflow. I wanted a platform where teams could brainstorm visually while AI actively helped generate and organize ideas directly on the canvas. Introducing SyncCanvas SyncCanvas is an infinite multiplayer whiteboard designed for students, developers, teams, and creators. Key features include: Real-time collaboration with live synchronization Infinite canvas with pan and zoom Drawing tools, shapes, text, and sticky notes AI-powered content generation using Gemini Private room sharing Guest mode access PNG export support WiFi Rooms for local collaboration Real-Time Collaboration Collaboration is at the heart of SyncCanvas. Using Yjs and WebSockets, multiple users can work on the same board simultaneously while seeing updates instantly. Users can: View live cursors Track online participants Join private rooms using secure room codes Collaborate anonymously through guest mode This creates a seamless experience similar to working together in the same room. Infinite Canvas Experience The whiteboard is designed to be limitless. Users can: Draw freehand sketches Create rectangles and circles Add text elements Organize ideas with sticky notes Move freely across an infinite workspace Export workspaces as images The canvas is powered by Fabric.js, providing smooth rendering and flexibility for future enhancements. AI-Powered Brainstorming One of the most exciting features is the integration of G

The main idea of a Carousel isn't just about moving a bunch of elements from left to right because there must be a smoothly infinite movement, this can be done by duplicating the element, but wouldn't it be a waste of time and resources to do so. So the best solution would be rather than moving the whole element, we just move each element on a time based manner, all elements will have the animation but each element will have a unique (incremented) index, by which we will delay its start, and if we made this delay negative, we will have a smooth movement without any lagging adding a will-change will make a separate compositing layer to make the animation run on gpu rather than cpu below is a demo by which, you can understand the effect You can reach me (if you had any problems with the effect): X / twitter "where I post a lot!" LinkedIn

A few months ago I was about to buy a flight. The page showed "Only 2 seats left at this price" in red letters. I hesitated, then refreshed the page out of curiosity. The counter said "Only 2 seats left" again. Same number. It had been resetting on every page load the whole time. That's when I started cataloguing every trick I'd seen on shopping sites and built a Chrome extension that flags them automatically, in real time, on any page. This isn't just my opinion — it's documented research In 2019, Princeton and University of Chicago researchers scraped 11,000 shopping sites and found dark patterns on more than 1,250 of them. The FTC has since fined several companies specifically for fake countdown timers and pre-checked subscription boxes. This isn't a grey area anymore — it's a known, studied, and increasingly regulated practice. The extension targets four categories that account for most of what's out there. The four patterns Fake urgency. Countdown timers that reset, "X people are viewing this" badges that never change, "only N left in stock" that's been static for a week. Trap checkboxes. A checkbox for "Yes, sign me up for the newsletter" that's pre-checked and styled to blend into the page so you don't notice it. Confirmshaming. The decline button reads "No thanks, I don't want to save money" instead of just "No thanks." Psychological pricing. Prices ending in .99 or .95 designed to register as a lower price bracket than they are. Why no AI this time My phishing detector used Claude because language and intent are genuinely ambiguous — you need a model that understands context. Dark patterns are different. They're structural. A countdown timer either resets on reload or it doesn't. A checkbox is either pre-checked or it isn't. That's a DOM query, not a judgment call. So this one runs entirely on regex and DOM inspection. No API calls, no latency, no cost per scan, works offline. Sometimes the boring solution is the correct one. Detecting the urgency pattern T

Your runbooks are out of date. I don't know your team, but I'd bet money on it. Most teams write runbooks once, in a panic after an outage, and then never touch them again until the next outage proves them wrong. How runbooks rot Steps reference deprecated tools. The grafana dashboard moved, the CLI command was renamed, the bastion host got retired. Nobody updated the runbook because nobody re-ran it during the calm months. The team that owned the system left. Three of the five engineers who wrote it are gone. The remaining two haven't actually run the runbook in 18 months because the outage type it covers stopped happening. Half-truths from the start. The original author skipped the obvious steps (because they were obvious to them) and the new on-call engineer can't reproduce the recovery. The result: at 2 AM during the actual incident, the runbook sends you down a dead end. Now you're improvising under stress. What working runbooks have in common I've seen exactly two patterns work: 1. Runbooks live with the code. Put them in the repo of the system they document. When the code changes, the runbook PR is part of the same review. Out-of-repo wikis die first because the cognitive distance is too great. 2. Runbooks are reviewed by people who weren't there. Have a junior engineer run through the runbook quarterly on a non-incident day. Every place they get stuck is a real bug in the document. Fix it then. The author will be too close to see the gaps. The three sections that matter A useful runbook has exactly three sections: Symptom : how do I know this is the right runbook? Concrete signals, with example screenshots if visual. First 5 minutes : what to do RIGHT NOW to stop the bleed. Not the root cause investigation, just the triage actions. Investigation : where to look, what queries to run, what to escalate. That's it. Anything else (architecture diagrams, history, philosophy) goes in a separate doc that the runbook links to. The cultural part The hardest part isn't

Dolphins, sharks, turtles, and human workers are all victims of unregulated squid fishing fleets. Another news article . As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered. Blog moderation policy.

What’s the most cliche possible gift you can give a relative? A digital photo frame, displaying a rotating slideshow of family photos. Now Aura has completely refreshed this product space with its gorgeous Aura Ink frame, which uses e-ink to create a display that doesn’t even look digital. Digital frames have always been so popular […]

submitted by /u/stronghup [link] [留言]