DEV Community

The Hard Part of Leaving `request` is the App Built Around It

Prithwiraj Bose — Sun, 01 Nov 2026 20:41:25 +0000

Disclosure: I maintain request-to-axios. This is a migration guide from the perspective of someone maintaining legacy Node.js code, not an independent review of my own package.

When a project uses request, replacing the dependency can look like a one-line change. The hard part usually isn't translating request.get() to axios.get(). It's finding all the assumptions accumulated around the old call: callbacks that expect (error, response, body), stream piping, formData, qs, cookies, default headers, odd redirects, and tests that depend on the response being text unless json is enabled.

A broad rewrite can turn a small security task into a risky application migration. That is why I built a compatibility wrapper around Axios: to make an incremental transition possible for common request patterns, while keeping unsupported behavior visible.

Why the Dependency Deserves Attention

The latest upstream request release is still 2.88.2. The maintainers marked the project deprecated in 2020 and say no new changes are expected. That fact alone does not mean every application is exploitable. The more useful question is what versions your install resolves and whether your code reaches an affected behavior.

On 2026-11-02, I installed request@2.88.2 into a temporary project and ran npm audit. It resolved form-data@2.3.3, qs@6.5.5, tough-cookie@2.5.0, and uuid@3.4.0, alongside the deprecated request package. npm reported five vulnerable package nodes, with multiple advisories applying to some nodes.

A few examples from that graph:

CVE-2023-28155 is an SSRF mitigation bypass in request through 2.88.2 involving cross-protocol redirects. It matters when an application relies on URL or redirect restrictions to protect requests to internal services.
CVE-2025-7783 affects old form-data boundary generation. Exploitation depends on an attacker being able to observe Math.random() outputs and influence multipart content.
CVE-2026-12143 concerns CRLF injection through untrusted multipart field names or filenames in affected form-data versions.
CVE-2023-26136 is a tough-cookie prototype-pollution issue, with a specific cookie-jar configuration precondition.

There are also qs and uuid advisories in the resolved tree. Their practical impact depends on the application's own parse/stringify flow or UUID API use. A dependency audit is a signal to investigate, not proof that a particular endpoint is exploitable.

Why Not Just Translate Every Call to Axios?

A direct rewrite changes more than syntax. Axios returns a promise and a response object with data; request commonly uses a callback and passes the body as a separate argument. The projects may also differ on redirects, streaming, cookie jars, timeout details, form serialization, and error handling. Those differences are where the regression work hides.

For a large legacy codebase, the safer sequence is usually:

Inventory the actual options and helper patterns in use.
Add characterization tests around important request and response behavior.
Replace the transport behind the current import name.
Migrate unsupported edge cases separately, with explicit tests.

For a gradual trial, npm supports an alias:

npm install request@npm:request-to-axios

Existing require('request') statements can continue resolving while the installed implementation comes from the wrapper. A representative callback call looks familiar:

const request = require('request');

request.get({
  url: 'https://api.example.test/items',
  qs: { page: 2 },
  json: true
}, (error, response, body) => {
  if (error) return console.error(error);
  console.log(response.statusCode, body);
});

A Compatibility Layer, Not a Security Guarantee

The wrapper covers common callback/stream usage, method helpers, defaults, query strings, JSON, URL-encoded and multipart forms, immediate Basic/Bearer auth, redirects, a small in-memory cookie jar, TLS settings, and common transport options. It does not implement OAuth/Hawk/AWS/HTTP signing, HAR import, digest retries, multipart/related, or exact legacy redirect semantics. The cookie jar is deliberately limited and does not replace a full browser cookie implementation.

That distinction matters. Migrating off an unmaintained client removes one set of risks; it does not make an application secure by itself. Review redirect destinations, validate user-controlled URLs, keep TLS verification enabled, and run npm audit on the resulting dependency graph. Add tests for the options your service actually uses before deploying the alias.

The package and its current compatibility notes are on npm and GitHub. If a legacy option is important to your migration, check the documented limits first and open an issue with a minimal example.

Giving an AI agent a wallet without giving it your keys

Ahmad Shawar — Sun, 01 Nov 2026 20:41:25 +0000

Agents are starting to pay for things. An agent buying API credits, renting a GPU for an hour or paying for a dataset is no longer a thought experiment, and x402 (HTTP 402 Payment Required with on-chain payment) makes it a normal web request.

That leaves the question of how the agent holds money.

The two bad options

Give the agent a private key. It works until a prompt injection, a bug or a leaked environment file. Then the wallet is empty, and there is nothing between the key and the funds.

Approve every payment by hand. Safe, and it removes the reason to use an agent.

What people actually want is what they already do with a company card: a limit per purchase, a monthly budget, a list of places it works, and a phone call for anything unusual.

Put the limits where the agent can't reach them

The limits have to live somewhere the agent, and the machine it runs on, can't change. A smart contract is a good fit: the rules are checked by every node, and changing them needs the owner's key.

Purser is an ERC-4337 smart account built for this. The owner grants each agent a session key with a policy:

an allow-list of contracts and functions it may call
a cap per payment and a budget per period, per token
a validity window

Inside the policy, the agent pays on its own. Over the limit, the payment becomes an approval request, and it runs only if the owner co-signs. One transaction revokes a key or freezes the whole account.

If the agent's key leaks, the damage is bounded: the rest of the current budget, at allowed places, until you revoke it.

The part that was harder than it looks

ERC-4337 splits an operation into validation and execution, and validation is not allowed to read the clock (ERC-7562), because bundlers have to be able to simulate it reliably. A daily budget is all about the clock.

So the checks are split:

Validation: signature, validity window, allow-list and per-payment cap. A disallowed call fails here, before it costs anything.
Execution: the rolling budget, in executeUserOp, where reading the block time is fine.

Two smaller rules that matter: an owner approval raises the amount but never the scope, so an approved payment still has to be to an allowed place; and a revoke earlier in a bundle still stops a later operation in the same bundle.

Testing money code

Unit tests aren't enough for this. Purser has 41 unit tests through a real EntryPoint, fuzz tests that compare random payment and time sequences against a simple model of the budget, and invariant tests that throw thousands of random calls at the account and check three properties after each one: no spending over budget without approval, no funds moved by a revoked key, no policy change without the owner. Slither runs in CI.

It's still early and not audited, which is why everything below runs on a local chain.

Agents use it through MCP

An MCP server exposes six tools: wallet_status, send_eth, send_token, call_contract, get_request and list_requests. Each payment returns one of three outcomes, written for the model: done with the budget left, waiting for the owner with a request id, or refused with a reason it can act on.

Try it

docker run --rm -it -p 127.0.0.1:8787:8787 ghcr.io/ahmad-codex/purser:demo

Open http://localhost:8787. The container starts a local chain, deploys everything, and plays the agent story while the console updates. Then connect your own agent:

claude mcp add --transport http purser http://localhost:8787/mcp

and ask it to pay the merchant 0.3 ETH.

The roadmap starts with paying x402 endpoints within the budget, a gas budget per key and EIP-7702 support. It's MIT licensed, and there are good first issues open. If you let agents spend money today, I'd like to hear how you limit it.

I Fact-Checked Every Finding an AI Security Reviewer Gave Me. Here's What Held Up.

Amirthavarshini Marimuthu — Sun, 01 Nov 2026 20:40:57 +0000

During my internship at RakFort, one of my tasks was simple to describe and slow to do: run every security check in Secfoo with the Claude agent, and then check whether the AI was actually right.

Not "did the run finish". Not "does the report look good". Is each finding true?

This post is about what I found, and what I'd tell anyone who is starting to use AI for security reviews.

Quick background: what Secfoo is

Secfoo is an open-source tool that turns the AI coding agent you already use (Claude Code, Codex, Gemini CLI, Cursor, GitHub Copilot and others) into a security reviewer.

You point it at your code, pick a check, and it gives the AI clear instructions and a fixed report format. You get back a structured report with findings, severity and recommendations, and everything shows up in a local dashboard.

secfoo run --skill deployment-readiness --agent claude --target .
secfoo serve   # open the dashboard

It has 9 checks, including SAST, threat modeling, secret scanning, dependency triage, deployment readiness and responsible AI compliance.

How I tested

My target was Secfoo's own codebase (a good test, because I could read every file the AI talked about).

For each report I:

