Privacy policy

Scope and who is responsible

This policy covers every personal data processing activity carried out by Malwagon at malwagon.com, including the anonymous free scan that needs no account, and it applies to visitors, account holders, team members and anyone whose personal data happens to be inside something a user submits.

The operator of the platform is the controller for that processing. The operator decides why and how the data is processed, and it is the operator you exercise your rights against. Its legal identity is stated below, and until it is stated you should treat this page as describing the platform rather than as naming a party.

The service is a professional malware analysis tool. It is built for security teams, and it processes hostile files on purpose. This policy should be read together with the terms of service, which govern your use of the service, and the security page, which describes how samples are isolated.

The controller is Malwagon: the service described on this site, run by the person who operates the hardware. It is not incorporated as a company, so there is no registered entity name, registration number or registered office to state, and no representative has been separately appointed. Contact for anything in this policy: [email protected].

What we collect

We collect seven categories of data: account data, submissions and everything derived from them, technical request data, the free tier's per address counter, administrative audit records, billing records, and correspondence you send us. Each category is set out below, field by field, as the platform actually stores it.

One point governs the whole of this section. A submission is an opaque object at the moment it arrives. We do not know what is inside a file, a document, an archive, a script or a page at a URL until the platform has analysed it, and analysis is the only way to find out. If a submission contains personal data, that data is processed because it was submitted, not because we sought it.

Account data

An account row holds your email address, which is also the identifier you sign in with; a display name, which is set from the part of your email address before the at sign if you leave it blank; how your identity is established, which is a local password, a Google sign-in or a Microsoft Entra sign-in; and, for an external sign-in, the stable subject identifier that provider issues. A local password is stored only as a salted hash produced by the framework's default password hasher, never as the password itself. The row also records when the account was created, when it last signed in, whether it is active, whether it is a staff or superuser account, and, if it has been suspended, when that happened and the reason recorded for it. The account table additionally carries the framework's standard first name and last name columns; the platform never asks for either and leaves both empty.

Authentication secrets

If you enable two-factor authentication, the shared secret and your single use backup codes are stored encrypted with Fernet, using a key held outside the database, and the earlier plaintext columns were removed from the table by migration. API and MCP tokens are stored as a short public identifier plus a keyed HMAC-SHA256 digest of the secret half, with the key held outside the database; the token value itself is shown once at creation and is never written down by the platform, so it cannot be recovered from a database copy. Each token row also records when it was created, when it expires if an expiry was set, when it was revoked, when it was last used and the address it was last used from.

Team data

An organization holds a team name and a URL slug. A membership holds the link between an account and a team, the role that account has, and when it joined. An invite holds the email address it was addressed to, which may belong to a person who has no account here at all, the role offered, who issued it, who accepted it, and its creation, expiry, acceptance and revocation times. An invite is delivered as a link you pass on yourself; the platform sends no email.

Submissions and everything derived from them

The file, document, URL, command or package you submit is stored so that it can be analysed. Sample rows are content addressed by SHA-256, which means one row and one stored copy represent a given set of bytes for everyone who has ever submitted them. Around that we store the name your submission used, the module you chose, the submission options as a structured document, and, for a pasted command, the first two hundred characters of it as a preview. Analysis then produces and stores hashes and fuzzy hashes, extracted strings and file metadata, process, file, registry and network activity, screenshots taken during detonation, packet captures and keystroke logs from the guest, memory forensics findings, rule matches, indicators of compromise, a score, a verdict, triage tags and the narrative written over that derived data. Pre-built PDF and DOCX reports are stored as files as well.

Technical request data

Source IP address, browser user agent string and timestamps are recorded where they are needed. The free tier records the source address on its counter row; the administrative audit log records the address and the user agent of the account performing an action; a token row records the address the token was last used from; and ordinary web server and application logs record request metadata in the normal way, including failed sign-in attempts and the address they came from. A scan row does not carry the submitter's IP address at all: there is no such column on it, so a scan is not linked to an address in the database.

The free tier per address counter

