Range.Run (beta)
Privacy Statements
This system does not use cookies. That´s why you have to re-enter login code on each visit or reaload.
All we know about you is your private Telegram ID and your public wallet address. Nothing else. We do not collect, process, nor store: balances, fees, transactions, derived keys, private contracts, identities, IP addresses, or caches. This type of data is not only useless for the services offered, but accessing or storing it in our database would make us a hoyneypot for unwanted pests.
You are free to wipe your data at any time. The DB backup lifespan is 7 days only. All we will keep stored is your private Telegram ID and the history of support messages associated with it.
We do not provide data to third parties, no data whatsoever. The Range.Run database is neither shared nor accessed by other activities of the developer or maintainer. We have ears but no mouth: we will never contact you requesting informations or actions. No SPAM, you will not receive messages from us with offers, neither from ourselves nor from partners or third parties.
All we know about you is your private Telegram ID and your public wallet address. Nothing else. We do not collect, process, nor store: balances, fees, transactions, derived keys, private contracts, identities, IP addresses, or caches. This type of data is not only useless for the services offered, but accessing or storing it in our database would make us a hoyneypot for unwanted pests.
You are free to wipe your data at any time. The DB backup lifespan is 7 days only. All we will keep stored is your private Telegram ID and the history of support messages associated with it.
We do not provide data to third parties, no data whatsoever. The Range.Run database is neither shared nor accessed by other activities of the developer or maintainer. We have ears but no mouth: we will never contact you requesting informations or actions. No SPAM, you will not receive messages from us with offers, neither from ourselves nor from partners or third parties.
System Architecture
FRONT-END: Despite hosted on IIS ASP.NET, the front-end is based solely on HTML + CSS + JavaScript + DOM/AJAX. There's no "code-behind" on front-end pages. Except for the locally maintained icon library (line-awesome), we do not use nor reference third-party libraries or objects.
MIDDLE-END: AJAX calls from the front-end pages are received by a thin layer in C#.NET CORE 6, which consumes back-end services exclusively in JSON traffic. This layer does not use third-party libraries or objects; however, being the first line of defense against attacks and intrusions, this layer communicates with other InfoSec tools, including permissions that are human independent, to activate restrictive firewall rules, leading traffic to honeypots if needed, block access with suspicious activity, or even take down the front-end in high-severity situations.
BACK-END: Based on two physically separate instances of Node.js, one is responsible for business logic and database, the other is responsible for consuming third-party services and MQTT. They are only accessible to the middle-end and reside below the DMZ network layer. Third-party libraries are audited before the build, and automatic updates are disabled.
DATABASE: PostgreSQL running on its own VM, accessible only by Node.js instances. Backups every hour, storage snapshots every 12 hours, all with a 7-day lifespan. Two login levels: one for select only, another for select/insert/update/delete, divided between distinct services in Node.js. Logins only access stored procedures; they do not have permission to call clauses or commands. The DBO profile is accessible only via console, with a double-custody password and strict access rules. It has a witness instance (managed by Patroni) intended for failover situations. Load management is performed by the VM OS adjusting vCPU availability.
NETWORKING & ACCESS: The front-end and middle-end are served behind a deny-all firewall with specific and ad hoc rules. Traffic is then routed to a load balancer that distributes the load between (at least) two front-end servers, prioritizing BGP routing, then load, already within a VPC/DMZ. The back-end and database are located in a third network layer, VPC/NAT outside the DMZ layer. Remote access to VPCs occurs via Mikrotik-based IKEv2 VPNs with strict addressing rules. Server logins occur via dual custody, or by the lead developer within a 30-minute window per day (04:00~04:30 AM UTC). Audit trails (of any type) are maintained for at least 18 months.
MIDDLE-END: AJAX calls from the front-end pages are received by a thin layer in C#.NET CORE 6, which consumes back-end services exclusively in JSON traffic. This layer does not use third-party libraries or objects; however, being the first line of defense against attacks and intrusions, this layer communicates with other InfoSec tools, including permissions that are human independent, to activate restrictive firewall rules, leading traffic to honeypots if needed, block access with suspicious activity, or even take down the front-end in high-severity situations.
BACK-END: Based on two physically separate instances of Node.js, one is responsible for business logic and database, the other is responsible for consuming third-party services and MQTT. They are only accessible to the middle-end and reside below the DMZ network layer. Third-party libraries are audited before the build, and automatic updates are disabled.
DATABASE: PostgreSQL running on its own VM, accessible only by Node.js instances. Backups every hour, storage snapshots every 12 hours, all with a 7-day lifespan. Two login levels: one for select only, another for select/insert/update/delete, divided between distinct services in Node.js. Logins only access stored procedures; they do not have permission to call clauses or commands. The DBO profile is accessible only via console, with a double-custody password and strict access rules. It has a witness instance (managed by Patroni) intended for failover situations. Load management is performed by the VM OS adjusting vCPU availability.
NETWORKING & ACCESS: The front-end and middle-end are served behind a deny-all firewall with specific and ad hoc rules. Traffic is then routed to a load balancer that distributes the load between (at least) two front-end servers, prioritizing BGP routing, then load, already within a VPC/DMZ. The back-end and database are located in a third network layer, VPC/NAT outside the DMZ layer. Remote access to VPCs occurs via Mikrotik-based IKEv2 VPNs with strict addressing rules. Server logins occur via dual custody, or by the lead developer within a 30-minute window per day (04:00~04:30 AM UTC). Audit trails (of any type) are maintained for at least 18 months.