Responsible Disclosure Policy

Circles.London and SwingCircles.com are two websites operated by the same sole trader, Samantha Dee trading as Circles.London and Swingcircles.com. They are not two unrelated businesses, and the use of two domains is not intended to obscure who is responsible for either website.

Circles.London is the public-facing information, editorial, advertising, market-research and waitlist site. SwingCircles.com is the main private adult community platform for registered and verified members. We use separate domains to keep public information and private member services distinct, apply appropriate access and security controls, and support the staged development of the service. This separation is about clarity and privacy, not about hiding who operates either site.

Send reports to: support@circlestech.atlassian.net

Security.txt: security.txt

Please do not send vulnerability reports through a public support form, social media, a member message, the complaints route or the Report a Violation route unless no security route is available. Those routes may expose sensitive technical information to people who do not need it.

Use the subject line “Responsible disclosure: [short description]” and include:

• the affected website, domain, feature, endpoint, application or supplier;
• a clear description of the vulnerability and its potential impact;
• the steps needed to reproduce it;
• a minimal proof of concept, screenshot or redacted example where useful;
• the account type or test account used, without sending a password;
• the approximate date and time of testing;
• any personal information, member content or credentials that may have been exposed; and
• your preferred contact details and whether you wish to be credited.

Please encrypt sensitive details where practical and do not include real member data unless it is necessary to show the problem. If you accidentally access personal or intimate material, stop testing immediately, do not copy or share it, and tell us only what is needed to locate and contain the exposure.

This policy covers security vulnerabilities that affect systems or services operated by or for Circles.London or SwingCircles.com, including public websites, member-facing features, APIs, authentication, access controls, media access, account security, configuration, integrations and infrastructure that we control.

Some systems connected to the service are operated by third-party providers, such as hosting, Cloudflare, WordPress, payment, email, verification and video-room providers. We may need to pass a report to the relevant provider or ask you to use its own disclosure route. We will try to keep you informed where we can do so safely and lawfully.

A report about a general weakness in a third-party product is still useful, but we may not be able to fix the underlying product ourselves. Please identify the affected Circles or SwingCircles feature as well as the supplier, if known.

If you comply with this policy, carry out testing in good faith and stop when you have demonstrated the issue, we will treat your activity as authorised for the limited purpose of investigating the reported vulnerability. We will not ask you to pay a fee or threaten legal action merely because you reported a genuine vulnerability responsibly.

This is not a promise of immunity from every legal consequence. It does not authorise unlawful access, access to another person’s data, damage, extortion, harassment, disruption or activity outside the scope of this policy. You remain responsible for complying with the law, respecting privacy and stopping when requested.

We cannot grant permission on behalf of a third-party provider, club, venue, member or other system owner. Do not test a third-party system because it is linked from our site unless its owner has authorised that testing.

Subject to the restrictions below, we generally accept careful testing of our own systems that is designed to confirm a vulnerability without causing harm. Examples include:

• testing access-control boundaries using accounts you own or have explicit permission to use;
• checking whether a test account can access another test account’s data;
• testing for injection, cross-site scripting, authentication, session or authorisation weaknesses with harmless proof-of-concept input;
• checking whether private media or an API endpoint can be accessed without the required permission;
• reviewing publicly exposed configuration or security headers; and
• demonstrating a vulnerability with the smallest amount of data and activity needed to establish it.

Use test accounts and synthetic data whenever possible. Do not use real member content to prove a point when a harmless alternative is available.

Do not:

• access, download, copy, retain, alter or disclose personal, payment, identity-verification or intimate member data;
• test another person’s account, private messages, profile, media or live room without their explicit permission;
• guess, steal, reuse or publish passwords, tokens, session cookies or authentication secrets;
• send phishing messages, social-engineering requests or deceptive communications to members, staff or suppliers;
• upload malware, establish persistence, install tools or create back doors;
• perform denial-of-service, load, stress or destructive testing;
• delete, modify, corrupt, ransom or encrypt data;
• evade a security control further than necessary to demonstrate that the control can be bypassed;
• scan or test third-party systems, infrastructure or suppliers without their permission;
• publicly disclose the vulnerability, sell it, threaten disclosure or use it to obtain money or other advantage before coordinated disclosure; or
• continue testing after we ask you to stop or after you have enough evidence to report the issue.

