How we protect public pages, private portals, payments, and alert data.
Security and Data Protection exists to answer one practical traveler need: what data is used, what action is available, and where to check before driving.
Public pages, private portals, data pages, and forms should operate over HTTPS in production.
Public pages, latest waits, history, nearby crossings, wait cards, daily report, and public page lists are public surfaces. They should preserve provider credit, update time, and delay notes so readers, search systems, and tools do not confuse current, historical, or incomplete data.
Dunvale handles wait data and licensing. Private pages, dashboards, accounts, billing, and support remain outside public use.
Private areas use protected sign-in and stay separate from public navigation.
Sensitive changes such as ads, businesses, billing, and SEO should be logged with actor, time, and before/after values where practical.
Payments and subscriptions are processed with Stripe. We store needed customer, subscription, invoice, and event identifiers, not full card details.
Email, SMS, WhatsApp, and push use external providers plus delivery logs for support, opt-out, and abuse control.
Forms, public pages, wait cards, alerts, login, payments, and ad events use limits and validation to reduce spam, bots, and abuse.
We prefer storing only what is needed to operate, bill, audit, improve, and protect service. Request identifiers should be protected or aggregated where practical.
Private settings and connection details should live in secure storage, not public pages or published repositories.
Report suspected security issues through contact. Include URL, time, steps, and evidence. Do not exploit, download others' data, disrupt service, or publish details before review.
ContactNo internet-connected system can guarantee absolute security. We will investigate reasonable reports and prioritize fixes by risk.
Use these links to verify data, contact, or related controls without scanning the whole page.