Privacy Policy

This notice describes the personal data re:Marque processes in providing the service, the purposes and legal bases of processing, retention periods, and the rights of users concerning their data. The notice uses plain language; each section defines the terms used in it. The Provider receives questions about this notice at the address given in “Contact”.

1. Controller details

The re:Marque platform is operated by Galcsik Győző Korlátolt Felelősségű Társaság (registered seat: 1063 Budapest, Szív utca 16. I. em. 17. ajtó, Hungary; company registration number: 01-09-389812; tax number: 27431913-2-42; represented by: Galcsik Győző, managing director; email: [email protected]) (the “Provider”). The Provider is the controller of the personal data described in this notice.

The Provider has not appointed a data protection officer because Article 37 GDPR does not require one. Privacy questions may be sent to the email address above and are handled by the managing director.

In this notice, the user is the natural person using the platform. Where the user acts for an organisation, that organisation is called the user’s organisation.

2. Applicable laws and principles

The Provider processes personal data in accordance with Regulation (EU) 2016/679 of the European Parliament and of the Council (General Data Protection Regulation, GDPR) and 2011. évi CXII. törvény on the Right of Informational Self-Determination and Freedom of Information (Infotv.). This notice provides the information required by Articles 13 and 14 GDPR. The Provider follows these principles when processing data:

• Lawfulness, fairness and transparency: the Provider processes data lawfully, fairly and in a way that is transparent to the data subject.
• Purpose limitation: the Provider collects data only for specified, explicit and legitimate purposes, and do not process it in a way incompatible with those purposes.
• Data minimisation: the Provider processes only data that is necessary and relevant to the purpose of the processing.
• Accuracy: the Provider corrects or erase inaccurate data without delay.
• Storage limitation: the Provider keeps data only for as long as necessary to achieve the purpose.
• Integrity and confidentiality: the Provider protects data through appropriate technical and organisational measures.
• Accountability: the Provider can demonstrate compliance with these principles.

3. Controller and processor roles

The Provider acts as a controller or processor as described below. The distinction determines against whom the user may exercise rights.

The Provider is the controller of data about people who hold re:Marque accounts, including their names, email addresses, credentials, preferences and service usage data. This notice applies to that data.

The Provider is a processor for content uploaded to re:Marque, including tickets, comments, screenshots, attachments and other data captured from websites used for the work. The user’s organisation is the controller of this content. The Provider processes it only on that organisation’s instructions under the “Data processing terms (GDPR Article 28)” section of the Terms & Conditions. This notice is not a contract: the Provider’s data processing commitments are in the Terms & Conditions, which the user accepts when creating an account.

If the user uses re:Marque on the user’s own behalf rather than for an organisation, the user is the controller of that content. In that case, the data processing terms in the Terms & Conditions apply directly between the user and the Provider.

If the user is an employee or client of an organisation that uses re:Marque and wants content removed, the user must contact that organisation. The organisation decides what happens to the content. The Provider helps it carry out that decision, but do not override its decision about its own data.

4. Data processed, purposes, legal bases and retention periods

To create an account, providing the user's name, email address and password, or a Google or Microsoft account instead of a password, is a condition of entering into the contract; an account cannot be created without them. Providing all other data is voluntary. One category of data does not originate from the user: if someone invites the user to a team, the Provider receives the user's email address from them before the user has any relationship with the Provider. The Provider uses it only to deliver and manage that invitation, on the basis of the Provider's legitimate interest in letting teams invite the people they work with (GDPR Art. 6(1)(f)). An invitation expires after the period the inviting team chooses (1, 7 or 30 days) or does not expire, and an expired link cannot be used. A team may also create a single-use invite link that contains no email address: it stops working once it has been used, and the person who accepts it provides their own email address, which the Provider records on the invitation. The inviting team may revoke an invitation at any time, and the Provider deletes it when the team is deleted. This paragraph is the notice required by GDPR Article 14. If the invitee requests this at the address given in “Contact”, the Provider deletes the invitation and the user's email address in it and stop this processing.

Screenshots can contain other people’s personal data. If the user captures a page showing customer records, names or email addresses, that personal data is stored in re:Marque. The user's organisation is the controller for it and is responsible for having a lawful basis to put it there. Capturing more data than necessary should be avoided.

5. Browse sessions

Browse mode can carry the user's login to another website, so that the user can report issues on pages that only exist behind a sign-in. When the user signs in to a site inside Browse mode, the cookies that site sets are stored by the Provider on the user's behalf.

