Location logs across apps photos vehicles and accounts

How should a cross-system location map be read?

Read each system as a separate evidence row: a permission, identifier, provider record, or account control does not by itself establish that location was collected or that a person was physically present.

The useful comparison is not a single location-history switch. It is a set of narrower questions asked of each named system: what event or permission is documented, which field is recorded, which actor controls the record, whether a sharing path is stated, whether retention or deletion is addressed, and what conclusion the evidence cannot support. Keeping those columns separate prevents a permission state from becoming a coordinate, an account identifier from becoming a trip, or a provider collection list from becoming a complete personal history.

The Federal Trade Commission's Gravy Analytics order supplies one order-specific definition for the opening boundary. In that order, Location Data includes data that may reveal a mobile device's or consumer's precise location, including Global Positioning System coordinates and cell-tower information. That definition explains what the Gravy Analytics order calls Location Data. It does not establish that every system on this page collects those examples, that a listed field was associated with a named person, or that one record proves conduct at a place.

Each section below therefore begins with the narrowest supported answer. Where a source establishes a permission state or provider collection list, the page names that context. Where no source on this page establishes photo-copy behavior, shared-channel behavior, or completed account-history deletion, the page says so directly. The methodology explains the source hierarchy and how freshness is handled.

• System — Name the application, file, vehicle service, provider account, shared channel, or account-history surface.
• Trigger or permission — Record the documented action or state without treating it as proof that collection occurred.
• Field — Preserve the source's own category and do not convert an identifier into a coordinate or presence claim.
• Controller and sharing path — Name the actor and recipient context only when the source does.
• Retention or deletion — Keep a stated rule, an available control, and completed erasure as separate claims.
• Evidence limit — State what the cited record does not establish before drawing any cross-system inference.

What do application permissions and background access establish?

A documented browser permission establishes an allow-or-deny choice and a queryable state that can change; it does not establish that an application collected location, used background access, stored a history, or transmitted a coordinate.

The browser standard describes common permission infrastructure for powerful platform features. In that model, the permission represents a user's choice to allow or deny access, and developers can query the state and receive notice when it changes. The permission is therefore a control state, not a record of what the application did after receiving or being denied access.

Four follow-on questions require their own evidence. Did the application request or obtain a location value? Did it operate while the application was not in active use? Did it store a history? Did it transmit data to another actor? An allowed state answers none of those questions by itself. A denied state likewise does not establish the absence of every other source of location-related information available to the device, account, network, or service.

The related Outbound Firewalls and Operating-System Telemetry reference owns the boundary between permission state and broader telemetry. That link does not add a collection finding here. For this map, the defensible entry is narrower: permission status is documented, while collection, background use, storage, and transmission remain separate evidence fields.

• Supported: the permission represents an allow-or-deny choice for a powerful platform feature.
• Supported: the permission state can be queried and can change.
• Not established by that state: collection of a location value.
• Not established by that state: background use, a stored history, or transmission to another actor.

Does photo metadata remain when a photo is shared?

No source on this page establishes which photo-file fields can contain location, whether a copied photo keeps those fields, or whether a receiving service preserves or removes them.

The photo question needs at least three separate answers: the fields present in the original file, the fields present in the shared or exported copy, and the receiving service's handling of that copy. No photo-metadata source on this page settles those questions. The page therefore does not name a metadata field, promise that sharing strips data, or claim that a recipient preserves it.

A preview, library entry, message attachment, downloaded copy, and cloud-hosted object may be different artifacts, but no source on this page establishes how any particular product treats them. Missing support is not evidence that location metadata is absent. It is also not permission to import familiar product behavior or general technical knowledge into the page.

A defensible check remains artifact-specific. Identify the exact file or copy being examined, the source date or version that describes it, and the field the source actually supports. Until a source answers those questions, sharing outcome, receiving-service behavior, and later retention are not established here.

What can a vehicle or manufacturer account record about location?

The Federal Trade Commission's final order concerning General Motors defines a bounded category of Covered Driver Data and imposes a scoped consent requirement; those terms do not establish the contents of every vehicle, application, trip, or driver record.

The Federal Trade Commission's final order concerning General Motors defines Covered Driver Data to include specified information originating from a vehicle or, when obtained from a General Motors-branded mobile application, a mobile device, as well as derived data that is Location Data or a listed event linked or reasonably linkable to a United States consumer. The definition matters because it keeps vehicle-originated information, application-originated information, and derived data within the General Motors order's own wording. It does not turn every vehicle signal into Location Data or show that a particular vehicle generated a particular record.

The General Motors order separately requires, within 180 days after its effective date, the relevant United States consumer's Affirmative Express Consent before the covered collection, use, or third-party disclosure of that consumer's Covered Driver Data, subject to seven purposes enumerated in the order. A requirement in the General Motors order is not a universal description of every manufacturer, vehicle service, application, jurisdiction, or historical record. The enumerated purposes and the order's timing remain part of the scoped claim rather than being shortened into a broader rule.

Vehicle, mobile-application, derived-data, consent, disclosure, and presence questions should therefore stay in different columns. The General Motors order establishes its definition and requirement at their stated scope. It does not establish which data a named vehicle currently holds, whether a specific consumer consented, whether a disclosure occurred, how long a record remains, or where a person was at a particular time.

Does a loyalty account prove that someone traveled?

No. Hilton's published collection lists show that a Hilton Honors number can appear in two defined provider contexts, but neither list proves physical presence, a completed stay, an itinerary, or a universal loyalty-program practice.

