Social Media Evidence Collection: API, Direct, Indirect and OSINT
Sources of social media evidence, the four collection methods (direct without login, direct with login, API-based and indirect), the OSINT toolset from Maltego to Sherlock, EXIF and document metadata extraction, geolocation pivots, recovery of deleted content via Wayback and provider subpoena, and authentication at trial under BSA Section 63.
Last updated:
Social media evidence collection uses four methods matched to four visibility tiers: direct without login (public OSINT), direct with login (account-access under warrant or consent), API-based (structured platform data under developer terms), and indirect (graph traversal through mutual contacts and tagged content). Platform metadata of greatest investigative value, including IP login logs, device IDs, and account creation records, sits exclusively in the provider tier and requires a BNSS Section 91 production order or MLAT request to obtain. Because stories vanish in 24 hours and deleted content is retained by providers for as little as a few days, the correct acquisition sequence is to preserve perishable public content first, then persistent account content, then serve the formal production order. Admissibility in Indian courts runs through BSA 2023 Section 63 certification, as confirmed in Anvar P V v P K Basheer (2014) and Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020).
Social media evidence degrades fast. Stories vanish in 24 hours, edited tweets retain only a 60-minute edit window on X Premium, Snapchat content disappears from view almost immediately, and platform metadata of investigative value, including IP logs, login fingerprints, and device IDs, sits behind a subpoena. The forensic discipline is therefore one of staging: capture perishable content first, then persistent content, then serve the formal production order for provider records.
Key takeaways
- Stories vanish in 24 hours and Snapchat content disappears almost immediately, so the correct acquisition sequence is to capture perishable content first, then persistent content, then chase provider records via subpoena.
- A social media account holds eleven artefact classes across four visibility tiers: public, friends-only, private DMs, and provider-only, with a different legal access route required for each tier.
- OSINT tools including Maltego, Sherlock, SpiderFoot, and Hunchly form the standard toolkit for aggregating open-source data across platforms before any formal legal process is needed.
- Image metadata extraction and geolocation pivots from EXIF GPS coordinates to Snap Map can establish physical location evidence directly from user-posted content without touching provider records.
- Indian trial admissibility for social media evidence runs through BNSS Section 91 production orders, BSA Section 63 certification, and the Anvar and Arjun Khotkar case line that governs electronic record proof.
This topic walks the social media acquisition stack end to end. It covers the eleven sources of evidence visible on a typical platform account, the four data-visibility tiers from public to provider-only, the four collection methods (direct without login, direct with login, API-based and indirect), the OSINT toolset led by Maltego, Sherlock, SpiderFoot and Hunchly, the metadata extraction routine for images and documents, the geolocation pivots from EXIF GPS to Snap Map, the deleted-content recovery options via Wayback, archive.today and provider subpoena, and the Indian authentication route at trial through BNSS Section 91, BSA Section 63 and the Anvar / Arjun Khotkar line of cases. The companion topic on social media crime taxonomy covers the offence side.
By the end of this topic you will be able to:
- Classify a social media account's artefacts across the four visibility tiers and identify the correct legal access route for each tier.
- Select and apply the appropriate collection method (direct without login, direct with login, API-based, or indirect) given the target account's privacy posture and the case's legal instruments.
- Construct an OSINT pipeline using Maltego, SpiderFoot, Sherlock, Hunchly, and ExifTool to aggregate cross-platform identity evidence and preserve chain of custody.
- Extract and interpret EXIF, document, and video metadata for geolocation, device attribution, and timeline reconstruction, accounting for platform-side metadata stripping.
- Produce a BSA Section 63 certificate for social media evidence that satisfies the Anvar / Arjun Khotkar admissibility standard at trial.
- OSINT
- Open Source Intelligence. Information collection from publicly available sources, without authentication. Includes public social media profiles, search engines, archives, leaked data corpora and registered-business records.
- Direct collection (without login)
- Acquisition of a target's public profile content using no credentials. The page is served to anyone. Limited to whatever the privacy settings expose to the public tier.
- Direct collection (with login)
- Acquisition using the subject's account credentials or a session cookie lifted from a seized device. Requires legal authorisation under BNSS Section 91 or a warrant; the chain of custody must explain how the credentials were obtained.
- API-based collection
- Acquisition via the platform's official API: X v2 API, Meta Graph API, LinkedIn API. Requires a developer account, often paid tiers, and platform-side terms of service that constrain forensic use.
- Indirect collection
- Deriving evidence from interconnected accounts (mutual friends, tagged content, common groups) rather than the target's own profile. Powerful when the target's account is private or deleted.
- Hunchly
- Browser-based case-management tool for OSINT. Captures every page visited as a hashed snapshot, builds the case dossier and produces a court-ready report. The standard tool for OSINT chain of custody.
Sources and visibility tiers: what lives where on a social media account
A social media account holds far more than the public timeline. The examiner's first job is to map the artefact surface against the visibility tiers, because the collection method that applies to each is different.
| Artefact class | Examples | Visibility tier | Standard access |
|---|---|---|---|
| Profile content | Bio, display name, profile photo, cover photo, links | Public | Direct without login; archive via Wayback |
| Timeline posts and stories | Feed posts, Reels, IG/FB stories, X tweets | Public or friends-only | Direct or indirect; story preservation in 24 hours |
| Direct messages | Instagram DMs, X DMs, WhatsApp chats | Private | Device acquisition or provider subpoena |
| Story / status archive | User's own archive of past stories | Account-only | Direct with login or provider subpoena |
| Search history | Recent searches within the app | Account-only | Device or account download |
| Friend / follower list | Connections, mutuals, blocked list | Friends-only to public | Direct or indirect via OSINT |
| Location check-ins and tagged places | Public check-ins, place tags | Public or friends-only | Direct or OSINT (Snap Map, IG location pages) |
| Photos with EXIF / geotag | User-uploaded images | Tier of containing post | EXIF extracted post-acquisition (often stripped by platform) |
| Saved content | Bookmarks, saved Reels, saved posts | Account-only | Direct with login or account download |
| Ad preferences | Categorised interests, advertiser audiences | Account-only | Account download (Meta 'Download your information') |
| Connected apps via OAuth | Third-party apps with scope-granted access | Account-only | Account settings or account download |
| Provider-side records | Login IP logs, device IDs, hashed passwords, sign-up email | Provider-only | Subpoena under BNSS Section 91 / MLAT |
The visibility tier determines the legal pathway. Public content is acquired without authorisation (OSINT). Friends-only or mutual-follow content is acquired with the subject's consent or via an indirect path (a mutual contact's account viewing the content within the scope of the warrant). Private content (DMs) sits on the device or requires a production order to the provider. Provider-only content (login IPs, account creation metadata, security event logs) requires a BNSS Section 91 production order, an IT Act Section 69 direction for interception, or for foreign platforms an MLAT request in parallel with the platform's Law Enforcement Request System (LERS).
A practical note about story-class content. Instagram and Facebook stories disappear from the public surface after 24 hours but persist in the user's own archive and on Meta's servers under the data retention policy. WhatsApp status follows a similar window. The acquisition discipline is to preserve immediately on victim notification, because the provider-side retention for non-account-holders is shorter than the user-archive window.
The four collection methods: direct without login, direct with login, API, indirect
The four standard collection methods cover the field. Each has a typical use case, a tool family and a legal posture under Indian procedure.

