Cite as
Addai, D., SectraTEK Lab (2026). What the Craigslist app leaves on an iPhone. LAB-0010, version 1.0. https://lab.sectratek.com/research/lab-0010/
Methodology note
Drafted with AI assistance and reviewed by the author before publication.
Summary
- Craigslist is a long-running classifieds service and its iPhone app is the company's own, first released in December 2019. Public records of fraud and robbery in online classifieds are about third parties misusing a legitimate service. We found no record about the iPhone app itself, so its place in our ranking rests on category context.
- On three research images the app left seven readable kinds of record: recent searches, opened postings, favorites, app state, a short startup log, and two views of its network cache (search requests and posting pages).
- All three images were signed out. No account email and no messages were stored, so the app's data alone does not say who used it or whom they contacted.
- A missing record is not a missing event: the searches list is capped, the cache is a sample, and the account, any messages and the person's own postings are not in the container.
What the app does and who uses it
According to its App Store listing, the app is the mobile version of Craigslist, a classifieds service founded in 1995. It covers jobs, housing, items for sale, vehicles, local services and gigs. People can save favorites, filter results, set search alerts and view listings on a map [S3]. Craigslist released its first official iPhone app on 3 December 2019. Until then only third-party apps existed, according to a report of 4 December 2019 [S4].
Its users are ordinary: someone looking for a flat, selling a used bicycle, or hunting for a part-time job or a local tradesperson. When we read the listing it showed a 4.8 rating from 562 thousand ratings and a current version of 1.30.0 [S3].
The listing's privacy details are written by the developer and are not verified by Apple. They list search history, device ID, location, email address, name, phone number and payment information among the data linked to the user [S3]. Craigslist's privacy policy says it applies to its mobile applications, and it names device information and IP address as collected through the app, and saved searches, account preferences and favorite or hidden postings as entered by the user [S8]. These are statements about what the service collects. They do not say what the phone keeps. The device section does.
Why this app matters to an examiner
A classifieds app is where a private sale, a rental or a job lead begins, so the questions that reach an examiner are small and concrete: what did this person look for, which listings did they open, and when. The same features that serve ordinary users are used by people who set out to defraud them.
Craigslist's own help pages warn about this. In summary, it advises dealing locally and in person, not sending or accepting payment before meeting, and treating requests to wire money, pay with gift cards or deposit a cashier's check as scams. It says a request for a code or verification is always a scam [S5]. Its phishing page says fraudulent messages can appear to come from Craigslist or from other users [S6], and its in-person guide suggests a public meeting place such as a bank or police station [S7].
Regulators describe the same patterns. A Federal Trade Commission consumer alert of 27 July 2022 names Craigslist among the sites that attract both buyers and scammers, and describes fake payment notices, check overpayment and requests for a verification code [S9]. A Federal Bureau of Investigation (FBI) public service announcement of 15 November 2023 lists similar buyer and seller warning signs without naming any service [S10].
The scale is only visible at category level. In its 2025 annual report the FBI's Internet Crime Complaint Center (IC3) counted 1,008,597 complaints and $20.877 billion in reported losses. Non-payment and non-delivery, the category for goods that are paid for and never arrive or are shipped and never paid for, accounted for 56,478 complaints and $503,373,587 [S11]. By our arithmetic that is about 5.6 percent of complaints and 2.4 percent of reported losses. The report does not name Craigslist or any other app. The FTC reported about $16 billion in fraud losses reported to it for 2025 [S12]. These are complaints, not counted incidents, and none of them is about this app.
Police statements are older and local. In August 2011, according to a CBS Philadelphia report, police said three people who had listed expensive watches for sale on Craigslist were robbed by men posing as buyers, and advised meeting in public, if possible at a police station [S13]. In January 2013, Baltimore City police warned that robbers had found sellers through Craigslist listings [S14]. Some police departments now offer a camera-monitored safe exchange zone for online sales, for example San Mateo, whose page names no platform [S15].
No app-specific record. In the pages we read, we found no regulator, law-enforcement or news record about the Craigslist iPhone app as distinct from the service, and none that treats the app as an instrument of misuse. Everything above is category context. The people who misuse classifieds are third parties, and Craigslist warns its users about them.
| Date | Publisher and kind | What it says, in short | Names Craigslist |
|---|---|---|---|
| 2011-08-19 | CBS PhiladelphiaNews report of a police statement | Three people who listed watches for sale were robbed by men posing as buyers; police advise meeting in public. S13 | Yes |
| 2013-01-20 | CBS Baltimore (WJZ)News report of a police warning | Baltimore City police say robbers found sellers through listings; advise a public meeting place. S14 | Yes |
| 2019-12-04 | 9to5MacNews report | Craigslist releases its first official iPhone app on 3 December 2019. S4 | Yes |
| 2022-07-27 | Federal Trade CommissionConsumer alert | Fake payment notices, check overpayment and verification-code requests aimed at online sellers. S9 | Yes |
| 2023-11-15 | FBI IC3Public service announcement | Buyer and seller warning signs for online marketplaces. S10 | No |
| 2024-05-29 | CraigslistPrivacy policy (last updated) | Covers the mobile app; names device information and IP address; may share data under legal process. S8 | Yes |
| 2026-06-15 | Federal Trade CommissionPress release | About $16 billion in fraud losses reported for 2025. S12 | No |
| 2026 (PDF dated 16 April) | FBI IC32025 annual report | 1,008,597 complaints, $20.877 billion; non-payment and non-delivery 56,478 complaints. S11 | No |
| Undated (read 2026-11-06) | CraigslistHelp pages: avoiding scams, phishing, in person | Deal locally; no payment before meeting; a request for a code is a scam; meet in public. S5, S6, S7 | Yes |
Why the Lab chose it
We compared the apps found in the Lab's research images with what the open-source parser reads. The images held 731 distinct non-stock apps. The parser, checked against its main branch on 6 November 2026, read 51 of them, 4 in part, and not the remaining 676. We ranked the unparsed apps by public-record relevance [S2].
Craigslist was seventh of ten. Its rank rests on category context: it is a marketplace, and the public record above describes marketplace fraud and meeting-place robbery. It does not rest on an app-specific misuse source, because we found none. The app was present in 3 of the 9 images, in versions 1.27.0 and 1.29.1 [S2]. There was also a practical reason. The state is plain JSON and a standard cache database, so a parser could be built and tested without a vendor-specific decoder.
Method
We worked in four read-only steps. First, container inspection: for each image we listed the app's container and recorded file, table, column and key names, not values. Second, a synthetic fixture: a script builds one invented container with the same layout, using fixed phrases for queries, a made-up town on a reserved domain, round coordinates and placeholder tokens. The parser can be tested and shared with no case data.
Third, tests: 15 unit tests, including that token values are never exported and that odd value types, missing tables and non-JSON bodies do not stop a run, and 7 of 7 test cases against stored baselines. A full run on the fixture loaded all seven artifacts [S1]. Fourth, a read-only run on the three real containers, recording row counts only, with no error from the module. The temporary extracts were deleted, and no case data left the Lab.
The counts matter because a parser can return an empty table instead of an error, and an empty table looks like an unused feature (LAB-TR-0006 [S16]). We did not sign in or out, use the app under controlled conditions, or test a backup input.
What is on the device and what is not
The app is built with React Native and has no database of its own. Its state sits in AsyncStorage, which stores named values: a small value inside a manifest.json file, and a larger value in a separate file named after a hash of its key. Figure 2 shows the three places the app writes and what each becomes in the parser [S1].
| Place in the app container | Names inside | Becomes |
|---|---|---|
| Library/Application Support/org.craigslist.CraigslistMobile/RCTAsyncLocalStorage_V1/AsyncStorage: manifest.json and hashed files | Keys persist:search, persist:root, persist:chat and startupLog. Fields such as recentSearches, visitedPostings, user, tokens, permissions, config. | Recent Searches, Viewed Postings, Favorites, Hidden and Saved Searches, Account and App State, Startup Log |
| Library/Caches/org.craigslist.CraigslistMobile/Cache.db with its -wal and -shm files | Tables cfurl_cache_response, cfurl_cache_blob_data, cfurl_cache_receiver_data. Request paths for search, suggestion, category counts and posting detail. | Cached Search Requests, Cached Posting Details, and the titles joined to Viewed Postings |
| Library/Preferences/org.craigslist.CraigslistMobile.plist | Keys deviceUID and RCTI18nUtil_makeRTLFlipLeftAndRightStyles. | A device identifier row in Account and App State |
Table 1 lists the seven artifacts the parser produces, with what each is worth and where it stops. Times are Unix milliseconds in some fields and Unix seconds in others, and the parser notes which for each field.
| Artifact | Source in the container | What it holds | Value to an examiner | Limits |
|---|---|---|---|---|
| Recent Searches | persist:search, field recentSearches | Query text, category labels, filters, search area, time (Unix ms) | Shows interest, area and time | Capped at 24 rows; radius and units not established |
| Viewed Postings | persist:search, field visitedPostings; titles from Cache.db | Posting identifier and time (Unix ms); title and category where a cached response exists | A list of opened postings | Identifier only if not cached; cache time is not viewed time |
| Favorites, Hidden and Saved Searches | persist:root, user.savedSearches | Favorite postings with title, category, location, posted date (Unix s); hidden and saved-search entries | Postings the person kept | Hidden and saved-search field names unknown; shown as stored text |
| Account and App State | persist:root, manifest.json, preferences plist | Sign-in state, login if present, home area, permission states, config version, token fields present or absent, device identifier | Signed in or out; app-level settings | Signed-in layout never observed; token values never exported |
| Startup Log | manifest.json, key startupLog | Tab-separated lines: ISO UTC time, event, detail | When the app started | Five lines on each image |
| Cached Search Requests | Cache.db, cfurl_cache_response | Search, suggestion and category-count requests with query text and area parameters | What the app asked the service | A cache, not a log; some requests only |
| Cached Posting Details | Cache.db, cfurl_cache_response and receiver_data | Title, price string, posted and updated dates, location, URL, body text | An advertisement as the app received it | Bodies kept as files not read (7, 1, 0); contact flag only |
Figure 3 shows how many rows each artifact produced on the three images. The images differ a great deal, 178 opened postings on one and 1 on another, which shows different use or retention, not a rate. Account and App State gave 32 rows and Startup Log 5 on every image, which is what a fixed set of settings and a short log look like. The other five artifacts vary with use.
Show this figure as a table
| Artifact | Image A | Image B | Image C |
|---|---|---|---|
| Recent Searches | 24 | 24 | 0 |
| Viewed Postings | 85 | 178 | 1 |
| Favorites, Hidden, Saved Searches | 1 | 0 | 0 |
| Account and App State | 32 | 32 | 32 |
| Startup Log | 5 | 5 | 5 |
| Cached Search Requests | 35 | 3 | 17 |
| Cached Posting Details | 49 | 31 | 14 |
Two details guard against over-reading. The viewed-postings list gives each posting identifier a time. Of 28 identifiers that also had a cached response, 14 were cached within 60 seconds of the viewed time, 8 later and 6 earlier, so the cache time is not a viewed time. And the recent-searches list is capped at 24 rows, which two images reached, so an older search that is not listed proves nothing [S1].
Most of what a reader might hope for is not on the device. Figure 4 lets you pick a kind of evidence and see whether it is on the device, where, what we counted, and the wording a report can use. Where the pages we read say who holds a record, the explorer says so; where they do not, it says the question is not established.
This figure needs JavaScript. The table under it holds the same content.
Show this figure as a table
| Evidence | Status | Where it would be, and what we counted | Value to an examiner | Limits | Sources |
|---|---|---|---|---|---|
| Search terms and search area | Partly on the device | persist:search, field recentSearches: query text, category labels, filter values, search area and a time in Unix milliseconds. Search requests are also in the network cache (Cache.db), on the suggestion and search paths. Recent searches: 24, 24 and 0 rows on images A, B and C. Cached search requests: 35, 3 and 17. | Shows what was looked for, where, and when the app recorded it. | Does not show who typed it, or that anything was bought, sold or answered. | S1 |
| Postings opened | Partly on the device | persist:search, field visitedPostings: a posting identifier and a time in Unix milliseconds. A title and category are added only where the cache holds a response for the same identifier. 85, 178 and 1 identifiers. Of 28 identifiers with both a viewed time and a cached response, 14 were cached within 60 seconds of the viewed time, 8 later and 6 earlier. | A list of postings the app opened, with a time for each. | Opening a posting is not contacting the advertiser. The cache time is not the viewed time. A posting may have been removed since. | S1 |
| What a posting said | Partly on the device | Cache.db, tables cfurl_cache_response, cfurl_cache_blob_data and cfurl_cache_receiver_data. A posting-detail response is JSON with a title, category, price string, posted and updated dates, location fields, image entries, a contact-information flag and the body text. Cached posting details: 49, 31 and 14 rows. Response bodies kept as separate files (7, 1 and 0) were counted and not read. | The wording of an advertisement as the app received it. | The contact flag says whether contact details exist, not what they are. The pictures were not examined. | S1 |
| Favorites | On the device | persist:root, user.savedSearches.favorites: posting identifier, title, category, location and posted date (Unix seconds). 1 favorite on image A; none on B and C. | A posting the person chose to keep. | One entry across three images, so how a busy list looks was not observed. | S1 |
| Saved searches, hidden postings and alerts | Not found on these images | persist:root, user.savedSearches: lists for searches and hidden postings, and a notifications entry. Empty on all three images. | None on these images. | Whether a saved search or alert is also kept by the service is not established. The App Store text says the app can set search alerts (S3). | S1, S3 |
| Messages with a buyer or seller | Not found on these images | persist:chat, stored inline in the manifest. Empty on all three images. | None on these images. | A signed-out phone says nothing about messages held in a mail account or by the service. | S1, S5, S8 |
| Account login and email | Not found on these images | persist:root, user.login and user.isLoggedIn. Login empty and signed-in flag false on all three images. No account email was found. | Shows the sign-in state when the evidence was taken. | Does not show that no account exists. No sign-in or sign-out test was run, so whether an earlier sign-in leaves a value is not known. | S1, S8 |
| Postings the person made | Not established | persist:root, user.drafts, user.postingsActive and user.postingsInactive (key names only). Never seen populated. The parser does not export these keys. | Not established. | A signed-in phone needs a manual check of these keys. | S1 |
| Payment cards and autofill | Not established | persist:root, user.paymentCards and user.autoFillFields (key names only). Key names seen; values are not exported. | Not established. | Do not infer a stored card from a key name. | S1, S3 |
| Sign-in and session tokens | On the device | persist:root, tokens: access token, browser cookie, push token and attestation fields. Reported as present or absent only. Account and App State: 32 rows on each image. | Shows whether the app held a session credential when the evidence was taken. | Presence is not use. No value is needed to say a field was there. | S1 |
| Search area | On the device | recentSearches location and favorite location fields: area identifier, city, region, postal code, coordinates, radius and URL, as stored. Posting locations are in the cache. Stored with recent-search rows (24 and 24 rows on images A and B). | Shows where the person was searching. | Not the phone's own position. The radius is shown as stored. | S1 |
| When the app was run | Partly on the device | manifest.json, key startupLog: tab-separated lines with an ISO UTC time, an event and detail. 5 rows on each image. | Times at which the app started, in UTC. | Five lines cannot show how often or for how long the app was used. | S1 |
| A device identifier | On the device | Library/Preferences, org.craigslist.CraigslistMobile.plist, key deviceUID. Exported in Account and App State (32 rows on each image). | A label for this installation of the app. | What the service does with it is not established. It is not the phone's serial number. | S1 |
Signed out: what a missing account email means
On all three images the stored login was empty and the signed-in flag was false. Chats and messages were empty, the hidden-postings and saved-searches lists were empty, one image had a single favorite, and one had no recent searches. The parser exports an account email when one is present. None was [S1]. For an examiner this has five consequences.
- No named person. Without an account email, nothing in the container ties the searches and viewed postings to a named person. Any such link must come from another source.
- No account does not follow. A signed-out app is consistent with never having signed in. It is also consistent with a sign-out. We ran no sign-in or sign-out test, so we do not know whether an earlier sign-in leaves a value behind.
- Browsing is not acting. The container shows searches and opened postings. It shows no message, no payment and no meeting. A flag in the cached posting says whether the advertiser gave contact details, not what they were.
- The signed-in layout is unobserved. The state has keys for drafts, active and inactive postings, payment cards and autofill fields. We saw only their empty shapes, and the parser does not export them. On a signed-in phone, check these by hand and tell the maintainers what you find.
- The service holds the rest. The account, any messages relayed through Craigslist and the person's own postings are not in this container. Craigslist's policy says it may share data in response to a subpoena, search warrant, court order or other legal process, and it states no retention periods [S8]. Whether the service still holds a record is a question for the service.
What an examiner can and cannot conclude
Can, with the file and key named. The app's stored state held these searches and opened-posting identifiers, with these recorded times, when the evidence was taken. That is consistent with the app having been used on this phone to look at classified listings. The cached posting pages show what the app received for those listings, which may no longer be online.
Cannot. The container does not show who held the phone, whether anyone contacted a seller, paid or met, or whether a listing was genuine or fraudulent. It does not show that nothing else was searched or opened: the searches list is capped and the cache keeps a sample. A phone supports a claim that nothing happened only where it could have recorded the event (LAB-TR-0034 [S17]). Opening a listing on this app looks the same on the device as any other use, and nothing here makes it suspicious in itself.
For wording, use the weaker honest statement. "The app's recent-searches list held 24 entries and holds at most 24" is true. "The person searched only these things" is a guess. The same discipline applies to a missing key (LAB-0005).
What this does not prove
Read these before you report a finding
- Nothing here shows that the app, or Craigslist, caused or enabled misuse. The public record we read concerns third parties and the service, not the app.
- A viewed or cached posting does not show contact, payment or a meeting, and a favorite does not show intent.
- A missing account email does not show that no account exists. A missing search or posting does not show it never happened.
- The counts describe three images and two app versions, with a single signed-out state. Other versions, a signed-in phone and a backup input are untested, and the counts are not rates.
- The meaning of some stored fields, for example the search radius and units and one telemetry flag, is not established, and the parser shows them as stored.
- The public figures are complaints and reported losses in categories, not counts of incidents, and they are not about this app.
Sources
Every number and claim, and where it comes from. Web pages were read between 5 and 6 November 2026 and are cited by publisher, title, date and address. Where a page shows no date we say so. We did not use U.S. Department of Justice news releases, because their pages could not be read automatically. S1 and S2 are Lab records: the parser and its synthetic fixtures are in preparation for the open-source project and the Lab artifact repository. S16 is on Zenodo (doi:10.5281/zenodo.23717928). S17 is a Lab Technical Report available on this site (no DOI yet): LAB-TR-0034.
| Ref | Source | Used for |
|---|---|---|
| S1 | Lab record: parser report for the Craigslist module (bundle org.craigslist.CraigslistMobile), 2026-11-06. Aggregate counts, schema names, format notes and limits only. | Container layout, artifacts, row counts per image (24/24/0, 85/178/1, 1/0/0, 32/32/32, 5/5/5, 35/3/17, 49/31/14), signed-out findings, 28-identifier timing check, 15 tests, 7 of 7 test cases, stated limits. |
| S2 | Lab record: iOS non-stock app inventory report, 2026-11-06, checked against the open-source parser main branch (512 plugin files) fetched that day. | 731 distinct non-stock apps; 51 parsed, 4 in part, 676 not; Craigslist present in 3 of 9 images in versions 1.27.0 and 1.29.1; rank 7 of 10; category-context ranking. |
| S3 | Apple App Store listing, craigslist, inc., apps.apple.com/app/id1336642410, read 2026-11-06. | Description (classifieds since 1995; favorites, filters, alerts, map), category Shopping, version 1.30.0, 4.8 from 562K ratings, developer-provided privacy details. |
| S4 | 9to5Mac, "Craigslist officially lands on iOS", 2019-12-04. 9to5mac.com. | First official app, released 3 December 2019; only third-party apps before. |
| S5 | Craigslist help, "Avoiding Scams". craigslist.org/about/help/safety/scams/avoiding. No date shown (copyright 2026), read 2026-11-06. | Deal locally; no payment before meeting; wire, gift card and cashier's check requests are scams; a code request is a scam; use the mail relay. |
| S6 | Craigslist help, "Phishing". craigslist.org/about/help/safety/scams/phishing. No date shown, read 2026-11-06. | Fraudulent messages can appear to come from Craigslist or its users. |
| S7 | Craigslist help, in-person transactions. craigslist.org/about/help/safety/in-person. No date shown, read 2026-11-06. | Meet in a public place such as a bank or police station. |
| S8 | Craigslist privacy policy, last updated 2024-05-29. craigslist.org/about/privacy.policy, read 2026-11-06. | Covers mobile applications; device information and IP address from the app; saved searches, preferences and favorite or hidden postings entered by the user; email relay services; sharing under legal process; no retention periods stated. |
| S9 | Federal Trade Commission, consumer alert "Selling stuff online? Here's how to avoid a scam", 2022-07-27. consumer.ftc.gov. | Craigslist among sites attracting buyers and scammers; fake payments, check overpayment, verification-code requests. |
| S10 | FBI Internet Crime Complaint Center, public service announcement I-111523-PSA, "2023 Holiday Shopping Scams", 2023-11-15. ic3.gov/PSA/2023/psa231115. | Buyer and seller warning signs; the page does not name Craigslist. |
| S11 | FBI Internet Crime Complaint Center, 2025 Internet Crime Report (PDF dated 16 April 2026). ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf. | 1,008,597 complaints; $20.877 billion; non-payment and non-delivery 56,478 complaints and $503,373,587; definition in Appendix B; the text does not mention Craigslist. Shares 5.6 and 2.4 percent are our arithmetic. |
| S12 | Federal Trade Commission, press release "FTC Data Show People Reported Losing $3.5 Billion to Imposter Scams in 2025", 2026-06-15. ftc.gov. | About $16 billion in fraud losses reported for 2025. |
| S13 | CBS Philadelphia, "Philadelphia Police Search For Suspects In Craigslist-Related Robberies", 2011-08-19. cbsnews.com. | Police statement on robberies after watches were listed; advice to meet in public. |
| S14 | CBS Baltimore (WJZ), "Detectives issue warning after string of Craigslist robberies", 2013-01-20. cbsnews.com. | Baltimore City police warning; robbers found sellers through listings; public meeting place advised. |
| S15 | San Mateo Police Department, Safe Exchange Zone page. cityofsanmateo.org/4483/Safe-Exchange-Zone. No date shown, read 2026-11-06. | A camera-monitored meeting place for private online sales; the page names no platform. |
| S16 | Addai, D. (2026). Empty Is Not Absent: Silent Failure Modes in Open-Source Mobile Forensic Parsers on iOS 26 and Android 16. Lab Technical Report LAB-TR-0006, abstract. doi:10.5281/zenodo.23717928. | A parser can return an empty table instead of an error; parsers should report how many files each pattern matched. |
| S17 | Addai, D. (2026). What an Empty Result Licenses: A Sound Calculus of Absence Claims for Phone Evidence. Lab Technical Report LAB-TR-0034 (available on this site, no DOI yet), abstract. | An empty result supports "nothing happened" only where the phone could have recorded the event. |
Version history and corrections
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-11-06 | First publication. |
Corrections log
No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.