Using the anonymous free tier creates or updates one row for your source address. That row stores the address itself, the calendar day the current counter belongs to, how many scans the address has used that day, a running total across all time, an optional per address limit and an optional block flag set by an operator, an operator note, when the address was first seen and when it was last seen. The row lives in the database rather than in a cache, deliberately, so that an operator can list and review the addresses that have used the tier. The address is taken from the connection itself and never from a forwarding header, because a header can be written by the client and would let one visitor mint unlimited identities.

Administrative audit records

Actions taken in the admin panel are written to an audit log holding the action, its target, a structured detail document, the acting account and a copy of that account's email address, the source address the request came from, the user agent string and a timestamp. The address here is the connection's own address and a client supplied forwarding header is deliberately not trusted, because the audit record exists precisely so that it cannot be authored by the person it describes. The stored copy of the email address is denormalised on purpose so that the record still says who acted after the account itself is gone.

Billing records

A subscription row holds your plan key, its status, the identifier the external payment platform uses for the subscription and the end of the current period. A credit ledger holds each transaction's type, amount, free text note, reference and timestamp. Plan and credit pack definitions hold no personal data. The platform does not store card numbers, bank details or any other payment instrument: payment is handled by the external payment platform, and what reaches this platform is a signed event about the subscription.

Correspondence

There is deliberately no contact form on this site. You write to [email protected], so what we hold is the message you sent, the address you sent it from and whatever you chose to put in it, in an ordinary mailbox, for as long as we need it to answer you and to keep a record of the exchange.

What you submit, and your responsibility for it

By submitting content you warrant that you have the lawful right to submit it, to have it analysed, and, for a public tier scan, to have the resulting report published; as between you and the operator, you are responsible for the content of your submission and the operator processes it to produce the analysis you asked for.

This matters more here than on an ordinary website, because a malware sample is an arbitrary object. A document, an archive, a memory image, a captured page or a script can contain names, addresses, message bodies, credentials, customer records or anything else its author put there. The platform does not know that in advance and cannot know it before the analysis it is being asked to run.

Do not submit personal data you are not entitled to disclose

If the material contains personal data about other people, satisfy yourself that you may lawfully hand it to a third party for analysis before you submit it. If it is sensitive, or if you are unsure, use a private scan on a paid plan rather than the public free tier, or use Ultra Privacy, which destroys the stored data when the run ends. The plans page sets out which tiers include private scans.

What the operator does with it

The operator processes a submission to run the analysis it was sent for, to produce and store the report, and for the further purposes set out under how we use it. It does not read submissions for its own purposes, and it does not sell them or pass them to anyone as a commercial data product.

If you submitted something you should not have

Tell us. Write to [email protected] with Subject: Takedown and identify the report. What can and cannot be undone is set out under public reports, and you should read it before you rely on withdrawal.

If you are not the submitter

If you believe a published report contains your personal data and was submitted by someone else, write to [email protected] with Subject: Takedown and say what identifies you in it. Your rights are set out under your rights and are not affected by the fact that somebody else did the submitting.

Legal bases

Every purpose below rests on one of four bases: performance of a contract with you, our legitimate interests, a legal obligation, or your consent; where the basis is legitimate interests, the specific interest is named in the same row rather than left as a label.

How we use it

We use the data for seven things and no others: running the analysis you asked for, metering the free tier, preventing abuse and protecting the platform, security monitoring, improving detection content, operating accounts and billing, and meeting legal obligations.

Running the analysis you asked for

A sample has to be stored to be detonated, and the analysis has to be stored for the report to exist, to be read again later, to be exported, and to feed similarity search and campaign clustering. This is the core purpose and everything else is secondary to it.

Metering the free tier

The anonymous tier allows a small number of scans per source address per calendar day with no account. Counting that without an account is only possible against the address, so that is what is counted, and nothing else about the request is used for the count.

Preventing abuse and protecting the platform

Source addresses, user agents, submission volume and audit records are what let us identify an account attacking the platform, an address exhausting the free tier automatically, or an administrative action that should not have happened. Failed sign-in attempts are counted per address and refused for a few minutes once the budget is spent. An operator can block a specific address from the free tier or suspend an account.

Security monitoring

