Video & subtitles · Direct Media Downloader
How the Direct Media Downloader announces a request before it makes it
· How it works
privacy http security
Two ToolAcre tools use the network by design, and each announces every request before making it. This post explains the announce-then-fetch pattern, what the registry records and how to confirm it yourself.
Most download sites contact somewhere before you finish pasting — the trust gap that silent requests create
A downloader that transmits a pasted link during typing has already crossed a boundary before the visitor can inspect it. Direct Media Downloader instead runs input parsing locally. The status names a host and states that nothing has been contacted, leaving time to reject an unexpected destination.
This is stronger than a generic privacy badge because it binds timing to a visible action. Check link and Download are the only media-network controls. Clipboard permission, page assets, and site-wide services are separate surfaces and should not be folded into a claim that the whole page makes no requests. An assessor should therefore describe “no request while typing” separately from broader page loading, rather than presenting a filtered media trace as proof of total silence.
The announce step: naming the host before the fetch — what the tool shows and why it comes from the parsed URL
After URL safety checks pass, the interface displays the normalized hostname derived from the pasted address. It does not perform a preliminary lookup to obtain that name. This makes the announcement available without leaking the URL to a resolver chosen by the application.
Pressing Check link is labelled as a request and sends HEAD to that URL. Pressing Download sends GET. Both omit credentials, suppress the referrer, avoid cache reuse, and follow redirects. The hostname shown beforehand describes the first URL, not every server a redirect chain may involve. The visible text gives the user a chance to notice lookalike domains, unexpected subdomains, or an internal-looking name before any remote server receives the address.
The registry entry: recording that a tool uses the network — how ToolAcre lists the two network-using tools and what each says about its hosts
The product registry marks local processing false and network-after-load true. Its manifest says that every request is stated before it is made, that no account is required, and that advertising and analytics are disabled for this product. Those records prevent a local-only badge from being reused here.
ToolAcre’s wider documentation identifies two products whose core functions contact external hosts: this downloader and the YouTube viewer. Their traffic shapes differ. The media tool contacts the visitor-selected public host; the YouTube tool contacts named Google endpoints after its own explicit action. This registry-level exception is important because most other ToolAcre tools transform selected local files and would use different privacy language.
Worked example: matching each explicit action to the request it creates
Clear the Network panel, paste a valid HTTPS file link, and observe no new media row. Press Check link once: a HEAD attempt should appear. After the rights confirmation, press Download once: a GET follows, and its body chunks drive the progress display before the result is offered for saving.
Calling that sequence a “single request” would erase the optional probe. One download action produces one GET, while using both controls produces HEAD and GET. Page navigation may also load first-party assets. Filter by the supplied hostname when auditing the tool’s destination-specific behavior. Cancellation can add a terminated row, and a redirect can add hops, so count actions and chains rather than asserting an invariant total from one uncomplicated sample.
What product policy and browser controls add to the observable request path
The page’s generated security policy constrains allowed connection destinations, and the product contains no proxy code or third-party downloader SDK. More importantly, the request implementation itself is readable: Fetch receives the parsed URL directly, not a ToolAcre endpoint wrapping it as a query parameter.
Policy is defence in depth rather than proof that no request can ever occur. Browser extensions, developer tools, service workers, or future site configuration are separate considerations. The repeatable evidence is the shipped source plus an observed trace in the environment being approved. Source review also confirms that requests set `credentials: omit` and `referrerPolicy: no-referrer`; a CSP cannot by itself establish either application-level choice.
What this does not cover — the announcement describes the tool's request, not what the remote host does with it or where a redirect leads
The announcement does not describe what the remote host logs. That server sees a request from the browser and may apply its own retention policy. It can redirect to another origin, and the browser follows redirects for both HEAD and GET unless a failure interrupts the path.
Nor does the initial hostname certify the file, the rights to it, or the final destination. The Network panel reveals redirects after contact. A cautious reviewer can preserve the log, expand the chain, and stop if a host outside the expected delivery infrastructure appears. For high-sensitivity work, avoid shortened destinations and ask the sender for the canonical delivery host so the pre-contact information is more meaningful.
Takeaway: transparency you can check, not just read — how the Direct Media Downloader's announce-then-fetch order makes its promise verifiable
Transparency is testable here because each stage has a different artifact: a local verdict before traffic, a HEAD row after Check link, a GET row after Download, response headers when CORS permits them, and accumulated bytes while the body arrives. A policy paragraph alone cannot provide that sequence.
Use the announcement as a pause point, not as a seal of approval. Confirm the host, confirm your authorization, and inspect redirects when provenance matters. Direct Media Downloader narrows its promise to traffic it initiates and leaves remote logging and destination policy visible as external boundaries. A screenshot of the status line plus an exported HAR gives reviewers complementary evidence about what was announced and what the browser subsequently attempted.