privacy policy

who we are, and how to reach us

Hackathon Singapore (hackathonsingapore.com) is an independent directory of hackathons in Singapore. Its operator is the organisation responsible for everything described below under Singapore’s Personal Data Protection Act 2012 (the PDPA). This is one of eight national editions of the same directory; each edition runs as its own isolated service with its own database, and no personal data moves between them.

We are not going to print a company name or a postal address here that we cannot stand behind: the operating entity's details are still being settled, and inventing them would be a strange way to open a privacy policy. Everything else on this page is a description of software that is running today, and can be checked against how the site behaves.

who publishes this, and the data protection officer

The PDPA requires an organisation that collects personal data to designate a Data Protection Officer — a person responsible for making sure the organisation complies with the Act — and to make that officer’s business contact information available to the public.

Neither the operating entity nor a DPO is named here yet, and this is the honest reason why: the entity is not settled, so there is nothing truthful to put here. We would rather say that plainly than publish an invented company name, a made-up UEN — which is a real, checkable registry number — or an address nobody sits at. Both will be published as soon as those details are provided, and this policy will be updated and re-dated when they are. Until then, everything on this page that does not depend on knowing the entity’s name is complete and accurate, and the submit form is the working route to whoever is behind it.

cookies

This site sets a few cookies of its own, and there is no banner. On this site, ad measurement with Meta is on unless you switch it off at cookie settings, which shows your answer and changes it with one click. Your answer there is stored as hx_consent (granted or denied, six months, readable only by our server, never sent to anyone else).

Unless you have switched it off, our server sets three more cookies. hx_id is a random visitor number that contains nothing about you (HttpOnly, six months, readable only by our server); Meta never receives it as it is — only its SHA-256 hash, as external_id. _fbp is a browser id set by this site, not by Meta: fb.1. followed by the time it was created and a random number (90 days, not HttpOnly); an _fbp left from an earlier visit is reused. When you arrive from a Meta ad, _fbc holds the ad's click id and the time you arrived (90 days, not HttpOnly). Switching it off in cookie settings deletes hx_id, _fbp and _fbc. See Meta below.

Browsing the site also stores two further values in your own browser, and neither of those is ever sent to us:

nl_shown

Session storage. Records that the newsletter popup has already appeared, so it does not reappear while you keep the tab open. Cleared when you close the tab.

nl_subscribed

Local storage. Records that you already subscribed, so the popup stops appearing for good. Cleared whenever you clear site data.

Both hold the literal value 1. They contain no identifier and are readable only by your browser on this site.

For completeness: there is a third value, admin_api_key, which the staff-only /admin console keeps in session storage so a reviewer does not retype their key on every action. This one is sent to us — the console attaches it to every admin request as an X-API-Key header, which is how the backend tells a reviewer from a stranger. It is a credential of ours rather than information about you, it only ever exists in the browser of someone who has typed that key in, and no public page of the site sets it or reads it.

analytics

There is no Google Analytics, no tag manager and no session-recording tool on this site. No code from Meta runs in your browser either: ad measurement with Meta is done from our server, described under Meta, and it is on unless you switch it off. The small amount of JavaScript that runs (the search box, the subscribe forms, the submit wizard) is written inline and talks only to this site's own API; the only script from another company is PayPal's, on the submit page.

how we count what's popular

We do measure which listings get looked at, so we know which events are worth featuring and whether the directory is useful. This happens on our server, not in your browser: there is no tracking script, no beacon and no cookie involved in that count.

Each listing keeps four running counters, per day: times shown in a list, times clicked from a list, times its page was opened, and times its registration link was followed. What gets stored is:

Stored

Which event, which calendar date (UTC), which of the four counters, and a count.

Not stored

Your IP address. Your browser's user-agent string. The page you came from. Any session or visitor ID. The time of day. Any free-text field.

To avoid counting the same person twice in one day, the server takes your IP address and browser user-agent, combines them, and stores a shortened one-way SHA-256 hash of the result. It also uses them, in memory, to discard traffic from bots and crawlers. The IP address and user-agent themselves are never written to disk — only the hash is kept.

Mechanically: the page-rendering process passes the hit to our own counting endpoint over the server's internal network, authenticated with a shared secret, and does not wait for the answer. Your browser is not involved and never contacts it. That is also why blocking scripts or trackers makes no difference to these counters — there is nothing in the page to block.

