Small ideas for Israel's home front, from inside the mamad

Over the course of two wars with Iran, I've spent more time than I'd like to admit thinking about civil defence from inside a mamad. What follows is a collection of small, practical ideas I've jotted down for improving Israel's home front alerting and shelter system — focused on UX, data, and physical infrastructure rather than on anything classified or operational.

These are offered with humility and the deepest respect for Pikud HaOref and the emergency services who keep us safe. I'm not a defence professional — just a resident who has had a lot of time to think about what works and what doesn't. None of these ideas claim expertise; I'm sharing them in good faith in the hope that even one is useful.

Illustration: mamad door at dusk with smartphone alert

The ideas are grouped into six themes: the official Pikud HaOref app; siren and alert delivery; information during and after an event; shelters and mamad logistics; and the data, APIs and developer ecosystem. Each follows a simple problem / suggested solution shape.

The official app (Pikud HaOref app)

1. Disable Android permission auto-reset and enable WEA extreme alerts

Problem. Two silent failure modes affect whether a user actually receives alerts on their phone, and neither is addressed by the app's current onboarding. First, recent Android versions automatically revoke permissions and degrade background work for apps you haven't opened in a while — and a civil defence app is, by definition, one you only open during an alert, so the OS reliably classifies it as 'unused' and quietly breaks it between events. Second, Wireless Emergency Alerts (cell broadcast) can be disabled at the OS level — most commonly the 'Extreme alerts' category specifically, which is the one that matters most. Both failure modes are invisible until the moment they matter.

Suggested solution. Treat 'the user can actually receive alerts' as a first-class setup outcome. During onboarding, deep-link the user to the Android per-app settings page to disable 'Remove permissions if app isn't used' (and the OEM-specific equivalents on Samsung, Xiaomi, Huawei, OnePlus). Walk the user through the OS-level WEA settings and confirm that all categories — explicitly including Extreme alerts — are enabled. Re-check on each launch, surface a non-dismissable warning if anything regresses, and provide an in-app 'test my alerting' page that summarises notification permission, background restriction, auto-reset status, WEA categories enabled, and the result of the last received test broadcast.

Siren & alert delivery

2. Integrate HFC alerts with traffic light SCADA

Problem. For people who rely on public shelters, the time from early warning to actually being inside is often measured in minutes, and every second matters. A frequent cause of delay is road users who themselves are not heading to shelter and who block or slow people trying to make it to safety. There is no civil-infrastructure-level mechanism that intervenes during an alert to clear the roads.

Suggested solution. On receipt of a red alert in a given area, all traffic lights in that area transition to a coordinated red, held for a defined window (e.g. ~3 minutes). During an early warning phase, a distinct visual state — flashing red, for example — could give motorists who missed the alert an unambiguous in-band cue. States reset on all-clear. Coordination with emergency services is needed so emergency vehicles aren't blocked, with a fail-safe design that reverts to normal if SCADA loses contact. Pilot in one municipality first.

Information during and after an event

3. Distinct stand-down state for cancelled early warnings

Problem. Occasionally an early warning is issued and no red alert follows. From the user's perspective this is ambiguous: did the threat pass? Was the warning cancelled? Should I still be in shelter? Sending the same all-clear that follows a real event feels semantically wrong and leaves people unsure whether they have understood the sequence.

Suggested solution. Introduce a distinct state and a distinct message variant for the specific case of 'early warning issued, threat dissipated, no alert followed' — with its own wording and ideally its own audible/visual signature in the app. The message should briefly explain the sequence. Logs and downstream systems can then distinguish stand-down from a normal all-clear, which is also useful for after-action analysis.

4. Add a 'current guidance' field to the alert feed

Problem. The alert feed is published roughly every three seconds and is effectively stateless: each poll tells you what is being broadcast right now, not what the standing instruction is for people already in shelter. Between a red alert and the corresponding all-clear, there is no explicit field saying 'the current guidance for this area is: remain in shelter.' That state has to be inferred, and inference is fragile — many people fall back on the well-known '10-minute rule' and end up leaving shelter earlier than they should.

Suggested solution. Extend the payload with an explicit per-area current-guidance field — a clear enum (none, early_warning, take_shelter, remain_in_shelter, all_clear, stand_down) plus a timestamp for when the current guidance was set, so apps can show 'in shelter for HH:MM.' Versioned and documented as part of a public schema. Because the feed is stateless and high-frequency, an authoritative current-guidance field on every poll is the cleanest fix: every consumer immediately knows the standing instruction without reconstructing event history. Existing consumers that ignore the new field continue to work.

Shelters & mamad logistics

Illustration: wall-mounted alert tablet and FM radio in a public shelter

5. A national public shelter authority

