ISRForge privacy policy.

Effective date: July 27, 2026. The MobileCommandISR tester-feedback section was updated August 13, 2026; the Release-Beta diagnostics section was updated August 24, 2026.

Overview

ISRForge builds practical macOS software. TelemetryISR processes user-selected photos and metadata locally unless the user chooses Gemini cloud analysis or optional Google Maps imagery. ISRForge does not operate a cloud-processing, advertising, analytics, or tracking backend for TelemetryISR. The ISRForge website separately collects information that a visitor voluntarily submits through the MobileCommandISR beta-interest and tester-feedback forms.

Information Handled By TelemetryISR

TelemetryISR may handle user-selected photos, downsampled image previews, filenames, relative folder context, local file paths, EXIF and GPS metadata, Lightroom-related metadata, user-entered prompts and context, keywords, captions, research text, and generated metadata results. This information is used to provide the app's visual grouping, metadata review, location review, and writeback workflows.

Local Processing And Storage

Visual similarity processing, workflow state, settings, and metadata review occur on the user's Mac. Gemini and Google Maps API keys are stored locally in the macOS Keychain. ISRForge does not receive or manage those keys. Users may remove configured keys in TelemetryISR Settings or with macOS Keychain Access. Local workflow data can be removed by deleting the app's container or using the supplied uninstall guidance.

Gemini Cloud Analysis

If the user configures Gemini cloud analysis, TelemetryISR may send selected downsampled image previews, filenames and relative folder context, existing metadata, GPS or location context, prompts, and user-provided instructions directly to Google's Gemini API using the user's own API key. If the user explicitly uses Research Distiller, text extracted locally from a selected PDF, Markdown, or text file is sent to Gemini to create editable research notes.

TelemetryISR explains this transfer before cloud analysis is enabled. These requests go directly from the user's Mac to Google under the terms associated with the user's Google account, API project, and service tier. Users can stop future transfers by disabling cloud analysis or removing the Gemini key. ISRForge does not receive, store, or proxy Gemini traffic.

Google Search Grounding

When an eligible user enables the paid grounded-location option, TelemetryISR may make one focused, text-only Gemini request for a proposed coordinate after image analysis identifies a subject. Google Search grounding may receive the selected subject identity and country context. The GPS review map displays the fixed grounded pin with a provenance explanation, the complete grounded result, its linked supporting sources, and Google's Search Suggestions. TelemetryISR keeps that grounding evidence only in the active app session, does not persist it in photo metadata, and excludes it from support logs. The coordinate becomes eligible for writeback only after the user confirms it.

Map Imagery

Apple Maps is the default in-app map. If the user separately configures a Google Maps Platform key, TelemetryISR requests Google map imagery tiles and required attribution for the visible review map. The Google Maps key is not used to resolve or validate GPS coordinates. Apple and Google handle map requests under their respective terms and privacy policies.

Data Collection By ISRForge

ISRForge does not collect TelemetryISR photos, metadata, API keys, generated results, or app-usage analytics. If a user voluntarily emails ISRForge for support or sends an exported support log, ISRForge uses the supplied information only to diagnose and respond to that request. Users should remove private photos, API keys, and sensitive catalog details before sharing support materials.

MobileCommandISR Beta Interest

If a visitor voluntarily submits the private MobileCommandISR beta-interest form, ISRForge collects the supplied name, email address, vehicle model and model year, optional vehicle generation and Bluetooth OBD-II adapter details, and optional notes. The form does not request a VIN and rejects VIN-shaped values in vehicle and testing free-text fields. ISRForge uses this information only to evaluate beta testing needs, select suitable vehicles and testers, and contact the visitor about MobileCommandISR testing.

Beta-interest responses are stored in a private, access-controlled file on the ISRForge website host. ISRForge does not sell this information or use it for unrelated advertising. Submitting the form records interest but does not guarantee selection for a beta build.

MobileCommandISR Tester Feedback

If a selected tester voluntarily submits the private MobileCommandISR tester-feedback form, ISRForge collects the supplied email address; vehicle model year, make, model, optional generation, engine or powertrain, and Bluetooth OBD-II adapter; iPhone or iPad type; optional operating-system and app-build details; and the tester's bug-report or feature-enhancement descriptions. A submission may contain a bug report, a feature enhancement, or both.

Bug reports may include a short title, app area, observed behavior, expected behavior, reproduction steps, frequency, impact, and recovery information. Feature-enhancement requests may include a short title, app area, requested capability, expected value, anticipated use frequency, and the tester's current workaround. The form does not request a VIN, license plate, home address, route, or exact location and instructs testers not to include them.

ISRForge uses tester feedback only to reproduce problems, evaluate requested improvements, improve MobileCommandISR, and contact the tester about relevant follow-up questions. Responses are stored in a private, access-controlled file on the ISRForge website host. ISRForge does not sell this information or use it for tracking, advertising, or unrelated analytics.

MobileCommandISR Release-Beta Diagnostics