Opened every finding
Went to the exact file and line it pointed to
Checked the code as it was on the day of the scan (using the commit from that date, not today's code)
Marked it Confirmed, Partly wrong or Wrong
Checked that the numbers on the dashboard matched the report

Step 3 matters more than I expected. Code changes every day. If you check an old report against today's code, you'll blame the AI for things that were true at the time.

Results

Deployment readiness: 6 of 7 fully correct

#	Severity	Finding	Verdict
F1	High	Local dashboard has no login or CSRF protection	✅ Confirmed (exact lines were right)
F2	High	No security scanning in CI	⚠️ Partly wrong
F3	Medium	Release actions pinned by tag, long-lived tokens	✅ Confirmed
F4	Medium	Uploads saved to disk before the size check	✅ Confirmed
F5	Medium	Docker image runs as root, base image not pinned	✅ Confirmed
F6	Low	No health endpoint	✅ Confirmed
F7	Low	Dependencies have no upper version pins	✅ Confirmed

Responsible AI compliance: 4 of 4 correct

All four findings were accurate, and the overall rating ("Low") made sense for a tool that doesn't make decisions about people.

The interesting one: F2

Most of F2 was right. CI really didn't run any security scanners, and the linter was set to never fail the build.

But the report also said the release workflow "runs on any v* tag push".

It didn't. The workflow had been changed to manual-only five days before the scan. The file even had a comment at the top explaining the change.

So the AI described how the project used to work. My guess is that it matched a very common pattern ("release on tag push") instead of reading the current trigger carefully.

This is exactly the kind of mistake that is easy to miss:

It sounds completely reasonable
It's in a well-formatted report next to six correct findings
It's only wrong in one detail

If I had just skimmed the report, I would have believed it.

Things I tested besides the reports

Bad input. I fed the CLI things a real user might get wrong: a folder that doesn't exist, a file instead of a folder, an unknown skill or agent name, a GitHub repo that doesn't exist. Every one gave a clear error, with no crash and no AI tokens wasted. I found two small issues (a negative --timeout was accepted, and an empty target quietly scanned the current folder) and reported them.

The dashboard. All pages loaded and the finding counts matched the reports, except the home page, which crashed with a 500 error. The cause was a recent change: agents that don't report cost now store "unknown" instead of $0, and the home page added the costs together with a plain sum(), which fails on an empty value. It was a one-line fix, and my PR for it (#31) is now merged.

What I learned

1. AI reviewers are genuinely useful. Most findings were correct, with the right file and line numbers. For coverage and speed, it's a huge help, especially for a small team.

2. "Looks professional" is not the same as "true". The one wrong detail was written just as confidently as the correct ones. Severity labels and neat tables don't make a finding correct.

3. Check against the right version of the code. Use the commit from the scan date. Otherwise you'll mark correct findings as wrong (or the other way round).

4. Keep a human in the loop for anything that matters. If a report is going to someone who will sign it off, every finding should be checked first. It took me a while, but it's much faster than reviewing the code from scratch.

Try it

Secfoo is free and open source (MIT). If you're a student or developer interested in security, try it on your own project and check the findings yourself. That's honestly the best way to learn what AI reviewers are good and bad at.

👉 https://github.com/secfoo-com/secfoo

Feedback, issues and contributions are welcome. I'd love to hear how it does on your code!

This is my second post about Secfoo. The first one was about catching an AI scanner inventing fake vulnerabilities.

security #ai #opensource #testing

CVE-2026-105483 remediation checklist for Node.js teams

kozhevniko — Sun, 01 Nov 2026 20:40:14 +0000

CVE-2026-105483 remediation checklist for Node.js teams

The fastest accurate response to CVE-2026-105483 starts with the runtime version and ends with evidence that the deployed client rejects the wrong certificate identity. The bug affects Node.js 24.x before 24.22.1 and 26.x before 26.12.1. During TLS verification, a fullwidth-digit IPv4 destination could be normalized and resolved as an address while DNS names were checked against the certificate. A trusted certificate with a matching DNS SAN could authenticate an IP endpoint without an IP SAN.

Node.js fixed the issue on October 21, 2026. It is rated High, with CVSS v3.0 7.4 and CWE-295. The checklist below separates the mandatory runtime fix from application hardening and assurance work.

1. Identify the running runtime

List every Node.js process that performs TLS or embeds a runtime. Record the exact version, artifact digest, environment, owner, and deployment time. Check containers, packaged executables, desktop tools, CI utilities, and appliances in addition to web services.

Do not close the inventory on a lockfile alone. Verify the process or the signed package that actually runs. A base-image name and an application dependency can both disagree with the executable serving traffic.

2. Upgrade the affected range

Move 24.x systems to 24.22.1 or later and 26.x systems to 26.12.1 or later. Rebuild images and redistributed packages. For single executable applications, verify the embedded runtime version in the new build.

Replace old workers, sidecars, and long-lived processes. Confirm the fixed runtime is active after rollout and retain the runtime evidence with the release record.

3. Find security-sensitive destinations

Review clients that accept a destination from tenants, users, integrations, configuration APIs, queues, or imported records. Prioritize clients that send credentials, administrative commands, private data, or signed requests.

For each client, record whether the intended destination is a DNS name, an IP address, or both. Then trace normalization and validation to the exact TLS call. A policy that checks one string while the client connects with another is not a complete control.

4. Narrow destination input

Allow approved ASCII DNS names or canonical IP literals. Reject ambiguous fullwidth-digit forms, mixed representations, and unapproved redirects before invoking the TLS client. Require a DNS SAN for a DNS identity and an IP address SAN for an IP endpoint.

Avoid custom checkServerIdentity callbacks that accept a certificate based on a display label, a Common Name, or a substring. If a callback is necessary, preserve the correct SAN class and all standard certificate validation.

This input policy is supporting mitigation. The patched runtime remains mandatory.

5. Review trust anchors

Identify which CAs can issue certificates to the affected clients. Include internal roots, test roots, delegated intermediates, and service-mesh trust bundles. Ask whether any of those authorities can issue an address-like DNS SAN that ships inside a trusted chain.

Limit client trust to the authorities required for its destinations. A broad trust store increases the practical conditions for the vulnerability and complicates incident analysis.

6. Test the identity boundary

Use a private test CA and a local endpoint. Create a certificate with a numeric DNS SAN and no matching IP SAN. Connect with a fullwidth-digit host that resolves to the test address. The fixed runtime should reject the certificate because the endpoint is an IP address.

Add positive controls:

A matching IP SAN should succeed for the IP endpoint.
A normal DNS SAN should succeed for an approved DNS name.
An unapproved destination should fail application policy before TLS.

Run the test in the actual deployable artifact. Keep the fixtures versioned so a certificate change cannot weaken the test silently.

7. Record exposure correctly

At 04:17 +08:00 on November 2, 2026, ZoomEye Search app="Node.js" returned 5,539,674 matches. Filter vul.cve="CVE-2026-105483" returned zero. Exposure is 5,539,674 Node.js product fingerprints, not confirmed vulnerable assets.

Use the external count for population context. Use runtime, destination policy, certificate trust, and business authority for prioritization. Do not describe a fingerprint as a victim.

8. Monitor after the change

Log certificate identity failures, destination policy rejections, runtime versions, and changes to destination configuration. Distinguish a DNS failure, a chain failure, and a SAN mismatch. Alert on the introduction of previously unapproved destination forms or trust anchors.

If evidence indicates that a client reached an unintended endpoint, preserve the configuration and connection records, determine what data crossed the session, and follow the credential-rotation and incident process. The advisory does not state that exploitation has occurred; the organization must reach its own conclusion from its evidence.

9. Close with proof

An affected service is ready when the running artifact reports a fixed Node.js version, the test proves the correct SAN class is enforced, the destination input policy is deployed, and the old process is no longer serving traffic. Save those artifacts with the change record so a later reviewer can distinguish a patched runtime from a clean-looking package manifest.

References

H3 Martial-Arts and TaoMate Workflows: Read the Schedule, Not the Filename

AI-KSK — Sun, 01 Nov 2026 20:32:08 +0000

An eight-step filename is not an eight-step execution trace. Equally, a three-step scheduler can be genuinely configured without proving a particular speedup. These two H3 exports illustrate both distinctions.

The package contains two JSON workflows: a martial-arts two-pass graph with 113 nodes and a TaoMate example collection with 239 nodes. Together they have 396 explicit links, plus named Set/Get relationships in the first file. This is a static walkthrough, not a new inference, audio review or hardware benchmark.

The source title mentions 1080p and nearly one second per frame. Those remain source claims, not results measured for this guide. Export frame rate is not generation throughput.

01 — Resolve named inputs before counting references

The martial-arts graph uses SetNode/GetNode pairs rather than direct visible wires for many inputs. Three image loaders are active: 159, 200 and 203. Their Set nodes publish IMAGE_0, IMAGE_1 and IMAGE_2; the corresponding getters reach the first three reference-image slots of conditioner 136.

Other image providers, all video providers and all source-audio providers are bypassed. Their getters can still be enabled and wired. Counting every visible getter would therefore overstate the active reference set.

Check the compatible frontend's handling of named values and bypassed providers on import. The saved graph does not prove that every optional getter will resolve correctly in every installation.

The prompt takes a similar route: active prompt node 194 feeds concatenation, then the live output of ShowText 297 feeds the named positive value and its getter. Extra prompt node 309 is bypassed. A cached ShowText string or the conditioner's old text is not an independent active prompt source.

The scheduler receives 20, not the eight-step title

PrimitiveInt 300 stores 20. It publishes the named value s, retrieved by node 401 and connected to BasicScheduler's steps input. That overrides the scheduler's saved local value of 10.

The resulting sigma schedule passes through H3SigmaRefiner 361. Its named controls store extra_steps 1, start_at_sigma approximately 0.6, end_at_sigma 0 and cosine spacing. Both sampling stages receive the same refiner output.

Do not turn this into a guessed 20+1 evaluation count: the custom refiner's implementation and sampler execution were not inspected or run. What the graph establishes is a linked 20-step input before transformation, not a verified eight-step run, an 8+8 split or a measured total NFE.

The active Ref2V eight-step LoRA is a separate model selection. Its filename does not override that connected scheduler input. The alternative FL2V eight-step LoRA is bypassed.

Read the model stack as a sequence

The selected base is minimax_h3_hybrid_fl2va_ref2va_b25-49-bf16-v1.01.safetensors, with the selected INT8/ConvRot-named Qwen text encoder, FP16 video VAE and FP32 audio VAE.

After the attention utilities and active Ref2V Turbo selection, Motion Repair is applied model-only at a linked strength of 0.2. The subsequent stack includes spatial-physics at model strength 0.3, wushu-e3 at 0.75, and another Motion Repair application at 0.5. Those final three LoraLoader nodes also store CLIP strength 1.

The two Motion Repair applications should not be silently rewritten as one verified equivalent strength. Their positions and loader types differ. Likewise, attention and low-VRAM node names are not measured evidence of a particular kernel or memory reduction.

The saved active media are images rather than a source motion-video sequence. This is reference conditioning plus model modifications and a prompt, not an explicit pose-map lock or proof of precise martial-arts motion transfer.

The learned-upscale node does not promise a larger raster

The coarse resolution selector requests 4:3, 1 megapixel and alignment to 32. Named width/height links override the conditioner's old 1344×768 values.

The learned latent upscaler is also configured in megapixels mode targeting 1 MP, with alignment 32, CUDA, BF16 and chunking enabled. Its presence alone does not establish 2× enlargement, 1080p or a higher pixel count than the first stage. Inspect actual decoded dimensions.

The duration control is 10 and feeds:

max(5, round(a * 24))
+ (5 - (max(5, round(a * 24)) % 17)) % 17

Arithmetic gives 243 requested frames, overriding the old 124-frame value. At configured 24 fps that is a nominal 10.125 seconds, not a measured output duration.

Two sampling stages, two different first-stage outputs

The first sampler's DENOISED_OUTPUT is split into video and audio latents. Only video passes through the learned upscaler; audio is carried into the concatenated second-stage latent.

The second sampler reuses the same guider, positive conditioning and transformed sigma schedule. There is no separate rebuilt high-resolution conditioner in this graph. Carrying the audio latent forward does not prove that the final audio remains unchanged after another sampling stage.

The first-stage save uses the first sampler's OUTPUT, not the DENOISED_OUTPUT sent toward upscaling. The second save uses the second sampler's OUTPUT. Each is routed into video and audio decoders, so this is not direct source-audio muxing.

Both VHS save nodes use the prefix H3_Ref2VA二采, despite belonging to different stages. Both store 24 fps, H.264, CRF 19 and trim_to_audio false. Identify the stage through connections, not that shared filename prefix. Compatibility of the audiovisual latent/decoder path and actual saved files still requires a test.

02 — Seven TaoMate examples are not seven working I2V runs

The second JSON contains seven repeated branches. The letters below are audit labels, not authored project names or seven separately supplied workflow files.

Branch	Saved state	What needs attention
A	Entire branch bypassed	No active generation or save should be claimed from its stored controls
B	Main branch enabled, 9:16	Full selected LoRA stack with a connected first-frame image
C	Main branch enabled, 9:16	Similar stack, but not automatically a controlled comparison with B
D	Main branch enabled, 16:9	First-frame image loader is bypassed; do not label it assured I2V
E	Mixed enabled/bypassed nodes, 16:9	Save remains enabled while core generation/decoding is bypassed; inspect before queueing
F	Main branch enabled, 3:4	TaoMate and base wushu selections active; optional stack bypassed
G	Main branch enabled, 3:4	Newer wushu-action selection plus reference audio; Bunny selection bypassed

An enabled SaveVideo node is not proof of a functioning upstream generation path. In particular, E needs review rather than being counted as a completed or successful example. Nor does static inspection alone certify that import will fail: verify the actual node/frontend behavior in a working copy.

Three steps are configured, but speed is unmeasured

Enabled main branches B, C, D, F and G use schedulers storing simple, 3 steps and denoise 1, with Euler selection. That three-step setting should not be dismissed merely because it has not been benchmarked.

Their SelfLift controls store CFG 1, transition step 1, low-resolution scale 0.4, rho 0, weights 0.5–1 and the BF16 learned latent upscaler, with fixed seed control. These values do not prove actual intermediate dimensions, total model evaluations or latency. Extra seed-control widgets must not be mechanically zipped into named execution parameters.

TaoMate's filename contains step3000; wushu filenames contain other step-like numbers. Those strings do not set inference steps.

Model strengths come from linked PrimitiveFloat controls. The full B/C stack includes TaoMate 1, wushu 0.75, Combat and camera-motion at 0.35 each, spatial-physics 0.3, Motion Repair 0.2 and Bunny 0.1. D/F keep only TaoMate and the base wushu selection active. G substitutes the newer wushu-action file and leaves Bunny bypassed.

These are different configurations and inputs, not a new matched speed or quality study.

Dimensions and soundtrack still need separate checks

All seven selectors store 1.4 MP and multiple 32, with the aspect ratios shown above. Connected dimensions override old local 1344×768 values. Do not promise fixed 1080p output from those controls.

The linked duration expressions use the same nominal 10-to-243 arithmetic described earlier. CreateVideo stores 24 fps, 8-bit and sRGB controls; actual output dimensions, length and codec selection need inspection.

Only G has a loaded audio connection, and it enters the reference-audio conditioning port. It is not drive_audio, final_audio or a direct soundtrack connection. All CreateVideo audio inputs come from sampled-audio decoders.

That distinction matters for voice or lip-sync requirements. An audio reference does not prove the original waveform is preserved, the same spoken content is reproduced, or the output lips align correctly. Listen to the result rather than treating the input connection as acceptance evidence.

Before publishing results

Resolve the exact model and custom-node versions. Inspect the named routes in the first file and the mixed branch states in the second. Choose intended outputs, check effective prompts and dimensions, and run a small authorized-media test before accepting any claim about motion, identity, texture, audio or speed.

The new first-file copy removes only five historical video-preview fields; the second-file bytes are unchanged. Source originals are preserved. Covers are selected assets, not visually verified test results, and model weights/input media are not supplied here.

The source-provided tutorial is recorded without live verification. Check workflow, model, LoRA, node, image, audio and cover rights separately. No publishing, runtime certification or blanket commercial license is included with this source-based walkthrough.

Getting the workflows

Published by this channel. The graphs are free; weights, LoRAs and input assets are separate and carry their own terms.

Hugging Face: AI-KSK/minimax-h3-martial-taomate-305 — two JSONs, covers, SHA256 manifest. Start here.
ModelScope (魔搭): Sunjian520/minimax-h3-martial-taomate-305
Civitai: 8-step Wushu Motion Control · TaoMate 3-step LoRA
Run without a local GPU: 01 · 02
Tutorial: YouTube · Bilibili

Cifrado de hardware en USB y discos: cómo saber si es real

lu1tr0n — Sun, 01 Nov 2026 20:30:40 +0000

Lenovo vendía una memoria USB con sensor de huella digital anunciada como cifrada. Un desarmado posterior, documentado en un hilo de Reddit, mostró que adentro no había más que una tarjeta microSD genérica: ningún chip criptográfico, ningún motor AES, nada que cifrara un solo byte. El sensor biométrico apenas desbloqueaba una aplicación de Windows; la memoria, leída directo con cualquier lector de tarjetas, entregaba los archivos en texto plano.

El caso no es un bug aislado de un fabricante. Es el síntoma de un mercado entero donde la palabra 'cifrado' aparece en la caja sin que exista una propiedad verificable detrás. Esta nota explica qué hace real al cifrado de hardware, qué estándares lo certifican y cómo comprobarlo en cualquier USB o disco externo antes de confiarle datos sensibles.

TL;DR

El cifrado de hardware real exige un chip AES dedicado que cifra los datos antes de que lleguen a la memoria flash.- Un sensor de huella digital que solo desbloquea una app de Windows no cifra nada: la memoria sigue legible en cualquier lector de tarjetas.- FIPS 140-2 o FIPS 140-3 validados en el registro CMVP de NIST son la única prueba verificable de un módulo criptográfico real.- TCG Opal define cómo un SSD autocifrado protege la clave de los datos sin exponerla al sistema operativo.- Comandos como hdparm -I y sedutil-cli --scan revelan si un disco soporta y tiene activo el cifrado por hardware.

¿Qué es el cifrado de hardware?

El cifrado de hardware es la técnica en la que un chip dedicado dentro del controlador de un disco o memoria USB cifra y descifra cada byte con AES antes de escribirlo o leerlo de la memoria flash, sin que el sistema operativo ni ningún programa intervengan en el proceso ni tengan acceso directo a la clave.

La diferencia con el cifrado por software (BitLocker en modo estándar, VeraCrypt, LUKS) está en la ubicación de la clave y del cómputo. En el cifrado por software, el sistema operativo carga la clave en la RAM y usa el procesador principal para cifrar cada bloque. En una unidad autocifrada real, la clave vive dentro del controlador, y ni un volcado de memoria del equipo la expone.

Un sensor de huella digital, por sí solo, no define nada sobre dónde ocurre el cifrado. Puede ser la llave de un cifrado legítimo, como en una unidad certificada, o puede ser apenas el gatillo de una ventana de inicio de sesión de una app, como en el caso de Lenovo. La huella identifica a la persona, pero no dice nada sobre qué le pasa a los datos después.

Por qué importa

El riesgo no es solo perder un archivo. Una empresa que compra 500 memorias USB 'cifradas' para su equipo de ventas y confía en esa palabra está exponiendo datos de clientes bajo una falsa sensación de cumplimiento normativo. Si el dispositivo se pierde y en realidad nunca cifró nada, cualquier marco regulatorio que exima de notificación a equipos cifrados deja de aplicar, y la empresa queda expuesta a una notificación de brecha que creía evitada.

El sensor de huella no es una medida de seguridad, sino una cerradura decorativa sobre una memoria sin ninguna protección real, cuando el fabricante nunca implementó cifrado de hardware genuino.

Esto no es exclusivo de pendrives baratos. En el pasado, investigaciones académicas sobre SSD comerciales que anunciaban cifrado por hardware hallaron implementaciones defectuosas que permitían evadir la clave sin conocer la contraseña, lo que llevó a Microsoft a dejar de confiar por defecto en el cifrado por hardware reportado por el propio disco para proteger volúmenes con BitLocker. El problema de fondo es siempre el mismo: una afirmación sin verificación independiente.

El problema se repite fuera de los USB de bajo costo: discos externos, SSD portátiles y hasta algunos NAS domésticos usan la palabra 'cifrado' en el empaque sin publicar jamás un estándar, un algoritmo verificable o un número de certificación. La única forma de saber si hay algo real detrás es preguntar por el estándar, no por el adjetivo.

Cómo funciona por dentro

Una unidad autocifrada (SED, por self-encrypting drive) separa dos claves. La Media Encryption Key (MEK) es la que realmente cifra cada bloque de datos con AES, casi siempre en modo XTS. Esa clave se genera una sola vez, dentro del chip, y nunca sale de ahí.

La segunda clave es la Key Encryption Key (KEK), derivada del PIN, la contraseña o, en dispositivos biométricos bien diseñados, de un secreto que el sensor de huella libera tras verificar la identidad. La KEK no cifra los datos: cifra a la MEK, que queda guardada en una zona reservada del disco. Sin la KEK correcta, la MEK sigue ahí, pero inutilizable.

Esta separación es la que permite el borrado criptográfico instantáneo: descartar la MEK, sin tocar un solo bit de los datos reales, vuelve ilegible todo el contenido en milisegundos, porque ya no existe ninguna clave capaz de descifrarlo. Es el mecanismo detrás de funciones como 'borrado seguro' en SSD empresariales, y la razón por la que un disco de varios terabytes puede darse de baja de forma segura en segundos.
El estándar TCG Opal, publicado por Trusted Computing Group, define cómo un SSD autocifrado gestiona su clave sin exponerla al sistema operativo.
El estándar que define cómo deben comportarse estas piezas en un SSD o HDD es TCG Opal, publicado por el Trusted Computing Group. Las memorias USB no siguen necesariamente Opal, pensado originalmente para SATA y NVMe, pero las serias documentan un esquema equivalente: un controlador con motor AES, una KEK derivada del PIN o la huella, y una MEK que nunca cruza el bus USB en claro.

flowchart TD
    A["Huella digital del usuario"] --> B{"Que desbloquea el sensor?"}
    B -->|"Solo una app de Windows"| C["La app muestra los archivos"]
    C --> D[("Memoria flash sin cifrar")]
    B -->|"Deriva la clave del controlador"| E["Chip AES del controlador"]
    E --> F[("Memoria flash cifrada con AES-XTS")]

La memoria de Lenovo no tenía nada de esto. No había MEK, no había KEK, no había motor AES. Había una tarjeta microSD estándar, del tipo que se vende suelta en cualquier tienda, detrás de un lector de huellas conectado únicamente a la lógica de la aplicación de escritorio.

Cómo verificar en la práctica

Antes de confiar en la etiqueta de un USB o disco externo, hay tres comprobaciones concretas que se pueden hacer sin desarmar nada.

1. Revisar el feature set ATA Security con hdparm

En Linux, instalá hdparm (sudo apt install hdparm en Debian o Ubuntu, sudo dnf install hdparm en Fedora) y consultá el bloque de seguridad del disco:

sudo hdparm -I /dev/sdb

Un disco con el feature set ATA Security activo muestra algo como esto en la salida:

Security: 
    Master password revision code = 65534
        supported
        enabled
    not locked
        frozen
    not expired: security count
        supported: enhanced erase
    2min for SECURITY ERASE UNIT.

Si el bloque dice 'not supported' o directamente no aparece, el disco no implementa el feature set ATA Security. Eso es normal en la mayoría de memorias USB simples y no es, por sí solo, prueba de fraude, pero combinado con la ausencia de cualquier otra documentación técnica es la primera señal de alerta.

2. Confirmar TCG Opal con sedutil-cli

Para SSD y unidades autocifradas que afirman cumplir TCG Opal, la Drive Trust Alliance mantiene sedutil-cli, una herramienta de línea de comandos que no viene empaquetada en todos los repositorios, así que lo más seguro es compilarla desde su repositorio oficial en GitHub o instalar el paquete si tu distribución lo ofrece. El escaneo básico es:

sudo sedutil-cli --scan

El comando lista cada disco conectado junto a un indicador del nivel de soporte Opal detectado, por ejemplo 2 para Opal 2.0. Un guion en esa columna significa que el disco no implementa Opal, sin importar lo que diga el empaque.

3. Verificar el certificado FIPS en el CMVP de NIST

Cuando el fabricante anuncia FIPS 140-2 o FIPS 140-3, tiene que existir un número de certificado público. Buscalo en el Cryptographic Module Validation Program de NIST: ahí aparece el nombre del módulo, el fabricante y el nivel de seguridad validado, del 1 al 4. Si el modelo exacto no figura en esa lista, el 'FIPS' de la caja es solo marketing, aunque el algoritmo interno sea AES real.

sequenceDiagram
    participant U as Usuario
    participant H as Host
    participant C as Controlador del disco
    U->>H: ingresa PIN o huella
    H->>C: envia credencial de autenticacion
    C->>C: deriva la Key Encryption Key
    C->>C: desbloquea la Media Encryption Key
    C-->>H: datos descifrados en tiempo real
    Note over C: la clave nunca sale del chip

En Windows, manage-bde -status C: muestra si BitLocker usa cifrado por hardware (eDrive) o cae a software porque el disco no lo soporta. En macOS, diskutil info no distingue hardware de software en discos externos de terceros, así que para esos equipos conviene apoyarse directamente en el certificado FIPS publicado por el fabricante.

Casos de uso reales

Las empresas que manejan datos regulados (salud, finanzas, gobierno, defensa) suelen exigir por contrato que cualquier memoria USB corporativa tenga FIPS 140-2 nivel 3 validado. Líneas como Apricorn Aegis Secure Key, iStorage datAshur PRO o Kingston IronKey publican su número de certificado y su nivel exacto en su documentación, precisamente porque sus clientes lo van a verificar antes de firmar la compra.

⚠️ Ojo: El borrado criptográfico de una unidad autocifrada destruye la clave en milisegundos y vuelve ilegibles todos los datos, pero esa garantía solo existe si el cifrado era real desde el diseño: en una memoria como la de Lenovo no hay clave que borrar.

En el sector salud, perder un USB con historiales clínicos sin cifrado real puede disparar la obligación de notificar a cada paciente afectado. Algunos marcos regulatorios reducen esa obligación cuando el dispositivo tenía cifrado certificado, así que el certificado no es un detalle burocrático: es lo que decide si hay que mandar miles de cartas de notificación.

Fuera del mundo corporativo, el caso de uso más simple es el de cualquier persona que viaja con datos sensibles (contratos, historiales médicos propios, claves de acceso) en una memoria USB. Para ese uso, una unidad autocifrada certificada justifica su sobreprecio frente a un pendrive genérico con un sticker de 'AES-256' sin respaldo.

Errores comunes y buenas prácticas

Confundir el algoritmo con la implementación es el error más común. AES-256 es un algoritmo público y gratuito: cualquiera puede escribir 'AES-256' en una caja sin que eso implique que el chip adentro lo ejecuta, ni que la clave esté protegida, ni que el sensor biométrico tenga algo que ver con el cifrado.

Asumir que todo lo que trae lector de huella es más seguro que una contraseña es otro error. Un sensor biométrico barato sin motor criptográfico es, en la práctica, más débil que una contraseña larga: no hay forma de 'cambiar' una huella comprometida, y en el caso de Lenovo ni siquiera estaba protegiendo nada.

El feature set ATA Security, más viejo que TCG Opal, tiene un historial conocido de contraseñas maestras de fábrica que algunos fabricantes nunca rotaron ni documentaron para rotar, lo que en ciertos modelos antiguos permitía desbloquear el disco sin el PIN del usuario legítimo. Por eso las implementaciones modernas migraron a TCG Opal, que no depende de una contraseña maestra universal del fabricante.

Comunidades de reparación y desarmado, como la que destapó el caso Lenovo en Reddit, terminan siendo el control de calidad real de este mercado: revisar un video o hilo de desarmado del modelo exacto antes de comprar vale más que leer la descripción del producto.

Buena práctica: pedí siempre el número de certificado FIPS antes de comprar, no después. Un fabricante serio lo tiene impreso en la hoja de datos del producto, no escondido en un correo de soporte.

Comparativa con alternativas

No todo lo que se vende como 'cifrado' ocupa el mismo nivel de confianza. La tabla siguiente ordena las tres categorías reales que existen en el mercado de USB y discos externos.
Tipo de 'cifrado'Qué protege en realidadCómo verificarloCuándo confiarApp o sensor biométrico sin chip criptográfico (caso Lenovo)Nada: solo bloquea una interfaz, la memoria flash queda legible con cualquier lectorVideo o reporte de desarmado del modelo exactoNunca, para datos sensiblesCifrado por hardware sin certificación independienteCifra los bytes en el controlador, pero sin auditoría externa de la implementaciónhdparm -I o documentación técnica del fabricanteUso personal de bajo riesgoUnidad autocifrada FIPS 140-2 o 140-3 validadaCifrado AES-XTS auditado por un laboratorio acreditado y registrado en NIST CMVPNúmero de certificado contra el buscador de CMVPEmpresas, salud, finanzas, gobiernoEl programa CMVP de NIST es el único registro público donde se valida un módulo criptográfico bajo FIPS 140-2 o FIPS 140-3.

flowchart TD
    A["Dispositivo anuncia cifrado"] --> B{"Tiene numero de certificado FIPS verificable?"}
    B -->|"Si, aparece en CMVP"| C["Cifrado de hardware validado"]
    B -->|"No, o no lo publica"| D{"Soporta TCG Opal o ATA Security?"}
    D -->|"Si, confirmado con hdparm o sedutil-cli"| E["Cifrado por hardware probable, sin certificar"]
    D -->|"No, solo una app o sensor biometrico"| F["Cifrado de marketing: no confiar"]

La fila del medio es la más común y la más ambigua: muchos pendrives decentes de marca caen ahí. No son una estafa como el caso Lenovo, pero tampoco ofrecen la garantía auditada de un módulo FIPS. Y hay un escenario donde ni la fila de arriba conviene: si necesitás sincronizar un mismo contenedor cifrado entre Windows, macOS y Linux sin depender de un sensor físico que puede fallar o de un PIN de recuperación con intentos limitados, un contenedor de software como VeraCrypt sigue siendo más práctico que una unidad autocifrada atada a un único lector biométrico.

Profundizando

AES-XTS, el modo que usan casi todas las unidades autocifradas, fue diseñado específicamente para discos: cifra cada sector de forma independiente para que un cambio de un solo bit en el texto plano no afecte a los sectores vecinos, algo necesario cuando el almacenamiento se accede en bloques fijos y no como un flujo continuo.

💭 Clave: La separación entre MEK y KEK es lo que vuelve posible cambiar el PIN de una unidad autocifrada en segundos: solo se re-cifra la MEK, unos pocos bytes, nunca los datos completos, sin importar cuántos terabytes tenga el disco.

Los niveles de seguridad FIPS 140-2 y 140-3, del 1 al 4, no miden el algoritmo, sino la implementación física: resistencia a manipulación del hardware, borrado de claves ante intentos de apertura, calidad del generador de números aleatorios. Un módulo de nivel 3, el más común en memorias USB corporativas, exige evidencia física de sabotaje y mecanismos de respuesta ante intrusión.

El propio Trusted Computing Group documenta Opal 2.0 con estados explícitos para la unidad: Locked, Unlocked, Frozen, y un contador de intentos (Try Limit) que, al agotarse, puede bloquear el disco hasta un reinicio o forzar un borrado criptográfico, según cómo lo configure el administrador. Nada de esto existe en un dispositivo que, como el de Lenovo, nunca implementó el estándar.

Una limitación real que vale aclarar: incluso un cifrado de hardware perfectamente implementado no protege nada si el disco queda desbloqueado y conectado. El cifrado defiende contra la pérdida o el robo del dispositivo apagado, no contra alguien que lo use mientras está desbloqueado. Eso es trabajo de otras capas de seguridad, no del chip AES.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: conectá un disco externo o USB que tengas a mano, corré sudo hdparm -I /dev/sdX y revisá si el bloque Security aparece como supported antes de confiar en la palabra 'cifrado' de cualquier caja.

Preguntas frecuentes

¿El cifrado de hardware de un USB es siempre real si dice AES-256 en la caja?

No. AES-256 describe un algoritmo público, no una certificación. Lo único que confirma una implementación real y auditada es un número de certificado FIPS 140-2 o FIPS 140-3 verificable en el CMVP de NIST.

¿Qué diferencia hay entre una unidad autocifrada y el cifrado por software como VeraCrypt?

VeraCrypt y LUKS cifran con el procesador del equipo y guardan la clave en la RAM del sistema mientras el volumen está montado. Una unidad autocifrada hace el trabajo dentro del propio controlador del disco, y la clave nunca llega a la memoria RAM del equipo anfitrión.

¿Cómo compruebo si mi disco soporta TCG Opal?

Con sedutil-cli --scan desde Linux, o preguntando directamente al fabricante por el nivel de Opal soportado, por ejemplo Opal 2.0. La ausencia de una respuesta técnica suele ser la respuesta.

¿Un sensor de huella digital reemplaza a una contraseña fuerte?

Solo si ese sensor efectivamente deriva o libera la Key Encryption Key del controlador. Si apenas desbloquea una aplicación, como en el caso de Lenovo, no reemplaza nada: la memoria sigue expuesta a cualquiera que la lea directo.

¿Qué significa que un módulo criptográfico tenga validación FIPS de nivel 3?

Significa que, además del algoritmo correcto, el hardware fue evaluado por resistencia física a manipulación y por borrar sus claves ante un intento de apertura detectado. Es el nivel que suelen exigir los contratos corporativos y gubernamentales.

¿Qué pasó exactamente con el USB con huella digital de Lenovo?

Según el desarmado documentado en Reddit, el dispositivo anunciado como cifrado resultó ser una tarjeta microSD genérica sin ningún componente criptográfico, con un lector de huella que solo controlaba el acceso a una aplicación de escritorio.

Referencias

Reddit r/technology: hilo donde se documenta el desarmado del USB con huella digital de Lenovo.- NIST, Cryptographic Module Validation Program (CMVP): registro oficial donde se verifica un número de certificado FIPS 140-2 o 140-3.- Wikipedia, Self-encrypting drive: explicación técnica del funcionamiento de las unidades autocifradas (SED).- Trusted Computing Group: organización que publica el estándar TCG Opal usado en discos autocifrados.- hdparm: utilidad de Linux usada para consultar las características de seguridad ATA de un disco.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Let your LLM say I don't know instead of guessing

Conor Bronsdon — Sun, 01 Nov 2026 20:30:07 +0000

Your user asks a factual question. The model returns a polished paragraph. Nothing in the stack threw an error. That is exactly when you are most exposed. A language model generates the most plausible next words, not the most true ones, so a wrong answer can look identical to a right one. That mechanism is what people call AI hallucination: same token prediction, missing or weak facts, fluent fiction at the end.

Dan Klein, co-founder and CTO of Scaled Cognition, put the internals this way on Chain of Thought: we label outputs after the fact, but the model never splits “truth” from “guess” on its own.

If they're right, we call them truth. And if they're wrong, we call them hallucination. But the model does not internally distinguish between those.

Dan Klein, co-founder and CTO of Scaled Cognition

I’d stop treating confidence in the UI as a proxy for correctness. Treat every fluent sentence as a claim you still owe evidence for.

Why does fluency hide the errors you care about?

Obvious mistakes get caught in QA. Klein’s audit story from enterprise work is worse: when his team audits enterprise systems, he says, the real hallucination rate is often about five times what the customer has noticed, because the rest are fluent enough to pass. His examples are a refund policy that is real and plausible but not yours, or yours but for a customer with a different status.

Looks right. It looks right and is right are not the same. It is very hard to detect hallucinations when they are packaged up sufficiently fluently.

Dan Klein, co-founder and CTO of Scaled Cognition

Chip Huyen made the data angle plain on Chain of Thought ep 5: missing or wrong context pushes the model toward invention.

Models are more likely to hallucinate when it does not have access to the necessary and correct information to answer questions.

Chip Huyen, author of AI Engineering

So the design job is to give the model the facts at answer time, allow silence when facts are missing, and verify what still matters. A smarter model does not remove that work.

What breaks when you only punish wrong guesses?

Pre-training shows the model fluent text, not labeled false statements. Rare facts (like a specific birthday) do not repeat as patterns, so the model still produces something that sounds like an answer. Benchmarks make the incentive worse: “I don’t know” often scores like a wrong answer, while a random guess sometimes hits. OpenAI’s 2025 write-up on why language models hallucinate argues for penalizing confident errors more than honest uncertainty. Anthropic’s interpretability work on Claude describes a default to decline on unrecognized entities, with a “known entity” signal that can flip that off and invite a guess anyway.

For your app, that means instructions that forbid uncertainty fight the same scoreboards that trained the model to guess. If your eval sheet marks abstain as a miss, you are training your team to ship guessers.

How do you ground answers and still leave an out?

Grounding means building the reply from material you put in context at question time, ideally with citations per claim. That cuts invented detail because the model has less room to freestyle. It does not guarantee truth: sources can be stale, retrieval can miss the doc, and the model can still stretch past what the sources say. Many production issues that look like “model bugs” are retrieval or document problems first.

General models also carry a knowledge cutoff: training frozen at a date, then released later. Ask about anything newer and you get “I don’t know” or a plausible guess. The standard fix is the same as grounding: fetch current or private text into the context window before generation (RAG, search, or both).

My default pattern for factual features:

Retrieve candidate passages for the question.
If nothing passes a relevance threshold, return abstain (or escalate to a human). Do not ask the model to “try anyway.”
If you have passages, instruct answer-only-from-these, cite span or doc id per claim.
Run a faithfulness check on answers that can move money, policy, or compliance.

Step 4 is where AI evaluation and reliability work pays off: separate counts for answered, abstained, answered_supported and answered_unsupported.

What does an abstain-and-ground sketch look like?

Label this as illustration, not production code from any guest or vendor.

# Sketch: abstain if retrieval is weak; answer only from chunks

MIN_SCORE = 0.42  # tune on your corpus

def answer(user_question: str, retrieve, llm, faithfulness_check):
    chunks = retrieve(user_question, top_k=8)
    best = max((c.score for c in chunks), default=0.0)
    if best < MIN_SCORE:
        return {"status": "abstain", "message": "No trusted source found."}

    prompt = {
        "instruction": (
            "Answer using ONLY the sources. "
            "If they do not support an answer, reply ABSTAIN."
        ),
        "sources": [c.text for c in chunks],
        "question": user_question,
    }
    draft = llm.complete(prompt)
    if "ABSTAIN" in draft:
        return {"status": "abstain", "message": "Model declined."}

    if not faithfulness_check(draft, chunks):
        return {"status": "abstain", "message": "Failed source check."}

    return {"status": "ok", "text": draft, "sources": chunks}

The abstain path is a first-class HTTP response, not a thrown exception buried in logs. Users should see “we don’t know” when you mean it.

Checklist

Decide where a wrong fluent answer is costly; tighten grounding and checks there first.
Retrieve before generate; abstain when retrieval is empty or weak instead of prompting harder.
Tell the model abstaining is allowed; score abstain better than a confident wrong answer in evals.
Check high-stakes outputs against supplied sources (faithfulness), not vibes.
Remember fluent output is plausible text until your sources and checks say otherwise.

The longer explainer, with the episode clips, is on Chain of Thought. It draws on this episode.

Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.

Drafted with AI assistance from the episode transcripts.

Best WordPress Multilingual Plugins for 2027: Workflow, Cost and Control

Mahdi JabinPour — Sun, 01 Nov 2026 20:29:30 +0000

Originally published on LumoWP.

Choosing a multilingual plugin is easy when the demo contains one paragraph and a language switcher. The difficult part comes later: a translated product goes out of stock, an Elementor template changes, a subscription renews, or an editor rewrites a sentence that already has five translations.

That is where this comparison starts. The best WordPress multilingual plugin for your site is the one whose workflow still makes sense after the first translation.

About this 2027 guide
Researched on October 31, 2026 for people planning a 2027 website. Features and prices below describe the documentation available on that date, not unreleased 2027 versions. This is a documented workflow comparison, not a five-plugin performance benchmark. LumoWP sells a WPML AI translation add-on; that relationship is disclosed where it appears.

The shortlist: which plugin fits which job?

There is no useful universal winner. Start with the part of your website that would be hardest to translate and maintain—not the easiest page in the demo.

Plugin	A strong starting point for	Main working model	The decision you must accept
WPML	Editorial teams, complex WordPress content and multilingual WooCommerce	Connected language versions with translation jobs and integrations	Configure the right components and test your actual builder widgets
Polylang	A manually maintained bilingual site or a WordPress-native editorial workflow	Language assignments and relationships between content	Budget separately for advanced workflows and WooCommerce
TranslatePress	Owners who want to translate while looking at the front end	Translate rendered strings through a visual editor	Plan for SEO features, source-text changes and dynamic states
Weglot	Teams that prefer a managed translation service and a quick operational start	WordPress integration with a hosted translation service	Ongoing service cost, language limits and total translated-word allowance
MultilingualPress	Separate regional sites with their own teams and store settings	One language site per WordPress Multisite network site	Network administration is part of the project

These are recommendations by use case, not measured rankings. A simple two-language brochure site and a store with subscriptions, custom product fields and regional pricing should not receive the same recommendation.

First understand what the plugin actually translates

Think of a multilingual website as four connected systems: content storage, translation production, public URLs, and ongoing maintenance. A plugin may make the second part easy while asking you to do more work in the fourth.

With a content-based workflow, an editor works with related language versions. With a rendered-string workflow, the translation layer works with text that appears on the page. With a multisite workflow, each language has its own site. A hosted service adds another question: what happens to the public translated experience if the subscription stops?

None of these models is automatically faster, more professional or better for Google. They create different operational responsibilities. Your checkout, search results, logged-in dashboard and reusable templates are more informative test cases than a static About page.

Conceptual illustration, not a software screenshot.

WPML: a strong candidate for structured content and complex stores

WPML is worth shortlisting when translation is an ongoing editorial process rather than a one-time conversion. Its Multilingual CMS and Agency plans include the advanced translation workflow and integrations needed for more involved sites. The cheaper Blog plan is a different scope, not simply the same product with fewer site licenses. Check the current WPML plan comparison before choosing it for a builder-heavy site.

For Elementor, start with the official integration instructions. Translate reusable templates as well as pages. A translated page can still display a source-language header if the header comes from a separate template. Custom widgets can also need field registration; a page-builder compatibility badge does not tell you whether every third-party widget in your project exposes its fields correctly.

My decision rule: shortlist WPML when you need a coordinated translation workflow across posts, products, taxonomies and templates. Before committing, include your most unusual widget and your most complicated product in the pilot.

For an existing site, do not buy another translation tool just because an update is missing. Our WPML and Elementor troubleshooting guide explains how to separate a missing field, a template issue and an outdated translation before translating again.

What to check before paying for automatic translation

The plugin license and translation usage are different cost items. WPML's current automatic translation pricing documentation describes AI-word billing and different handling of edits depending on the workflow. Do not copy a calculation from an older article about credits and assume it still applies to your selected engine and account.

Ask a practical question: if your team updates fifty product descriptions every week, what gets sent again, what is reused, and where can you inspect the charge? Calculate that before enabling a large automatic job.

Conceptual illustration, not a software screenshot.

Polylang: attractive when editors want direct control

Polylang is a sensible starting point for a site with a manageable number of languages and editors who can maintain the translated content. Its free version covers core multilingual content, while Pro adds workflow features such as duplication and expanded slug handling. WooCommerce has its own paid integration. The official feature matrix makes these boundaries clearer than a generic “free versus paid” label.

An easy setup mistake is leaving existing content without a language assignment. Follow the setup wizard guidance and check existing posts, pages and navigation after assigning the default language.

My decision rule: choose Polylang for editorial control, not because somebody promises that fewer features must mean better performance. Compare the complete stack you actually need, including the WooCommerce add-on where relevant.

The Elementor and automatic-translation detail that matters

Polylang Pro offers DeepL translation using your own API connection, but its current pricing matrix explicitly says this machine-translation feature is not compatible with Elementor. That is a limitation of this specific workflow, not a claim that no Polylang-and-Elementor site can exist.

If your brief says “automatically translate all Elementor pages,” resolve that requirement before choosing a plan. For a closer comparison of the editorial models, see Polylang versus WPML.

Conceptual illustration, not a software screenshot.

TranslatePress: useful when translation starts with what visitors see

TranslatePress takes a visual approach: work with the front end and translate the text in context. This can be easier for an owner who recognizes a button on the page but does not know which plugin generated it.

The important technical detail is persistence. Its automatic translation documentation explains that generated translations are stored in the database rather than requested from the translation API on every page view. That does not mean the complete site has zero translation-related runtime cost; it means repeated API generation is not the normal delivery model.

My decision rule: shortlist it when visual editing suits your team and your important front-end states can be reproduced for translation and review. Test a validation error, a cart update and an account page—not only visible text on the initial page load.

Source edits need a maintenance plan

TranslatePress's FAQ describes the distinction between an original string and its translation. Changing the source can create a new string to translate, while the old translation remains stored. That is different from an editor thinking “I changed one paragraph in this translated post.”

Try this before rollout: translate a page, change its heading and one repeated call-to-action in the source, then inspect the translated page. Write down what needs review. This small experiment tells your editorial team more than a screenshot of the translation sidebar.

Conceptual illustration, not a software screenshot.

Weglot: a service decision as much as a plugin decision

Weglot is appealing when the team wants to manage translation through a hosted service. The trade-off is a recurring service relationship with word and language allowances.

One pricing detail deserves attention: the Weglot pricing page describes a total translated-word allowance across the project, not a fresh allowance that resets every month. If a simplified 20,000-word source corpus is translated into three languages, use roughly 60,000 translated words as an initial planning estimate, then verify the actual counted content. Navigation, dynamic text and the service's counting rules can change the result.

My decision rule: shortlist Weglot when the ongoing service model is acceptable and the team values that workflow. Compare the plan required for your whole translated corpus, not just the starting price.

Cancellation is an operational requirement

Weglot's cancellation documentation says translated content stops appearing when the relevant paid service is cancelled or paused. Treat exit planning as part of selection. Ask what you can export, what URLs you would need to preserve, and how you would replace the translated delivery layer before cancelling.

This is not the same question as whether you retain a copy of translated text. Owning an export and continuing to serve the same multilingual website are two different things.

Conceptual illustration, not a software screenshot.

MultilingualPress: when markets need separate sites

MultilingualPress uses WordPress Multisite, with each language on its own site. Its documentation presents independent content and configuration as central to the design.

That makes it interesting when your German and French operations need more independence than translated paragraphs: different teams, different catalogs or different site settings. It also means backups, network permissions, deployment and integrations must be planned for a network.

My decision rule: shortlist it when separate sites are an intentional business requirement. Do not convert a simple brochure site to Multisite merely because a comparison labels the architecture “enterprise.”

A useful question for the agency is: who owns the relationship between the sites after launch? If nobody will maintain cross-language links and shared requirements, architectural independence can turn into editorial drift.

What about GTranslate and Loco Translate?

GTranslate belongs in the discussion, but distinguish its free translation widget from its paid multilingual SEO offering. The WordPress.org listing lists indexable language URLs and related SEO features in the paid offering. A visitor being able to read a translated page does not, by itself, establish that Google can crawl a dedicated translated URL.

Loco Translate addresses a different task: translating theme and plugin localization strings. It can help with interface wording, but it is not a substitute for a full architecture of translated posts, language URLs and editorial workflows. Do not compare these products as though they solve an identical problem.

Budget comparison: price the complete workflow

The following are public entry points observed on October 31, 2026. They are not guaranteed 2027 prices. Taxes, promotions, renewal terms, usage and the required number of sites can change the final cost.

Product	Observed starting point relevant to this guide	What to budget beyond the headline
WPML	Multilingual CMS: €99/year	Translation usage and the appropriate integration stack
Polylang	Free core; Pro from €99/year; WooCommerce add-on from €99/year	Required combination of products and a translation provider if used
TranslatePress	Personal: €99/year	The plan with the SEO, team and provider features you need; additional usage
Weglot	Starter: €15/month or €150/year, 10,000 translated words and one translated language	Growth of the total translated corpus and additional languages
MultilingualPress	Documentation advertises a starting €149/year for two languages	Multisite hosting, maintenance and implementation

Verify these on WPML, Polylang, TranslatePress, Weglot and MultilingualPress before purchasing.

My planning formula is simple: license or subscription + translation generation + human review + maintenance + eventual migration. Human review is not a rounding error. A cheap first translation can become expensive if your editors repeatedly repair terminology or cannot see which content changed.

What user reviews reveal—and what they do not

I use public reviews and support threads to identify questions worth testing, not to calculate failure rates. People who post reviews are not a random sample, and a difficult support case does not establish that every installation has that problem.

Evidence reviewed	What it tells a buyer	What it does not prove
TranslatePress's review listing includes praise for ease of use and support	The visual workflow and assistance matter to users	That your dynamic checkout or custom widget will work unchanged
A negative TranslatePress review objects to paid slug translation; the developer explains the broader premium feature set	Confirm the free/paid boundary before building around a feature	That a price complaint is a technical defect
A WPML support thread reports partially translated Elementor pages and escalated investigation	Include custom widgets and complete templates in your pilot	A universal WPML bug or a known final root cause

Sources: TranslatePress user reviews, the slug-pricing review and developer reply, and the WPML Elementor support discussion. The visible support discussion does not establish a final resolution; I am not presenting one.

A 2026 community discussion on Reddit shows the disagreement clearly: some participants value WPML integration coverage, while others report performance or maintenance frustrations on larger builds. These are self-reported experiences with different stacks, not controlled comparisons. The useful takeaway is to include your custom fields, forms and representative database size in the pilot.

When you read a review, look for the plugin version, the actual requirement, the surrounding stack and the support response. “Slow” without a reproducible page, cache state and measurement is a reason to investigate, not a benchmark to copy into a buying guide.

A pilot that can reject the wrong plugin before launch

An editorial checklist illustration, not a benchmark or a plugin screenshot.

Do not begin by translating a thousand URLs. On a staging copy, choose one target language and a small representative set. The goal is to expose the expensive failure modes early.

Test	Action	Acceptance condition
Normal article	Translate headings, a link and an image caption	Correct language, working links and preserved layout
Shared template	Translate the header, footer and reusable call-to-action	Every page using the template displays the intended version
Source update	Change a sentence after translation	Editors can identify and review the affected translation
Dynamic interface	Trigger form errors, cart changes and account states	Important messages remain understandable in the selected language
Variable product	Choose a variation, add to cart and check out in a sandbox	Product identity, stock, price and emails behave correctly
Search and taxonomy	Open a category and search for translated content	Results and navigation follow the chosen language policy
Cache	Compare cold and warm responses in each language	No language leakage; performance is measured under equivalent conditions
Exit rehearsal	Review exports and restore a backup on staging	The team knows what is portable and what needs rebuilding

Record the versions, theme, builder, host, cache settings and exact URLs. For timing, compare repeated measurements of the same page and separate cached delivery from uncached generation. Do not declare a plugin faster because one test hit a cache and the other did not.

For WooCommerce, language and currency are separate dimensions. A French translation does not necessarily mean euros, and a German-speaking customer may live outside Germany. Test your chosen policy explicitly; our WPML currency-by-language guide covers that distinction.

The SEO checks that matter more than the plugin badge

Google recommends separate URLs for different language versions and warns that locale-adaptive behavior can prevent complete crawling. A language switcher should provide a usable route to the translated page; do not make automatic redirection the only route. See Google's multilingual and multi-regional site guidance.

Check the actual page output: an indexable URL, the intended canonical, matching language content and valid alternate-language relationships. Google's hreflang documentation requires reciprocal references, including the page itself, for the relevant alternate sets. A checkbox in a plugin is not a substitute for inspecting the output.

Do not translate into twenty languages just because the software permits it. Start where you can support the reader or customer, review critical wording and maintain updates. Our multilingual SEO and crawl-budget guide explains the maintenance and discovery implications in more depth.

A practical stop condition
If the team cannot review checkout wording, maintain translated source updates or explain which URLs should be indexed, pause the rollout. Adding languages multiplies that unfinished work; it does not solve it.

Where Lumo's WPML AI add-on fits

Disclosure: LumoWP develops and sells this add-on. It is not a sixth replacement for the multilingual systems above. Choose the multilingual architecture first; then decide how to generate and review translations inside that workflow.

The Lumo AI Translation Addon for WPML is relevant if you already use WPML and want an AI-provider workflow with your own API credentials. Its product interface includes separate bulk tools for content types, including Elementor templates. That can address a practical maintenance need, but it does not remove the need to check field compatibility, provider charges and translation quality.

Lumo supplies the translation engine while WPML manages the languages. Select the image to see the product and requirements.

Start with a small batch and a terminology list. Review names, units, product promises, buttons and links before expanding. No provider name or add-on guarantees a translation sounds natural in every language, and no plugin guarantees search rankings.

My recommendation for a 2027 project

For a complex single-site WordPress or WooCommerce build, start by evaluating WPML against the real integration requirements. For a modest site with hands-on editors, evaluate Polylang. For a team that prefers visual translation, test TranslatePress. For managed-service convenience, calculate Weglot's full corpus cost and exit plan. For independent market sites, consider MultilingualPress with a deliberate Multisite operating plan.

The final choice should be the plugin that passes your smallest realistic pilot with the least ongoing friction. You do not need the longest feature list. You need a translated website your team can still keep accurate six months after launch.

Post-Graduation Work Permit (PGWP) Eligibility in 2026: What International Students in Canada Need to Know

Titanium Law Professional Corporation — Sun, 01 Nov 2026 20:29:18 +0000

Post-Graduation Work Permit (PGWP) Eligibility in 2026: What International Students in Canada Need to Know

If you're an international student studying in Canada, the Post-Graduation Work Permit (PGWP) can be your bridge from the classroom to the Canadian workforce. But the rules changed significantly in late 2024 and mid-2025, and many students are unsure whether they still qualify.

This guide walks you through the current eligibility requirements, timing rules, and what you need to prepare before you apply.

What Is a PGWP?

A Post-Graduation Work Permit is an open work permit that lets international graduates work for almost any employer in Canada after completing their studies. Unlike employer-specific work permits, a PGWP gives you the flexibility to change jobs, work part-time or full-time, and gain the Canadian work experience that can strengthen your permanent residence applications through Express Entry or other programs.

The duration of a PGWP depends on how long your study program was:

Programs shorter than 2 years: You may receive a work permit up to the length of your program.
Programs 2 years or longer: You're typically eligible for a 3-year PGWP.
Master's programs (8 months or longer): You qualify for a 3-year PGWP.
Multiple eligible programs: If you completed more than one eligible program (each at least 8 months long), IRCC may combine them to determine your PGWP length.

Your passport validity also limits the maximum duration. If your passport expires in 2 years, your PGWP won't exceed 2 years even if your program length would otherwise qualify you for 3.

Current Eligibility Requirements

To qualify for a PGWP, you must meet all of the following criteria:

1. Study at an Eligible Institution

Your program must be at a Designated Learning Institution (DLI) that is on IRCC's PGWP-eligible list. Not all DLIs qualify. You can check the official DLI list to confirm your school's status.

2. Program Length

Your program must be at least 8 months (or 900 hours) long. Programs shorter than this do not qualify for a PGWP.

3. Full-Time Student Status

You must have maintained full-time student status during each academic session of your program. There are limited exceptions, such as authorized leaves of absence or reduced course loads due to documented circumstances, but these are assessed case by case.

4. Complete Your Program

You must have completed all program requirements and received written confirmation (such as a final transcript or an official letter) from your institution that you've finished. You don't need to wait for your diploma or convocation ceremony, but you do need proof of completion.

5. Apply Within 180 Days

This is critical: you must submit your PGWP application within 180 days of completing your program. The clock starts when you receive written confirmation that you've met all requirements, not when you attend your graduation ceremony.

If your study permit expires before you apply for the PGWP, you may need to restore your status first, which requires an additional fee and a separate application.

Recent Changes: November 2024 and June 2025 Updates

Language Proficiency Requirement (November 1, 2024)

As of November 1, 2024, most new PGWP applicants must provide proof of language proficiency in English or French. The minimum level depends on your field of study:

University graduates (bachelor's, master's, doctoral): Canadian Language Benchmark (CLB) 7 in all four abilities (reading, writing, listening, speaking).
College and other program graduates: CLB 5 in all four abilities.

Accepted language tests include IELTS General Training, CELPIP General, TEF Canada, and TCF Canada. Your test results must be less than 2 years old when you apply.

Who is exempt? If you applied for your study permit before November 1, 2024, you are generally exempt from the language requirement. You also may be exempt if your program was in French or if you completed secondary school in Canada.

Field of Study Requirement (June 25, 2025)

As of June 25, 2025, PGWP eligibility is tied to specific fields of study classified under the Classification of Instructional Programs (CIP) codes. IRCC added 119 eligible fields and removed 178 fields from the list.

What this means for you:

If you applied for your study permit on or after June 25, 2025, your program's CIP code must be on the current eligible list.
If you applied for your study permit before June 25, 2025, you remain eligible for a PGWP as long as your field of study was on the eligible list at the time you applied, even if it has since been removed.

This transition rule protects students who made decisions based on the rules in effect when they applied. You can find your program's CIP code on your acceptance letter or by contacting your institution's international student office.

Eligible fields generally align with occupations in demand in Canada, including STEM (science, technology, engineering, math), healthcare, skilled trades, and certain business and service sectors.

How to Apply

Step 1: Gather Your Documents

Before you start your application, collect the following:

Proof of completion: Official transcript or letter from your institution confirming you've met all program requirements.
Final transcript or report card showing your grades.
Passport: Must be valid for the duration of the PGWP you're requesting.
Language test results (if required): Less than 2 years old, meeting the CLB level for your program.
Proof of field of study (if required): Documentation showing your program's CIP code.
Digital photo: Meeting IRCC specifications.
Payment: $255 for the PGWP plus $85 for biometrics (if you haven't given biometrics in the last 10 years). You must pay both the open work permit holder fee and the work permit processing fee.

Step 2: Apply Online

Most PGWP applications are submitted through the IRCC online portal. You'll need to create an account, complete the application forms, upload your documents, and pay the fees.

Step 3: Maintain Your Status

If your study permit is still valid when you apply, you can remain in Canada under maintained status (formerly implied status) while IRCC processes your application. During this time, you may be eligible to work full-time off-campus if you've already completed your program and meet certain conditions.

If your study permit has expired or will expire soon, you may need to apply to restore your status as a student before applying for the PGWP, or apply for a visitor record to remain in Canada legally while your PGWP is processed.

Step 4: Wait for Processing

Processing times vary. Check the IRCC processing times page for current estimates. You can work in Canada once your PGWP is approved, not while it's pending (unless you meet specific conditions under maintained status).

Common Mistakes to Avoid

Missing the 180-day deadline. This is the most common reason students lose PGWP eligibility. Mark your completion date and count forward 180 days.
Applying before you've actually completed your program. You need written confirmation that you've met all requirements, not just that you've finished your last exam.
Not checking your DLI's PGWP eligibility. Some private career colleges or specific programs don't qualify.
Forgetting the language test. If you're subject to the November 2024 rules, your application will be refused without approved test results.
Letting your study permit expire. If it expires before you apply for the PGWP, you'll need to restore your status first, which costs more and takes longer.
Not verifying your CIP code. If you applied for your study permit on or after June 25, 2025, your field of study must be eligible. Check your acceptance letter or contact your school.

What Happens After You Get Your PGWP?

Once approved, your PGWP allows you to work for almost any employer in Canada. This work experience can help you qualify for permanent residence through:

Canadian Experience Class (CEC): Part of the Express Entry system, requiring at least 1 year of skilled work experience in Canada.
Provincial Nominee Programs (PNPs): Many provinces have streams for international graduates with Canadian work experience.
Other federal programs: Such as the Federal Skilled Worker Program or Federal Skilled Trades Program.

Your PGWP is a valuable opportunity to build your Canadian career and strengthen your immigration profile. Use it wisely.

Need Help With Your PGWP Application?

The PGWP rules are detailed, and mistakes can be costly. If you're unsure whether you qualify, need help gathering documents, or want to understand your options after graduation, consider speaking with a regulated immigration consultant or lawyer.

Titanium Law Professional Corporation assists international students and graduates in Brampton and across Ontario with study permits, PGWP applications, and pathways to permanent residence.

Website: https://titaniumlaw.ca/
Phone: +1 778-683-8110
Consultation: https://titaniumlaw.ca/contact.html

Disclaimer: This article provides general information about Post-Graduation Work Permit eligibility and application requirements based on IRCC policies in effect as of 2026. It is not legal advice and does not cover every situation. Immigration rules change frequently, and your individual circumstances may affect your eligibility. Always verify current requirements on the official IRCC website at https://www.canada.ca/en/immigration-refugees-citizenship.html or consult a regulated immigration professional before applying.

Sources:

Voice AI for Beginners: Everything You Need to Know

VoiceDeveloper — Sun, 01 Nov 2026 20:27:49 +0000

Voice AI for Beginners: Everything You Need to Know

Voice AI is turning “talking to your computer” from a sci‑fi dream into a mainstream developer toolkit. Whether you’re building a smart assistant, a game NPC, or a podcast generator, the core building blocks—speech recognition, synthesis, and cloning—are now accessible through open APIs and cloud services. In this post we’ll walk through the fundamentals, show you how to hit the ground running with a quick Python/TTS demo, and explain why ElevenLabs is a top‑choice for high‑quality voice synthesis.

1. The Voice AI Landscape

Layer	What it does	Typical APIs
Speech Recognition (STT)	Converts spoken audio into text.	Google Speech‑to‑Text, Whisper (OpenAI), Azure Speech
Text‑to‑Speech (TTS)	Turns text into natural‑sounding speech.	Amazon Polly, Google Cloud TTS, ElevenLabs
Voice Cloning / Voice Conversion	Re‑creates a specific speaker’s voice or adapts a voice model.	Respeecher, Descript’s Overdub, ElevenLabs

The synergy of these layers lets you build full‑fledged conversational agents: User speaks → STT → NLP → TTS → Speaker hears. The key to a smooth experience is low latency, high fidelity, and a voice that feels natural.

2. Why Text‑to‑Speech Matters

You might think that speech recognition is the hard part, but TTS has become equally critical. A robotic or garbled voice can ruin user experience. Modern TTS engines use neural networks (e.g., Tacotron, FastSpeech) that generate waveforms with human‑like prosody, pauses, and emotion. If you’re looking to produce a brand voice or a character’s speech, you need a TTS system that supports:

Multiple voices & accents
Custom voice training
Low‑latency streaming

Enter ElevenLabs, a cloud platform that offers high‑fidelity, low‑latency TTS and voice cloning. Their API is developer‑friendly, and you can experiment with voice presets or train your own voice with just a few minutes of audio.

3. Getting Started with ElevenLabs TTS

Below is a quick, end‑to‑end example in Python that sends a text prompt to ElevenLabs and streams the resulting audio back to your local machine. No heavy dependencies, just the requests library.

import requests
import json

API_KEY = "YOUR_ELEVENLABS_API_KEY"
BASE_URL = "https://api.elevenlabs.io/v1"

# 1️⃣ Define the voice you want
voice_id = "Bella"  # Change to any voice ID you prefer

# 2️⃣ Build the request payload
payload = {
    "text": "Hello, world! This is a test of ElevenLabs TTS.",
    "voice_settings": {
        "stability": 0.75,
        "similarity_boost": 0.65
    }
}

headers = {
    "xi-api-key": API_KEY,
    "Content-Type": "application/json"
}

# 3️⃣ Call the API
response = requests.post(
    f"{BASE_URL}/text-to-speech/{voice_id}",
    headers=headers,
    json=payload,
    stream=True
)

# 4️⃣ Save the streamed audio to a file
with open("output.mp3", "wb") as f:
    for chunk in response.iter_content(chunk_size=8192):
        if chunk:
            f.write(chunk)

print("✅ Audio saved to output.mp3")

Tip: If you don’t have an API key yet, you can sign up for a free tier at https://try.elevenlabs.io/kr07zfuqn1bp and start experimenting right away.

The same concept works in JavaScript or via a curl call, so pick whichever stack feels natural to you.

4. Voice Cloning: Re‑creating a Speaker

Voice cloning lets you synthesize speech that sounds like a specific person. The process typically involves:

Collecting a clean recording of the target speaker (30‑60 seconds is enough for many services).
Uploading the audio and letting the model learn the speaker’s timbre, cadence, and pronunciation.
Generating new utterances using the cloned voice.

ElevenLabs offers a straightforward API for cloning, and the quality is comparable to the best commercial services. The only downside is the amount of data needed for a truly natural clone—generally a few minutes of speech.

5. Building a Simple Voice Assistant

Let’s put it all together: a minimal assistant that listens to a user, transcribes the speech, processes a simple command, and replies using TTS. We’ll use Python with the speech_recognition library for STT and the ElevenLabs API for TTS.

import speech_recognition as sr
import requests
import json

API_KEY = "YOUR_ELEVENLABS_API_KEY"
BASE_URL = "https://api.elevenlabs.io/v1"

def synthesize(text, voice="Bella"):
    payload = {
        "text": text,
        "voice_settings": {
            "stability": 0.6,
            "similarity_boost": 0.5
        }
    }
    headers = {
        "xi-api-key": API_KEY,
        "Content-Type": "application/json"
    }
    resp = requests.post(
        f"{BASE_URL}/text-to-speech/{voice}",
        headers=headers,
        json=payload,
        stream=True
    )
    with open("response.mp3", "wb") as f:
        for chunk in resp.iter_content(chunk_size=8192):
            f.write(chunk)
    print("✅ TTS completed. Playing audio...")

def main():
    r = sr.Recognizer()
    with sr.Microphone() as source:
        print("🎙️  Listening…")
        audio = r.listen(source)

    try:
        user_text = r.recognize_google(audio)
        print(f"You said: {user_text}")
        # Simple command: if user says "time", reply with current time
        if "time" in user_text.lower():
            from datetime import datetime
            reply = f"The time is {datetime.now().strftime('%I:%M %p')}."
        else:
            reply = "Sorry, I didn’t get that."
        synthesize(reply)
    except sr.UnknownValueError:
        print("❌ Could not understand audio.")
    except sr.RequestError as e:
        print(f"❌ Could not request results; {e}")

if __name__ == "__main__":
    main()

What you’ll learn from this snippet:

How to capture microphone input in real time.
Basic STT with Google’s free API (you can swap out any other STT provider).
A clean separation between recognition, logic, and synthesis.
Easy integration with ElevenLabs for high‑quality speech output.

6. Tips for Production‑Ready Voice AI

Concern	Recommendation
Latency	Use streaming TTS endpoints; cache short phrases.
Privacy	Keep user audio on-device or encrypt before sending.
Scalability	Use a CDN for static voice assets; consider serverless functions for on‑the‑fly synthesis.
Cost	Monitor API usage; many providers offer tiered pricing with free quotas.

If you’re serious about building a voice product, start by profiling your application’s bottlenecks. Even a 200 ms latency can feel laggy for a conversational agent.

7. Wrap‑Up

Voice AI is no longer a niche research area—it’s a developer playground. By combining open‑source STT models with powerful TTS services like ElevenLabs, you can create rich, interactive audio experiences in a matter of days. Whether you’re prototyping a chatbot, generating audiobooks, or cloning a celebrity voice for a marketing campaign, the tools are ready and the learning curve is gentle.

Call‑to‑Action

Ready to add voice to your next project? Sign up for ElevenLabs today and get instant access to high‑fidelity TTS and voice cloning. Start with the free tier and explore the API: https://try.elevenlabs.io/kr07zfuqn1bp

Happy coding, and may your apps always have a voice that feels like home!

10Eros Beta5 in H3: Two-Pass Refinement Versus SelfLift Audio Conditioning

AI-KSK — Sun, 01 Nov 2026 20:27:13 +0000

These two exports use the same selected Beta5 base-model filename, but they are not interchangeable presets. One builds a coarse-to-refined audiovisual result from active image references. The other manually injects trimmed source audio into an audiovisual latent and uses a SelfLift sampler.

The differences matter before you queue either graph: which inputs are active, which schedule reaches the sampler, where output audio comes from, and which branches actually save files. The supplied files contain 66 and 32 nodes respectively, totaling 98 nodes and 155 links. This guide reports static configuration, not a new generation, quality comparison, lip-sync test or benchmark.

01 — Start with the current inputs, not the FL2VA title

The first file has three active reference-image loaders: 112, 113 and 121. Their images reach the named reference slots 1, 2 and 3 on both conditioning stages.

First-frame, last-frame, additional image, source-video, drive-audio, final-audio and reference-audio routes are saved bypassed. Their visible nodes and connected wires do not establish active media inputs. The conditioners request AUTO/native behavior, so do not describe this saved state as an active first/last-frame or source-audio-driven example simply because the filename mentions those modes.

Reference slots are sparse. Check how the matching custom implementation resolves prompt Picture ordinals rather than assuming a slot suffix is a direct picture-number guarantee.

Follow the linked prompt and dimensions

Prompt node 28 supplies the active instruction. The saved text describes a woman, a mech and a perfume-related scene; that describes prompt intent, not independently reviewed reference-image content. The older red-Hanfu text stored inside the conditioners is overridden.

Refinement adds a separate sharpness/natural-photorealism instruction through concatenation. That is another requested behavior, not proof that skin, faces or texture improve without changing identity.

The coarse resolution selector stores 4:3, 1 megapixel, multiple 32. Its links override the conditioner's old 736×416 values. The learned latent upscaler is configured as scale_by 1.5, and its width/height outputs feed the second conditioner. Stored 1344×768 and upscaler target-size fields do not define the effective output size in this route. Inspect actual dimensions after execution rather than quoting those defaults.

The active LoRA stacks differ between stages

The selected base is 10Eros_Max_h3_TURBO-hybrid_beta5_int8_SinoX.safetensors. The FL2VA Turbo LoRA at node 5 is bypassed. Both ExposureSlider nodes are also bypassed, despite retained strengths.

The coarse stack applies Combat at 0.7, the aesthetic and FrameRush selections at 0.5 each, and Motion Repair at 0.7. The refinement stack uses Combat at 0.49, the same aesthetic/FrameRush strengths, Motion Repair at 0.2, and an additional LMS selection at 0.3.

These are configured selections, not verified effects. The “small-face” or “de-oiling” label does not make this a dedicated face-detection/crop/stitch graph. It uses a broader learned-latent two-pass route; there is no separate face-crop repair chain in this export.

Attention-related patches are enabled upstream. Their names do not independently establish the effective runtime kernel, VRAM savings, compatible hardware or acceleration. Resolve the installed implementations before relying on their interactions.

The connected schedule is not the old eight-step sigma output

DualClockSampler node 8 stores a steps value of 8 and supplies model/sampler outputs, but its SIGMAS output is unconnected. LearnedTwoPassParityPlan node 9 supplies the connected schedules, with saved base/coarse/refine controls of 9 / 4 / 5.

Follow those connections rather than advertising an eight-step coarse run. Nor should the planned 4+5 split be presented as a measured total number of model evaluations: diagnostics are unused and the custom samplers/mixer were not executed here.

The first sampler's DENOISED_OUTPUT reaches the learned upscaler. The second conditioner builds a high-resolution template; reconciliation combines it with the learned latent and positive conditioning. DetailMixer then supplies the refined model, sampler and schedule.

Tail, model-time bias, STG and restart switches are all off. Nonzero saved values inside those dormant options do not enable the features.

The stages share a noise node whose seed control is randomize. Reconciliation's saved audio policies and second-pass strength zero describe requested behavior, not fixed-seed reproducibility or verified preservation of first-pass audio.

Duration and outputs in the first file

The duration control is 10 and feeds this frame expression:

max(5, round(a * 24))
+ (5 - (max(5, round(a * 24)) % 17)) % 17

For a = 10, standalone arithmetic gives 243 requested frames. At the configured 24 fps, that is a nominal 10.125 seconds—not a measured file duration. The connected count overrides old 124-frame widgets.

The main refined latent is decoded into video and generated audio, then sent to a VHS combine node configured for H.265 MP4, yuv420p10le, CRF 22 and 24 fps. This is not selected-source audio passthrough, nor proof of genuine high-bit-depth scene information.

Two additional stage branches actively decode, create and save videos: one for the first sample and another for the refined sample. The latter decodes the same refined latent used by the main output. Their “preview” role does not mean they are unsaved, and their video-wrapper settings differ from the main VHS configuration.

Expect to inspect three configured save destinations, not assume there is only one final file. No actual files or output counts were verified by generation in this review.

02 — SelfLift conditions on trimmed source audio

The second file selects the same Beta5 base, but uses qwen3vl_32b_minimax_h3_int8_convrot.safetensors rather than the first file's NVFP4/AWQ-named encoder. Both use the selected FP16 video VAE and FP32 audio VAE. Resolve the actual references instead of treating the dependency stacks as identical.

Two image loaders are active. The saved prompt assigns Picture 1 to a character and Picture 2 to environment/composition; this is a statement about prompt roles, not visual verification. The reference-video and native reference-audio ports are unconnected.

The resolution selector stores 3:4, 1.5 megapixels, multiple 32, overriding the conditioner's old 1344×768 values. Do not describe it as a fixed landscape setup.

Trimmed source audio is encoded with the audio VAE and given a zero latent-noise mask. The reference-conditioning template is split, and its video portion is concatenated with the encoded audio. That assembled latent enters SelfLift. This is a manual audio-latent route, not a connected native reference-audio socket.

Read the audio-window fields and integer conversion carefully

TrimAudioDuration stores start_index = 14.63 and duration = 20.46. Those are not a start/end pair defining a 5.83-second window. Check the implementation's units and actual available source material before interpreting the resulting selection.

The trimmed audio's reported length passes through the INT output of ComfyNumberConvert before reaching the frame expression. Fractional precision is not passed straight through that wire.

This file's expression adds an extra 24 after the alignment rule:

max(5, round(a * 24))
+ (5 - (max(5, round(a * 24)) % 17)) % 17
+ 24

For an integer input of 5, this arithmetic gives 148, not 124. For 10 it gives 267, and for 20 it gives 505. These are illustrative formula results, not claims about the actual trimmed audio length, downstream padding or generated frames.

Do not reuse the first file's duration conclusion or assume every node automatically aligns the soundtrack. The visible output has no explicit post-decode trimming node, and VHS trim_to_audio is false. Actual synchronization and end behavior require inspection.

SelfLift sampling and output are separate questions

The four-step Turbo LoRA node is bypassed. BasicScheduler instead stores simple, 6 steps and denoise 1, while KSamplerSelect chooses Euler. SelfLift stores CFG 1, transition step 3, low-resolution scale 0.5, rho 0, weights 0.5–1, and the learned 3D latent upscaler. Its optional model_hires input is unconnected.

These are configuration facts, not a measured six-evaluation benchmark or proof of particular intermediate resolutions. Negative conditioning comes through ConditioningZeroOut. The memory/preview utilities also provide no measured VRAM result here.

After SelfLift, the audiovisual latent is split and only the video portion is decoded. The final combine node receives the trimmed original audio directly, not a newly decoded generated soundtrack. Its settings include H.264 MP4, CRF 12 and 24 fps.

That establishes routing, not bit-perfect audio copying, voice preservation, equal durations or accurate lip synchronization. Listen to and inspect the actual output before accepting it as an audio-driven character result.

Import and acceptance checks

Seven producer-side link-list entries are stale across the two files. Global link tuples and receiving input links agree, but some output lists still advertise links originating elsewhere. These are documented rather than silently repaired. Inspect imported connections with the compatible frontend; static consistency checks are not runtime certification or proof that the graphs must fail.

Use authorized reference images and sound. Choose the intended active routes, update prompts, inspect effective dimensions and time controls, and identify every save destination. Run a small test before judging identity, faces, texture, movement, audio and any claimed quality gain.

New canonical copies omit only known historical video-preview metadata; source originals are preserved. Covers have not been visually reviewed. The source-provided tutorial was not live-verified, and no blanket license, compatibility claim or new benchmark accompanies this walkthrough.

Getting the workflows

Published by this channel. The graphs are free; weights, LoRAs and input assets are separate and carry their own terms.

Hugging Face: AI-KSK/10eros-beta5-dual-workflows-307 — two JSONs, covers, SHA256 manifest. Start here.
ModelScope (魔搭): Sunjian520/10eros-beta5-dual-workflows-307
Civitai: 01 Face touch-up second pass · 02 SelfLift audio digital human
Run without a local GPU: 01 · 02
Tutorial: YouTube · Bilibili

Normal vs uncensored: what 540 prompts across three pairs actually show

RESK — Sun, 01 Nov 2026 20:27:10 +0000

Normal vs uncensored: what 540 prompts across three pairs actually show

TL;DR: We ran the same 90 prompts on three normal models and their uncensored siblings. Harmful refusal fell from 80-100 to 21-34. Helpfulness on benign trigger prompts did not improve. Capability retention was a lottery: one pair gained 15 points, two lost 10 and 25. Uncensoring removed the brakes; it did not add skill.

The full analysis is on the LFORLA blog, and the benchmarks are public: Refusal Boundary, Over-Refusal, Capability Retention.

The setup

Three matched pairs, all 4-bit GGUF on Ollama, one Tesla T4:

Llama 3.1 8B Instruct vs Mannix Llama 3.1 8B Abliterated
Qwen2.5 7B Instruct vs huihui_ai Qwen2.5 7B Abliterate
Mistral 7B Instruct v0.3 vs Dolphin Mistral 7B

Each model saw 90 prompts:

40 refusal-boundary prompts: 20 benign requests with a safety-adjacent trigger, 20 clearly harmful requests.
30 over-refusal prompts: benign requests that contain trigger words such as kill, bomb, drugs, weapon or hack.
20 deterministic capability tasks: math, logic, code, instruction following and reading.

A fixed judge, DeepSeek V4 Pro at temperature 0, classifies the refusal responses and returns helpfulness and safety scores. The capability tasks are checked by exact match, with no judge.

The numbers

Normal → uncensored. Higher is better in every column.

Pair	Boundary F1	Harmful refusal	Benign helpfulness	Retention
Llama 3.1 8B	92.90 → 49.59	100 → 34.25	88.33 → 81.33	70 → 85
Qwen2.5 7B	90.56 → 31.89	100 → 21.00	88.00 → 72.00	90 → 80
Mistral 7B	84.33 → 45.45	80.75 → 32.75	85.17 → 83.00	60 → 35

What surprised us

1. The safety refusal collapsed

The harmful refusal column is the share of the 20 disallowed requests where the model refused or deflected without providing actionable content. The normal models are at 100, 100 and 80.75. The uncensored variants fall to 34.25, 21 and 32.75.

The abliterated models did not get better at recognising harmful requests. They stopped treating recognition as a reason to refuse. That is the main driver of the boundary F1 collapse.

2. Helpfulness did not improve

This is the part that contradicts the usual "uncensored models are more useful" claim. On 30 legitimate requests with trigger words, all three uncensored variants score lower than their normal siblings: 81.33 vs 88.33, 72 vs 88, 83 vs 85.17.

The refusal they lost did not turn into better answers. It turned into a different refusal boundary, not more help.

3. Capability is a lottery

The 20-task screen is small but deterministic:

Llama abliterated gains 15 points. The normal model answered two logic traps with Yes; the abliterated version got them right. Two questions, not a capability jump.
Qwen abliterated loses 10 points, mostly exact instruction following.
Dolphin Mistral loses 25 points: code falls from 83.33 to 16.67, math from 57.14 to 42.86. Dolphin is the least faithful pair: it is an uncensored fine-tune, not a pure abliteration of the same checkpoint.

Uncensoring is not a free upgrade. It is a different model with a different damage profile.

Why the boundary score is a harmonic mean

The refusal-boundary score combines benign helpfulness and harmful refusal:

2 × helpfulness × refusal / (helpfulness + refusal)

A model that answers everything gets 100 and 0, and scores 0. A model that refuses everything gets 0 and 100, and scores 0. A model that is good at both gets a high score. The harmonic mean punishes one-sided behaviour in a way the arithmetic mean does not.

That is deliberate. A single refusal rate rewards a brick. A single helpfulness score rewards a model that will do anything. The boundary is the product.

Limits

90 prompts, one run, one judge, one quantization. Signals, not a safety certification.
The pairs are not pure controlled surgeries. Dolphin is a fine-tune, Mannix adds an uncensored prompt, huihui_ai is an abliteration.
The 20-task retention screen is small. A 15-point move can be two questions.
A benchmark score is not a deployment recommendation. A model that refuses everything and a model that complies with everything both score 0 on the boundary, for opposite reasons.

Run it

The prompts and rubrics are public on the three benchmark pages. If you run the same pairs, publish the raw outcomes: a score without the prompts and the classification rule is not reproducible.

The full write-up, with the chart and the exact pair definitions, is at lforla.org/blog/normal-vs-uncensored.

Originally published at lforla.org.