• The Provider stores the cookie store encrypted at rest with AES-256-GCM.
• It is scoped to one user and one registrable domain. Another member of the user's team cannot use it, and neither can the Provider makes it available to them.
• It expires 7 days after the user last uses it and is deleted no later than 30 days after creation, whichever comes first.
• The user can delete it at any time from the Browse toolbar with “Forget site login”.
• Administrators have no bypass for this data. It is the one place in re:Marque where the usual admin override does not apply.
• The scripts of a website loaded in Browse mode run on the Provider's origin (remarque.app), so they may set their own cookies or browser storage entries in the user’s browser, for example for that site’s own analytics. The Provider does not read, use or forward them; the operator of the website the user loaded is responsible for them.

Browse mode should be used on pages showing health data, financial account details or other highly sensitive information only when capturing that data is necessary to report an issue.

Limitations of the design. Browse mode renders the third-party page on the Provider's own origin, which is what makes the annotation overlay work. A hostile page loaded this way could, in principle, reach the user's other Browse sessions in the same way it could reach the user's own browser. The Provider limits the possible impact through separate cookie jars for each domain, short expiry and exclusion of access across users and by administrators. The Provider cannot, however, guarantee complete isolation between the sites the user browses. Browse mode should be used on trusted sites and with accounts limited to the permissions needed to see the problem.

6. Processing activities not carried out

The Provider does not carry out the following processing activities:

• No third-party analytics. There is no Google Analytics, no Plausible, no PostHog, no Mixpanel, no Segment, no Hotjar.
• No advertising or marketing trackers, and no advertising cookies.
• No third-party error-reporting or session-replay service.
• No profiling, and no automated decision-making that produces legal effects under Article 22 GDPR.
• The Provider does not sell personal data, and the Provider does not share it for anyone else’s marketing.
• The Provider does not use the user's content to train machine-learning models.

7. Cookies and browser storage

The Provider stores data on the user’s device only where it is strictly necessary for the service to work: cookies for sign-in and its security, text the user has entered but not yet submitted, and interface settings that the user has expressly chosen. These fall within the exception under 2003. évi C. törvény 155. § (4) on electronic communications and Directive 2002/58/EK Article 5(3), because they are essential to provide a service expressly requested by the user or remember the user’s own choice; neither requires consent. The Provider does not use analytics, tracking or advertising cookies at all. The cookie banner therefore provides information rather than requesting consent: it has a single acknowledgement button and no optional categories, because the Provider stores nothing the user could decline while continuing to use the service.

The table below lists cookies set on remarque.app, the application’s localStorage and sessionStorage entries, and entries placed by the widget on the user’s own website. The Provider writes localStorage entries only when the user changes the relevant setting; none are sent to the Provider's servers. Scripts belonging to third-party websites loaded in Browse mode run on the Provider's origin and may set their own cookies or storage entries there; the “Browse sessions” section describes these.

The widget stores nothing about the user's website’s visitors and draws no interface for anyone who is not a signed-in member of the project. A visitor’s browser fetches the small loader script from the Provider's origin and, on a website the user has configured as an environment, one hidden request that checks whether that browser holds its own re:Marque session; a browser without one gets a plain “no” and downloads nothing further. Neither request stores anything in the visitor’s browser or about the visitor.

8. Recipients and international transfers

To operate the service, the Provider currently engages three sub-processors: Railway Corp. (United States) hosts the application and database on servers in the European Union; Cloudflare, Inc. (United States) provides DNS, CDN and DDoS protection and stores uploaded files in the European Union; and Resend (Plus Five Five, Inc., United States) delivers notification and transactional emails. No provider processes personal data on the Provider's behalf without a data processing agreement under GDPR Article 28, and not every provider processes data for every account. Google Workspace (Google Ireland Ltd, Ireland) hosts the Provider's own legal, privacy and customer support correspondence, including the [email protected] mailbox. In that capacity, Google is the Provider's processor as controller and has no access to content uploaded to the service. The providers' roles, locations and transfer safeguards are listed individually in the “Annex: sub-processors” section of the Terms & Conditions. That annex also lists providers announced in advance but not currently engaged. They receive no personal data until activated. Account holders receive advance notice of activation by email, with a right to object, under “Data processing terms (GDPR Article 28)” in the Terms & Conditions.

