Privacy

Last updated 9 October 2026

This is a free games site. There are no adverts, no ad networks and no analytics trackers, and playing a game still needs no account. Nothing here is sold or shared with a data broker. What the site does collect exists to keep it up and reachable: telling a person apart from a script, and recognising a device that has been thrown off before. An account is optional and only covers the chat and the forums — what one holds is set out below.

Which site this covers

The same server answers to several names. Two of them are permanent: plyz.org, which is the main one, and plyz.dev, which is there for when the first is blocked on a school or office network. Three are being retired and stop working in September 2027: squishes.shop, plyz.tech and plyz.website. The moving page explains why.

This policy covers all of them, and so does everything written below. They share one catalogue and one set of saved data: game progress, pinned games, high scores and preferences are held against your account and against a random id, not against the name in the address bar, so they follow you from one name to the next. Settings that live only in your browser's own storage are the exception — those belong to the browser, under the name you were on when they were written.

What the site collects

Your IP address and what kind of network it is

Every request is screened. Your address is checked against public abuse feeds, and it is also sent to an outside address registry — ip-api.com — which answers with the network operator and AS number behind it, a rough location (country, region, city, timezone) and whether that network is a home connection, a datacentre, a VPN or proxy, or a mobile carrier. The address is also reduced to the subnet it sits in — the block of neighbouring addresses the same network hands out — because moving one address along is the cheapest way to get around a block and the block is the thing that has to hold. The registry lookup means a third party sees your address. It goes on its own: no name, no cookie, nothing about which page you were on, because the site has none of that for you. The answer is cached for about a day so the same address is not looked up again on every page.

All of it feeds one verdict, and the verdict decides what happens next. There are five. Malicious is refused outright. Bot and VPN are asked to pass a check. Residential — an ordinary home connection — and unknown are let straight through, as is a search engine crawler whose address survives a reverse lookup. The evidence behind the verdict is kept in plain words rather than as a number you cannot read: which feed matched, what the registry said about the network, whether a published VPN exit list names the address, whether the request headers matched the browser they claimed to be, and whether this address was flagged on an earlier visit.

Your address is also written down. An IP address counts as personal information, so here is exactly what happens to yours. Every visiting address gets one row, and that row holds the address, the first and last time it was seen, how many times it has been seen, what the screening decided about it (which tier, which list it matched, what was done about it), which of the site's hostnames you were on, the country Cloudflare says the address is in, and a note if an administrator has written one. It does not hold your browser's name, the pages you opened, or anything you did on them. The rows are not kept on the games server itself: they are batched up and handed every half a minute to the paired scriptsfor.me service, which stores them in a Cloudflare database. They exist to keep the site up: security, stopping abuse, and rate limiting.

An ordinary row is deleted automatically seven days after it was last seen. A row for an address the screening called malicious, or caught flooding the site, is different: it is kept with no time limit at all, until a person deletes it by hand. There is no date on which it goes away by itself. That is on purpose — those are the addresses the site needs to keep remembering.

The lists your address is checked against

None of the lists are ours. They are public ones published by other people, downloaded fresh every six hours, and they come in three kinds:

• Abuse blocklists — Spamhaus DROP, FireHOL level 1, blocklist.de and Emerging Threats. These name networks run by criminals, machines known to be compromised, and addresses reported for attacking other servers. An address on one of these is refused with a 403.
• Proxy and VPN exit lists — published open-proxy lists, the Tor exit list, commercial lists of VPN ranges, and the server directories the VPN companies publish themselves (NordVPN, Mullvad, Proton VPN, Surfshark). An address on one of these is asked to pass a check. It is not refused and it is not banned.
• Datacentre range lists — which addresses belong to hosting providers rather than to home connections. Also a check, not a refusal.

You can see exactly what the screening knows about the address you are on right now, and why it decided that, at the screening lookup. If that page will not load because you are already blocked, the same answer is served from security.squishes.shop, which is deliberately reachable from a blocked address. If you want the row for your address deleted, ask through the Comment Box on the homepage.

Decoys

Some of what looks like an ordinary page is not. A few form fields are hidden from a person and visible only to something reading the markup, and a few addresses are not linked from anywhere and exist only to be found by something guessing at them. Filling in the first or asking for the second is recorded as what it is — the only thing that does either is a script — and it counts towards the verdict on your address.

Blocks and bans

Separate from the row above there is a ban list. An entry on it holds one address or a range of them, the reason, who added it, when they did, and the moment it lifts. Nothing else about you is in it.

