Page Transparency Protocol
- Page Transparency (PT) is a proactive web security protocol that logs login pages to verify legitimacy and prevent phishing attacks.
- It uses a cryptographic Signed Page Timestamp (SPT) and visual similarity matching via a Public Logging Service (PLS) to ensure integrity.
- The protocol shifts from reactive defenses to pre-render verification, demonstrating high precision in login-page detection and controlled performance overhead.
Page Transparency (PT) is a proposed web anti-phishing protocol for login pages. Inspired by Certificate Transparency, it requires login pages that capture users’ sensitive information to be publicly logged via a Public Logging Service (PLS) and made available to web clients for verification. The pages are verified to be logged using cryptographic proofs, and the PLS visually compares submitted pages with existing pages through a visual page-matching algorithm so that an attacker cannot register a deceptive look-alike page on the PLS and receive the cryptographic proof required for client verification (Varshney et al., 13 Jul 2025).
1. Conceptual basis and security objective
PT is designed for the specific case of credential-entry pages. The protocol targets the fact that phishing pages are often visually close to real login pages, newly created, and not yet present in a blacklist when first seen. In the PT model, legitimate login pages are logged in advance, browsers verify that a page has a valid proof of logging before rendering it, and a public log performs visual similarity checks so a phisher cannot simply register a deceptive clone and obtain a valid proof (Varshney et al., 13 Jul 2025).
The protocol is positioned against defenses that are reactive rather than proactive, dataset-dependent, or limited to browser add-ons, blacklists, heuristics, ML classifiers, or user training. PT is instead framed as a protocol-oriented prevention system. The paper explicitly characterizes the shift as moving from “detect the phishing page after the fact” to “only render pages that have been publicly logged and validated.” This makes PT a public-accountability mechanism for login pages rather than a standalone page classifier (Varshney et al., 13 Jul 2025).
2. System architecture and trust model
PT uses three principal entities: the Domain Owner Server (DS), the Public Logging Service (PLS), and the PT-enabled browser. It also introduces a custom HTTP header, the SPT-Header, which carries the proof used at rendering time.
| Component | Function |
|---|---|
| Domain Owner Server (DS) | Authenticates to the PLS, submits the login page, URL, and domain name, stores the returned SPT, and includes it in the SPT-Header |
| Public Logging Service (PLS) | Verifies ownership, checks visual similarity, logs accepted pages, generates the SPT, and publishes log metadata |
| PT-enabled Browser | Detects whether a page is a login page, verifies the SPT-Header, and triggers fallback visual verification if needed |
The system operates in two phases. The Page Logging Phase (PLP) covers page submission, ownership verification, visual comparison, and proof issuance. The Page Rendering Phase (PRP) covers browser-side login-page detection, proof verification, and the decision to render or block the page. The trust model is explicit: the PLS is the trust anchor, PLS public keys are publicly available, domain owners authenticate with certificates and signatures, and browsers use the published log metadata to validate received proofs (Varshney et al., 13 Jul 2025).
3. Logging and rendering workflow
During the Page Logging Phase, the domain owner authenticates itself to the PLS using its certificate and a signature made with its private key. The PLS extracts the public key and domain name from the certificate and verifies the signature; the PLS then sends back its own certificate and a signature, which the domain owner verifies. After mutual verification, the domain owner sends the login page HTML, the URL, and the domain name. The PLS checks whether the submitted page is visually similar to pages already logged for other domains. If it is not too similar, the PLS logs it and returns an SPT proof. The domain owner stores the SPT and includes it in future HTTP responses via the SPT-Header (Varshney et al., 13 Jul 2025).
During the Page Rendering Phase, the browser first determines whether the page is a login page. If it is not a login page, it renders normally. If it is a login page, the browser checks whether the response contains an SPT-Header. If no SPT-Header is present, the page is treated as suspicious and is not rendered. If the header is present, the browser verifies the SPT cryptographically. If verification succeeds, the page is rendered. If verification fails, the browser captures a screenshot, sends it and the URL to the PLS, and asks the PLS to visually verify it. The paper motivates this fallback by noting that legitimate pages can change slightly over time; visual re-validation is therefore intended to reduce false positives and service disruption (Varshney et al., 13 Jul 2025).
4. Cryptographic proof and visual matching
The proof mechanism is the Signed Page Timestamp (SPT). Its purpose is to show that a page has been logged in a PLS, that the page content and URL correspond to the logged version, and that the proof was issued by the PLS. The paper’s pseudocode computes hashed_url using SHA256_HASH(url), computes hashed_page using HASH_HTML_PAGE(page), DER-encodes the PLS public key, signs the structure {version, timestamp, hashed_url, hashed_page}, and returns a base64-encoded SPT header (Varshney et al., 13 Jul 2025).
The SPT header structure contains Version (1 byte), Timestamp (4 bytes), LogID (32 bytes), and a Signature over a struct including Version, Timestamp, URL Hash (64 bytes), and Textual Hash (64 bytes). The logID is derived from the SHA-256 hash of the DER-encoded public key of the PLS, and logs containing logIDs and public keys are publicly available so browsers can recover the appropriate public key for verification (Varshney et al., 13 Jul 2025).
The anti-evasion component is the visual similarity check. The PLS uses a Siamese Network Model (SNM) to transform page screenshots into embeddings and compares the submitted page embedding against embeddings of pages already logged. The training setup is described as a triplet network paradigm with an anchor legitimate login page, a corresponding phishing page as positive, and other pages as negatives. Operationally, if the difference between embeddings is below siameseThreshold, the pages are considered similar and one may be a phishing page of the other. During logging, visually similar submissions are rejected; during browser fallback, the same mechanism is used to decide whether a changed page is still legitimate for that domain (Varshney et al., 13 Jul 2025).
A separate browser-side classifier determines whether PT enforcement should apply. The paper defines loginThreshold as the value above which a page is considered a login page, set to 76, using a weighted scoring procedure over page features (Varshney et al., 13 Jul 2025).
5. Threat model and enforcement properties
The threat model includes several specific attacks. A cross-domain request attack attempts to log a page under a domain the attacker does not own; PT defends by requiring certificate exchange and challenge-response authentication. A header spoofing attack attempts to forge the SPT-Header; PT defends by requiring browser verification using the public key associated with the logID. A visual similarity evasion attack attempts to register subtle variants of a target login page; PT defends through the SNM-based similarity screening at the PLS (Varshney et al., 13 Jul 2025).
The model also considers SPT verification failure / denial of service, where legitimate page changes could prevent rendering; the fallback screenshot-based PLS validation is intended to preserve service continuity. A phishing page rendering bypass attempts to evade login-page detection; the browser therefore uses a weighted login-page detection algorithm based on keywords, inputs, submit buttons, and URL patterns. The paper also mentions DoS against the verification pipeline, for which redundancy, rate limiting, CAPTCHAs, and load balancing are discussed, and PLS compromise, which is acknowledged as a major limitation because the PLS is a trusted anchor (Varshney et al., 13 Jul 2025).
From this architecture, the paper claims authenticity of logged login pages, integrity of the proof, public verifiability of whether a page is logged, non-acceptance of look-alike phishing pages by the PLS, and browser-side enforcement of rendering only logged login pages. This suggests PT is intended as a pre-render verification layer rather than a purely post hoc detection mechanism (Varshney et al., 13 Jul 2025).
6. Evaluation, overhead, and deployment considerations
The evaluation covers login-page detection, visual similarity performance, runtime overhead, and a prototype deployment. For login-page detection, the paper reports testing on 103 webpages with TP = 67, TN = 34, FP = 2, FN = 0, Precision = 0.971, and Accuracy = 0.981. For the Siamese model, the dataset includes 115 legitimate images, 2325 phishing images, and 50 unseen legitimate pages; on 697 phishing test images, the results are 609 true positives, 88 false negatives, 50 true negatives, Precision = 1, Recall = 0.873, and F1 = 0.932 (Varshney et al., 13 Jul 2025).
The reported average latencies are approximately 0.014 s for the Login Page Detection Algorithm, 0.016 s for the Header Verification Algorithm, and 0.11 s for SNM processing. The paper reports about 9% overhead when signature verification succeeds and about 43% overhead when verification fails and screenshot/SNM processing is triggered; one section of the conclusion also mentions a worst-case increase of 793%. Communication overhead is reported as 112.61% data increase when SPT is verified successfully and 381.2% data increase when the SPT is unverified and SNM processing is needed (Varshney et al., 13 Jul 2025).
For scalability, the paper states a space complexity of
where is the number of stored embeddings, is the number of query images, and is the embedding dimensionality. The reported timings are about 18.64 s for 1,000 images and about 233.36 s for 10,000 images. The prototype was implemented not in a commercial browser core but as a Chrome extension named AntiPhish using Manifest v3, with Flask servers, Python, and Selenium/WebDriver for screenshots (Varshney et al., 13 Jul 2025).
The practical limitations are also explicit. Overhead is nontrivial, the image-similarity subsystem requires improvement, the PLS is a critical dependency, privacy concerns arise because browser verification may contact the PLS, and mobile and desktop login pages may require separate models in future work. Within those constraints, PT is presented as a certificate-transparency-inspired, logging-based, browser-enforced protocol for zero-day phishing defense focused on login pages (Varshney et al., 13 Jul 2025).