| Method | Use case | Tool family | Legal posture |
|---|---|---|---|
| Direct without login | Public profile, public posts, OSINT cluster mapping | Hunchly, Wayback, archive.today, browser DevTools, wget | No authorisation required for public content |
| Direct with login | Subject's own account; recovered session cookie from seized device | Browser, account download tools, X-Ways Forensics for cookie extraction | BNSS Section 91 production order or consent of account holder; warrant where credentials forced |
| API-based | Bulk collection, structured fields, repeat queries | X v2 API, Meta Graph API, LinkedIn API, Tweepy, snscrape (where permitted) | Platform terms of service apply; developer access keys required; some APIs paid-only |
| Indirect | Target account is private, deleted or unreachable | Maltego, Sherlock, theHarvester, friend-of-friend graph traversal | OSINT for public-tier visible-via-others; production order for provider-side |
Direct collection without login is the default for any FIR that names a public-tier account. The investigator opens the profile in an isolated browser (Hunchly running), captures every page (URL, full DOM, screenshot, hash), archives via Wayback Machine and archive.today, and exports the captured pages to the case dossier. Hunchly is the Indian state cyber-cell standard for OSINT chain of custody because every page capture is automatically SHA-256 hashed, time-stamped and packaged with the case ID.
Direct collection with login is the path when the target account is the subject's own (seized device, voluntary unlock or BNSS Section 105 search warrant) or when the victim's account is being preserved. Cookie acquisition from a seized device lets the examiner authenticate as the user without forcing a password reset that the attacker would notice. The platform's data-export ('Download your information' on Meta, 'Download your data' on X) yields the account-only artefacts in a structured archive. The chain of custody must record how the credentials or session cookie were obtained.
API-based collection is the structured path. The X v2 API yields tweets, replies, follower lists, user lookups and DMs (with the right scopes) under paid tiers. The Meta Graph API requires app review for most non-public scopes; the older Public Feed and Keyword Insights APIs that historically supported research are deprecated. LinkedIn's API is largely closed; investigators rely on direct collection with login. Tweepy is the Python wrapper for the X API; snscrape historically scraped Twitter without API access but is constrained by current X policy.
Indirect collection is the path when the target account is locked. The mutual contact's view (with their cooperation and consent), the tagged-content cluster across other accounts, the common-group membership and the public mentions of the target on other accounts all yield evidence without touching the locked account. Maltego is the link-analysis workhorse: entities (account, email, phone, domain) and transforms (run a query on each entity to find related entities) build a graph that the IO can pivot through. Sherlock takes a username and queries 400+ platforms for matching profiles in seconds.
The OSINT toolset: Maltego, SpiderFoot, Recon-ng, Sherlock, Hunchly