Logs and audit records are read when something goes wrong, when an incident is investigated, and when a security report is assessed. A platform whose stated function is to execute hostile software cannot be operated without them.

Improving detection content

Indicators, rule matches and behavioural patterns derived from analyses are used to improve scoring, detection rules and clustering across the platform. This works on derived output, not on the bytes you submitted, and derived output from an Ultra Privacy scan is excluded from it.

Operating accounts and billing

Your email address identifies your account, secures sign-in and receives account messages. Plan, subscription and credit records are what make quotas, concurrency limits, team credit pools and entitlements work.

Meeting legal obligations

We keep and produce what the law requires us to keep and produce, including for tax and accounting, and we respond to lawful requests from a competent authority.

Public reports

A free tier report is public by design: it is readable by anyone with the link, it is listed in the public analyses index, and the submission form states this before you submit and refuses the submission unless you confirm it.

Publication is not reversible in practice. Once a report has been indexed by a search engine, archived, quoted, scraped or copied, the copies are outside our control and we cannot recall them. We can stop serving a report from this platform and we will act on a well founded request to do so, but we cannot undo publication itself. Read that sentence before you rely on withdrawal, and do not use the free tier for anything that must not become public.

What becomes public

The report page for a public scan, which carries the submitted name, the hashes, the identity and static analysis of the sample, the behaviour observed during detonation, network indicators, screenshots taken in the guest, rule matches, the score and the verdict, together with the narrative built over that derived data. Public samples are also reachable through the public index and through the indicator, domain, family and address pages built from them.

What is not published

Your account details are never published. An anonymous free scan is created under a shared service account rather than under any identity of yours, and no source address is recorded on the scan, so a public report does not identify who submitted it.

The confirmation is required, and it is enforced on the server

The checkbox on the submission form is marked required in the browser and the same confirmation is checked again on the server, so a submission made with a script rather than a browser is refused in exactly the same way. For a submission made while signed in, the moment of acceptance and the version of this policy in force are recorded against that scan.

Private scans

Paid plans allow a scan to be private. A private scan is not listed in the public index, is not included in the sitemap and is not readable outside the account that owns it. An owner can also make an already published scan private again, which stops it being served, subject to the irreversibility point above. Ultra Privacy goes further and is described under retention and deletion.

Asking for a published report to be removed

Write to [email protected] with Subject: Takedown, identify the report and say why it should be removed. We will consider the request and, where it is well founded, stop serving the report. We reserve the right to retain the derived indicators, rule matches, detection content, statistics and security records produced from that analysis, because those are what the platform exists to produce and they are not the published page.

Who receives what

The submitted sample never leaves the platform; what can leave is hash values and derived indicators, sent to reputation and threat intelligence services, and locally derived summaries, sent to the AI layer, and each of those integrations only makes a request at all when its API key is configured.

Samples stay here

The submitted sample and its raw content are stored and detonated on hardware the operator runs and are not uploaded to any third party. This is a design rule of the platform rather than a configuration option, it holds for every analysis module, and the integrations that exist deliberately implement lookup endpoints only, with no upload path.

Reputation and threat intelligence services

To enrich a report the platform may send hash values and derived indicators, such as domain names, addresses, URLs and TLS fingerprints, to third party reputation and threat intelligence services, and compares them against public indicator feeds. Those services receive the indicator and nothing else. Every such integration is gated on an API key that may be unset; where a key is not configured the lookup is not attempted and the report simply records that the service was not available. An Ultra Privacy scan is never enriched against any external service.

The AI layer

The narrative layer receives only material derived locally first: a behaviour summary, an API call sequence, an indicator list and non-sensitive extracted strings, assembled by a single module that copies named fields and drops everything else, including storage paths, raw strings dumps, decoded script bodies and captured payload bytes. The sample bytes are never sent to it. Depending on configuration that summary is processed either by a language model running on the operator's own hardware, which takes precedence when it is enabled, or by a third party model provider, and if neither is configured no AI request is made at all.

Infrastructure and service providers