The MobileCommandISR Release-Beta sends no diagnostic result merely because a test finishes. On first entry, the tester must acknowledge the current privacy notice before continuing to local tests. That acknowledgment does not send data or authorize a later report. A tester must separately choose Send Results after reviewing the transfer scope and confirming consent for that report. The Test 02 envelope-v3 result records the privacy-notice version and acknowledgment time, the report-consent version and confirmation time, and is otherwise limited to manually entered vehicle model, model year, powertrain, market, and entry category; app version and build; operating-system version and iPhone or iPad platform class; the approved adapter family and coarse GATT-path summary; and the finite TS-001 probe, signal, interruption, summary, quarantine, and outcome records. Probe results must be full, single-frame diagnostic responses with the exact response prefix and length approved for that probe.

Test 04 separately keeps a rolling seven-day operational summary locally while the beta is open and connected. Nothing is sent automatically. If the tester separately consents and chooses Send Telemetry, the operational-envelope-v1 result is limited to bounded metric-health summaries; adapter family and connection type; connection and reconnect outcomes; command timing, timeouts, and transport interruptions; app version and build; iOS version and iPhone or iPad platform class; and, when a vehicle test exists, vehicle model, model year, powertrain, and market. It does not contain raw OBD frames or a raw live telemetry stream.

The Release-Beta diagnostic result never includes a VIN, location, latitude or longitude, geographic routes, trip records, fill-up records, diagnostic trouble codes, Live telemetry streams, phone-sensor samples, device or account identifiers, Bluetooth peripheral UUIDs, or the app's local adapter identifier. Envelope v3 also excludes a client run ID, client submission ID, compatibility fingerprint, raw adapter ATI identity response, raw vehicle trim, name, initials, email address, typed signature, tester ID, device ID, IP address, cookie, and account. The acknowledgment is an anonymous record that the notice was reviewed, not an authenticated legal signature. The closed receiver validates each supported legacy or current envelope against its exact versioned contract and rejects unapproved fields, probes, campaigns, multi-frame responses, and VIN-shaped values. Current envelope-v3 reports require notice version 2026.08.13.1 and consent version 2026.08.13.1. Current operational-envelope-v1 reports require notice version 2026.08.22.1 and consent version 2026.08.22.1. Frozen legacy envelopes are not rewritten as version 3.

ISRForge uses Test 02 results only to compare Drive and Overland input availability across approved GA-F vehicles and approved Bluetooth adapter families. It uses Test 04 summaries only to identify reliability, timing, and transport issues during the beta. ISRForge does not sell them or use them for tracking, advertising, or unrelated analytics. Sending a result requires no tester account, username, password, token, cookie, device identifier, or tester identifier. The receiver uses only the exact report bytes and their SHA-256 digest for acceptance, retry matching, and receipts.

Canceling a transfer revokes that one-send consent, stops the network work, deletes the pending payload bytes and that report's send-consent evidence, and preserves the completed local run and local privacy-notice acknowledgment. The local run identifier remains on the device and is not included in the submitted envelope. A later Send requires renewed consent and records a new confirmation time. A notice-version change requires acknowledgment again. The tester can also delete the local run in the app.

The SHA-256 digest of the exact canonical envelope bytes is the server's idempotency, storage, and deletion key. A byte-identical replay returns the same receipt without storing another payload. The server receipt contains exactly a server-generated receipt_id and the envelope sha256. Payloads are stored privately outside the web root as submissions/<sha256>.json and are not web-readable. After a successful send, the tester can request server deletion by sending the receipt through the contact method below. The receiver removes the payload from active export and retains a payload-free SHA-256 tombstone with bounded size and secondary-digest collision metadata so the same canonical payload cannot be recreated during the campaign.

Diagnostic payloads, server-side index records, receipts, and deletion tombstones are scheduled for removal 90 days after ISRForge closes the campaign. Any protected export downloaded by ISRForge must be inventoried and securely removed on the same schedule. The receiver application code does not intentionally read or persist a source IP address, forwarded address, cookie, or user-agent value. Shared-host access-log and backup-snapshot behavior is outside the PHP receiver and must be confirmed, and disclosed if applicable, before any external TestFlight beta begins.

Retention And Deletion

ISRForge has no TelemetryISR cloud-processing account or backend record to delete. Local app data and Keychain items remain under the user's control on the Mac. Data sent through a user-configured provider is handled under the terms and controls associated with the user's own account, API project, and service tier. Support emails and voluntarily supplied diagnostic files are retained only as long as reasonably necessary to resolve the request or meet legal obligations; users may request deletion by contacting ISRForge. MobileCommandISR beta-interest records are retained while they remain useful for beta recruitment and testing, or until the person who submitted the information asks ISRForge to delete the record. MobileCommandISR tester-feedback records are retained while they remain useful for beta testing, problem diagnosis, and product improvement, or until the tester asks ISRForge to delete the record. MobileCommandISR Release-Beta diagnostic records follow the campaign-close and server-deletion process described above.

Tracking And Advertising

TelemetryISR does not contain third-party advertising, cross-app tracking, or marketing analytics.

Website Advertising Measurement

The ISRForge website uses the Google tag for Google Ads measurement. Google may receive information such as page visits, browser/device details, referral data, and advertising identifiers or cookies where available. This website tag does not send TelemetryISR photos, local file paths, metadata, prompts, API keys, or app workflow data to ISRForge or Google.

Google's use of this information is governed by Google's policies at policies.google.com/privacy.