Problem. More than 30% of Israelis rely on public shelters rather than a private mamad. In practice, many of these shelters are dilapidated and lack basic amenities — running water, ventilation, summer cooling, accessible entry, reliable lighting. Responsibility is fragmented across municipalities and standards vary enormously.

Suggested solution. Establish a national public shelter authority responsible for: a national GIS register of every public shelter with status, capacity, accessibility and last-inspection data; a minimum code that goes beyond structural integrity and asks 'is it viable for human beings to spend hours or days in here?'; an accessibility and medical baseline (step-free access, somewhere to sit or lie down, power outlets for medical devices); redundant connectivity in every shelter; a hardened, MDM-managed wall-mounted alert tablet in every shelter; and routine inspections with published results and clear remediation paths. In the interim, operators of public shelters should be explicitly prohibited from barring access or obstructing reasonable efforts to make a space habitable. And every public shelter should display, on the exterior, its national-register ID, the responsible operator, a 24/7 contact number and an escalation route.

6. Standard listing format and physical wayfinding

Problem. Municipal shelter lists are frequently maintained as PDFs or Word documents — formats that are poorly machine-readable and effectively impossible to use in an emergency from a geolocation app. The bigger and less-discussed problem is that even when a shelter appears on a list, the location information is often insufficient to actually find it: the shelter is in the lower level of a multi-storey car park, or behind an unmarked door at the back of a mixed-use building. The infosec argument for keeping locations vague is weak in practice — locations are widely known locally — and the cost is paid in seconds during a real alert.

Suggested solution. Two complementary requirements. First, every municipality publishes its shelter list in a structured machine-readable format (GeoJSON or a defined CSV/JSON schema), with shelter ID, precise lat/lon, floor/level, capacity, accessibility flags, operator, contact and last verified date. PDFs may exist as a human-readable rendering but the canonical source must be the structured data. Second, rich locational documentation per shelter: multiple daylight photographs of the exterior and entrance, a short video walking the access route from the nearest public point to the shelter door, and photographs of the in-building signage on every floor pointing toward the shelter — with missing or inadequate signage itself triggering a remediation requirement on the operator.

7. Mandatory municipal shelter-finder app

Problem. Finding the nearest public shelter in an unfamiliar part of one's own city — let alone in another city — is much harder than it should be. Information is fragmented across municipal websites of varying quality, PDF lists, and word of mouth. People with access requirements have an even harder time, because accessibility metadata is rarely surfaced even when it exists.

Suggested solution. Each major municipality should be required to maintain (or adopt a shared standard for) a shelter-finder app providing: geolocation and 'nearest shelter' by live position with walking directions; an up-to-date list of every public shelter, generated from the same dataset published on the official website; photos and short videos of each shelter; structured accessibility filtering (step-free access, accessible toilet, wheelchair space); and status information (open / closed / under maintenance) with a clear contact per shelter. A common national standard or shared backend would prevent every municipality reinventing the wheel. Offer a single national app as a fallback for smaller municipalities.

8. Communications redundancy in every public shelter

Problem. Once people are inside a public shelter, they are often effectively cut off from the alert system that sent them there. If nobody present happens to have a charged phone with signal and the Pikud HaOref app, the people inside have no reliable way to know whether an all-clear has been issued. Comms inside a shelter is currently a bring-your-own problem for residents — and that's the wrong place for the responsibility to sit.

Suggested solution. Every public shelter should have multiple independent communications channels — deliberately heterogeneous so that no single failure mode silences the people inside:

• Cellular connectivity sufficient for personal devices and in-shelter equipment.

• A working Wi-Fi access point — not just an ethernet socket in the wall.

• A hardened, MDM-managed alert tablet: wall-mounted, mains-powered with battery backup, on its own SIM, locked down to display only Pikud HaOref and WEA messages.

• A pre-tuned AM/FM emergency radio, bolted in place, mains-powered with battery backup — the cheapest, most robust, last-resort channel that degrades gracefully when everything else fails.

9. Long-stay amenities — fewer but better-equipped shelters

Problem. Many public shelters are relied upon by families who must make a fast, life-saving trip to shelter, sometimes with infants in tow. Repeated short trips are exhausting and risky, and these households would find shelters far easier to use if they could stay inside for protracted periods. In their current state, shelters are designed at best for a brief, uncomfortable wait — not for the multi-hour or overnight stays that real-world conflict patterns increasingly demand.

Suggested solution. Expand the minimum shelter standard to support longer stays: basic foam mattresses, eye masks and single-use earplugs, reliable air conditioning (and heating where relevant), power outlets accessible from sleeping positions, and a defined sanitation baseline. The underlying thesis is worth stating openly: fewer but better-equipped shelters would deliver more real-world protection than a larger number of barely-usable ones. A shelter a family can plausibly stay in for hours without acute discomfort is functionally a different category of facility than a concrete box people flee out of as soon as the immediate threat passes.