Sub-processors process personal data only on the Provider's instructions. They do not decide independently how to use it, and the Provider is responsible for their activities. Apart from them, the Provider does not disclose personal data to third parties unless required by law. Even when a court, public prosecutor, investigating authority or other authority requests data, the Provider discloses only what is strictly necessary for the purpose of the request.

Service data is stored primarily on servers in the European Union. The providers engaged are established in the United States or belong to a group established there, and access from there counts as a transfer even when the servers are in the EU. For certified providers, transfers rely on the European Commission’s adequacy decision under the EU-US Data Privacy Framework. Otherwise they rely on the European Commission’s Standard Contractual Clauses, together with the supplementary measures those clauses require. The annex referenced above identifies the safeguard that applies to each provider. The Provider will send a copy of the applicable terms on request.

GitHub is not the Provider's sub-processor. If the user switches on the GitHub Issues mirror for a project, the Provider sends that project’s tickets to the repository the user designates. GitHub then processes that data for the user, under the user's own agreement with GitHub. The Provider has no contract with GitHub covering the user's repository, and the user is responsible for the lawfulness of that onward transfer. The mirror is off unless the user turns it on.

An issue the Provider opens there carries the ticket in full — its description, the reporter and assignee by name, tags, environment, page URL, checklist, browser and operating system, the element and text it points at, its attachments, and a link back to the board. If the ticket has a screenshot or an attachment, the issue serves them from a view-only public link the Provider's system creates for that ticket, so the image shows inside the issue and the files can be opened from it. That link needs no sign-in, and it is not narrower than the ticket: anyone who obtains it can open the ticket’s public page — its description, screenshot and the comments that are not internal — and fetch any file attached to the ticket or to one of its comments. It is created once and reused, it never allows commenting, and it stops working when the user revokes it or deletes the ticket or the project.

Comments are transferred with the ticket, regardless of their author. When comment synchronisation is on, a comment posted on a mirrored ticket is copied to the issue, and that includes a comment written by somebody who has no account with the Provider: a person the user gave a share link to, or a commenter imported from BugHerd who matched nobody on the user's team. Each is attributed by the display name they gave, which is what a reader of the issue sees. The Provider never writes their email address into the user's repository, and where the only name the Provider holds for somebody is an email address the Provider publishes no name at all. The Provider sends the comment to the destination chosen by the user. The user must therefore inform people with whom the user shares a ticket if their replies will also be placed in a repository.

Tickets and notes the user marks internal are held back from the repository unless the user switches on “Sync internal tickets” for that project. That switch is off by default, and switching it on is a decision about a destination the Provider does not control: everyone who can see the repository can then read them, and GitHub lets search engines index the issues of a public repository. The application warns the user in the project’s Integrations settings when the repository the user selected is public, or when the Provider cannot tell. Once it is on, an internal ticket’s issue is a full issue like any other: the same view-only link is created for it, its screenshot is embedded, its attachments are listed and reachable, and the issue says so in a notice at the top. Development notes, which re:Marque administrators and the AI agents they operate add to a project, count as internal here and follow the same switch.

The badge at the foot of each issue is drawn by the Provider. No third party is involved in it: the image is rendered by re:Marque, from the ticket’s number and a fixed line of text, and the address it is fetched from carries nothing else — no title, no status, no name. GitHub re-serves images in an issue body through its own image proxy, so the request reaches the Provider from GitHub and not from the person reading the issue, and it tells the Provider nothing about who that person is.

BugHerd is not the Provider's sub-processor. This is a customer-directed integration. When the user connects BugHerd, the Provider imports data from the BugHerd account the user controls at the user's direction. If the user enables two-way sync, the Provider also sends supported ticket and comment changes to that project and receives task event webhooks. BugHerd processes that data under the user's own agreement with BugHerd. The Provider retains the encrypted credential until the user removes the connection. Imported task and comment metadata remains with the ticket until the user deletes the ticket or its project.

9. Data security

In accordance with Article 32 GDPR, the Provider applies technical and organisational measures proportionate to the risks. Only authorised persons bound by confidentiality may access personal data. In particular:

• All traffic is served over HTTPS.
• Passwords are stored only as salted hashes. API keys are stored only as hashes and shown to the user once, at creation.
• Browse session cookie jars are encrypted at rest with AES-256-GCM.
• The service is multi-tenant by team: every read and write is scoped to the teams the user belongs to, enforced in the database access layer rather than only in the interface.
• Access to production systems is limited to the managing director.
• Endpoints that fetch a URL on the user's behalf are guarded against requests to internal and private network addresses.

