HLTV Enhancements 的隐私政策
HLTV Enhancements 作者: Plennhar
Effective date: 2026-08-02
Developer: Plennhar
Privacy and support contact: plenhar@proton.me
HLTV Enhancements is a Firefox extension that runs only onhttps://www.hltv.org/*.
The developer does not collect or receive personal data from the extension.
The extension has no developer-operated server and includes no telemetry,
analytics, advertising, tracking pixel, crash-reporting service, or data
broker integration. It does not sell data.
The extension locally processes the HLTV pages that the user visits. Local
DOM access and calculations that remain inside Firefox are not a transfer to
the developer or another recipient. Some enabled features make HTTPS requests
to HLTV.org or submit an action to HLTV.org. Those transfers go only to HLTV,
which processes them under its own terms and privacy policy.
The extension can read the content and structure of the current HLTV page to
render enabled features. Examples include forum and match rows, thread posts,
user and team links, timestamps, voting state, match state, player metrics,
statistics tables, filters, and comparison data.
The following version 2.0 features use only information already present in
the loaded page and make no additional network request:
- sticky match headers;
- past-three-month player form overlays;
- loaded-row column selection, automatic sizing, sorting, selected calculated
columns, trends, and CSV generation; - comparison-page deltas, highlighting, summaries, swapping, filter-link
generation, and CSV generation; - the moderation rule-risk indicator.
CSV and JSON exports are generated locally as browser downloads. The
extension does not upload them.
Setting-help screenshots are packaged with the extension and loaded through
an exact local allowlist. Opening screenshot help does not contact a website.
The optional moderation rule-risk indicator analyzes the current draft in
memory. It is a deterministic heuristic, not a ban probability or official
HLTV decision. It can produce false positives and false negatives.
Draft text, new-thread titles, matched excerpts, and moderation-analysis
results are not written to extension storage, included in the diagnostic log,
or sent to the developer. The indicator does not block or require confirmation
before posting. Draft text is sent to HLTV only when the user presses HLTV's
or the extension's Post control.
While the user types a valid
@ prefix in the packaged preview composer, theprefix can be sent to HLTV's username-suggestion endpoint. The rest of the
draft is not sent for suggestions.
The extension can make the following same-origin HTTPS requests to
www.hltv.org:| Feature | Request and data | Trigger |
| --- | --- | --- |
| Forum activity | Enabled forum-list path and pagination offset; receives forum rows | Automatically for forum sources selected in settings |
| News and Matches activity | HLTV home-page GET; receives news and match rows | When either source is selected and suitable current-page markup or a fresh local activity cache cannot be reused; the two sources share a refresh request |
| Additional match teams |
/searchTeam query containing the typed team-name prefix; receives matching team IDs and names | After expanded filtering is enabled and the user types at least two characters || Thread preview | Selected HLTV thread URL; receives the thread and comment content needed for the preview | When the user hovers a supported title while previews are enabled |
| Vote state and verification | Thread URL plus the selected thread/reply identifier; receives current vote state | Before or after a managed HLTV +1 when verification is needed |
| Real HLTV +1 | Bodyless POST to HLTV's thread or reply +1 toggle endpoint | Only when the user activates or removes a real HLTV +1, or converts a provisional local +1 |
| Managed reply | Reply text, thread identifier, optional parent-reply identifier, and applicable form context | Only when the user presses Post in an extension-managed reply composer |
| Username suggestions | Valid username prefix | While the user types a supported
@ mention in the packaged preview composer || Block or unblock | Profile GET to inspect current state, followed by the selected profile form action | After the user opens the optional right-click menu and chooses Block user or Unblock user |
| Selectable WAR column | Linked HLTV team-statistics pages; receives team wins, draws, and losses | When the user starts the WAR calculation or enables WAR auto re-fetch; merely showing the selected column and controls does not fetch team pages |
| Player map matrix | Filter-preserving
/stats/players/matches/... pages and pagination; receives match-history rows | When enabled and the user opens its player analytics tab || Player consistency | Filter-preserving
/stats/players/matches/... pages and pagination; receives the filtered match-history rows | Automatically after the user enables the feature on a supported player overview; requests are bounded, sequential, cached in memory, and each failed page has delayed retries || Date-period comparison | The user-selected player ranking or overview comparison URL; receives that period's displayed metrics | When enabled with valid comparison dates and no specific-event filter |
| Player-comparison trend graph | Every filter-preserving match-history page for each available comparison player; receives dated map rows | Only after the user presses Fetch comparison trends on an enhanced comparison page |
Raw comparison points, 10-map averages, optional 1-365-day trailing means, and
optional per-player straight least-squares trend lines are calculated locally
from those fetched rows. 10-map average and Trailing
daily mean are mutually exclusive transient controls; both unchecked means
raw per-match data. Trailing means use an integer 1-365-day inclusive UTC
window, default to 30 days, emit one position per shared UTC calendar day, and
leave unbridged gaps where a window contains no maps. Hover and keyboard-focus
detail popups are also rendered locally and do not make another request. The
daily span is capped at 20,000 days, and visible, keyboard-focusable markers are
sampled to at most 600 per player while the plotted lines retain the bounded
data. Bounded SVG-level nearest-point hit testing makes every finite daily date
mouse-inspectable with one reused hover indicator.
Map-matrix and comparison-trend player-history requests are sequential, start
at least 500 ms apart, detect repeated pages and pagination loops, and stop at
100 pages or 10,000 unique rows per filtered history. Each failed history page
is retried after 3 seconds and, if needed, once more after 5 seconds; failure
of the final retry ends that operation with an error. Consistency starts after
500 ms and uses the same bounded, sequential, filter-preserving history loader,
cache, pagination limits, and 3-second and 5-second per-page retry delays. Parsed history is
cached in memory for up to 15 minutes, with at most four histories retained.
A comparison-period page is cached in memory for up to five minutes. That page
cache is limited to 16 entries and 8 MiB of aggregate UTF-8 serialized
content; older entries are evicted first. These memory caches disappear when
the content-script context ends.
The map matrix preserves only an allowlist of relevant statistics filters.
Unknown query parameters are not copied to generated fetch URLs. Responses
are size-bounded and parsed into detached, sanitized fragments. Only
same-origin HLTV statistics paths are accepted.
Win-adjusted-rating team requests start at least 500 ms apart. A failed team
request is retried after 3 seconds and, if needed, once more after 5 seconds.
For identity-sensitive forum-list and team-statistics requests, the extension
also validates the final URL after any same-origin redirect. Forum pages must
remain the exact requested section and offset. Team pages may change their
human-readable slug, but their numeric team ID must remain unchanged.
A local minus does not send a downvote to HLTV. If it replaces the user's
active real HLTV +1, the extension first asks HLTV to remove that +1 and
records the local
-1 only after the removal is confirmed. A provisionalpink local +1 makes no request when created or removed; the user can later
choose to convert it to a real HLTV +1.
Normal browser request information can include the user's IP address, user
agent, request time, requested HLTV path, referrer, and applicable HLTV
cookies. Firefox attaches applicable cookies to same-origin requests so HLTV
can recognize the user's existing session. The extension does not request
cookie permission and does not read, copy, or store cookie contents.
On the create-thread page, the risk indicator reads the native title and body
fields only in memory. Pressing Post submits through HLTV's own page form; the
indicator does not add a request or change that native submission.
No executable request is made to a developer, analytics, advertising, or
other third-party endpoint. Links that the user chooses to open are ordinary
browser navigation.
Depending on the enabled features and the user's actions, Firefox
extension-private
browser.storage.local can contain:
- settings and per-source colors;
- locally selected additional match teams;
- local user tags and exact tag-hiding rules;
- thread read state and first-unread information;
- local reaction records, derived user scores, provisional local +1 records,
and bounded action-recovery state; - recent forum, news, and match activity caches;
- bounded win-adjusted-rating and related statistics caches;
- persistent stats-table column layouts and multi-sort definitions; and
- the optional diagnostic log described below.
Short-lived vote, reply, and profile-action lock metadata can be stored in
Firefox's memory-only
browser.storage.session. It contains an action kind,validated target, tab, expiry, and random lock token. It is used only to avoid
duplicate actions across tabs and is not sent over the network.
Settings and local feature records remain until the user clears or resets
them, removes the extension's site data, or uninstalls the extension. Bounded
caches expire or evict entries according to their implementation. An upgrade
preserves compatible saved values.
Diagnostic logging is disabled by default. When the user explicitly enables
it, the extension stores a redacted troubleshooting log in
browser.storage.local with all of these limits:
- at most 500 entries;
- at most 256 KiB;
- at most seven days of retention; and
- duplicate nearby events can be collapsed into a counter.
The log can contain a timestamp, severity, generic event name, broad page
class such as
thread or stats, occurrence count, sanitized error name andcode, and extension-source stack frames. Free-form error messages are omitted.
It does not record draft or post text, usernames, tags, cookies, credentials,
raw HTML, response bodies, full URLs, query strings, fragments, IP addresses,
email addresses, or numeric profile/thread identifiers. Turning logging off
stops new records but does not silently upload or delete existing ones. The
user can clear the log or download a local JSON copy. Nothing is sent
automatically.
The toolbar and in-page settings interfaces can create local JSON downloads:
- Export saved settings includes normalized extension settings, source
colors, table layouts, and saved multi-sort definitions. - Export user data includes local tags, read state, reactions, derived
scores, provisional local +1 records, and additional match teams. - Export debug log includes only the redacted bounded diagnostic record.
Creating an export does not send it anywhere. The user controls any later
sharing of the downloaded file. Exports can reveal private local choices and
should be reviewed before sharing.
The toolbar and in-page interfaces provide separate controls for the
saved-settings and user-data JSON formats, and reject a valid export of the
wrong kind. Import files are read only inside Firefox, limited to 5 MiB,
validated and normalized before storage, and never uploaded. Recognized
settings replace their current values while unrelated storage is preserved.
User tags, read state, reactions, provisional local +1 records, and additional
teams are merged by identity; where a record exists in both places, the newer
valid timestamp wins. The validated result is committed through one storage
batch so a partial import is not left behind.
Private settings and user-interface values are rendered in closed Shadow DOM
where practical. The packaged preview reply field is an extension-origin,
sandboxed field. HLTV page scripts cannot directly traverse those closed
roots or read their raw values through the normal DOM API.
This is not complete invisibility. HLTV page scripts can observe effects that
must be visible on the page, such as extension host dimensions, wider layout,
hidden-comment layout, read indicators, source colors, statistics columns,
match panels, and other rendered output.
- Host access is limited to
https://www.hltv.org/*. - Extension-generated fetch targets are validated against the HLTV origin and
expected path families. - Fetched HTML is parsed with Firefox's Sanitizer API into detached fragments;
scripts, event handlers, resource-bearing elements, and unsafe resource
attributes are removed before querying. - No remote executable code,
eval, code generator, analytics SDK, or
third-party JavaScript library is included. - The only general Firefox API permission is
storage. - The extension is not allowed in private browsing.
The settings interfaces provide controls to reset local reaction counts,
clear the diagnostic log, and disable individual features. Firefox's add-on
settings can remove the extension and its private storage. The user can also
clear the extension's stored data through Firefox.
Disabling a feature stops its new processing and removes its rendered UI where
supported. Some previously stored local preferences remain so they can be
restored if the feature is re-enabled; the user can remove them by clearing
extension data or uninstalling the extension.
Material changes to these practices will be reflected in an updated policy
and extension release.
Questions can be sent to
plenhar@proton.me.