Browser support traces · Research guidance. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Read the scope of the label
Chrome’s DevTools documentation identifies Cookie, Set-Cookie and Authorization headers as information excluded by its default sanitised HAR export. Edge documents the same named exclusions. Those are important safeguards, but the label should not be expanded into a claim that every possible field in every application’s trace has been assessed for private information.
Consider application-specific data
A website may use account-specific values in an address, a query parameter or submitted content. This is a general review scenario, not a finding about a particular player. The developer documentation shows that request inspection includes URLs and payloads. The practical inference is to inspect those surfaces rather than assuming a header-focused description covers every secret format.
Prefer a narrower support question
Before exporting a full archive, ask whether a redacted hostname, status, time and error text would answer the immediate question. If a trace is necessary, keep the capture short and use the trusted team’s secure route. Do not upload it to an arbitrary public analyser simply to check whether it looks safe.
Preserve evidence and redaction context
Keep a private original only as long as needed and identify any redacted copy clearly. If changing a value removes information relevant to diagnosis, describe that limitation to the trusted recipient. Sanitisation reduces particular exposure risks; review and controlled sharing are still necessary parts of handling a private browser session.
Questions, answered
Does sanitised certify every private field was removed?
No. Inspect the export and its documented scope.
Should a private trace be posted publicly for convenience?
No. Use the minimum necessary evidence and a trusted destination.