A ban is normally enforced by this server. A persistent one is also handed to Cloudflare and enforced at the edge instead, which means the request is stopped before it ever reaches the site — either refused outright or held at Cloudflare's own managed challenge. The same address and the same reason go across; nothing else does.

Screening adds entries by itself, and how long one lasts depends on what earned it: an hour for hammering a cooldown, a day for scraping, a week for coming back from a new address to get round a block, a month for probing or forging headers. An address published on one of the abuse blocklists is banned with no expiry at all and stays banned until a person takes it off. A person can also add one by hand, either for a set length of time, at most a year, or again with no expiry. Every automatic ban is emailed to the operator for review as it is made. How screening works sets all of this out in full.

A ban can be appealed. Every one of them opens a review: the address, the reason, the path that triggered it and the browser it claimed to be are mailed to the operator, who can approve the ban or lift it. Review records are kept for seven days and then dropped. If you think a block is wrong, ask for it to be reviewed. The refusal you get when an abuse list matched names your address, says in one line why, and names the list, so quote those; a ban shows only that the network is blocked, in which case quote the address. Send it through the Comment Box on the homepage. A block covers the whole site from that address, so you will need a different connection to get the message through.

Signals from your browser

Before anything runs in the page, the shape of the request itself is read: which headers arrived, in what order, with what capitalisation, and whether all of that matches the browser the User-Agent says it is. A real Chrome sends a particular set of headers in a particular order; a script wearing Chrome's name usually does not. It is the shape that is compared, not what you were asking for.

What your device looks like

On pages that load the collector, the site reads a set of technical signals from the browser and builds a device fingerprint out of them. Here is the full list of what is read:

• How your machine draws — a small canvas image and its result, the WebGL vendor and renderer strings (which name your graphics chip), and the characteristics of an AudioContext rendering a short signal. Every one of these comes out slightly differently on different hardware.
• CPU core count and the device memory figure the browser reports.
• Which fonts are installed.
• Screen resolution, pixel ratio and colour depth.
• Timezone and the languages the browser asks for.
• Which plugins and extensions are present, and which browser features are.
• The User-Agent string and the platform it names.
• A marker cookie holding a random value with no meaning of its own. It is the only identifier we write for this purpose, and clearing site data removes it.
• Your IP address, the subnet around it, and the AS number of the network — including whether that network reads as a home connection, a datacentre or a VPN.

Those are combined into two short hashes — a strict one and a loose one that tolerates a changed window size or a browser update. What is kept is the pair of hashes, the graphics chip string, a random device id, the addresses that device has been seen on, the first and last time it was seen, and, if it was banned, when and why. The underlying readings are not stored.

It is used for three things. One: noticing that several accounts are one person. Two: recognising a banned visitor who has come back on a new address or through a VPN — the point of a fingerprint is that it does not change when the address does. Three: telling a script apart from a person, which is the same job the rest of this page describes. It is not used to decide what you are shown, and it is not sold, shared or sent anywhere outside the site.

A device record is deleted 90 days after that device was last seen. A record attached to a ban is kept 180 days instead. Alongside it the site sets the sq_who cookie, which holds nothing but that random device id, signed so it cannot be edited and unreadable to scripts in the page.

How you type and how you move

The collector also records behavioural statistics: the cadence of your typing — how long keys are held, how long the gaps between them are, how regular those gaps are — and the shape of your mouse movement: how far the pointer travelled, how smooth or how straight the path was, how long you were on the page before doing anything, how quickly a check was solved, and whether the events look like they came from a real input device. Touch and scroll activity are summarised the same way. A script types at machine-perfect intervals and moves a pointer in straight lines; a person does neither, and that difference is most of what separates them.

The timing is recorded. What you typed is not. No key, no character, no word and no field value is read, sent or stored — only how many keys were pressed and how long they were held down. The one exception is the hidden decoy fields described above, which a person never sees and never fills in, so anything that appears in one is kept as evidence that something automated filled it.

None of this is used to build an advertising profile, none of it is ever sent to an advertiser, and none of it is attached to your comments or your saved games.

The two parts run in different places, so it is worth being exact about which is where. The fingerprint is read only on pages that load the screening bundle; this page and the terms page are not among them, and never load it. The behavioural statistics and the decoy fields are on every page the site serves, including this one and the terms page.

Checks

When the score is unclear, you are asked to pass a check. The site uses Cloudflare Turnstile and Google reCAPTCHA. Both receive your IP address and interaction data directly and set their own cookies, under their own policies — Cloudflare's terms, Google's Privacy Policy and Google's Terms of Service.

