DEV Community: aurelio avila

A playable preview is not a recovered original

aurelio avila — Tue, 20 Oct 2026 11:39:52 +0000

A recovery tool finds a video. Its thumbnail looks right, the player opens, and the first few seconds are familiar. That is useful evidence about a preview. It does not answer whether the complete original file survived.

For developers testing a media recovery workflow, keep three checks separate: what bytes were retained, what the decoder can read, and what the available metadata actually establishes. Here is a small review exercise using your own non-sensitive test media.

1. Keep a known reference before the experiment

Start with a short clip you created and a separate, preserved reference copy. Record its byte length and SHA-256 before doing any recovery experiment. Keep the reference away from the source you will examine and the destination used for exports.

In PowerShell, the following reads two existing files and compares their SHA-256 values. Replace both placeholder paths with files in your test corpus:

$referenceHash = (Get-FileHash -LiteralPath '.\reference\known-good.mp4' -Algorithm SHA256).Hash
$candidateHash = (Get-FileHash -LiteralPath '.\export\candidate.mp4' -Algorithm SHA256).Hash
$referenceHash -eq $candidateHash

Microsoft documents Get-FileHash as a content-based check. Renaming a file does not change its content hash. No example output is supplied here: the comparison depends on the actual files you test.

2. Interpret the comparison narrowly

A matching SHA-256 against a trusted reference is strong practical evidence that the retained bytes match that reference. It does not identify the person who created the media, the application that downloaded it or the time it was recorded.

A mismatch means you have not established a byte-for-byte match. It does not tell you the cause. Truncation, a different container or metadata, and re-encoding can all produce different files. Keep the original export before making a repair or transcode, so you can distinguish the retained candidate from later derivatives.

3. Record the checks that a thumbnail cannot replace

Check	Record	Limit
Retained bytes	File length and SHA-256; reference used	A hash without a trusted reference is an identifier, not a completeness result.
Playback	Sections examined and any decoder errors	Opening the first frame does not establish that the ending or every stream is decodable.
Source context	Image or device identifier and available offset or extents	An offset is a location in that source, not proof of authorship.
Dates	Each available value with its recorded source	A filesystem creation date can reflect copying rather than recording.
Coverage	Scope, selected mode, interruptions and failed reads	Reading the selected scope does not prove that every original file was recovered.

Check full decoding separately when it matters to the test. Keep a note of which streams and portions were examined. Do not silently turn an unknown date, an untested ending or a failed read into a successful result.

4. Keep the exercise separate from a product claim

I build Frame Witness, a Windows photo and video recovery application. Its gallery, player and source details are intended to keep these observations together. The official workspace screenshot below uses generated test media in a licensed full-scan workspace; it is a demonstration, not a result from this exercise.

The free account has different limits: a quick scan of the first 8 GB, up to 100 results, previews and saving recovered files up to 1 MB each. Full scans, larger exports and advanced tools require a paid licence. A preview alone should not be presented as proof of complete recovery.

Recovery depends on surviving bytes. Overwrites, SSD TRIM and cryptographic erasure can prevent it. Preserve important sources independently and use a different physical destination for exports. Frame Witness is not a certified forensic product; independent field validation is still needed for institutional use.

For a broader testing reference, NIST's Computer Forensics Tool Testing program develops specifications, procedures and test sets for forensic tools. Linking that methodology is not a claim that Frame Witness was evaluated or endorsed by NIST.

Which check would you add to a media recovery test before calling a candidate a complete original?

Test a prompt-redaction workflow with fictional logs

aurelio avila — Tue, 20 Oct 2026 09:49:34 +0000

A debugging prompt can contain two things at once: useful evidence and identifiers the recipient does not need. Removing everything makes the problem impossible to diagnose. Removing only the obvious email address can leave a credential behind.

Before choosing a redaction tool, define what a useful result should preserve. Here is a small, repeatable review exercise. It uses made-up data and does not require an account, a scanner or a real client document.

1. Seed a fictional example

Start with a deliberately invented support log:

Please explain why this request returned 401.
User: person@example.com
Authorization: Bearer DEMO_NOT_A_REAL_TOKEN
POST /v1/orders
Response: 401 Unauthorized
Timestamp: 2026-10-20T08:00:00Z

example.com and the token marker are test data. This is not an incident record, a working credential or output captured from a scanner.

For this exercise, the method, route and response are the useful context. The email and bearer value are unnecessary for explaining a 401. A manually prepared target might be:

Please explain why this request returned 401.
User: [email]
Authorization: Bearer [token]
POST /v1/orders
Response: 401 Unauthorized
Timestamp: [time]

This is an intended example, not a claim that a particular tool produced it. In a real log, the route, timestamp or identifier might also be confidential. Decide from the task and your organization's handling rules, rather than treating this field list as universally safe.

2. Test both misses and unnecessary changes

One successful substitution says little about coverage. Keep a small set of cases with an expected review decision:

Fictional case	What to check
A repeated email in a heading and a quoted reply	Did you inspect both occurrences?
An authorization header beside a 401 response	Was the credential removed while the error remained understandable?
A stack trace with a local profile directory	Could the path identify a person or reveal an internal project?
A harmless placeholder such as `[email]`	Was useful placeholder structure needlessly destroyed?
A client-specific project name	Do you need a protected term beyond generic email or token patterns?

Record the input, the proposed result and your decision. Count a missed value separately from an unnecessary replacement. These are review cases, not a benchmark, and they do not establish a detection rate.

3. Trace the processing boundary first

A check performed before an AI model receives a prompt may itself send that prompt to a service. Ask three questions before entering sensitive text:

Where does this particular mode run?
What is retained, and what does the policy actually cover?
Is the destination permitted for this material?

Encryption in transit and a retention policy address different questions. A server-side check still sends text to a server. If your rules prohibit that transfer, do not use a confidential document to test it.

I build Redaxa, so its current modes provide a concrete example of why the distinction matters:

Mode	Processing path
Free Chrome extension prompt checks	In the browser, on supported chat sites; the checked text stays on the device.
Web or Windows prompt checks, and extension checks with an active plan	Redaxa's servers; the published policy says text is analyzed and discarded.
Public repository checks on the web	Server-side, on the default branch, with detected values hidden in results.
Extended repository reviews in Windows	Local review with accessible Git history and supported archives; downloads and vulnerability lookups require networking.

Repository review is a separate workflow. Private repositories are not supported. Local extended reviews require Pro or Business; they should not be described as part of the free prompt check.

4. Inspect the result before sharing

Read both versions. Search for repeated identifiers, quoted history and attached fragments. Check that the remaining question is still answerable. An empty finding list is not evidence that every sensitive value was removed, and a replacement does not establish anonymity.

OWASP's guidance on sensitive information disclosure includes sanitization and user education among mitigations. A redaction preview is one review step, not a complete security control.

If a real credential was already exposed, changing a later copy does not revoke it. Follow the issuing service's revocation or rotation process and your incident procedure.

To inspect the product example, compare Redaxa's processing paths and open its fictional preview. The web example uses made-up data; it is not a live detection test. Free live web prompt checks have a daily allowance shared across the network. Detection can miss information and flag harmless text.

Which case would you add to this review set before using a redaction workflow with real work?

Before you uninstall a Windows app, read the command

aurelio avila — Tue, 20 Oct 2026 07:34:04 +0000

An uninstall button can hide several different operations: running a vendor's uninstaller, removing a Store package, or cleaning files that remain afterward. Treat those as separate decisions.

1. Identify what you are removing

Read the program name, publisher and install location. A shared runtime is different from an application you no longer use. A removal score can help prioritize a review; it cannot decide whether another program still needs that component.

2. Read the proposed action

Inspect the exact command and requested permissions before confirming. An administrator prompt describes a privilege boundary, not proof that the operation is harmless.

3. Check your recovery options

Maintain an independent backup of important data. A Windows restore point may fail, be unavailable or provide limited recovery. Its creation is not a guarantee that a removed app, its settings or personal files can be restored.

4. Separate estimates from observations

An installed-size value in the registry is an estimate supplied by software. Do not present it as disk space that an uninstall actually recovered. Read the recorded outcome, exit code and reboot requirement before drawing a conclusion.

5. Review leftovers individually

A leftover scanner finds candidates for review. A file name or old directory alone does not establish that deletion is safe. Keep anything whose ownership or purpose you cannot establish.

A concrete example: inspect the registration without running it

For the per-user NSIS installation of PC Tweaker Uninstaller, this PowerShell snippet reads its registered uninstall entry. It does not launch an uninstaller or change settings:

$key = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\PC Tweaker Uninstaller'
Get-ItemProperty -LiteralPath $key |
  Select-Object DisplayName, DisplayVersion, Publisher,
                UninstallString, QuietUninstallString