We want to be precise rather than flattering here: that hash is pseudonymous, not anonymous. It cannot be read back to reveal an IP address, but the same visitor produces the same hash on the same day. That is enough for us to treat it as personal information and tell you it exists, what it is for, and when it disappears. Anything older than 90 days is deleted — to be exact about the mechanism, that cleanup runs when the service restarts rather than on a timer, so a hash can outlive 90 days by however long the service has been up. The daily counters that remain afterwards are plain totals with nothing personal in them, and we keep those indefinitely.

Why we may do this under the PDPA. We rely on the Act’s legitimate interests exception to the consent requirement, and this paragraph is us saying so, which is what the Act expects of an organisation that relies on it. The interest is knowing which listings are actually useful; the method is the least identifying one we could implement, with no cookie, no client-side script and no third party involved. You can ask us to stop counting you at any time, through the route above.

the newsletter

If you subscribe, here is the entire record we create:

Your email address

Lowercased and trimmed.

A timestamp

When you subscribed.

That is genuinely all of it — the database table has three columns and the third is an ID number. We do not record your IP address, your browser, or which page you subscribed from, and the three signup forms on the site all behave identically in this respect.

Your address is stored in this site's own database on our own server. It is not sent to a mailing-list provider, not shared, not sold, and not used to build a profile. If we later start sending through an email provider, that provider will be named here before any address reaches it.

How this works under the PDPA. Your consent, given by entering your address, and used only for the purpose you gave it for. The Act gives you the right to withdraw that consent at any time; do it through the submit form and we will delete the record rather than merely flag it. We keep addresses until you ask us to stop.

submitting an event

The submit form collects the event's details — name, URL, description, organisation, topic tags, format, location, venue, street address, postal code, start and end dates, ticket name and price, prize value and description, and a link to a banner image — plus a contact email address, which is the only part that is necessarily personal data. If you buy a featured listing, we also record the PayPal order ID and the date you want the banner to start. There is no file upload anywhere in the form: the image is a link to a picture that already exists on your own page.

Event details are published on this site, which is the point of submitting them. Your contact email is not published — it is used to reach you about the listing.

How this works under the PDPA. Your consent, given by sending us the form, for the purpose the form is plainly for — listing the event you asked us to list. Submissions are kept as our record of what was published and why.

other companies that see something

We deliberately keep this list as short as we can, but it is not empty, and pretending otherwise would be the easiest thing in this policy to get wrong:

Google Fonts

Every page loads two typefaces from Google's font servers, so Google receives your IP address, your user-agent and the address of the page you are viewing — on every page view, before you interact with anything, and without our asking you first. This is by some distance the most significant third-party data flow on the site, and it is worth stating plainly rather than burying: an IP address can identify a person, this happens on every page view before you interact with anything, and we did not ask you first. Serving the same two fonts from our own server removes the flow completely; that is the change we want to make, and until it is made this paragraph stays here saying so.

Meta (Facebook)

We advertise this directory on Facebook and Instagram and use Meta's tools to see whether those ads bring visitors. No code from Meta runs in your browser: our server reports to Meta's Conversions API directly, and on this site it does so unless you opt out at cookie settings. It reports a page view, an event page opened, a registration link followed, a newsletter signup, an event you submit through the submit form (ListingSubmitted — the listing type, never your contact email) and a featured-listing payment (Purchase — the price and the PayPal order id). Each report carries your IP address, your browser's user-agent string, the click id (_fbc) and browser id (_fbp) if they exist, and the SHA-256 hash of hx_id as external_id; a newsletter signup also carries your email address as a SHA-256 hash so Meta can match the signup to an ad — we never send the address itself, and nothing else you type — and signups, submissions and payments carry a hash of this site's country code. To stop it: opt out at cookie settings, one click: that deletes hx_id, _fbp and _fbc and stops every report from the next page. What Meta already holds is governed by Meta's own tools. Meta processes this under its own privacy policy, partly outside your country.

PayPal

The /submit page loads PayPal's payment script, so PayPal receives the IP address and user-agent of everyone who opens that page, whether or not they pay, and sets its own cookies under paypal.com. No other page loads it. Payment is handled entirely on PayPal's side — we never see or store card details, only an order ID.

Bunny.net

Hosts the endpoint that receives event submissions, as described above — it sees the form's JSON and the IP address it arrives from, and nothing else. It is not involved in ordinary browsing, and no file is ever uploaded to it.