There is a second kind, run by Cloudflare rather than by this site: a managed challenge, shown at the edge before the request arrives here. It is the interstitial page with the spinner on it. The site does not see what happens on it — only whether Cloudflare let the request through — and it leaves Cloudflare's own cf_clearance cookie behind.

Passing one sets the squishes_pass cookie: signed, readable only by the server, and tied to the address you passed it from, so it is no use to anyone who copies it to another connection. It lasts 24 hours, after which you are asked again. It can also be revoked early if that address starts behaving like a script.

Cookies

All of these are first-party, and none of them are advertising cookies.

The reference on an error page

If something breaks and you are shown an error page, it carries a short reference. It identifies that one request, so you can quote it and we can find out what actually happened instead of guessing. Ordinary pages do not show one.

Against that reference we keep: the path you asked for (never the query string after it), which of our names you were on, the status the request finished with, how long it took, the browser's User-Agent, and what the screening described above had already decided about the request. Your address is not kept — it is hashed first, so repeat visits from one person line up with each other without the address itself being stored. If an address happens to appear inside any of the text we keep, it is struck out before the record is written.

How long: these records live only in the memory of the server process. It restarts roughly daily, and only the few thousand most recent page loads are held at any time, so a reference stops resolving within about a day and often sooner. Nothing about them is sold, shared, or used for advertising. Only an administrator can look one up. Asset and API requests are not recorded at all — only pages.

If you send a support report from an error page, that reference is attached automatically, so the report arrives tied to the real request rather than a description of it.

Things kept in your browser, not on the server

Game saves and preferences are written to your browser's local storage under keys beginning sqg:. Clearing site data for whichever name you are on removes them, and nothing on the server is needed to read them. The marker cookie described above is the only other thing we write for recognising a device, and clearing site data removes it too.

Saved game progress

Progress is also copied to the server so it survives clearing one device. It is stored as the game's name, the save data itself, and the random id from the squishes_save cookie. There is no name, no email and no address attached. Delete that cookie and the copy on the server can no longer be connected to you by anyone, including us.

Comments

The comment box stores only the text you typed and the time you typed it. No address, no id, no browser details. That also means a comment cannot be traced back to you — so please do not type anything into it you would not want a stranger to read, and never put a real name, a school, an email address or a phone number in one.

News stories you send in

Anyone can send a story to the news page. Nothing you send is published automatically: a person reads every one and either publishes it or declines it. What is stored is the title, the summary, the body, the name you signed it with — anonymous if you left that blank — the time you sent it, and the IP address it came from, which only an administrator can see and which is there because an open submission box is otherwise a free spam channel.

Submissions are kept after the decision, published or not, so the same story cannot simply be resent until a different answer comes back. A published story stays up until it is taken down. Ask through the Comment Box on the homepage to have one you sent removed.

If you make an account

An account is optional. It exists only for the web chat and the forums; the games, the saves and the search all work without one and always will. Sign-up and sign-in are handled by this site itself. Your password is never stored. What is stored is a scrypt hash of it — a one-way derivation that can confirm the right password and cannot be turned back into it.

What the site keeps against an account is short: an internal id, your email address, the display name and handle you chose, that password hash, your two public keys, your private key already encrypted under a passphrase only you know, when you verified, when you signed up and when you were last seen. That is the whole record.

• Chat messages are end-to-end encrypted. The server stores ciphertext it cannot read. The passphrase that unwraps your private key is never sent to it, so losing that passphrase means those messages are gone for everyone, including the operator.
• An email address is used to verify the account, to send the one reminder before the two-day deadline, and to answer you if you open a support ticket. It is not used for marketing and there is no mailing list.
• An account left unverified for two days is suspended, not deleted. Verifying the address brings it straight back.
• Forum posts and pinned threads are tied to the account that made them and are public.
• The device fingerprint described above is what makes one person, one account enforceable. If several accounts share a device, that is visible, and it is the signal used to act on it.
• Ask through the Comment Box on the homepage to have an account deleted. That removes the record above and the keys with it.

The name you go by

The site asks every visitor to pick a name before carrying on, and will keep asking until one is picked. It does not have to be your real name, and you are asked not to use one. A button will invent one for you if you would rather not think of one. The only names refused are slurs and names somebody else already holds.

The name is shown on leaderboards and in the corner of your own screen, where clicking it lets you change it. Against that name the site keeps the browser identifier described under Cookies, when you chose it, how many times you have changed it, when you were last seen, and the last IP address, ASN and network name you were seen on. That last part is written when your browser asks the server what it is called, which is once a page load, not once a request.