Here is the entry read on 20 October 2026. This particular installed copy is 0.13.0, not a claim about the latest release. The personal profile path was replaced with %LOCALAPPDATA%:

{
  "DisplayName": "PC Tweaker Uninstaller",
  "DisplayVersion": "0.13.0",
  "Publisher": "Aurelio Avila",
  "UninstallString": "\"%LOCALAPPDATA%\\PC Tweaker Uninstaller\\uninstall.exe\"",
  "QuietUninstallString": ""
}

This is the tool's own registered entry, not a removal receipt. No uninstall was run to obtain it. The empty QuietUninstallString means this entry supplies no quiet command; it is not permission to invent switches. Other packages can use different registry locations or installation scopes, and a registry key name is not automatically an MSI product code.

Read an MSI result in its own context

For Windows Installer, Microsoft documents these result codes:

Code	Meaning
`0`	Operation completed successfully.
`1603`	Fatal installation error.
`1641`	Success; the installer initiated a restart.
`3010`	Success; a restart is required to complete the operation.

These meanings apply to Windows Installer, not every vendor EXE. A completed process, even with a success code, does not prove that all user data, services or shared components disappeared. Keep the package identity, version, logs and restart state together.

The msiexec reference distinguishes /i installation from /x removal. Do not mechanically rewrite a registered command, add /quiet, or execute a command copied from a screenshot. Verify the intended package and the vendor's documented removal route first.

Source: Microsoft's Windows Installer result codes.

What the app's removal brief looks like

Interface preview from version 0.13.3, using example programs. This is demonstration data, not the registry capture above or evidence of an actual removal. The registry size estimate is not measured freed space, and the restore-point result still needs checking.

I build PC Tweaker Uninstaller. It brings the removal brief and a local outcome ledger into this workflow. Single uninstalls and the leftover scan are free; cleaning detected leftovers and batch removal require Pro. Before elevated removals it attempts a restore point and records the result.

See the workflow and its limitations: https://pctweaker.app/uninstaller/

What do you inspect before removing an unfamiliar Windows component?

Turn a website security finding into a client-ready next step

aurelio avila — Sun, 06 Sep 2026 23:39:35 +0000

A scanner can identify an observation. It cannot, by itself, settle every business decision that follows.

For an agency managing client websites, a useful report needs to bridge that gap. The reader should be able to identify the affected website, understand the evidence and decide who should investigate next.

Here is a practical reporting structure we use in Glarion. The examples below are fictional and illustrate communication, not findings about a real customer's website.

Start with the observation

Compare these two statements:

Your website is insecure.

The homepage response observed during this check did not include a Content-Security-Policy header.

The second statement is narrower, but more useful. It identifies an observable condition without claiming that an attack occurred or that the whole website has been assessed.

Include the domain, the check date and enough context to reproduce the observation. Avoid putting credentials, session tokens or unnecessary personal data into evidence that will be forwarded to a client.

Explain the consequence separately

For a missing CSP, the explanation might be:

This response did not declare a Content Security Policy through an HTTP header. Check whether the page supplies a policy through HTML before concluding that none exists. An appropriate policy can reduce the impact of injected content.

This explains why the finding matters without claiming that a single header prevents every attack. Severity is a useful signal, but it should not replace an explanation of the risk in the website's context.

Make the next step concrete

A recommendation such as “fix security headers” leaves too much work to the reader.

A more useful next step is:

Ask the development team to test a report-only Content Security Policy, review the resources the site needs and investigate violations before enforcing it.

Report-only mode lets the team observe violations without enforcing that policy. Centralized collection also requires reporting configuration; simply naming the mode is not an implementation plan. The MDN reference covers the relevant header and reporting directives.

Agree on an owner and a follow-up check. Do not mark a finding resolved merely because a change was requested.

Separate actions, decisions and reference observations

Not everything belongs in one list of problems:

Actions have a concrete proposed fix or investigation.
Decisions need context from the people responsible for the website. Publishing a security contact, for example, requires choosing a monitored address and a process for handling reports.
Reference observations preserve useful context, such as an observed HTTPS endpoint. They are not a count of security tests passed.

Keeping these categories separate helps a client understand what requires a response. It also avoids inflating a report with information that looks more urgent than it is.

Keep the limits visible

A report describes what was observed within a particular scope and at a particular time. A clean result is not proof that the website has no vulnerabilities today.

