Effective 5 October 2026
Privacy policy
This policy explains how Genese handles information when visitors read our English-language editorial resource from Indonesia or elsewhere. It applies to the website, contact messages, correction requests and ordinary browsing. Genese is based at Jalan Kemang Raya No. 12, Mampang Prapatan, Jakarta Selatan, 12730, DKI Jakarta, Indonesia. Questions may be sent by phone at (021) 7586-9172.
1. Scope and responsibility
Genese is responsible for deciding why basic website information is processed. We collect only what is reasonably connected to operating, securing and improving the publication. We do not sell reader profiles or use the site to create medical records. This document applies from 5 October 2026 and replaces earlier website wording. In practice this means Genese acts as the data controller for the website rather than any advertising network, analytics vendor or printing partner that might later be engaged. For example, when a visitor reports a broken link through the contact form, the controller role determines who decides how long that message is kept and who may see it. The practical consequence is that a reader can direct a privacy question to one organisation, Genese, rather than contacting several vendors separately. An edge case arises when a third-party embed, such as a video player, briefly appears on a page; in that narrow moment the embed provider may act as an independent controller for its own cookies, a distinction explained further in the cookie policy. This approach is consistent with the controller and processor concepts set out in Indonesia's Law No. 27 of 2022 on Personal Data Protection.
- a) Genese does not transfer control of reader data to advertising exchanges or data brokers.
- b) Any future plugin or widget that collects information independently will be named here before it goes live.
- c) Where a vendor acts as an independent controller for a specific feature, that scope is stated on the relevant page.
-
2. Information collected
Server logs may include IP address, browser type, requested URL, date and time, referrer and security events. When a visitor contacts us, we receive the name, email address and message they choose to provide. We do not ask contact visitors to submit health diagnoses, financial credentials or government identity numbers. A typical server log entry might show a timestamp, a partially masked IP address, the page requested and the browser family, without a field that identifies a visitor by name. For example, if an unusual volume of requests targets the contact endpoint from one address, that log entry helps our hosting provider distinguish ordinary traffic from an automated script. The practical consequence is that routine reading of articles leaves a technical footprint but not a named profile, since the two data sets are not linked by default. An edge case involves a visitor who includes personal detail inside a free-text message, such as a training history; that content is treated as part of the message itself rather than as a separate collection category. This separation mirrors the data-minimisation expectation found in the Personal Data Protection Law, which asks organisations to limit collection to what a stated purpose requires.
- a) Technical fields support security and delivery, not a browsing history tied to a name.
- b) Free-text fields submitted voluntarily are stored only as part of that specific message thread.
- c) We do not request national identity numbers, payment details or insurance information through the contact form.
-
3. Legal basis and purpose
We process technical data where it is necessary for security and reliable delivery. We use contact details to respond to a message or correction request. Optional analytics, where enabled, rely on consent recorded through the cookie banner, and a visitor may reject that choice without losing access to editorial pages. For instance, a sudden spike in failed attempts on an administrative page would be logged and reviewed purely to protect the publication, independent of any individual's consent status. When a reader asks for a correction, the basis shifts to the step necessary to respond to that specific request rather than to general marketing. The practical consequence is that declining optional analytics has no effect on whether a contact message receives a reply, because the two processes rest on different grounds. An edge case occurs if a visitor withdraws analytics consent mid-session; any analytics script already loaded stops collecting new events but does not retroactively delete the technical security log, which follows its own retention rule described below.
- a) Security logging relies on a legitimate interest in keeping the site available and safe.
- b) Responding to a message relies on the step necessary to address that specific request.
- c) Optional analytics, where used, relies on a recorded and revocable consent choice.
-
4. Retention periods
Security logs are normally retained for 30 days and then deleted or aggregated. Contact correspondence is retained for 24 months after the last meaningful exchange so that we can track corrections and continuity. Cookie-choice information remains in the browser until removed by the visitor; consent records used by a measurement service are retained for up to 13 months. Thirty days is typically enough time for our hosting provider to identify a pattern of abuse, such as repeated scraping, without keeping logs indefinitely. For a correction request, the 24-month window allows us to refer back to an earlier exchange if a reader follows up about the same article months later. The practical consequence is that older contact threads are periodically reviewed and deleted once they no longer serve an active editorial or security purpose. An edge case involves a safety-related inquiry, which may be retained longer where a genuine compliance obligation applies, with the extended period documented internally. The 13-month ceiling mentioned for consent records reflects common regional practice for cookie-consent logs, also referenced in the cookie policy.
- a) Security logs: approximately 30 days, then deleted or aggregated into anonymised statistics.
- b) Contact correspondence: up to 24 months from the last substantive reply, then archived or deleted.
- c) Consent records for optional analytics: up to 13 months, after which consent must be refreshed.
-
5. Service providers
Hosting, security, email delivery and limited measurement providers may process information under contractual instructions. They may not use Genese contact messages to build advertising audiences. Provider access is limited to the information required for their function and is reviewed when services change. Our hosting provider, for example, operates the servers that deliver these pages and is bound by a data-processing arrangement limiting use of logs to service delivery and security. An email-delivery provider may temporarily route a contact submission before it reaches our inbox, but does not retain a permanent copy for its own marketing. The practical consequence is that a reader's message passes through a small, defined set of technical intermediaries rather than an open network of advertisers. An edge case arises if a provider is replaced; access for the outgoing vendor is revoked and any residual copies are requested to be deleted under the existing contract. This layered approach reflects the processor obligations described in the Personal Data Protection Law, which requires a written basis for any party handling data on a controller's behalf.
- a) Hosting and security providers process technical logs strictly for uptime and protection.
- b) Any measurement provider, if activated, is limited to aggregate statistics rather than individual profiles.
- c) Providers are reviewed periodically and replaced if their safeguards no longer meet our standard.
-
6. Cookies
Genese uses a browser key named cookieChoice to remember whether a visitor selected Accept or Reject. It is a first-party preference and has no fixed server-side lifespan; it remains until browser storage is cleared. Optional analytics cookies, if activated in a future deployment, will be described by name, purpose and lifespan on the cookies page before use. The cookieChoice value is read only by the site's own script and is not shared with an external advertising network. For example, a returning visitor who selected Reject will not see the banner reappear on their next visit, because the browser already stores that choice locally. The practical consequence is that essential functioning of the cookie banner does not depend on any optional or third-party cookie. An edge case occurs when a visitor uses private browsing, which typically clears the cookieChoice value at the end of the session, so the banner may reappear next time even though no preference was actually withdrawn.
- a) cookieChoice: first-party, stores accept or reject, persists until browser storage is cleared.
- b) No cross-site advertising identifier is set by the core site template.
- c) Any future analytics cookie will be documented by name and duration before deployment.
-
7. International transfers
Some infrastructure providers may process data in countries outside Indonesia. Where that occurs, Genese uses contractual safeguards and limits the transferred fields. Readers may ask for a description of the relevant provider and transfer mechanism through the contact details on this site. A content delivery network, for instance, may cache static files on servers located outside Indonesia purely to load pages faster for a given region. When that happens, the transferred fields are typically limited to technical request data rather than the content of a contact message. The practical consequence is that a reader's location can slightly influence which data-centre handles a request without changing who is legally responsible for that data. An edge case involves a provider based in a jurisdiction with a different data-protection framework; Genese relies on contractual clauses requiring a comparable standard of protection before any such transfer occurs.
- a) Transfers are limited to infrastructure necessary for hosting, security and delivery.
- b) Contractual safeguards require recipients to protect data to a comparable standard.
- c) A description of a specific transfer arrangement can be requested through our contact details.
-
8. User rights
Subject to applicable law, a person may request access, correction, deletion, restriction or an explanation of processing. Send the request from the relevant contact address and identify the message or browser information concerned. We may ask for reasonable verification so that information is not disclosed to the wrong person. For example, a reader who sent a correction request last year may ask what information from that message is still retained and request its deletion if it is no longer needed. Exercising the right to restrict processing might mean asking Genese to pause further contact on a thread while a dispute is resolved. The practical consequence of a verified request is that we confirm what action was taken and roughly when, rather than leaving the outcome unclear. An edge case arises when a request cannot be matched to any stored record, such as an email address that was never actually submitted; in that case we explain the search performed rather than assume the data exists.
- a) Access: ask what information, if any, is held about a specific message or browsing session.
- b) Correction or deletion: ask for inaccurate detail to be fixed or old correspondence removed.
- c) Restriction or objection: ask that further processing of a specific thread be paused pending review.
-
9. Complaints
Contact Genese first so we can understand the concern and respond. We aim to acknowledge a privacy request within seven days and provide a substantive response within 30 days, unless complexity requires a documented extension. A person may also contact the relevant Indonesian authority or regulator available for their situation. For example, if a reader believes a contact message was kept longer than the stated 24-month period, naming the specific date and subject line lets us check the actual record rather than reply in general terms. The practical consequence of contacting us first is usually a faster resolution than escalating immediately, since most concerns can be addressed once the full file is in front of us. An edge case involves a complaint that cannot be resolved internally to a reader's satisfaction; the reader remains free to pursue the matter with the relevant Indonesian data-protection authority, once formally designated under the Personal Data Protection Law, or another applicable body for their location. Response timing may be extended beyond 30 days for an unusually complex request, but we explain the reason and give a revised estimate rather than leave the request open indefinitely.
- a) Acknowledgement: typically within seven calendar days of a verified request.
- b) Substantive response: typically within 30 calendar days, extended only with a documented reason.
- c) External escalation: available if internal handling does not resolve the concern.
-
10. Security
We use access controls, limited retention, transport encryption where supported and routine review of administrative access. No internet service can promise absolute security. If a material incident affects personal information, Genese will assess notification duties and communicate through a reasonable channel. Administrative access to the website, for example, is limited to a small number of individuals and reviewed periodically to remove access that is no longer needed. Transport encryption protects data such as a contact submission while it travels between a visitor's browser and our servers. The practical consequence is that casual interception of ordinary browsing or message submission is made meaningfully harder, though no method can be described as flawless. An edge case involves a suspected compromise of a third-party provider rather than Genese's own systems; in that scenario we would still assess whether any reader information was exposed and communicate accordingly.
- a) Access control: administrative accounts are limited and reviewed on a periodic basis.
- b) Encryption in transit: supported connections use standard transport security.
- c) Incident review: a material incident triggers an assessment of notification duties.
-
11. Children and sensitive information
The publication is intended for adults and does not knowingly solicit information from children. Please do not send medical records, detailed diagnoses, passwords or unrelated sensitive documents through the contact form. If such information is received unnecessarily, we will restrict access and delete it when the communication purpose ends. For example, a message mentioning a minor's participation in a school sports programme would still be treated as adult-submitted correspondence rather than data about a child subject, unless it clearly concerns a child's own account. The practical consequence of receiving sensitive detail unprompted, such as a specific diagnosis, is that Genese limits internal visibility of that message and deletes it once the underlying question is resolved rather than retaining it with ordinary correspondence. An edge case arises if a message appears to come from someone under the age of majority; we respond narrowly to the factual question asked and avoid retaining unnecessary personal detail.
- a) The site is not directed at children and does not knowingly collect their personal data.
- b) Unsolicited sensitive detail is minimised internally and deleted once no longer needed.
- c) Readers are asked to avoid including medical records or identity documents in messages.
-
12. Changes and contact
Revision history: 5 October 2026, policy refreshed for the current site structure and cookie-choice behaviour. Material changes will be dated at the top of this page. Questions can be sent to Genese at Jalan Kemang Raya No. 12 or discussed by calling (021) 7586-9172. For example, if Genese begins using a new analytics provider, that change would be reflected first on the cookie policy and then summarised here with a new dated entry. The practical consequence of dating revisions is that a returning reader can quickly see whether anything materially changed since their last visit. An edge case involves a minor wording clarification that does not change how data is actually handled; such edits may be made without a new dated entry, while any change affecting retention, rights or transfers will always be dated. Readers who want a copy of an earlier version of this policy may request one through the contact details above.
- a) 5 October 2026: current version describing site structure and cookie-choice behaviour.
- b) Future material updates will add a new dated entry above this one rather than replacing it silently.
- c) A request for a prior version of this policy can be made using the contact information on this page.