If your testing reveals a serious vulnerability or possible unauthorised access, stop immediately and report it. Do not investigate how far the access extends.

We aim to:

• acknowledge a report within two working days where reasonably possible;
• complete an initial triage or ask for clarification within ten working days where the report contains enough information to assess it; and
• provide updates when there is a material change, subject to security, privacy and legal limits.

These are targets rather than guaranteed deadlines. A report may take longer to assess if it is incomplete, affects a third-party provider, requires specialist testing, involves a live incident, or arrives outside the monitored security route.

We may ask you for further information, a safe reproduction method, a test account or permission to contact you. Please do not send more sensitive material than we need.

We may close a report as invalid, duplicate, already known, out of scope, not reproducible or lower risk than claimed. Where safe and useful, we will explain the reason.

We may consider:

• whether the report affects confidentiality, integrity or availability;
• whether personal, payment, identity-verification or intimate information could be exposed;
• how easily the issue can be exploited;
• whether authentication or special access is needed;
• the number and type of people potentially affected;
• whether exploitation is active or likely; and
• whether a mitigation, configuration change, supplier action or code fix is available.

We may temporarily disable a feature, restrict access, rotate credentials, preserve logs, contact a supplier, notify affected people or report an incident to a regulator or law-enforcement body where necessary. We may not be able to tell the reporter every detail of our response.

Treat suspected exposure of member information, payment information, identity-verification material, private media, messages or live-room content as urgent. Put “URGENT SECURITY” in the subject line and send the minimum details needed to help us locate the issue.

Do not attach or forward the exposed material. If you have already downloaded or received it, do not open, copy, publish or share it further. Tell us what type of information was involved, approximately how much may have been accessible, the affected URL or account context, and when you saw it. Keep any unavoidable copy secure and delete it when we confirm that it is no longer needed, subject to any lawful instruction.

We will assess whether the incident engages our data-protection, safeguarding, contractual or other reporting obligations. The Privacy Policy and any internal incident-response procedure may apply.

Please give us a reasonable opportunity to investigate and address a reported vulnerability before publishing details. Do not publish proof-of-concept code, exploit steps, screenshots, member information, credentials, URLs containing secrets or other details that could enable harm.

We will try to agree a disclosure timetable with you. Unless we agree otherwise, we ask that you wait at least 90 days from our acknowledgement before public disclosure. A shorter or longer period may be appropriate depending on the severity, active exploitation, availability of a fix, third-party dependencies and risk to members.

We may ask you to delay disclosure where immediate publication could expose people or make exploitation more likely. We cannot require you to keep information confidential indefinitely, but we may need to protect personal information, trade secrets, security details and legal obligations. Please discuss any proposed disclosure with us before publishing it.

If a vulnerability has already been publicly disclosed or is being actively exploited, tell us that immediately. Do not assume that public disclosure removes the need to report it directly.

We do not currently operate a paid bug-bounty programme and do not promise payment, gifts or compensation for vulnerability reports. Do not assume that a report creates a contract for payment.

With your permission, we may acknowledge a researcher in a security acknowledgements list or private communication. We will not publish your name or other identifying information without your permission, unless we are legally required to do so.

We will use information in a vulnerability report to assess, investigate, fix and communicate about the issue, protect the service and meet legal or regulatory obligations. Reports may be shared with staff, contractors, insurers, professional advisers, hosting providers, technology suppliers, affected organisations, regulators or law enforcement where reasonably necessary.

Please avoid including personal information about yourself or anyone else unless it is necessary. We will handle personal information in accordance with the Privacy Policy. Security reports may contain sensitive technical details, so do not send them through public comments, social media or member messaging.

We may update this policy to reflect changes to the service, law, suppliers, security controls or disclosure arrangements. The current version will be published with an updated date.

Questions about this policy can be sent to: support@circlestech.atlassian.net