Providers that host, connect or support the platform process data on the operator's behalf and on its instructions, under a contract, for the purpose of providing their service and no other. The external payment platform receives what it needs to take payment and to tell us the resulting subscription state; the platform does not hand it your submissions or your analysis data.

Operators

Administrators can see account details, scan metadata and audit records in order to run the platform, investigate abuse and answer support requests, and their own actions are written to the audit log.

Disclosure required or permitted by law

We may disclose data where we believe in good faith that disclosure is required by law, by a court or by a competent authority, or that it is necessary to investigate a suspected breach of the terms, to prevent or address fraud, abuse or a security incident, or to protect the rights, property or safety of the service, the operator, its users or a third party. We may also disclose data in connection with a merger, acquisition or transfer of the business, in which case this policy continues to apply to the transferred data until it is replaced by one that is not less protective.

What we do not do

We do not sell submissions, analysis data or account details, and we do not pass them to anyone as a commercial data product.

These are the recipients enabled in production, and each receives only what is named beside it. VirusTotal and FileScan receive file hashes for reputation lookup. The abuse.ch services, MalwareBazaar, ThreatFox and URLhaus, receive hashes and derived indicators, and a URL submitted for analysis is itself such an indicator. The model provider behind the AI narrative is a hosted one and receives locally produced summaries of an analysis. Hosting is not a recipient: the hardware is the operator's own. None of them receives the submitted file, and that boundary is enforced in the code rather than by this policy alone. A recipient not listed here is not enabled.

International transfers

The platform is operated from one region and the sample itself never leaves it, but some of the recipients described above may be located elsewhere, and where personal data reaches another country it is transferred under a lawful transfer mechanism.

In practice that means one of the following, chosen according to the destination: a decision by the competent authority that the destination country offers an adequate level of protection; standard contractual clauses or an equivalent approved instrument entered into with the recipient, together with any additional technical and organisational measures the transfer requires; or, for an occasional transfer, a derogation the law expressly allows. The no upload rule limits the exposure considerably: what can cross a border to a third party is a hash value, a derived indicator or a locally built summary, never the submitted bytes.

Analysis, storage and every layer of the pipeline run on hardware the operator runs and controls directly, rather than on rented capacity from a cloud provider. The recipients listed above are operated by others and process what they receive on their own infrastructure, which may be outside the country the analysis hardware is in.

Retention and deletion

Data is retained until it is deleted, there is no automatic time based expiry running today, and the deletion mechanisms that do exist are the four described here; alongside them the operator reserves the right to retain derived indicators, detection content, audit and security records, and anything the law requires it to keep.

Ultra Privacy destroys a scan's data when the run ends

A scan submitted with Ultra Privacy is private by definition and cannot be made public. It is never enriched against an external service and its derived data never feeds a shared store. When analysis completes, the platform deletes the analysis documents, the artifacts and their stored bytes, the indicators the scan produced, the packet capture and keystroke log, any pre-built report file, and the sample bytes themselves unless another scan that supplied the same bytes still refers to them. What deliberately remains is a stub: the scan row marked as destroyed so that the report page can explain what happened, together with the scan's own metadata, the content addressed sample row with its hashes, name, size and type, and the score and verdict. The destruction of everything else is not reversible. It runs when a scan completes, so a scan that failed before completing is not purged this way.

You can delete your own scans

You can delete an individual scan from the console, or every scan you own in one action. Both remove the scan row and the analysis, verdict, artifact and indicator records attached to it, the artifact files that nothing else refers to, the packet captures and keystroke logs, any pre-built report, and the sample bytes when no other scan still points at them. Deletion happens immediately and is not a soft delete. A public report that is deleted stops being served.

You can ask for your account to be erased

An erase request removes the scans you own together with their stored files, removes your credit ledger, and then removes the account itself along with the records attached to it, such as your subscription, your team memberships, your tokens and your two factor enrolment. It is irreversible. The audit log is not erased, and the erasure itself is written to it, which is described under your rights.

An operator can purge old scans

An operator can delete finished scans older than a chosen number of days, through the same deletion path as everything above. This is a manual action rather than a schedule, so no automatic deletion should be assumed from it.

Some records are kept beyond that, and the operator reserves the right to keep them for as long as the purpose lasts.