The site operator can search that list by name, by address or by browser identifier, and from a result can open the screening record for the address or ask that the person be challenged on their next request. This is how a report about somebody on a leaderboard gets matched to an address. Giving a name up releases it after a cooling-off period, during which nobody else may take it; the record goes when the name does.

If you would rather not be asked, do not pick one — the site will not let you past the question, so the alternative is not to use it. There is no way to browse anonymously and still appear on a leaderboard, because the leaderboard is the reason the name exists.

Leaderboard laps

When a lap is posted to a leaderboard, the site records the track, the lap id, the time, the name it was posted under, the browser identifier, and the IP address and ASN it came from, so that a lap can be checked and taken down if it was not really driven. Taking one down hides it from the board; it is not deleted, so it can be put back. These records are dropped after ninety days.

Play counts

The site counts how many times each game has been opened. That is a single number per game with nothing about who opened it.

Email

Account notices — the verification link, the reminder before the deadline, the note that an account has been suspended — and the replies to support tickets are sent from the site's own mail server, on its own machine, using addresses at plyz.org. Mail is not handled by a webmail provider on the site's behalf. The request to send one is passed to the paired scriptsfor.me service, which holds the mail credentials; the message, the address it goes to and the time it was sent are what travels.

There is no mailing list, no newsletter and no marketing mail. The only mail this site will ever send you is one you caused: a verification, a reminder, a suspension notice or an answer.

Other companies involved

• Cloudflare — sits in front of the site, runs the Turnstile check and the managed challenge, enforces edge bans, and holds the database the address rows described above are stored in.
• Google — reCAPTCHA, and the fonts the pages are set in.
• YouTube — the video page embeds through youtube-nocookie.com, YouTube's privacy-enhanced mode.
• ip-api.com — receives an IP address in order to answer what kind of network it is.
• scriptsfor.me — the paired site, run by the same person. It answers the reputation lookups the screening makes, holds the address rows described above, and sends the site's mail.
• Clerk — sign-in for administrators only. Ordinary accounts do not go through it.
• Heroku and an Oracle Cloud machine — run the server, the mail, and the pages you see when the site is down or your address is blocked.

What the site never does

• No advertising, no ad networks, no retargeting pixels.
• No selling, renting or sharing of anything collected.
• No analytics SDKs, no third-party session recording.
• No email address, no sign-up and no password is ever asked for to play a game.
• No password is ever stored, even for an account — only a one-way hash of one.
• No recording of what you type. The timing of your keystrokes is measured; the characters are not read, not sent and not stored.
• No reading of chat messages. They arrive encrypted and are stored that way.

Younger visitors

Plenty of the people here are at school. The site is built so that it never needs to know who you are: playing asks for no name, no age, no email address and no login, and it cannot send you anything. The three places personal information could get in are a comment you type yourself, a story you send to the news page, and the optional account for the chat and the forums, which does ask for an email address. Do not put a real name, a school or a phone number into any of them. If you are under 13, do not make an account; play the games instead, which is the whole site as far as anything needs to know. The screening described above measures a device and a connection, not a person — it has no idea how old you are and never asks.

Your choices

• Clearing cookies and site data removes every cookie, every local save and the stored device id listed above. The site keeps working; you will simply be asked for a check again.
• Blocking cookies entirely still lets you browse and play, but progress will not be kept and you may be asked to pass a check more often.
• Clearing site data does not remove the row holding your IP address, and it does not remove the device fingerprint — a fingerprint is calculated from the machine, not stored on it, so a fresh browser produces the same one. Both live on the server. You can look at what screening has on you at the screening lookup.
• To ask for something to be removed — the row for your address, the device record, a story you sent in — use the Comment Box on the homepage.
• If you are blocked, or asked for a check over and over, and you think that is wrong, ask for it to be reviewed the same way, quoting the address shown at security.squishes.shop, which answers even from a blocked connection.

Security

Everything is served over HTTPS. Cookies that prove something — a passed check, a save id — are cryptographically signed, so they cannot be edited or forged. Keys and secrets live in the server's environment and are never sent to the browser.

Changes

If this policy changes, the date at the top changes with it. There is no mailing list to notify, so the date is the honest signal.

Questions or a removal request? Use the Comment Box on the homepage. See also the Terms of Service, How screening works and where the site is moving. Press ESC twice at any time to switch to Google Classroom.