Privacy + ethics: MGRS, sub-meter, ITAR

Space GIS is not ethically neutral. Sub-meter satellite imagery, real-time launch detection, ground-track prediction — all carry legitimate dual-use concerns: every capability that helps an emergency responder also helps an adversary. This week is the responsible-practitioner primer, written for engineers who will at some point have to make a judgment call.

MGRS and military coordinate systems

The Military Grid Reference System (MGRS) is a global coordinate system used by NATO militaries. It's a friendlier-to-humans version of UTM: instead of "326.4521 N, 47.821 E in UTM zone 33", an MGRS coordinate looks like "33TWN8345621324" — a compact alphanumeric string with built-in zone, 100-km square identifier, and easting/northing.

MGRS precision is variable: trailing digits = meters of precision. 33T alone is a 6° UTM zone. 33TWN is a 100 km × 100 km square. 33TWN8362 is 1 km. 33TWN83456213 is 10 m. 33TWN8345621324 is 1 m.

Why this matters for civilian work: you may receive coordinates in MGRS from operational partners or open-source intelligence (OSINT) sources. Know how to convert. mgrs on PyPI handles it cleanly.

ITAR and export control

The International Traffic in Arms Regulations (ITAR) is a US law restricting the export of defense-related articles and services. Some satellite imagery is on the US Munitions List, and some isn't. The lines:

• Imagery resolution: Per the Kyl-Bingaman Amendment, US-domiciled commercial imaging companies are limited to 0.5 m resolution over Israel. Other US restrictions are largely lifted; non-US providers have their own rules.
• Specific intelligence products: Military reconnaissance imagery and derived products remain controlled.
• Software: Image-processing software with specific defense capabilities (e.g. automated target recognition for weapons systems) is ITAR-controlled.
• Information: "Technical data" related to defense articles — including software documentation in some cases — is controlled even when the underlying data is public.

For a civilian space-GIS product (LaunchDetect-style), the practical guidance is:

1. Process only publicly available raw imagery (NOAA GOES, ESA Sentinel-2, etc.) — these are pre-cleared.
2. Don't derive products specifically designed for military targeting (predicting individual rocket-stage debris landing locations, for example).
3. Consult export-control counsel before any government / defense partnership.

Privacy and sub-meter

Sub-meter commercial satellite imagery (WorldView-3 at 0.3 m, BlackSky at 1 m, Planet SkySat at 0.5 m) raises privacy concerns that ~10 m imagery (Sentinel-2) does not:

• Individuals and vehicles are identifiable.
• Activities (gatherings, construction, military maneuvers) become observable.
• Patterns of life — when does this farm work? when does this base have shift change? — emerge from time-series.

Practitioner responsibilities:

• Don't publish sub-meter imagery of identifiable private individuals or properties without consent. EU GDPR and US state-level privacy laws (CCPA, BIPA) reach into this space.
• Beware aggregation: each sub-meter image is fine; a time-series of sub-meter images over one address is surveillance.
• Implement appropriate access controls when the imagery is sensitive (humanitarian work in active conflict zones, for example).

Dual-use awareness

Every capability in this course is dual-use. SGP4 propagation (Week 8) helps amateur astronomers spot the ISS and helps an adversary plan a satellite-blinding attack. Plume detection (Week 14) helps journalists confirm launches and helps competitors timing intelligence on rivals. Real-time SAR change detection helps disaster response and helps military targeting.

The practical position: build openly, but think clearly. When a capability has clear malicious applications and limited civilian value, reconsider building it. When it has broad civilian value and constrained malicious uplift, build it openly. When in doubt, talk to legal — they don't bite, and they will tell you what you can ship.

The lab

You'll produce a written ITAR compliance assessment for a hypothetical orbital-tracking SaaS product. Cite the controlling statutes. Identify the in-scope and exempt features. Document the controls (data minimization, access restrictions, geographic restrictions) you'd implement. This is the kind of memo a real product team produces before launch — and the kind of thinking the responsible space-GIS engineer practices proactively.