Derived indicators and detection content

Indicators, rule matches, signatures, statistics and detection content derived from analyses may be retained indefinitely, including after the underlying scan is deleted, because they are the security output the platform exists to produce and they do not reproduce the submitted content. Indicators from an Ultra Privacy scan are excluded and are deleted with it.

Audit and security records

Administrative audit entries, security logs and abuse records are retained as an accountability and security record. They are not routinely erasable by the people they describe, and that is the point of them.

The free tier address counter

A counter row for an address that used the free tier is retained so that the daily allowance can be metered and so that an operator can review or block an abusive address. The daily count resets on the next use in a new day; the row itself persists until an operator deletes it.

What the law requires

Where the law requires a record to be kept, or where a record is needed to establish, exercise or defend a legal claim, it is retained for as long as that requirement or that claim lasts, and a deletion request does not reach it.

No fixed retention period is set. A submission, its report and the data derived from them are kept while the service holds them, and are removed when you ask for removal under the rights set out below or when the operator removes them. A report published on the public index can be taken down on request through the contact address above.

Security

The measures below are the ones the platform actually implements, described exactly, and the honest limits of them are stated at the end of this section rather than left out of it.

Private file permissions

Samples and artifacts are written under a dedicated storage root in a layout sharded by SHA-256, with the file named after the digest rather than after anything you submitted. Files are created readable and writable by the owning account only and never with an execute bit, and every directory level from the storage root down is set to owner access only, so a local account cannot list the tree or read what is in it. Path traversal out of the storage root is rejected on every read and delete. Note what this is not: the bytes are stored as they arrived and are not encrypted at rest, and permissions plus the mount options are what protects them.

Encrypted two factor secrets

A two factor shared secret and the backup codes issued with it are encrypted with Fernet before they are stored, using a key held outside the database, and the plaintext columns they replaced were dropped from the table.

Hashed API tokens

An API or MCP token is stored as a keyed HMAC-SHA256 digest with the key held outside the database, alongside a short public identifier used to find the row. The token itself is displayed once, at creation, and is never stored, so a copy of the database does not yield a usable credential. Verification is a constant time comparison, a token can carry an expiry and a read or submit scope, and revoking one takes effect on the next request that presents it.

Rate limiting in front of the password check

Failed sign-in attempts are counted per client address, ten inside a five minute window, across every sign-in surface, and a further attempt from that address is refused with a retry hint until the window passes. Successful sign-ins never count. The budget is charged to the address doing the guessing rather than to the account being named, so nobody can lock you out of your own account by guessing at it. The address is taken from the connection and not from a forwarding header. The counter is designed to fail open, so if its backing store is unreachable it stops limiting rather than refusing every sign-in on the platform; failures are logged independently of it. The two factor challenge has its own separate limit of five tries in five minutes, after which the pending sign-in is discarded.

Password rules

A password must be at least twelve characters, is rejected if it is too similar to your own account details, is checked against a list of common passwords, and is rejected if it is entirely numeric. These run wherever a password is chosen, at registration and at password change. Passwords are stored only as salted hashes.

Isolation of analysis

Samples are detonated in isolated virtual machines rather than on the application host, and an anonymous free scan is placed on a network with no route out, so it cannot reach the internet whatever the submission asked for. The security page describes the isolation model in more detail.

Session and transport hardening

Session and cross-site request forgery cookies are restricted as described under cookies and local storage, framing of the site is refused, and no page on this site loads a script or a stylesheet from a third party host, which is enforced by an automated test over every template.

The limit of all of this

No method of transmission over the internet and no method of electronic storage is completely secure. We take the measures described above, and we do not guarantee the security of any data, whether in transit or at rest. Nothing on this page is a warranty of a security outcome.

Cookies and local storage

The site sets two cookies, both strictly necessary for it to work, and there is no analytics, advertising, profiling or tracking cookie of any kind on any page.

The session cookie