No system is perfectly secure. If the Provider becomes aware of a personal data breach that is likely to result in a risk to the user's rights, the Provider will notify the supervisory authority within 72 hours and inform affected customers without undue delay, and in any event no later than 72 hours after becoming aware of it.

10. Keeping and deleting data

Retention periods for each category are in the table in “Data processed, purposes, legal bases and retention periods”. In addition:

• Deleting a ticket moves it to Trash, where the user can restore it. While it is in Trash its share links stop resolving. Deleting it permanently also deletes its screenshots, attachments and share links.
• Deleting a project permanently deletes its tickets, comments, activity, share links and media.
• The user can export a full copy of a project — its tickets as JSON and Markdown, plus all media — at any time from the project menu, for as long as the user's account is open.
• The user may request closure of the user's account at the address given in “Contact”. The user can ask the Provider to export the user's data for 15 days after closure. The Provider deletes the data within 30 days of closure, except records the Provider must keep to satisfy accounting and tax obligations under 2000. évi C. törvény 169. § (the Hungarian Accounting Act), which the Provider retains for 8 years, and the record of acceptance of the terms, which the Provider retains until the end of the general civil limitation period, namely a further 5 years.

11. User rights and remedies

Under Chapter III of the GDPR the user has the right to:

• Access the user's personal data: learn whether the Provider processes it, and if so under what conditions, and obtain a copy (Art. 15);
• Have inaccurate data corrected and incomplete data completed (Art. 16);
• Have the user's data erased (the “right to be forgotten”) where the conditions of Art. 17 are met;
• Request restriction of processing (Art. 18), in particular if the user contests the accuracy of the data, the processing is unlawful but the user opposes erasure, or the user has objected to the processing;
• Receive data processed by automated means on the basis of consent or a contract in a structured, commonly used, machine-readable format, and transmit it to another controller (Art. 20);
• Object to processing based on the Provider's legitimate interest (Art. 21);
• Withdraw consent at any time where processing was based on it. Withdrawal does not affect the lawfulness of processing carried out before it (Art. 7(3)).

To exercise these rights, the user may write to [email protected]. The Provider will fulfil or answer the user's request without undue delay and no later than one month after receiving it. For complex or multiple requests, the Provider may extend that period by up to two further months under Art. 12(3) GDPR; the Provider will tell the user within the first month and explain why. The Provider informs every recipient to whom the Provider disclosed the data of any correction, erasure or restriction of processing, unless this proves impossible or requires disproportionate effort (Art. 19).

If a person’s data appears in content uploaded by a customer, such as a screenshot, ticket or attachment, the Provider processes it as a processor on the customer’s behalf. The controller is the organisation that uploaded the content, and the data subject should submit the request to that organisation. If the data subject cannot identify the organisation, the data subject may write to [email protected]. Where possible, the Provider forwards the request to the customer. The Provider does not decide the request independently and assists with the response on the customer’s instructions.

The user may submit a complaint directly to the Provider; the Provider investigates it and informs the user of the outcome. The user may also complain to the Hungarian supervisory authority: Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH), registered seat: 1055 Budapest, Falk Miksa utca 9-11., Hungary; postal address: 1363 Budapest, Pf. 9.; telephone: +36 (1) 391-1400; [email protected], naih.hu. If the user lives in another EU country, the user may also contact the authority there.

Independently of a complaint to an authority, the user may also go to court. In Hungary, data protection cases fall within the jurisdiction of the törvényszék (regional court); at the user's choice, the user may also bring proceedings before the court for the user's own domicile or place of residence.

If a breach of data protection rules causes the user financial or non-financial damage, the user is entitled to compensation from the controller or processor for that damage. If the user's personality rights are infringed, the user is entitled to compensation for non-material harm under Polgári Törvénykönyv 2:52. §. A processor is liable only if it has failed to comply with obligations specifically directed to processors or has acted contrary to the controller’s lawful instructions.

12. Minors' data

re:Marque is intended for professional teams, not children. The Provider does not knowingly collect personal data from people under 16. If a report sent to the address in “Contact”, or other information, shows that a child has provided the Provider with personal data, the Provider deletes it.

13. Amendment of this notice

The Provider may update this policy. If a change materially affects the user's rights the Provider will tell account holders by email at least 30 days before it takes effect. The date at the top of the page always reflects the current version.

14. Contact

Questions about this notice or the user’s data may be sent to [email protected], or by post to the Provider at the registered seat given in “Controller details”.