Login & access

What "headshot login" means on this editorial site

The headshot site is an editorial newsroom, not a closed platform. There is no separate account to create to read the desk. The only login-style flow on the site is the play entry route, which uses a single first-party URL with disclosure.

Read access noteOpen the desk
Login and access route explanation illustration

What is here

Reading the desk, vs entering the play route

The headshot site is a public newsroom. Reading any desk, any guide, any newsroom brief is free and does not require an account. The site does not collect a username or password to access editorial content. If you have arrived here looking for a "login" form, the desk's recommendation is to read the page you were trying to log in to, free of charge.

The only login-style flow on the site is the play entry route, which is a single first-party URL. That route is reached via the header CTA, the mobile sticky bar, and a small number of contextual editorial links. The route is hosted at the central /Login/playnow endpoint and is disclosed on every page where it appears.

If you have a question about whether a particular login flow on the headshot site is legitimate, the desk's recommendation is to verify the URL bar before submitting any details. Phishing attempts targeting editorial brands are common, and the desk does not authorise any third-party "headshot login" page outside the central URL.

URL check

How to verify you are on the headshot site

The headshot site is served at headshotin.com. The play entry route is served at headshotin.com/Login/playnow. Any other URL claiming to be a headshot login is a third-party surface that the desk does not control.

The URL bar is the single most reliable phishing defence for editorial brands. Verify that the domain is headshotin.com, that the certificate is valid, and that there is no subdomain or path that the URL bar glosses over. The desk treats these as the minimum verification steps for any reader who is unsure about a login flow.

Phishing awareness

What the desk does if a phishing page is reported

The desk takes phishing reports seriously. If a reader identifies a third-party page that uses the headshot brand name or logo without authorisation, the desk routes the report to the security contact listed on the contact page. The desk does not host or maintain any third-party "headshot login" page outside the central URL.

The desk's standard practice is to publish a public note on the newsroom if a credible phishing attempt is identified. The note names the surface, the affected reader class and the verification steps. The desk never republishes a phishing URL in public copy.

Comparison

Login-style flows, and how to tell them apart

Editorial brands and platform brands use "login" in different ways. An editorial brand login usually unlocks bookmarks, reading history, and saved searches. A platform brand login usually unlocks a wallet, a play entry, a withdrawal, and a notification feed. The two are not interchangeable, and a phishing surface often tries to merge them by asking a reader to enter their editorial credentials on a platform-style page.

The headshot site uses the first pattern. The desk does not host a wallet. The desk does not maintain a platform account. The only login-style flow on the site is the play entry route, which is reached via a single first-party URL. If a reader is asked for a password, an email confirmation, or a phone number on a "headshot login" page, the desk's recommendation is to close the surface and verify the URL bar.

The desk's standard practice is to keep the editorial surface free of friction. A reader should be able to read every desk, every guide, every newsroom brief without creating an account, submitting a password, or sharing personal data. The play entry route is the one exception, and the route is reached via a single URL that the desk displays on every page where it appears.

Editor's note

Why the desk's login posture is editorial, not platform

The decision to keep the headshot site as an editorial surface — with no editorial login, no account, no password — is editorial, not technical. A platform site is built around a wallet, a play entry, and a withdrawal flow. The desk has chosen not to maintain any of those surfaces. The desk's editorial role is to publish reads, not to host a platform.

That decision has consequences. The desk cannot offer personal bookmarks, cannot offer reading history, and cannot offer a notification feed tied to an account. The trade is acceptable to the desk because the alternative — building a platform surface — would compromise the editorial standard. The desk would rather lose personalisation features than compromise the boundary on the responsible play page.

For readers who want a personal feed, the desk publishes an RSS feed at /feed.xml and a sitemap at /sitemap.xml. The two surfaces are standards-compliant and work with any reader that supports them. The desk does not maintain a proprietary notification surface, and the desk will not start a notification surface that requires an editorial login.

Password

Why the headshot site does not ask for a password

The headshot site does not ask for a password. The site does not ask for a username. The site does not ask for a phone number. The site does not ask for a date of birth. The site does not ask for any piece of information that would tie a reader's reading history to a unique identity. The site's editorial surface is intentionally minimal so that the reader can leave without leaving a trace.

The decision is editorial, not technical. A platform site that maintains a wallet must verify the user's identity at every step. The verification is regulatory. The headshot site is not a platform site, and the verification step is not required. The site's editorial role is to publish reads, not to identify readers. The trade-off is acceptable to the desk because the alternative would compromise the editorial standard.

For readers who want a personal feed, the site publishes an RSS feed at /feed.xml and a sitemap at /sitemap.xml. The two surfaces are standards-compliant and work with any reader that supports them. The site does not maintain a proprietary notification surface. The site does not maintain a saved-search surface. The site's editorial role is the URL; the reader's role is the reader.

If a third-party surface asks for a password on a "headshot login" page, the standard verification step is the URL bar. The canonical URL is headshotin.com. The canonical path for the play entry is /Login/playnow. Any other URL that asks for a password is not a headshot surface, and the desk's recommendation is to close the surface and verify the URL bar against the canonical list on the official-website page.

For readers who have already submitted a password to a third-party surface, the standard recovery steps are: change the password on any account that shares the password, run a security scan on the device used to submit the password, and contact the relevant operator to revoke the third-party session. The desk does not collect passwords, so the desk's password reset is not relevant. The relevant reset is for any other account that shares a password with the third-party surface.

The desk's editorial boundary on the login surface is the same as for any other editorial surface: the desk never publishes invented language, the desk never paraphrases a private leak, and the desk never endorses a third-party surface. The login page is no exception. The page documents the standard and asks the reader to verify the standard on any third-party surface that claims to be a headshot surface.

History

Why the desk chose editorial over platform from the start

The headshot desk was founded as an editorial newsroom, not as a platform. The founding team's first decision was the editorial boundary: the desk would publish reads, not predictions. The second decision was the verification standard: the desk would surface the canonical source, not paraphrase the canonical source. The third decision was the login posture: the desk would not maintain a user account, and the desk would not ask for a password.

The three decisions are interlinked. An editorial site that maintains a user account must reconcile the editorial boundary with the platform boundary. A platform site that maintains a wallet must reconcile the verification standard with the operator's regulatory obligations. The two reconciliations are not always compatible. The headshot desk chose the editorial path because the editorial path keeps the desk's role simple: the desk publishes reads, the reader reads the desk, the URL is the limit of the surface.

The decision has consequences. The desk cannot offer personal bookmarks. The desk cannot offer reading history. The desk cannot offer a notification feed tied to an account. The trade is acceptable to the desk because the alternative — building a platform surface — would compromise the editorial boundary. The desk would rather lose personalisation features than compromise the editorial standard.

The decision also has an upside. The desk's editorial surface is inspectable. The desk's standard is publishable. The desk's verification step is shareable. A reader can hold the desk to the standard by reading the standard, applying the standard to any third-party surface, and writing in via the contact page when the standard is crossed. The desk's role is to publish the standard; the reader's role is to apply the standard.