In Hilton's documented reservation example, the collected categories include a Hilton Honors number alongside identity, contact, payment, room, corporate, travel-agent, and airline-partner fields. That is a provider-stated collection list for the reservation context. A reservation field can be evidence that a system recorded a category; it does not by itself establish that travel occurred, that the named guest arrived, or that every listed partner received the record.

In Hilton's documented logged-in-member browsing example, the listed categories include internet or network activity information, IP address, session ID, customer ratings and survey responses, free-form textual feedback, Hilton Honors number, and Hilton Honors tier. That second list belongs to a different event: a Hilton Honors member logging into an account during a browsing session. An IP address in that list is a collected field, not proof of a hotel stay or a person's physical location.

The Hilton Honors number connects the two provider-stated lists at the category level, but it does not erase the difference between them. Reservation collection and logged-in browsing collection are different contexts with different accompanying fields. Neither source establishes retention duration, a completed itinerary, recipient access, or what another loyalty provider collects. The Travel and Mobility hub keeps adjacent provider and government travel-record references separate rather than treating one loyalty-account field as a complete travel history.

• Reservation context: the Hilton Honors number appears with identity, contact, payment, room, corporate, travel-agent, and airline-partner fields.
• Logged-in browsing context: the Hilton Honors number appears with network activity, IP address, session ID, feedback, and loyalty-tier fields.
• Evidence limit: neither provider-stated list proves presence, a completed stay, an itinerary, or an industry-wide rule.

What do shared calendars and device-location channels reveal?

No source on this page establishes product behavior, recipient visibility, update timing, retention, or revocation results for a shared calendar or device-location channel.

A shared-calendar entry and a device-location channel should not be collapsed into one mechanism. The questions differ: which actor created or enabled the shared item, which recipients can access it, what field or view is exposed, whether the view updates, whether a recipient can retain a copy, and what happens when sharing is revoked. No source on this page answers those questions for a named product.

The page therefore does not claim that a calendar event contains a location, that a device-location service exposes a live position, that every recipient sees the same information, or that revocation removes earlier copies. Those may be reasonable questions to ask of a product record, but a question is not a finding. Each answer needs a source tied to the named channel, version, account state, and action.

The related Personal AI Data Boundaries page covers a separate access and cloud-use boundary. Linking to that boundary does not establish collection or retention of location data by an AI tool, calendar, or device service. Until sources answer these questions, recipient scope, update behavior, retention, and revocation are not established here.

Does deleting location history remove every copy?

No source on this page establishes a universal retention period, completed deletion, backup erasure, or removal of downstream copies when an account-level history control is used.

History creation, retention, a user-facing control, a deletion request, completed deletion, backup handling, and downstream copies are separate claims. The existence of a control establishes none of the later states unless the source says what the control does and at what scope. A displayed setting cannot be rewritten as proof that every related record was erased.

No account-history source on this page states a retention period or criterion, confirms completed deletion, describes backup persistence, or accounts for copies held by another actor. The page therefore supplies no number, deadline, completion promise, or universal deletion rule. Silence does not mean immediate erasure, indefinite retention, or zero downstream copies.

A source-bounded account-history entry should name the provider and product, identify the record category, distinguish a control from its reported result, and preserve any exception or scope limitation. A later observation of an absent item would still be an observation of one surface at one time, not proof that every copy is gone. Without those records, the correct answer remains narrow: removal across primary storage, backups, recipients, and derived systems is not established here.

1. Identify the exact history surface and record category.
2. Separate the available control from the action a user takes.
3. Separate request submission from provider-reported completion.
4. Treat primary storage, backups, recipient copies, and derived records as distinct scopes.
5. State only the retention or deletion result the source actually establishes.

What can each system infer versus record?

The sources establish one browser permission model, two Hilton collection lists, and three facts from the Gravy Analytics and General Motors orders; they do not establish a person's location, presence, travel, ownership, wrongdoing, or a universal inference rule.

A recorded field and an inference drawn from that field are different statements. The browser-permission source establishes an allow-or-deny state that can be queried and can change. It does not establish collection. The Hilton sources establish provider-stated categories in one reservation context and one logged-in browsing context. They do not establish presence or completed travel. The Gravy Analytics order defines Location Data for that order, while the General Motors order defines Covered Driver Data and states a scoped consent requirement. Neither order establishes the contents of every vehicle or application record.

Cross-system linkage needs evidence of the linkage itself. The same identifier appearing in two provider contexts may support a category-level comparison, but it does not prove that two observed records concern the same event, device, place, or person. An IP address, account number, permission state, reservation field, shared setting, or vehicle-derived category may narrow a question without resolving it. No single one becomes a universal location answer.

The page also preserves what remains unknown. Photo-file and shared-copy behavior is not established. Shared-calendar and device-location-channel behavior is not established. Account-history retention, deletion completion, backups, and downstream copies are not established. Those gaps prevent a complete cross-system chronology and are disclosed rather than filled from common knowledge.

The defensible conclusion is system-specific and source-specific: name the actor, event, field, record, date, and limitation carried by the source. Stop before a documented capability becomes an observed action, before a collected field becomes a physical-presence finding, and before one provider's statement becomes an industry rule.

• Permission state is not collection history.
• A collected identifier is not proof of physical presence.
• A provider-stated context is not a universal industry practice.
• A consent requirement is not proof that a named consumer consented or that a disclosure occurred.
• A deletion control is not proof of completed erasure across every copy.

Frequently asked questions

Related research

• Outbound Firewalls and Operating-System TelemetrySeparates browser permission state from broader operating-system telemetry.
• VoIP and Carrier Numbers: What a Number EstablishesSeparates a portable telephone number from evidence of present physical location.
• Mobile Operating-System Privacy ComparisonIt compares four mobile operating-system paths on update sources, app distribution, identity requirements, and telemetry.