
Features
Reducing location exposure in a fictional neighborhood marketplace app case
Fictional neighborhood marketplace case reducing location exposure through feature mapping, approximate areas, listing controls, retention, deletion, and tests.
What to take away
- This fictional case demonstrates privacy design and makes no claim about a real marketplace.
- The team separates discovery area, pickup point, seller address, photograph metadata, and message content.
- Approximate location reduces precision but does not eliminate neighborhood risk.
- Exact pickup details appear only after both parties agree and can be changed.
- Deletion covers listings, drafts, geotags, map-provider data, messages, and backup expiry.
- Threat reports preserve evidence before content and accounts are changed.
"PorchLoop" is a fictional app where neighbors list household items for local pickup. The company, users, code, vendors, neighborhoods, dates, incidents, and results are invented. The case is educational and is not safety, legal, product, or incident-response advice.
The risky starting design
A seller opens the app, grants precise location "always," takes a photo, and posts a chair. The listing shows a pin on the seller's building. The original photograph retains coordinates. The map provider receives the precise point, and analytics records it again with an advertising identifier.
Five Location Values
Value
- Discovery area
- Show nearby listings
- Seller address
- Arrange pickup
- Listing pin
- Order and map result
- Photo coordinates
- No product need
- Message pickup point
- Complete exchange
Purpose
- Discovery area
- Public to local viewers
- Seller address
- Stored on account
- Listing pin
- Building-level
- Photo coordinates
- Embedded in original file
- Message pickup point
- Shared in chat
Initial exposure
- Discovery area
- Seller address
- Listing pin
- Photo coordinates
- Message pickup point
The team maps five different location values instead of calling all of them "location":
| Value | Purpose | Initial exposure |
|---|---|---|
| Discovery area | Show nearby listings | Public to local viewers |
| Seller address | Arrange pickup | Stored on account |
| Listing pin | Order and map result | Building-level |
| Photo coordinates | No product need | Embedded in original file |
| Message pickup point | Complete exchange | Shared in chat |
Challenge necessity
Browsing needs only a user-entered area or approximate device location while the app is visible. Creating a listing needs a general neighborhood, not continuous background access. Pickup details are a later transaction between two people.
Necessity Challenge
- Browsinguser-entered area or approximate location
- Creating listinggeneral neighborhood only
- Pickup detailslater transaction between two people
- Remove background location from app configuration
- Precise location off by default
The team removes background location from the application configuration. It does not merely hide the prompt. A user can enter a ZIP code or district manually, and precise location remains off by default.
Redesign public display
Public listings show a coarse named area and a randomized map region rather than the seller's point. Sparse areas receive a larger region. The result is labeled approximate so buyers do not treat the center as a pickup address.
Public Display Redesign
Before
- Map display
- Seller's point
- Area shown
- Precise building
- Sparse areas
- Same small region
- Label
- Exact location
After
- Map display
- Randomized map region
- Area shown
- Coarse named area
- Sparse areas
- Larger region
- Label
- Approximate
Google's Android help page on app location sharing statements explains that supported prompts can display developer-stated sharing practices, that developers are responsible for accuracy, and that users can change precise, approximate, and duration choices. It supports treating the label as a statement to verify, not proof that the fictional design behaves as claimed.
Strip location from media
At upload, the app removes location metadata from the public derivative and does not keep coordinates in analytics. The original remains on the user's phone unless the user selects cloud backup. A prepublication preview flags addresses, mail labels, school badges, reflections, and house numbers that metadata removal cannot detect reliably.
Media Location Stripping
- Remove location metadata from public derivative
- Do not keep coordinates in analytics
- Original stays on user's phone unless backed up
- Preview flags addresses, mail labels, school badges
- Preview flags reflections and house numbers
- Let seller crop or replace image
The interface tells the seller that visible clues may remain and lets them crop or replace the image.
Stage pickup sharing
The seller first chooses a public meeting place or a custom point. Exact details are withheld until both parties accept a pickup window. Either party can change or withdraw the point, block the other account, and preserve abusive messages for reporting.
The app warns against sharing home access codes, schedules, identity documents, or payment credentials. High-risk reports open a safety route that does not require continued conversation.
Limit recipients
The map provider receives the coarse region for public display and the exact point only when an agreed pickup map is generated. Contract and configuration prohibit advertising reuse in the fictional design. Analytics receives an event category, not coordinates or message content.
The team checks the actual network requests. A library still transmits latitude and longitude in a diagnostic payload. Release is blocked until the field is removed, old diagnostic records are deleted under the vendor process, and a regression test detects coordinates.
Set retention and deletion
Draft listing location expires when the draft is discarded. Public region disappears when the listing closes. Pickup details expire after the transaction and dispute window. Threat evidence follows a restricted case schedule. Backup copies age out through a documented cycle.
NIST guidance on managing mobile devices notes that enabled location services can increase privacy and targeted-attack risks because location can be correlated with associations and activities. It supports the fictional risk analysis. It does not set PorchLoop's controls or certify its implementation.
Test the new journey
A test seller denies device location, enters an area manually, uploads a geotagged image, selects a public meeting place, blocks the buyer, closes the listing, and requests deletion. The test confirms:
- no background permission is requested;
- public viewers see only the coarse region;
- the public image has no coordinate tag;
- analytics receives no latitude or longitude;
- the pickup point disappears after the defined event;
- the deletion record preserves completion without retaining the listing.
The case proves only that the fictional build passed this limited test. It does not guarantee personal safety, anonymity, map accuracy, or legal compliance.
Common questions
Why not hide every listing pin completely?
The fictional product keeps broad local discovery while withholding exact pickup details. Another service may choose a different design.
Does randomized mapping prevent re-identification?
No. Item photos, messages, repeated listings, small areas, and outside information can still narrow location.
Should abusive messages be deleted immediately?
Preserve evidence and follow the safety and reporting plan before deletion when threats or disputes are involved.
Does denying permission stop manual address sharing?
No. Users can still type addresses, attach geotagged files, or reveal places through visible content.