OSINT for social media runs on a small set of category leaders. The examiner does not need every tool; one from each category gets the job done.
| Tool | Category | What it does | Forensic use |
|---|---|---|---|
| Maltego | Link analysis | Graphs entities and transforms; 100+ community transforms | Cluster identification, sock-puppet linkage, common-infrastructure mapping |
| SpiderFoot | Automated reconnaissance | Runs 200+ modules against a target (domain, IP, email, name) | Bulk recon on a person or organisation; first-pass OSINT sweep |
| Recon-ng | CLI OSINT framework | Modular CLI reconnaissance with workspaces and modules | Scripted recon in headless investigation pipelines |
| Sherlock | Username enumeration | Checks 200+ platforms for a given username | Cross-platform identity mapping for a single handle |
| theHarvester | Email and subdomain enumeration | Harvests emails, subdomains, hosts from search engines | Corporate target recon; phishing kit infrastructure mapping |
| Hunter.io | Email pattern discovery | Finds emails by domain pattern (first.last@example.in) | Witness contact, corporate phishing target list |
| OSINT Framework | Catalogue | Curated directory of OSINT tools by category | Reference for choosing the right tool per task |
| Censys | Internet asset search | Indexes TLS certificates, banners, services across IPv4 + IPv6 | Phishing kit hosting, malicious infrastructure |
| Shodan | Connected device search | Indexes banners on internet-facing services | Connected IoT exposure, exposed databases linked to a target |
| Hunchly | Case management | Captures every visited page with hash, timestamp and case ID | OSINT chain of custody for court |
| Wayback Machine extension | Browser plugin | Archives the current page or fetches archived versions | Quick preservation of pages that may disappear |
| ExifTool | Metadata extraction | Reads and writes EXIF, IPTC, XMP across image and document formats | Image attribution, GPS extraction, camera fingerprint |
The reference workflow stacks these tools in order. SpiderFoot runs the first-pass sweep against the target identity (name, email, phone, username) to gather every public reference. Sherlock checks the username across 200+ platforms to find cross-platform accounts. theHarvester adds the email-and-subdomain corpus. Maltego ingests the SpiderFoot and Sherlock outputs as entities and runs transforms to expand the graph (related accounts, registered domains, breach corpus matches). Hunchly captures every page touched in the investigation, building the case dossier with hash and timestamp on each capture. ExifTool extracts metadata from any images or documents recovered. Shodan and Censys map the infrastructure side when phishing kits or malicious hosting are part of the case.
The Indian state cyber cells maintain Maltego Classic or Maltego CE licences for link analysis and Hunchly site licences for case management. The procurement template treats both as core OSINT tools alongside the disk-imaging hardware. SpiderFoot HX is the hosted variant some units use for cloud-side scanning.
- Define the target entity setNames, usernames, email addresses, phone numbers, known account URLs. Capture the entity set in writing at the start of the case.
- First-pass sweep with SpiderFoot or theHarvesterRun a 200-module sweep on the target identity. Export findings as a CSV ingestible into Maltego.
- Username enumeration with SherlockRun Sherlock against each known username. Capture the hit list; visit each hit through Hunchly so the page is preserved.
- Link analysis in MaltegoImport the entity set; run transforms (Have I Been Pwned, breach corpus lookups, WHOIS, social media graph) to expand connections.
- Per-account direct capture via HunchlyOpen each target profile through Hunchly. Every page is hashed, timestamped and added to the dossier with the case ID.
- Metadata extraction on recovered images and documentsRun ExifTool on downloaded images. Note EXIF GPS, camera make/model, timestamp, software, thumbnail. Cross-reference document metadata (Word author, PDF producer) for attribution.
- Generate the Hunchly case report and BSA Section 63 certificateHunchly exports the case dossier with hashes and an evidence index. Sign the BSA Section 63 certificate over the dossier file for production at trial.
Metadata and geolocation: EXIF, document metadata, Snap Map, Strava
When a user uploads a photo or document to a social media platform, much of the embedded metadata travels with the file unless the platform strips it on ingest. The examiner's task is to extract whatever the platform retained and, more productively, to locate the off-platform copies that carry the complete metadata set.
| Metadata class | Fields of forensic interest | Tool |
|---|---|---|
| EXIF (image) | Camera make/model, lens, ISO, aperture, shutter, GPS coordinates, software, original timestamp, modify timestamp, thumbnail | ExifTool, Jeffrey's Image Metadata Viewer, ExifPilot |
| IPTC / XMP (image) | Description, author, copyright, keywords, location names | ExifTool |
| Document (Word, Excel, PowerPoint) | Author, last-modified-by, company, total editing time, revision number, template path | ExifTool, oletools, DocBleach |
| Producer, creator, title, author, modify-date, document-ID | ExifTool, pdfinfo, peepdf | |
| Video (MP4, MOV) | Container metadata, recorded timestamp, codec, GPS atoms (iOS, Samsung), encoder | ExifTool, MediaInfo |
| Audio (M4A, MP3) | Encoder, recording timestamp, ID3 tags, device model | ExifTool, MediaInfo |
Most major social media platforms strip EXIF from uploaded images for privacy reasons. The forensic implication is that an EXIF-rich image found in a victim's WhatsApp media folder, or in an attached email, or in a cloud backup retains the GPS coordinates that the public Instagram upload of the same image does not. The off-platform copy is therefore evidentiarily richer than the on-platform copy.
ExifTool is the unified tool. A single command (exiftool -GPSLatitude -GPSLongitude -DateTimeOriginal -Make -Model file.jpg) yields the relevant fields. ExifPilot is the GUI variant for examiners who prefer a windowed workflow. Jeffrey's Image Metadata Viewer is a quick web-based reader for triage.
Geolocation pivots beyond EXIF.
- Geotagged postsInstagram location pages, X tweet location (where enabled), Facebook check-ins. Open the platform's location page for the tagged place; the post will appear in the public feed for that place.
- Snap MapSnapchat's public-tier location feed shows submissions to 'Our Story' on a world map. Useful for events and breaking incidents.
- Strava heat mapStrava's public global heat map exposed the locations of US and allied military bases in 2018 when service members ran routes that lit up otherwise-classified perimeters. The cautionary tale applies broadly: any aggregate fitness data leaks individual location.
- Background-derived geolocationLandmark recognition in photos. The 2018 Bellingcat investigations into MH17 and Syria established the technique: identify the photo's location from architectural and geographic landmarks visible in the background.
- Wi-Fi BSSID lookupIf a photo's EXIF or metadata captures nearby Wi-Fi BSSIDs (some Android cameras and IoT devices do), services like WiGLE map BSSIDs to physical locations.
- IP-derived approximationLogin IP from the provider subpoena, geo-resolved to city. Approximate, not precise, but corroborative.
The Strava 2018 incident illustrates a broader principle: aggregate, anonymised data still locates individuals when the underlying population is small. The investigator should expect that fitness apps, ride-share apps and food-delivery apps carry the same risk pattern, and that subpoena to those providers (BNSS Section 91) is part of the toolkit when a target's physical location at a given hour is the question.
Deleted and edited content: Wayback, archive.today, provider subpoena, notification cache
When a target realises an investigation is under way, post deletion, tweet editing, and DM clearing are immediate responses. Five complementary recovery paths address this.
| Path | Coverage | Limitations | Indian access route |
|---|---|---|---|
| Wayback Machine (web.archive.org) | Public web pages, including many public profiles | Coverage depends on whether the crawler visited; private posts not captured | Open access; cite by archive URL with timestamp |
| archive.today | Manual snapshot service; preserves on demand | Snapshot must be triggered before deletion | Open access; investigator can trigger preservation on observation |
| Google cache (deprecated 2024) | Historically retained Google's last crawl of a page | Discontinued by Google in early 2024; Bing cache still available for some pages | Open access where available |
| Provider subpoena for retained server-side copy | Many platforms retain deleted content for 30-90 days for abuse review | Window is short; preservation request must go in fast | BNSS Section 91 production order; MLAT for foreign provider |
| Push-notification history on phone OS | iOS Notification Centre and Android notification log retain DM and post text | Device must be accessible; OS retention varies | Device acquisition under BNSS Section 105 search warrant |
| Platform edit history | X Premium (60-minute edit window), Reddit edit history, Threads | Only where platform exposes the edit chain | Direct collection or platform LERS |
The Wayback Machine is the default first move for any public-tier deletion. The investigator pastes the profile URL into web.archive.org and checks for snapshots. The archive URL itself (https://web.archive.org/web/YYYYMMDDHHMMSS/https://...) is the citable evidence; the snapshot date is the timestamp at which the page held the content shown. For pages not previously crawled, archive.today lets the investigator trigger a snapshot at the moment of observation, before the target deletes.
Google's cache (previously available at cache:URL or via the search-result cached link) was deprecated by Google in February 2024. Some Bing cached pages remain available. archive.today is the surviving on-demand alternative.
Provider-side retention varies. Meta retains deleted content in a recovery queue for 30 days for the account holder and longer for the provider's abuse-review functions; X has historically retained deleted content for up to 30 days during its deletion process, with server copies potentially persisting for up to 90 days; WhatsApp's content is end-to-end encrypted and provider-side recovery is generally not available (metadata is available). A preservation request to the platform's Nodal Contact Person (for SSMIs under the Intermediary Guidelines 2021) is the immediate action; the formal production order under BNSS Section 91 follows.
The notification cache is an underused source. iOS Notification Centre and Android's notification log retain the preview text of social media DMs and post mentions for a window that depends on the OS version (typically the most recent 48-72 hours of notifications, longer for some message types). When the target has deleted the DM but the recipient's device still has the notification cached, the cache is a primary evidence source. Cellebrite, Oxygen Detective and Magnet AXIOM all parse the notification stores.
Edit history is platform-specific. X Premium allows editing a post for 60 minutes; the platform exposes the edit chain to viewers. Reddit's edit history is accessible to logged-in users. Threads inherits Instagram's edit semantics. Where the edit chain is exposed, capture it via Hunchly before the platform's window closes.
Authentication at trial: BSA Section 63, BNSS Section 91, Anvar, Arjun Khotkar
Social media evidence reaches the trial court through the same admissibility framework as all electronic records: BSA 2023 Section 63, which replaced IEA Section 65B. The certificate format and the case-law line that interprets it define the qualification standard.
| Element | Statutory anchor | Indian case-law anchor | Practical content |
|---|---|---|---|
| Production of records from provider | BNSS Section 91 (was CrPC 91) | Bishwajit Halder line on procedural propriety | Magistrate's order, served on platform's RGO or LERS portal |
| Interception or stored-content access | IT Act Section 69 | PUCL v Union of India (1996) safeguards extended to electronic | Authorised officer, written reasons, time-bound, reviewed |
| MLAT for foreign providers | Mutual Legal Assistance Treaties (US, UK and others) | Government of India guidelines on MLAT requests | Channelled through MHA Internal Security division |
| Electronic record admissibility | BSA 2023 Section 63 (was IEA 65B) | Anvar P V v P K Basheer (2014); Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020); Shafhi Mohammad v State of Himachal Pradesh (2018) [restricted] | Certificate identifying the device, the imaging method, the working condition, signed by responsible official |
| Expert opinion at trial | BSA Section 39 (was IEA 45) | State of NCT of Delhi v Navjot Sandhu line, post-Anvar | Examiner's deposition admissible as expert evidence |
The Indian case-law evolution on electronic-record admissibility runs through three landmark judgements. In Anvar P V v P K Basheer (2014) the Supreme Court held that Section 65B (now BSA Section 63) is a mandatory pre-condition to admissibility of any secondary electronic evidence, and that oral evidence about the contents of an electronic record cannot substitute for the certificate. In Shafhi Mohammad v State of Himachal Pradesh (2018) a two-judge bench appeared to relax the requirement when the certificate could not reasonably be procured; that relaxation was overruled. In Arjun Pandit Rao Khotkar v Kailash Kushanrao Gorantyal (2020) a three-judge bench restored Anvar P V in full: the certificate is mandatory; the party seeking admission must produce it; failure is fatal. BSA 2023 Section 63 codifies the Anvar / Arjun Khotkar position.
The certificate's content (under BSA Section 63(4)) identifies the electronic record, describes the way it was produced (including the device, the software and the imaging method), states the conditions under which the device operated (the device was used regularly and was operating properly during the relevant period; the information stored is regularly fed in the ordinary course of activities), and is signed by a person occupying a responsible official position in relation to the operation of the relevant device. For social media evidence the 'device' includes the imaging workstation and any platform-side records produced under BNSS Section 91.
- Capture the page with URL visibleBrowser address bar visible in screenshot. Hunchly does this automatically; manual capture requires a full-page screenshot tool that captures the chrome.
- Hash the captured artefactSHA-256 over the captured page bundle (HTML, screenshot, MHTML or PDF). Record the hash in the chain of custody.
- Cross-reference with provider recordsWhere available, match the captured content against the provider's API or production-order response. Note the Message-ID / post-ID / tweet-ID for cross-reference.
- Image the device side if applicableWhere the captured content sits on a seized device (notification cache, app database, browser cache), image the device under BNSS Section 105 search warrant procedure.
- Draft the BSA Section 63 certificateCertificate identifies the device, describes the imaging method (Hunchly version, browser version, OS, network position), states the working-condition language and the regular-feed language, and is signed by the responsible official (senior FSL analyst or IO with the requisite designation).
- Annex to charge sheet under BNSS Section 193The FSL report, the captured exhibits with hashes, the platform's production-order response (if any) and the Section 63 certificate together form the annexure to the charge sheet.
- Lead expert evidence at trialExaminer deposes under BSA Section 39 (expert opinion). Cross-examination typically targets the chain of custody, the imaging method and the certificate's signatory authority.
The Indian context anchor for foreign-platform subpoena is the Sushant Singh Rajput investigation, in which the Mumbai Police and later the CBI sought records from Twitter (now X) and Instagram for posts and DMs of multiple parties. The cooperative request channel ran through Meta's and X's Law Enforcement Request Systems in parallel with formal MLAT requests via the MHA. Bombay High Court orders on Twitter content takedown during the same period set out the procedural template for high-profile takedown applications.
The cross-link for the substantive admissibility doctrine sits with Bharatiya Sakshya Adhiniyam 2023 Section 63; the BNS 2023 cyber and BSA 2023 electronic evidence topic covers the wider statutory frame.
Which collection method applies when the target's social media account is private and the investigator must derive evidence from mutual friends, tagged content and common groups?
Frequently asked questions
What are the four visibility tiers on a social media account and how do they map to collection methods?
Which OSINT tools are standard in Indian state cyber-cell procurement?
How is EXIF metadata extracted from a recovered image, and what is the GPS field of interest?
What are the standard recovery paths for content the target has deleted from a social media account?
What does the BSA Section 63 certificate need to contain for social media evidence?
How does the investigator obtain content from Meta, X or Google when no Indian office is incorporated for content access?
Why is the notification cache on a recipient's phone a useful evidence source after a DM is deleted?
Test yourself on Digital Forensics with free, timed mocks.
Practice Digital Forensics questionsSpotted an error in this page? Report a correction or read our editorial standards.