Keep this explanation close to the findings, and retain it in exported documents. A forwarded PDF should still make sense without the application that produced it.

A checklist before sending

Can the reader identify the domain, date and scope?
Is each observation separated from assumptions?
Is the consequence understandable without scanner terminology?
Does each recommendation provide a next step?
Are context-dependent decisions distinct from reference observations?
Is there a way to verify the follow-up work?
Are the limits visible in both the web report and PDF?

We build Glarion for agencies that need this workflow. You can inspect the fictional sample report without signing up. Glarion provides a limited free public check; full scans require a paid plan and current proof of domain control. It does not replace a manual penetration test.

What information do you find most useful when turning a technical observation into work a client can approve?

Redexa Social: building local-first creator analytics for Windows

aurelio avila — Sun, 06 Sep 2026 07:50:50 +0000

I build Redexa Social, formerly Social Dashboard: a Windows desktop application for reviewing creator analytics in one workspace.

Its focus is analysis, not automated posting. It combines local analytics storage, trends and diagnostics, with CSV exports on Pro and Studio. The application uses a Python/FastAPI backend and an HTML, CSS and JavaScript interface.

Local-first does not mean offline-only

A useful distinction for an analytics product is where data is stored versus which services it needs to contact. Redexa Social keeps its analytics cache locally, but platform connections still communicate with provider APIs. Instagram and TikTok token exchanges can use a minimal remote OAuth proxy. Account authorization, billing, license verification and updates also involve remote services.

On Windows, credentials are protected at rest using DPAPI in the current user’s scope. This helps protect stored credentials, but it does not make them inaccessible to malware already running as that user.

Locally computed insights do not require calls to an AI model. That keeps those calculations separate from a hosted AI service.

What can you connect today?

Updated 20 October 2026.

YouTube: direct connection is available.
Instagram and TikTok: current use requires your own developer application, subject to provider requirements.
X: credential status only; X analytics are not available.

The free plan supports one connected account and the core overview. CSV exports and full history require Pro or Studio.

That distinction matters: this is not yet a one-click connection experience for every platform. The application requests read-only analytics access; it is not a social publishing or scheduling tool.

Branding and package identity

Version 1.9.3 introduced the Redexa Social branding across the Windows shortcut, application icon and repository. The Windows executables distributed in the release are digitally signed and timestamped. The ZIP is a distribution container, not itself an Authenticode-signed executable.

Existing WinGet users should note that the package identifier remains AurelioAvila.SocialDashboard, even though the product is now called Redexa Social.

Try the current release

The project uses a proprietary license. Please check the repository license before reusing its code.

I would welcome feedback on the onboarding experience: is it clear which integrations work directly, which require developer setup, and where your data is stored? Please remove tokens, account identifiers and private analytics from any screenshots or logs you share.

PC Tweaker: reviewable Windows tuning with Rust and Tauri

aurelio avila — Thu, 03 Sep 2026 10:30:11 +0000

I build PC Tweaker, a Windows 10/11 utility built with Rust, Tauri and React. It brings performance and privacy settings, maintenance tools and hardware monitoring into one desktop application.

The useful question for a tuning tool is not just “what can it change?” It is “can I understand the change before I apply it?”

What is new in version 1.10.0?

The latest release adds configurable Gaming, Study and Work profiles to the free tier. Optional settings start unchecked, so you can review the proposed changes and choose what fits your PC. Supported settings can be restored individually.

A profile is a starting point, not a promise of higher FPS. Results depend on your hardware, workload and existing Windows configuration.

The desktop stack

Rust handles native Windows operations.
Tauri connects the native backend to the web-based interface using Windows WebView2.
React provides the interface for reviewing controls and monitoring hardware.

This architecture does not by itself prove that an application is faster or safer. Those claims need measurements and testing on representative systems.

Trust and recovery

The version 1.10.0 Windows installer is digitally signed and timestamped with a certificate issued to Aurelio Avila. Code signing helps verify the publisher and detect changes to the signed file; it is not a guarantee that software is risk-free or that Windows will never show a reputation warning.

Recovery support varies by setting. Restore controls are not a full system backup, so review each operation and keep appropriate backups before making system-level changes.

Try it or review the project

PC Tweaker has a free tier and optional paid Pro features. The repository is source-available under a proprietary license, not an OSI-approved open-source license.

I would particularly appreciate feedback on whether the explanations make it clear what each setting changes and how to restore it. If you report a problem, include your Windows version and reproduction steps, but remove personal information from logs.