{"id":"de4cbab3-44ad-4139-8f05-e02e346eb3fc","arxiv_id":"2507.09564","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"A proposed login-page transparency log with visual similarity gating is undermined by the paper's own recall of 87.3%, which contradicts the claim that attackers cannot register look-alike pages.","lead":"This paper proposes a protocol that logs all login pages in a public server and requires browsers to verify a signed timestamp before rendering them, aiming to stop zero-day phishing. Its own experiments, however, show that 88 of 697 phishing pages evade the visual similarity check, so an attacker can still obtain proof for many look-alike pages.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The impossibility claim fails under a first-logger-wins race: Section 3.1 only compares a submitted page against previously logged pages, so an attacker who logs a look-alike before the legitimate owner receives a valid SPT, and the legitimate page is then refused.","rationale":"The reader's REJECT verdict is well-supported, and the first-logger-wins race is the most load-bearing concern because it contradicts the central impossibility claim under the protocol's own assumptions. Unlike the Siamese network's 0.873 recall, which weakens the guarantee probabilistically, the ordering race breaks the guarantee unconditionally—even with a perfect visual similarity model, a page that is the first of its visual class in the log cannot be rejected. The Algorithm 1/Algorithm 3 hash mismatch is a serious cryptographic bug, but it is a coding error that could potentially be corrected without changing the architecture; the first-logger-wins issue is a structural flaw requiring a new mechanism (e.g., pre-registration of legitimate domains, domain-priority rules, or a trusted bootstrap step) that the paper does not provide. The proposed concrete test directly exercises the PLS decision logic and would settle whether the race is real. Therefore the recommendation is unchanged: REJECT.","tokens_in":23462,"tokens_out":3709,"duration_ms":44938,"concrete_test":"Implement a minimal integration test of the Page Logging Phase in Section 3.1: (1) submit a login page for attacker-domain 'evil.example' that is visually identical to a target 'bank.example' login page not yet present in the PLS; (2) verify whether 'evil.example' receives a valid SPT because the similarity check finds no previously logged match; (3) then submit the genuine 'bank.example' page and observe whether it is rejected as visually similar to the attacker's logged page. If both steps succeed, the first-logger-wins race is confirmed and the protocol requires an explicit priority or bootstrap mechanism for legitimate domains.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that an attacker cannot register a deceptive look-alike page on the PLS and receive the cryptographic proof required for client verification. This rests on Section 3.1: the PLS checks the submitted page for visual similarity only against embeddings of previously registered login pages of other domains. There is no bootstrap step or temporal ordering that guarantees the legitimate domain has logged its page before an attacker submits a look-alike. An attacker who registers first—cloning a not-yet-logged login page of a target brand, hosting it on an attacker-owned domain, and passing the certificate-based domain-ownership check—will find no similar page in the log, so the PLS will issue a valid SPT. Worse, when the legitimate owner later submits its genuine login page, that page will be flagged as visually similar to the attacker's already-logged page and refused, locking out the legitimate domain. The threat model (Table 3) addresses cross-domain request attacks and visual similarity evasion but never analyzes this ordering race. This is a logical flaw independent of Siamese network accuracy: even a perfect visual similarity model cannot reject the first page of a given visual class if no prior page exists for comparison. Thus the abstract's 'impossible' claim is false as written, and the protocol's core guarantee is unsupported.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Page Transparency (PT), a certificate-transparency-inspired protocol for phishing prevention. Domain owners register login pages with a Public Log Server (PLS), which issues a Signed Page Timestamp (SPT) after checking the page's visual similarity against previously logged pages using a Siamese network. Clients are expected to refuse login pages that lack a valid SPT or fail a secondary visual check. The paper describes the protocol, a threat model, a prototype browser extension, and experiments on login-page detection (precision 0.971) and Siamese-network similarity detection (recall 0.873). The central claim, stated in the abstract and Section 3, is that it becomes impossible for an attacker to register a deceptive look-alike page on the PLS and receive the cryptographic proof required for client verification.","tokens_in":23647,"tokens_out":4673,"duration_ms":50647,"significance":"The idea of extending Certificate Transparency to login pages is conceptually interesting, and the paper contributes a new dataset of 91 brands' login pages and a working prototype browser extension. However, the central security claim is unsupported. The protocol's own evaluation admits 88 false negatives in the similarity check, and more fundamentally the PLS only compares a submitted page against pages that were logged earlier, so an attacker who logs a look-alike page before the legitimate owner can obtain a valid SPT. The SPT generation and verification algorithms are inconsistent as written. The thresholds used in the evaluation are fitted on the same data used to report performance, so the reported numbers cannot be taken as predictive of real-world security. If the protocol worked, it would be a meaningful step toward proactive phishing defense, but the version presented here does not establish that guarantee.","major_comments":[{"comment":"The PLS compares a submitted page's embedding only against embeddings of previously registered login pages. There is no bootstrap step or temporal ordering that guarantees the legitimate domain has logged its page before an attacker submits a look-alike. An attacker who registers first—hosting a clone on an attacker-owned domain and passing certificate-based domain ownership—will find no similar page in the log and will receive a valid SPT; the legitimate owner's later submission may then be rejected as visually similar to the attacker's already-logged page. This first-logger-wins race contradicts the abstract's claim that it is 'impossible' for an attacker to register a deceptive look-alike page and obtain a valid proof, and it is a logical flaw independent of the Siamese network's accuracy.","section":"Section 3.1 (Page Logging Phase)"},{"comment":"The siameseThreshold is described only as an 'experimented threshold' and its numeric value is never reported, but it is central to the PLS decision to accept or reject a page. More seriously, the threshold appears to be selected using the same 697 phishing images and 50 legitimate images on which recall (0.873) and precision (1.0) are reported. Similarly, in Section 6.1, the login keyword weights and the loginThreshold are tuned on the same 103 or 105 websites used to report precision of 0.971. This circular evaluation overstates the models' performance and provides no evidence for the security claim that look-alike pages will be rejected by the PLS.","section":"Section 6.2 and Table 2"},{"comment":"Algorithm 1 signs struct_data_to_sign (version, timestamp, hashed_url, hashed_page) directly with the PLS private key. Algorithm 3, however, packs the same fields, computes SHA256_hash(packed_data), and verifies the signature against that hash. As written, an SPT produced by Algorithm 1 would not verify under Algorithm 3, because the signature is over the struct rather than over the SHA-256 hash of the packed data. This is a protocol-level inconsistency that breaks the core client-side verification flow.","section":"Section 3.1.3, Algorithms 1 and 3"},{"comment":"The threat model states that the SNM 'can correctly detect a smart variation of the page by an attacker and deny it for logging over PLS.' Yet Section 6.2 reports 88 false negatives out of 697 phishing test images (recall 0.873). These false negatives mean that a substantial fraction of look-alike pages would not be flagged as similar to already-logged pages and would therefore be eligible to receive a valid SPT. The paper provides no analysis of how this false-negative rate affects the impossibility claim and does not bound the probability that a phishing page obtains a valid proof. The threat model as stated is contradicted by the paper's own experimental results.","section":"Table 3 (Visual Similarity Evasion) and Section 6.2"},{"comment":"The threat model lists 'PLS Compromise' as 'NA' with no mitigation, while Section 7 acknowledges that 'any compromise of PLS will affect the trust of the complete system.' Since the PLS is the trust anchor that signs SPTs, a compromised PLS can issue valid SPTs for arbitrary phishing pages, and clients would accept them. The paper offers no mechanism—such as append-only logs, multiple independent PLSs, or a monitor akin to Certificate Transparency—to detect or recover from a malicious or compromised PLS. This is a central gap in the threat model for a protocol whose entire security rests on the PLS.","section":"Table 3 (PLS Compromise) and Section 7"}],"minor_comments":[{"comment":"The title-page footnotes contain unrelated text about polaritons on a cuprous oxide slab and polystyrene micro-spheres, which appears to be leftover template content and should be removed.","section":"Title page footnotes"},{"comment":"Figure 1 contains garbled text and appears to duplicate Figure 2; the body text refers to the 'attack lifecycle' but never references Figure 1 explicitly.","section":"Figure 1"},{"comment":"The value of loginThreshold is inconsistent: Table 2 says it is set to 76, while the text says 'we have kept the threshold at 75' and Algorithm 2 does not specify a numeric value.","section":"Section 3.2 and Table 2"},{"comment":"The siameseThreshold value is never reported, despite being load-bearing for the PLS decision; the paper should state the value and how it was chosen.","section":"Section 6.2"},{"comment":"References 'Azeez et al., 2021a' and 'Azeez et al., 2021b' are identical; the duplicate should be merged or removed.","section":"References"},{"comment":"The abstract states that 'all implementations occur on the client side,' but the protocol requires a PLS, domain-owner cooperation, and a browser extension; this wording is misleading.","section":"Abstract and Section 4"}],"recommendation":"reject","confidential_remarks":"The manuscript is not ready for publication. The central impossibility claim is contradicted by the authors' own experimental results (recall 0.873) and by the inherent first-logger-wins race in the protocol. The inconsistency between SPT generation and verification algorithms is a further blocker. The paper has numerous presentation artifacts suggesting an incomplete draft. I recommend rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know this paper is a mixed bag. The idea—CT-style transparency for login pages, where a public log server issues a signed page timestamp only after checking the page's visual similarity against previously logged pages—is genuinely new and worth thinking about. The authors built a working Chrome extension, measured latency and bandwidth overhead, and they are candid that this is a prototype. That part deserves credit.\n\nThe problems are in the security claim, not the prototype. The abstract says it is \"impossible for an attacker to register a deceptive look-alike page.\" That is false on two independent grounds. First, the PLS only compares a submitted page against pages already in the log (Section 3.1). There is no bootstrap step guaranteeing the legitimate domain registered first. An attacker who clones a not-yet-logged login page and passes the certificate-based ownership check receives a valid SPT, and the genuine page is then flagged as similar and refused. The threat model (Table 3) never analyzes this ordering race, and it is independent of ML accuracy. Second, even ignoring the race, their own Siamese network has recall 0.873 on 697 phishing test images—88 false negatives would get SPTs. So \"impossible\" is contradicted by the paper's own numbers.\n\nThere is also a concrete crypto inconsistency. Algorithm 1 signs a struct containing version, timestamp, and hashes; Algorithm 3 verifies against SHA256 of a packed version of those fields. Under standard signature API semantics, the verifier will not accept a signature produced by the generator as written. This may be fixable, but as written the protocol does not work.\n\nThe evaluation is weak in familiar ways: the dataset is tiny and not released, pages were manually cleaned after collection, and both the login threshold and the siamese threshold were fitted on the same data used to report performance. The siamese threshold is never even given a value in the paper. These numbers are suggestive, not evidence of a deployed guarantee.\n\nOne more minor thing: the title block contains a leftover footnote about polariton formation, clearly a template artifact. It does not affect the science, but it says the manuscript was not carefully cleaned.\n\nBottom line: the idea is worth a reading group and a citation as prior work. The current paper should not be accepted in this form. A serious editor should send it to reviewers—there is enough new thought here that a desk reject would be wrong—but a referee should come back with major revision or reject, and the authors need to fix the race, the crypto inconsistency, and reframe the claim from \"impossible\" to \"reduces the window.\"","headline":"Genuinely new CT-style transparency idea for login pages, but the 'impossible' claim fails on the first-logger-wins race and the model's own false negatives.","tokens_in":24279,"tokens_out":4431,"would_cite":false,"duration_ms":44394,"reading_group":"yes","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A public log of login pages, guarded by visual similarity checks, could make look-alike phishing impossible to register.","keywords":["phishing prevention","login page transparency","signed page timestamp","public log server","visual similarity detection","Siamese network","zero-day phishing","certificate transparency"],"falsifier":"Run the paper's adversarial generation scheme, which builds a generic login template with a target brand's logo and primary color placed in nine screen positions plus old-logo swaps, through the actual PLS registration pipeline and count how many of the resulting look-alikes receive SPTs; the reported recall of 0.873 predicts roughly one in eight will be logged, directly contradicting the claim that it is impossible for an attacker to register a deceptive look-alike page.","tokens_in":23161,"feed_emoji":"🛡️","tokens_out":5817,"duration_ms":58785,"temperature":0.7,"pith_summary":"This paper proposes a protocol-level defense against zero-day phishing: every login page must be publicly logged and issued a signed timestamp before any browser will render it. The public log server rejects any new page that visually resembles an already-logged page from a different domain, which the authors argue makes it impossible for an attacker to obtain a valid signed timestamp for a look-alike page. If the scheme works, look-alike phishing stops being a detection arms race and becomes an administrative failure, because the attacker cannot get the credential every browser demands. The protocol runs client-side through a new HTTP header, avoiding platform-specific changes or third-party extensions. The paper backs the claim with a prototype browser extension, a Siamese-network visual similarity model, and a new dataset of credential-requiring pages.","feed_headline":"Login-page transparency aims to make look-alike phishing impossible","feed_subtitle":"A certificate-transparency-style public log would block spoofed login pages before the first victim.","key_machinery":"The load-bearing mechanism is the Page Logging Phase combined with the Signed Page Timestamp (SPT). The PLS checks each submitted page against stored embeddings of already-logged pages using a triplet-trained Siamese Network Model (SNM); only visually distinct pages are logged and issued an SPT, an HTTP header carrying version, timestamp, log ID, and a PLS signature over the URL hash and page-content hash. The browser's rendering phase first detects whether a page is a login page using weighted keyword and input-field scoring, then requires the SPT, and on any verification failure falls back to sending the page screenshot to the PLS for an on-the-fly visual comparison. The SNM is what carries the impossibility claim, because it is the only component that recognizes a page as an impersonation at registration time.","core_discovery":"The central claim is that a public, append-only log of login pages, analogous to certificate transparency for certificates, can make visual look-alike phishing impossible. On a page-logging request, the public log server (PLS) verifies domain ownership, computes an embedding of the submitted page with a Siamese network, and refuses to log any page whose embedding is close to a page from a different domain. Only logged pages receive a Signed Page Timestamp (SPT), and the browser renders a login page only when that SPT verifies. Because the attacker cannot register the look-alike page without triggering the similarity check, and because a page without a valid SPT is not rendered, the paper concludes that cloned login pages can be stopped at the first attempt, even for never-before-seen phishing pages.","pith_inferences":["Editorial inference: the protocol inherits certificate transparency's first-logger-wins weakness; the paper never analyzes what happens if an attacker registers a look-alike page before the legitimate owner logs its page, in which case the legitimate page becomes the 'look-alike' and can be refused logging.","Editorial inference: at the reported recall of 0.873, roughly 88 of the 697 phishing test images would still pass the similarity check and obtain SPTs, so the impossibility claim holds only if the model never misses a look-alike in deployment, which the paper's own results contradict.","Editorial inference: the PLS becomes a centralized privacy and availability chokepoint; the paper itself notes that IP addresses seen in verification requests could reveal short-term browsing patterns, and a compromised PLS would undermine trust in the entire system.","Editorial inference: adoption faces a chicken-and-egg problem, because browsers only gain protection after enough sites register their login pages, and sites only benefit after browsers enforce SPTs; a transitional period where phishers log first and lock out legitimate owners appears likely."],"forward_implications":["If the protocol is correct, every credential-collecting page must carry a valid SPT, so a phishing page that slips through the visual check would still be blocked because it lacks verifiable proof of logging.","The fallback screenshot check turns SPT failures into a second line of defense, so small legitimate changes to a login page do not become a denial of service.","The defense is entirely client-side: a browser that enforces SPTs protects users without server cooperation, blacklist updates, or user training.","Zero-day look-alikes are addressed at registration time, before the first victim arrives, because the PLS refuses to log pages that resemble an existing domain's login page.","Measured overhead is modest in the common case: about 9% extra load time when the SPT verifies, 43% when the Siamese model must process a screenshot, and 381% more data transferred in the worst case."],"supporting_citations":[{"why":"Supplies the certificate-transparency public-log architecture that the paper adapts to login pages, including the idea of a public, verifiable log.","marker":"Laurie (2014)"},{"why":"Supplies the visual similarity method: triplet-network training on legitimate and phishing screenshots and the embedding-distance threshold used by the Siamese model.","marker":"Abdelnabi et al. (2020)"},{"why":"Establishes the phishing landscape the protocol targets and frames anti-phishing as a problem needing a comprehensive, protocol-level solution.","marker":"Varshney et al. (2024)"},{"why":"Provides the prior TLS-certificate-footprint detection approach that the paper positions against, motivating the need for login-page transparency.","marker":"Sakurai et al. (2020)"},{"why":"Inspires the weighted login-page detection algorithm (keywords, URL terms, submit button, input tags) that browsers use to decide whether to require an SPT.","marker":"Corp (2024)"}],"fun_headline_variants":["Public login page log blocks zero-day phishing","Login transparency makes look-alike phishing impossible","Anti-phishing protocol: public login log plus visual check","Zero-day phishing thwarted by login page transparency"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire impossibility claim rests on the visual-similarity model never missing a look-alike page, but the paper's own results report 88 false negatives out of 697 phishing test images: pages that slip through can still be logged and receive valid SPTs.","fun_headline_variants_meta":{"raw":{"variants":["Public login page log blocks zero-day phishing","Login transparency makes look-alike phishing impossible","Anti-phishing protocol: public login log plus visual check","Zero-day phishing thwarted by login page transparency"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000325,"raw_usage":{"total_tokens":1821,"prompt_tokens":945,"completion_tokens":876,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":561,"completion_tokens_details":{"reasoning_tokens":817}},"tokens_in":561,"tokens_out":876,"duration_ms":9452,"temperature":1.0,"reasoning_tokens":817,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:52:48.346122+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's adversarial generation scheme, which builds a generic login template with a target brand's logo and primary color placed in nine screen positions plus old-logo swaps, through the actual PLS registration pipeline and count how many of the resulting look-alikes receive SPTs; the reported recall of 0.873 predicts roughly one in eight will be logged, directly contradicting the claim that it is impossible for an attacker to register a deceptive look-alike page.","supporting_citations":[{"cited_title":", year 2014","cited_arxiv_id":null,"evidence_quote":"Supplies the certificate-transparency public-log architecture that the paper adapts to login pages, including the idea of a public, verifiable log."},{"cited_title":", author Krombholz, K","cited_arxiv_id":null,"evidence_quote":"Supplies the visual similarity method: triplet-network training on legitimate and phishing screenshots and the embedding-distance threshold used by the Siamese model."},{"cited_title":", author Kumawat, R","cited_arxiv_id":null,"evidence_quote":"Establishes the phishing landscape the protocol targets and frames anti-phishing as a problem needing a comprehensive, protocol-level solution."},{"cited_title":", author Watanabe, T","cited_arxiv_id":null,"evidence_quote":"Provides the prior TLS-certificate-footprint detection approach that the paper positions against, motivating the need for login-page transparency."},{"cited_title":", year 2024","cited_arxiv_id":null,"evidence_quote":"Inspires the weighted login-page detection algorithm (keywords, URL terms, submit button, input tags) that browsers use to decide whether to require an SPT."}],"review_version":1}