Ethics Online

What Didn't Work

Your attempt to inject XSS or SQL code was detected and blocked by our security mechanisms. We employ several layers of protection:

• Input validation and sanitization at the application level
• Content Security Policy (CSP) headers to prevent script injection
• Parameterized queries to prevent SQL injection
• Rate limiting to prevent abuse
• Real-time monitoring for suspicious activity

Why We Don't Track You

Unlike many websites that collect and monetize your data, we believe in serving our users without surveillance. Our approach:

• No persistent cookies or tracking pixels
• No browser fingerprinting or device profiling
• No advertising or marketing partnerships
• No data collection beyond what's necessary for service provision
• No selling or sharing of any data with third parties

Our Ethical Position

We believe that network diagnostic tools should serve their purpose without becoming surveillance mechanisms. Our tools are designed with privacy as a fundamental requirement, not an afterthought.

"We do not hide behind marketing blurb. We give consumers something more to read and respect their intelligence."

Cross-Site Scripting (XSS)

XSS attacks inject malicious scripts into web pages viewed by other users. Common techniques include:

• Injecting <script> tags into form inputs
• Using JavaScript event handlers like onclick, onload, etc.
• Exploiting poorly sanitized user inputs

Our defense: Input sanitization, CSP headers, and proper output encoding.

SQL Injection

SQL injection attacks insert malicious SQL code into database queries. Common techniques include:

• Inserting SQL commands into form fields
• Using UNION SELECT to retrieve unauthorized data
• Exploiting dynamic SQL queries without parameterization

Our defense: Parameterized queries and input validation.

Why These Don't Work Here

Our application is built with security as a foundational principle:

• All database queries use parameterized statements
• User inputs are validated and sanitized
• Content Security Policy prevents script injection
• Rate limiting prevents abuse attempts
• Real-time monitoring detects suspicious patterns

Measurements come with their conditions

A latency figure without the conditions that produced it is a decoration, not a measurement. Every performance claim on this site is published next to the test setup that generated it: the region, the payload, the concurrency and the sample size. Where a number is a best case rather than a typical one, it says so.

See /solutions/breathgslb/benchmarks for a worked example, including the run conditions and the raw figures.

Limitations are published, not discovered by the reader

Every tool here has a boundary it will not cross, and the boundary is stated before you reach it rather than inferred afterwards from a failure. Discovering a tool's limits by trusting it first is how people get hurt, so the limits go in the documentation.

The same rule applies to this site's own discovery documents: a capability is not advertised unless it is actually implemented and enforced. If /.well-known/ lists it, it exists; if it exists, it is listed.

Comparisons use the current baseline, not the flattering one

When something here is compared against an alternative, the comparison is against the alternative's current version under the same conditions. Benchmarking an old release to make a new one look good is a technique, not an argument, and it is not used on this site.