The framework's session cookie, named sessionid, is what keeps you signed in. It carries an opaque identifier and the session data itself is stored on the server. It is marked HttpOnly, so page scripts cannot read it, and SameSite is set to Lax, so it is not sent on cross-site requests. It is not cleared when you close the browser and its default lifetime is two weeks, so signing out is what ends a session on a shared machine. The Secure attribute is set by the deployment and is on wherever the site is served over HTTPS.

The cross-site request forgery cookie

The framework's CSRF cookie, named csrftoken, is what proves a form submission came from a page we served. SameSite is set to Lax. Unlike the session cookie it is deliberately readable by page scripts, because the live view and one-shot pages have to attach the token to the requests they make themselves; the token is not a secret from a page that can already read it. The Secure attribute is again set by the deployment.

Neither cookie profiles you

Neither is used to build a profile, neither is shared with anyone, and neither is read by a third party, because no third party script runs on this site at all. There is consequently no cookie banner: there is nothing to consent to beyond cookies that are strictly necessary for the service you asked for.

Local storage

Separately from cookies, your light or dark theme choice is stored in your browser's local storage under the key sandbox-theme. It stays in your browser, it is never sent to us, and clearing your browser storage removes it.

Your rights

You have the rights of access, rectification, erasure, restriction of processing, objection, and data portability, together with the right to withdraw a consent you have given and the right to complain to a supervisory authority; you exercise all of them by writing to [email protected].

Access

You can ask for a copy of the personal data we hold about you. The platform can produce a structured export of your profile fields, being your email address, display name, sign-in method, whether the account is active, when it was created and when it last signed in; the metadata of every scan you own, being the identifier, time, module, status, verdict, score, sample hash and submitted name; your credit ledger; and your team memberships. That export contains no sample bytes, because the raw sample never leaves the platform, and it does not include audit records, source addresses or user agent strings; if you want those as well, say so in your request and we will deal with them separately.

Rectification

You can correct your own account details in the console. Anything you cannot reach there, ask us to correct.

Erasure

You can ask us to erase your account and the data attached to it, which is done as described under retention and deletion. Erasure is not absolute, and this is the honest version of what it does not reach: the audit log is kept, so the record of administrative actions, including the address and user agent recorded for actions taken on that account, survives the account and is keyed by an email address that outlives it; the erasure itself is written to that log as a new entry naming the erased address; derived indicators and detection content may be retained; and a report that has already been published, copied or indexed elsewhere cannot be recalled.

Restriction and objection

You can ask us to restrict processing while a dispute about accuracy or lawfulness is resolved, and you can object to processing we carry out on the basis of our legitimate interests. Where you object, we will stop unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or the processing is needed for legal claims. Processing that keeps the platform secure, that meters the free tier, and that maintains the audit trail is where we are most likely to rely on those grounds, and we will say so plainly if we do.

Portability

Where the processing rests on your consent or on a contract with you and is carried out by automated means, you can ask for that data in a structured, commonly used and machine readable format. The export described under access is provided in exactly such a format.

Withdrawing consent

Where processing rests on consent you can withdraw it at any time. Withdrawal takes effect from that point and does not make the earlier processing unlawful. Read the irreversibility point under public reports before relying on withdrawal for a report that has already been published.

Complaining

You can complain to a supervisory authority. We would rather you told us first so that we can put it right, but the right does not depend on that.

How to make a request

Write to [email protected] from the address on the account, say which right you are exercising and what you want done. A request about a specific report should identify the report.

Some lawful reservations apply to every request, and stating them here is not a limitation of your rights but a description of how they work.

We verify identity first

We will take reasonable steps to confirm that a request really comes from you before acting on it, and we may ask for information needed to do that. This protects you: an unverified erasure request is a way for somebody else to destroy your data, and an unverified access request is a way for somebody else to read it. Where we cannot verify identity, we may decline to act.

An anonymous free scan may not be identifiable

Because a free scan is not linked to an account and no source address is stored on the scan, we may be unable to identify the person a request concerns. Where we can show that we cannot identify you from the data we hold, we may tell you so and decline to act unless you provide additional information that makes identification possible, and we are not obliged to acquire more data merely to make you identifiable.

Manifestly unfounded or excessive requests