Data, APIs & developer ecosystem

10. Provide a public and documented API

Problem. There are now well over 100 Red Alert scrapers in the wild. Israel's public alerting system can reasonably be assumed to have been actively monitored by hostile actors before the recent wars and certainly is now — so the usual 'security through obscurity' argument for withholding a public feed is weak. The current sprawl of community projects relying on undocumented endpoints is brittle, error-prone, and hardest to trust at exactly the moments reliability matters most.

Suggested solution. A publicly available, professionally managed and documented API from Pikud HaOref: a stable, versioned HTTP/JSON API with clear schemas and an OpenAPI spec; an accompanying MCP server so AI assistants can consume alert data through a standard interface; published SLAs, rate limits and a status page; clear terms of use that permit downstream apps and research; and historical data endpoints for post-event analysis. The goal is not to replace the official app but to give the surrounding ecosystem a solid foundation.

11. Formally model the alert payload schema

Problem. The de facto schema of the HFC alert feed is currently understood only through observation. There is no canonical machine-readable model — no JSON Schema, no OpenAPI document, no formal specification — and as a result every consumer has to reverse-engineer the same fields, edge cases and quirks independently. The same modelling work is duplicated across dozens of projects, and no single project has high confidence its model is complete.

Suggested solution. Capture the live feed under real conditions with a long-lived passive collector, derive a JSON Schema directly from the observed corpus (each field annotated by frequency and example), and publish both the schema and a representative sample corpus openly. Treat it as a living document, regenerated as new variants are observed. Pair it with a small validator CLI so any developer can pipe a captured payload through it and immediately see whether it conforms. Useful as community infrastructure even before an official API exists — and a strong starting point if one is eventually offered.

12. Observed payload schema (v0)

This one is a working sketch rather than a proposal — an empirical model of what the feed actually looks like on the wire today, based on a live capture against the upstream Pikud HaOref feed. It exists to give the formal-modelling idea a concrete starting point.

Endpoints. Two shapes are exposed: a live alerts endpoint (an array, empty when nothing is active, plus a server-side unix epoch timestamp) and a history endpoint (a rolling list of recent alert rows).

Live alerts payload:

{ "alerts": [], "timestamp": 1775483085.268129 }

History payload:

{ "history": [ { "alertDate": "2026-04-06 16:43:54", "title": "ירי רקטות וטילים", "data": "גדות", "category": 1 } ] }

History row fields. alertDate is a local-time string with no timezone marker — consumers must assume Israel local time and handle DST themselves. title is a Hebrew human-readable label with no parallel English field, no language tag, and no stable machine-readable identifier. data is a single area name as a Hebrew string, with no coordinates, no polygon, no area ID. category is a small integer enum: 1 = rocket and missile fire, 2 = hostile aircraft intrusion, 13 = event ended (all-clear). One row per affected area — a single event covering 30 areas appears as 30 separate rows with no event ID grouping them.

What this confirms. The empirical schema validates several issues raised elsewhere in this collection: there is no current-guidance field; the all-clear is a per-area event rather than a state; there is no distinct stand-down code; there are no coordinates; and there is no timezone, no event ID and no language tag. Each is small on its own, but together they explain why every scraper independently re-implements the same fragile heuristics.

13. Official multilingual area names plus stable area IDs

Problem. The live feed identifies affected areas only by a Hebrew name string. Every downstream consumer that wants to display alerts in any other language has to maintain its own Hebrew → target-language mapping table for ~1,500 area names. Those tables drift: one project's 'Kiryat Shmona' is another's 'Qiryat Shmone' is another's 'Kiryat Shemona,' which breaks aggregation and confuses non-Hebrew-speaking users who follow more than one source. The brittleness is paid disproportionately by exactly the populations who most need alerts in their own language: olim, tourists, Arabic-speaking citizens, foreign workers, refugees.

Suggested solution. Pikud HaOref should publish, as part of the canonical area dataset, an official multilingual name table, and the alert feed should reference areas by a stable area ID rather than (or in addition to) a Hebrew name string. A short opaque code per area that never changes even if the human-readable name is corrected, transliterated differently, or if the area is split or merged. Official names in at least six core languages — Hebrew, Arabic, English, Russian, French and Amharic — chosen by who actually shelters in Israel, not by political symbolism. Published as a versioned, machine-readable dataset (CSV / JSON / GeoJSON) alongside the polygon geometry, with a clear changelog. The alert feed payload carries the area ID on every row so consumers can join against the official name table in whatever language they need without ever touching strings. Additive and low-risk: existing consumers ignoring the new field continue to work.

That's the full list as it stands. The repo where I'm collecting these — including a Hebrew translation of each idea — is at github.com/danielrosehill/Israel-Home-Front-Ideas. If you've spent time in a mamad and have your own observations to add, I'd genuinely like to hear them.