Each of these companies processes data under its own privacy policy and on its own global infrastructure. All three are US-headquartered, so where they receive your IP address, that data leaves Singapore. The PDPA has a transfer limitation obligation for exactly this: an organisation sending personal data out of Singapore has to satisfy itself that it will be protected to a standard comparable to the Act’s own. That obligation sits on us rather than on you, and we are not going to dress up how we meet it — these are three large providers operating on their own published terms, we are not in a position to audit them, and we are not going to claim we have. The honest summary is that avoiding the transfer means self-hosting the fonts (planned) and not opening /submit. Beyond these three, no third party receives anything about you.

Two more companies sit near the site without receiving anything about your browsing: the server provider that hosts it, and the DNS provider that answers the name lookup turning hackathonsingapore.com into an address before your browser ever contacts us. A DNS answer is a name, not a page: whoever answers it is told which domain was looked up, never which listing you read. There is no such provider to name today, because the domain is not registered yet and has no DNS zone at all — the same fact that is why there is no email address anywhere on this site. One will be named here when there is one. Nothing else sits in between either: the site is not behind a proxy or content network on the page-serving path, so no such intermediary sees your page views.

links out to organisers

Registration links go through a /go/ address on this site. That step adds one to the "registration link followed" counter described above and then immediately forwards you to the organiser's own page — usually on Eventbrite, Devpost, Luma or Meetup, sometimes the organiser's own site. It stores nothing else. The links are marked so that the destination is not told which page you came from.

Once you land on an organiser's site — or any other site we link to — you are covered by their privacy policy, not ours. Banner images on the listings we collect ourselves are downloaded and served from our own domain rather than hotlinked, so viewing one of those listings does not announce you to the organiser. The exception is an event submitted through our form with an image hosted elsewhere: that stays a link, and your browser fetches it from whichever server it lives on, the same as any image on any web page. Every listing here today is in the first category.

logs

The application itself keeps no visitor log files: no access log, no request log, no record of which pages you viewed. As with any website, the web server and network provider in front of it may hold short-lived operational logs for security and reliability.

how long we keep things

Newsletter address

Until you ask to be removed. There is no expiry — we would rather hold an address you still want on the list than quietly drop it.

Event submission

Kept after it is processed, as the record of what was published and why, including a rejected one. Deleted on request; nothing purges it automatically.

Counting hash

90 days — see the note above about the cleanup running at restart rather than on a timer.

Daily counters

Indefinitely. They are plain totals per event per day with nothing personal in them.

organiser accounts

Organiser accounts are optional. You only have one if you made it yourself at /organiser/register, to list a hackathon or to claim one we already list. Browsing this site never creates an account and never needs one.

If you do have one, this is everything it holds:

The account

Your email address, the name you chose to give (optional) and the language you signed up in. The password itself is never stored — only an argon2id hash of it, which cannot be turned back into the password.

Sign-in sessions

One record per device you are signed in on: your browser's user-agent string, a truncated hash of your IP address rather than the address itself, and when the session was created and last used. A session expires 30 days after it was last used, and you can end any of them yourself.

Your organisation

Its name, website, description, contact address and logo link, plus who else is a member and at what role. An invitation you send holds the invited address until it is accepted, revoked or expires.

What you create

The listings you publish through the portal, and any claim you file on a listing we scraped — including the evidence you wrote and the decision made on it.

The numbers an organiser sees. The per-listing counts described above are broken down, for that listing's organiser, by city and by where the visit came from. The city is worked out from the visitor's IP address against a database file held on our own server (DB-IP City Lite, CC BY 4.0), so no lookup leaves this machine and the address itself is never written down: what is stored is the city name, one of five coarse traffic labels (search, social, this site, other, direct) and the same truncated 90-day hash of IP address and browser string the counters already use. None of it identifies a visitor, and none of it is shown to anyone but that listing's organiser.

The weekly summary email is off until you switch it on. An organiser can ask for a short weekly email of their own listing numbers from the portal dashboard, and switch it off again in the same place.

Who can see it. Your organisation's details and its listings are visible to the other members of that organisation. A claim you file is read by the person who runs this site, in order to approve or reject it. None of it is published — the contact address on a listing is never shown on the site — and none of it is sold, shared or handed to an advertiser.