Where a request is manifestly unfounded or excessive, in particular because it is repetitive, we may charge a reasonable fee reflecting the administrative cost of dealing with it, or refuse to act on it. If we do either, we will say which and why, and you can challenge that decision with a supervisory authority.

Other people's rights, and our obligations

A request will not be met to the extent that meeting it would adversely affect the rights and freedoms of others, would disclose another user's personal data, would reveal information that would compromise the security of the platform or an ongoing abuse or security investigation, or would require us to delete something the law requires us to keep.

How long we take

We will answer a request within the period the applicable law allows, and we will tell you if we need to extend it and why.

Automated analysis and decisions

The score and verdict on a report are produced automatically, by analysing the submitted artefact and nothing else; they are a statement about a file, a URL or a command, not about you, and they produce no legal or similarly significant effect on any person.

No profiling of the submitter takes place. The scoring engine reads the static, dynamic, memory, network and intelligence output of the analysis and adds up rule contributions; it does not know or use who submitted the artefact, and no output of it is used to evaluate a person's characteristics, behaviour or reliability. An automated verdict can be wrong, in both directions, and it is offered as analysis for a professional to read rather than as a decision.

Two automated mechanisms do act on a request rather than on an artefact, and both are disclosed here for completeness. Failed sign-in attempts from an address are refused automatically for a few minutes once the address has spent its budget, which is a temporary security control and not a decision about a person. Free tier usage from an address is counted automatically and refused once the daily allowance is spent. Beyond those, an account is only flagged for a human to review, and blocking an address or suspending an account is a decision an operator takes, not one the platform takes on its own.

Children

Malwagon is a professional security analysis tool, it is not directed at children, and we do not knowingly collect personal data from a child.

If you believe a child has created an account or submitted material through the free tier, tell us at [email protected] and we will remove the account and its data.

The service is not directed at children. You must be old enough to enter into a binding agreement where you live, and in any case at least 16, to submit anything or to hold an account.

How this policy applies

This policy applies to the fullest extent permitted by applicable law, and where a provision of it goes further than the law permits, that provision applies only as far as the law does permit and the rest of the policy is unaffected.

Severability

If any provision of this policy is held to be invalid, unlawful or unenforceable by a competent authority or court, that provision is severed to the minimum extent necessary and every remaining provision continues in full force. Where a severed provision can be given a valid reading that comes closest to its original intent, that reading applies instead.

Mandatory rights are preserved

Nothing in this policy is intended to exclude, restrict or waive a right you have under a law that does not allow it to be excluded, restricted or waived, and nothing in it removes a protection that applicable law gives you as a matter of mandatory rule. Where this policy and such a law conflict, the law prevails to the extent of the conflict and this policy is read accordingly.

Reservations are exercised lawfully

Where this policy reserves a right to the operator, such as the right to retain derived indicators, to keep audit and security records, to refuse a manifestly unfounded or excessive request or to verify identity before acting, that reservation is exercised only where and to the extent the applicable law permits it.

No waiver

A failure or delay in exercising a right or a reservation under this policy is not a waiver of it, and a single or partial exercise does not prevent any further exercise of it.

Changes to this policy

We may update this policy, and when we do we change the date at the top of this page, which is the version in force.

If a change materially affects how data already collected is handled, we will describe it here rather than change practice silently, and where the change requires your consent we will ask for it. Continuing to use Malwagon after a change means the updated policy applies to your use of the service from that point.

The consent recorded against a signed-in submission stores the version of this policy that was in force at the time, so what you agreed to at submission remains identifiable after this page changes.

Contact

Write to [email protected] for anything to do with this policy, including a request under your rights and a request to remove a published report, and put the topic at the front of the subject line.

Use Subject: Privacy for a question about this policy or a data protection request, and Subject: Takedown for a published report you want removed. Write from the address on the account where there is one, and say clearly what you are asking for. The contact page lists the other routes into the same mailbox.

The rules that govern use of the service are in the terms of service, and how the platform is secured is described on the security page.

There is one address for everything in this policy, including access, deletion and any complaint: [email protected]. No separate privacy contact is designated, and a message sent there reaches the person who runs the service.