Private Pierce

Travel and Mobility

Travel questions become tractable when record, border, loyalty, network, and carrier questions stay separated and route to the page that owns each fact.

Use this hub to map the questions that arise before, during, and after a trip, then follow each link to the page that owns the applicable rule, dataset, or technical mechanism.

For mobile private operators mapping what to review before, during, and after a trip without treating one country's rule or one vendor policy as universal.

Covers: visible, searchable, indexable, reusable, actionable, verified, constrained

Start here

Records across a trip

The exposure vocabulary used to classify travel records belongs to The Nine Exposure Verbs.

Use The Nine Exposure Verbs for the site's exposure vocabulary. The traveler scenario applies that vocabulary without redefining it or treating every record as if it had the same access path.

For the Puerto Rico case, see Puerto Rico Jurisdiction Reference: Records and Exposure.

The list below links the Travel research pages. Each listed page keeps its own factual scope, source dates, and unresolved gaps.

Trip-stage exposure

Border Device Search owns the factual answers about compelled unlock, passcodes, biometrics, device or account reach, federal-circuit positions, and published device-search counts; this hub only organizes those questions by trip stage.

Border Device Search owns the border-specific legal limits on compelled unlock, passcodes, biometrics, and the reach of a demand across devices, authentication factors, accounts, cloud content, and detention. It also owns the cited federal-circuit positions and published CBP device-search counts.

Before the border, use the technical owners for Passkeys and Second-Factor Location, Full-Disk and Container Encryption, and 3-2-1 Backups and Border Crossings. At the border and during secondary screening, return to Border Device Search for the supported legal record rather than inferring a legal answer from a technical mechanism.

After crossing, the accepted T00 evidence supplies no factual basis for government redress or records-request procedures following a seizure or repeated secondary referral. This hub therefore states no custody-receipt, port-contact, complaint, records-request, or redress procedure.

  • Before the border: separate device, authentication, encryption, and backup mechanics from border-law questions.
  • At the border: use Border Device Search for supported compelled-access and search-limit facts.
  • During secondary screening: keep the same legal questions with the Border Device Search owner page.
  • After crossing: treat redress and records-request procedures as an unresolved T00 gap, not as an answer supplied by this hub.

Traveler threat model

Identify the travel scenario, then use the generic method at Threat Models; the accepted T00 evidence does not supply a separate traveler-specific threat-model method.

Start by naming the travel scenario and the question it raises, then use Threat Models for the generic method. Keep record systems, border authority, device mechanics, communications law, loyalty data, network characteristics, and carrier acceptance as separate questions until an owning page supplies the applicable evidence.

The accepted inputs for this hub provide structure sources only for this section. They do not establish a traveler-specific threat-model method, so no additional method, risk ranking, or factual traveler profile is asserted here.

  • Name the travel scenario without adding an unstated personal profile.
  • Use Threat Models for the generic method.
  • Route each factual subquestion to its owner before drawing a conclusion.

Loyalty and location history

Hilton's published policy provides one bounded example: a Hilton Honors number appears in both its reservation collection list and its logged-in member browsing list, alongside different fields in each context.

In Hilton's documented reservation example, the collected categories include a Hilton Honors number alongside name, additional names, phone number, address, address type, email address, preferred language, payment-card information, room preference, corporate name and number, travel-agent name and number, and airline-partner name and number.

In Hilton's documented example for a Hilton Honors member who logs into an account during a browsing session, 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.

These are vendor-stated collection lists for two defined Hilton contexts. They are not a claim about every loyalty program or any person's history. An IP address in the browsing list is a collected field, not proof of a stay or physical location.

  • Reservation context: the Hilton Honors number appears with identity, contact, payment, room, corporate, travel-agent, and airline-partner fields.
  • Logged-in member browsing context: the Hilton Honors number appears with network activity, IP address, session ID, feedback, and loyalty-tier fields.
  • Evidence boundary: this is one published vendor-policy example, not a universal loyalty-program model or a personal travel history.

Network hygiene

Within TLS, application-data payloads are opaque to TLS and application-data messages are protected, but TLS remains susceptible to traffic analysis based on encrypted-packet length and timing.

The TLS boundary is specific. Application Data messages contain payloads that are opaque to TLS, and those messages are protected. The same standard states that TLS remains susceptible to traffic analysis based on the length and timing of encrypted packets.

That evidence does not support a claim that TLS is ineffective against its defined threats, nor does it extend application-data protection to endpoints or to information outside the standard's stated scope. It supports a narrower distinction between protected application-data messages and observable length-and-timing characteristics.

Capability facts about formation filings, mail, and masked identifiers belong to the Private Operator Stack. DNS-Level Filtering and Outbound Firewalls and Operating-System Telemetry remain separate technical references; this hub does not turn any of them into a product recommendation.

  • Protected within the stated TLS scope: application-data messages.
  • Not eliminated by TLS: traffic analysis based on encrypted-packet length and timing.
  • Not supplied here: a product ranking or product recommendation.

Carrier acceptance

VoIP and Carrier Numbers owns number-type acceptance, verification, carrier-versus-VoIP, and carrier-number-abroad questions.

Use VoIP and Carrier Numbers for number-type acceptance and verification, including carrier-versus-VoIP questions and carrier numbers abroad. Use the Private Phone-Number App Comparison for masking, retention, and verification-trigger capability facts, and the Private Operator Stack for its formation-filing, mail, and masked-identifier capability facts.

The accepted T00 evidence does not support any foreign-carrier acceptance claim beyond those owner pages. Carrier or service acceptance should therefore remain an unresolved question whenever the cited owner does not answer the exact country, number type, or verification context.

Related threat models

Continue across subjects