A copy of it, or the door. /organiser/account downloads everything above as a JSON file, and deletes the account — with its sign-in sessions and any organisation you were the only member of — from one form. Deletion is refused while you are the last owner of an organisation that still has listings: hand ownership over, or remove those listings, first, so nothing goes dark by accident.

your rights

Under Singapore’s Personal Data Protection Act 2012 you have the right to:

• Access — ask what personal data we hold about you and how it has been used or disclosed in the past year.
• Correction — have anything inaccurate or incomplete corrected.
• Withdrawal of consent — withdraw consent for any purpose you gave it for, at any time. For the newsletter we delete the row rather than flag it.

We go further than the Act requires on two of these, because the data is so small that there is no reason not to: we will delete a newsletter address or an event submission on request rather than merely stopping its use, and we will export what you gave us in a machine-readable form — in practice your email address and, if you submitted an event, the submission JSON. Neither is a PDPA obligation; both are things we will simply do.

You may also withdraw consent for the newsletter at any time, which does not affect anything done before you withdrew it. We do not carry out automated decision-making or profiling. We do not sell personal information to anyone, and we have never disclosed any of it for money or for anyone else’s advertising.

What each of those means concretely, given how little there is:

• Your newsletter subscription — we can confirm whether an address is on the list, export it, and delete it.
• An event submission — we can send you what was submitted, correct it, or remove it.
• The 90-day counting hash — it is not searchable by name or email, so we cannot single yours out to show you or delete only yours; it expires on the schedule described above, and you can object to the counting entirely.

Ask through the submit form — that is the working route while there is no published address. There is no charge, we do not require a particular form of words, we will not treat you differently for asking, and we aim to answer well inside the thirty days in which the PDPA requires an organisation either to answer an access request or to tell you when it will. We honour these rights for everyone who asks, wherever they live.

If you think we have handled your data badly, tell us first — we would rather put it right than have you take it elsewhere. But you also have the right to complain to a supervisory authority, and you can do that without coming to us at all. Singapore has exactly one: the Personal Data Protection Commission (the PDPC, pdpc.gov.sg). It takes complaints online, and you do not need a lawyer or a particular form of words.

The PDPC is the authority we expect to be answerable to, on the basis that this edition is aimed at Singapore. We have stopped short of writing anything stronger, because the organisation the Act attaches its obligations to is exactly the detail this page cannot yet state — see the section on the operator and the DPO above. It will be confirmed here once the entity is settled.

The PDPA also establishes Singapore’s Do Not Call Registry, which the PDPC administers and which covers telephone marketing — voice calls, text messages and faxes. It has no bearing on this site: we do not ask for a telephone number anywhere, we hold none, and we send no telephone marketing of any kind. It is named here only so you know we have not quietly skipped it.

if there is ever a data breach

Since 2021 the PDPA has required an organisation to assess any breach of the personal data it holds and to notify the PDPC when the breach is a notifiable one — either because it is likely to cause significant harm to the people affected, or because it is of significant scale, which the regulations put at 500 or more affected individuals. The Commission has to be told no later than three calendar days after the organisation concludes the breach is notifiable, and where significant harm is likely the affected people have to be told as well.

It is worth saying concretely what that would mean here, because the answer is unusually small. The personal data this site holds is a list of email addresses, a set of event submissions each with a contact address attached, and a ledger of one-way hashes that cannot be read back into anything. There are no passwords, no card details, no home addresses and no telephone numbers to lose. There has been no breach to notify. If there is one, that is the obligation we are under, and we would rather you knew its shape now than met it for the first time in a notification.

children

This is a listings site for public events and is not directed at children. Singapore’s PDPA fixes no minimum age at which a person can consent, and we are not going to invent one: the Act relies on the ordinary law of capacity, and the PDPC’s guidance is that a minor who genuinely understands what they are agreeing to can consent, with a parent or guardian consenting where they cannot. That is deliberately different from the European editions of this directory, which name a statutory number because their law provides one. If you are a child, please ask a parent or guardian before you subscribe to the newsletter or submit an event. Some listed hackathons are student or school events with their own age rules — those are set by the organiser, not by us.

changes

This policy describes the site as it works on the date shown at the top. If what the site does changes — a mailing provider, self-hosted fonts, a different submission endpoint — this page gets updated to match, and the date changes with it. We make no claim to hold any privacy certification or third-party audit; this is a plain description of the system, and you are welcome to ask us about any part of it.