{"id":"ff7bc8cc-310f-487b-8e3c-fa6dfef697a1","arxiv_id":"2607.06134","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":0,"one_line_summary":"Packet-capture analysis reveals that DNS resolution completes after Google Safe Browsing query closures in ~79% of measured cases, with median delays of 67-79 ms and maxima exceeding 2.4 seconds.","lead":"This paper measures a timing gap between Google Safe Browsing (GSB) connection closures and final DNS resolution events during browser navigation, finding DNS often lags behind GSB closure by tens to thousands of milliseconds. A smart generalist might read it to understand a potential security weakness in how browsers coordinate safety checks with network resolution.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"The measured GSB connection close and DNS response events may not belong to the same causal navigation chain, making the timing gap a comparison of unrelated asynchronous events rather than a security-relevant window.","rationale":"The reader's verdict of CONDITIONAL with MODERATE confidence is appropriate. My concern is complementary to the reader's: the reader identified that FIN/RST may not track the actual safety decision, while I identify that the two events being compared may not even belong to the same causal chain. Both concerns point in the same direction — the measured gap may not correspond to a real security-relevant window — and both are consistent with the reader's assessment that the work is preliminary and appropriately cautious for a poster. The paper explicitly states 'We do not claim a complete browser bypass' and frames results as a 'foundation for further research,' which is honest. The verdict should remain CONDITIONAL: the empirical observation is interesting but the security relevance is unvalidated, and the causal linkage between measured events is the most important thing to verify before elevating the claims. No change to the verdict is needed; the concern reinforces the existing conditions.","tokens_in":5040,"tokens_out":2649,"duration_ms":170627,"concrete_test":"Use Chrome's chrome://net-export (or net-internals) to capture the browser's internal event timeline for a single domain navigation, then cross-reference with the packet capture. Specifically, identify: (1) the timestamp when Chrome records its GSB safety decision for the target URL, (2) the timestamp when Chrome receives the DNS response it actually uses to open the TLS connection to the target, and (3) whether these correspond to the same FIN/RST and DNS packets selected by the paper's extraction logic. If the net-export trace shows the browser consuming a DNS response that arrived before the GSB connection (while the packet-capture methodology selected a later, unrelated DNS refresh), the measured positive gaps are artifacts of event misattribution.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper computes Δ_time = T_resolution − T_query_close, where T_query_close is the FIN/RST of a GSB-related TLS stream (identified via SNI) and T_resolution is the final DNS A/AAAA response. For this gap to be security-relevant, both events must be part of the same navigation decision: the GSB check must be the one the browser used to decide whether to proceed to the target domain, and the DNS response must be the one the browser actually used to establish the connection. The paper does not establish this causal linkage.\n\nThis matters because Chrome performs GSB database updates in the background (not necessarily tied to a specific navigation) and performs speculative DNS prefetching that may not be the resolution actually used for the connection. The 79% positive-gap rate is itself suspicious: DNS resolution is a prerequisite for establishing the TLS connection to the target domain, so one would expect DNS to typically complete *before* GSB-related traffic for that same navigation. The high frequency of DNS-lagging-behind-GSB suggests the captured DNS responses may be secondary events (cache refreshes, prefetch completions, CNAME chain continuations) rather than the resolution the browser actually consumed, or that the GSB connection being measured is a background update unrelated to the specific navigation.\n\nThe reader's concern about FIN/RST as a proxy for the safety decision is valid but secondary: even if FIN/RST perfectly tracked the GSB decision point, the gap would be meaningless if the two events are not causally linked to the same navigation. The paper's Section 3.1 describes extraction but does not verify that the GSB stream and DNS response being paired correspond to the same URL navigation or the same browser decision.","agreement_with_reader":"partial"},"referee_report":{"model":"glm-5.2","summary":"This poster paper characterizes the timing gap between Google Safe Browsing (GSB)-related connection close events and final DNS resolution events during browser navigation. The authors define a metric Δ_time = T_resolution − T_query_close, where T_query_close is the TCP FIN/RST of a GSB-related TLS stream (identified via SNI) and T_resolution is the final DNS A/AAAA response. Using packet-capture on a single macOS workstation running Chrome Stable, the authors measure this gap across 100 general-domain and 103 CNAME-domain websites from the Tranco list. They report positive timing gaps (DNS lagging behind GSB closure) in approximately 78–80% of samples, with median delays of 67–79 ms and maxima exceeding 2,400 ms. The paper frames these gaps as a potential security-relevant precondition under DNS-manipulation threat models, while explicitly disclaiming a complete browser bypass.","tokens_in":5222,"tokens_out":1208,"duration_ms":176750,"significance":"The paper identifies a measurable and previously undercharacterized timing phenomenon at the packet level between GSB-related traffic and DNS resolution. The metric is parameter-free and directly computed from observed timestamps, which is a strength. The datasets are clearly described, and the results are reproducible in principle given the methodology. The security framing is appropriately cautious—the authors do not overclaim a bypass. However, the significance is substantially limited by the causal linkage problem (see major comments) and the single-machine, single-browser measurement design, which constrains generalizability.","major_comments":[{"comment":"§3.1, Eq. (1): The central claim—that the measured Δ_time represents a security-relevant timing window—depends on both T_query_close and T_resolution belonging to the same causal navigation chain. The paper does not establish that the GSB-related TLS connection (identified via SNI) corresponds to the specific safety check the browser used for the target navigation, nor that the DNS response captured is the one the browser actually consumed for the connection. Chrome performs background GSB database updates and speculative DNS prefetching that may be unrelated to the navigation being measured. Without correlating these events to a single navigation (e.g., via browser-internal timing APIs or per-navigation request IDs), the measured gap may compare unrelated asynchronous events. This is load-bearing for the security claim in §6.","section":null},{"comment":"§3.1: The use of TCP FIN/RST as a proxy for GSB check completion is not validated. The paper states T_query_close is 'the timestamp of the associated TCP FIN or RST packet,' but transport-layer connection teardown does not necessarily correspond to the browser's safety decision point. The browser may complete its GSB evaluation before or after the connection closes, and the GSB check may be satisfied from a local cache without a server round-trip at all. If FIN/RST timing does not track the actual safety decision, the measured gap is an artifact of connection teardown semantics. The paper should either validate this proxy or substantially soften the security framing.","section":null},{"comment":"§5.2, Table 2: The 79% positive-gap rate is itself surprising. DNS resolution is a prerequisite for establishing the TLS connection to the target domain, so one would expect DNS to typically complete before GSB-related traffic for the same navigation. The high frequency of DNS-lagging-behind-GSB suggests the captured DNS responses may be secondary events (cache refreshes, prefetch completions, CNAME chain continuations) rather than the resolution the browser actually used. The paper should address this apparent counterintuitiveness directly, as it bears on whether the measured gaps are security-relevant or artifacts of background activity.","section":null}],"minor_comments":[{"comment":"§4: The measurement is conducted on a single macOS workstation with Chrome Stable. While the authors acknowledge this limitation in §7 (Future Work), the generalizability concern should be discussed more prominently in the results section, as all quantitative claims derive from this single configuration.","section":null},{"comment":"Table 1: The absolute timestamps (e.g., 1.426 s, 6.847 s) appear to be relative to capture start, but this is not stated. A brief note on the reference point for these timestamps would improve clarity.","section":null},{"comment":"§3.2: The CNAME-domain selection criteria are described as 'the highest-ranked entries that explicitly require CNAME resolution.' It would help to specify how CNAME requirement was determined (e.g., manual inspection, automated DNS query).","section":null},{"comment":"§5.1: The text states 'positive timing gaps appear in approximately 78%–80% of measured samples, with median delays around 70 ms,' but Table 2 reports medians of 79.40 ms and 67.88 ms. Rounding to 'around 70 ms' is acceptable for the abstract but slightly imprecise for the results section.","section":null},{"comment":"§2.2: The threat model mentions 'cache poisoning, resolver manipulation, or an on-path position' but does not discuss whether the browser's DNS cache or OS-level resolver cache (which were cleared before each navigation per §4) would still be warm during the measurement, potentially affecting the gap. This interaction should be clarified.","section":null}],"recommendation":"major_revision","confidential_remarks":"The stress-test concern about causal linkage between GSB connection close and DNS resolution events is the most serious issue and is well-founded. The paper is a poster submission, which typically allows for more preliminary results, but the security framing in §6 is difficult to evaluate without at least some validation that the two measured events are part of the same navigation chain. If the authors can demonstrate this linkage (even for a subset of measurements) or substantially reframe the contribution as a purely observational timing characterization without the security precondition claim, the paper could be acceptable for a poster venue. The single-machine design is a secondary concern that is more easily addressed by framing."},"author_rebuttal":{"model":"glm-5.2","summary":"We thank the referee for a careful and substantive review. The three major comments all identify the same underlying concern from different angles: without establishing that the GSB-related connection close and the DNS response belong to the same causal navigation chain, the measured Δ_time may compare unrelated asynchronous events, undermining the security framing. We agree this is the central limitation of the current manuscript and will revise accordingly.","responses":[{"response":"The referee is correct that the current manuscript does not establish causal linkage between the GSB-related connection and the DNS response for a single navigation. This is a genuine limitation of our packet-capture-only methodology. SNI-based identification of GSB traffic cannot distinguish a navigation-triggered safety check from background database updates, and the captured DNS response may be a prefetch or cache-refresh event rather than the resolution the browser consumed for the target connection. We will address this in two ways. First, we will add an explicit limitations subsection acknowledging that without browser-internal correlation (e.g., Chrome's net-internals tracing or the Performance Timeline API), we cannot confirm that the two timestamps belong to the same navigation chain. Second, we will conduct a supplementary measurement using Chrome's --log-net-log flag to emit per-request timing metadata, allowing us to correlate the GSB-related request and the DNS resolution to a specific navigation ID. If this correlation confirms that the gap persists for same-navigation events, the security framing is strengthened; if it does not, we will report that finding honestly and substantially soften the security claims in §6. In either case, the revised manuscript will not present Δ_time as a security-relevant window without this validation.","revision_made":"yes","referee_comment":"§3.1, Eq. (1): The central claim—that the measured Δ_time represents a security-relevant timing window—depends on both T_query_close and T_resolution belonging to the same causal navigation chain. The paper does not establish that the GSB-related TLS connection (identified via SNI) corresponds to the specific safety check the browser used for the target navigation, nor that the DNS response captured is the one the browser actually consumed for the connection. Chrome performs background GSB database updates and speculative DNS prefetching that may be unrelated to the navigation being measured. Without correlating these events to a single navigation (e.g., via browser-internal timing APIs or per-navigation request IDs), the measured gap may compare unrelated asynchronous events. This is load-bearing for the security claim in §6."},{"response":"We agree that FIN/RST timing is an imperfect proxy for the browser's safety decision point. The GSB check may be satisfied from the local hash-prefix database without any server round-trip, in which case there would be no GSB-related TLS connection to observe at all — meaning our metric only applies to the subset of navigations where a prefix match triggers a server query. Even in that subset, the browser may reach its safety decision before the connection closes (e.g., after receiving the response body but before FIN), or the connection may be kept alive for reuse rather than closed promptly. We will revise the manuscript to: (1) explicitly state that T_query_close measures connection teardown, not the safety decision itself, and that the relationship between the two is not established; (2) note that the metric is conditional on a server-side GSB query occurring, which is itself a subset of all navigations; and (3) soften the language in §6 from 'a Safe Browsing-related decision may complete before DNS resolution' to 'the GSB-related connection closes before the observed DNS response arrives,' which is what the data actually shows. We will also explore whether Chrome's net-log can provide a more direct timestamp for the safety decision, though we note that the browser's internal GSB decision timing may not be directly exposed even in detailed logs.","revision_made":"yes","referee_comment":"§3.1: The use of TCP FIN/RST as a proxy for GSB check completion is not validated. The paper states T_query_close is 'the timestamp of the associated TCP FIN or RST packet,' but transport-layer connection teardown does not necessarily correspond to the browser's safety decision point. The browser may complete its GSB evaluation before or after the connection closes, and the GSB check may be satisfied from a local cache without a server round-trip at all. If FIN/RST timing does not track the actual safety decision, the measured gap is an artifact of connection teardown semantics. The paper should either validate this proxy or substantially soften the security framing."},{"response":"This is the most challenging comment, and we acknowledge it raises a serious concern about the validity of our measurement. The referee's observation is correct: if the captured DNS response were the one the browser consumed to establish the target TLS connection, it should appear before the connection close, not after, in the majority of cases. The fact that 79% of measurements show DNS lagging behind GSB closure is indeed consistent with the hypothesis that the captured DNS responses are secondary events — cache refreshes, speculative prefetch completions, or later stages of CNAME chain resolution — rather than the resolution that enabled the navigation. We cannot rule this out with the current methodology. We will address this directly in the revised manuscript by: (1) adding a dedicated discussion of this counterintuitive result and its implications; (2) acknowledging that the high positive-gap rate may be an artifact of capturing background DNS activity rather than navigation-critical resolution; and (3) reporting the results of the net-log correlation experiment described in our response to the first major comment, which will allow us to determine whether the DNS response that the browser actually consumed for the target connection also exhibits a positive gap. If the correlated measurements show a substantially lower positive-gap rate, this would confirm that the current 79% figure is inflated by background activity, and we will report this transparently. We will not maintain the current security framing if the correlation experiment does not support it.","revision_made":"yes","referee_comment":"§5.2, Table 2: The 79% positive-gap rate is itself surprising. DNS resolution is a prerequisite for establishing the TLS connection to the target domain, so one would expect DNS to typically complete before GSB-related traffic for the same navigation. The high frequency of DNS-lagging-behind-GSB suggests the captured DNS responses may be secondary events (cache refreshes, prefetch completions, CNAME chain continuations) rather than the resolution the browser actually used. The paper should address this apparent counterintuitiveness directly, as it bears on whether the measured gaps are security-relevant or artifacts of background activity."}],"tokens_in":4756,"tokens_out":2085,"duration_ms":144075,"standing_objections":[]},"desk_editor":{"model":"glm-5.2","letter":"Bottom line: this poster reports a packet-level timing measurement between Google Safe Browsing connection closures and DNS resolution that nobody has published before, but the central measurement may be comparing two events that aren't causally linked to the same browser decision. The gap is real as an observation; its security relevance is unestablished.","headline":"Poster measures a GSB-DNS timing gap, but the two events being compared may not be causally linked to the same navigation.","tokens_in":6019,"tokens_out":130,"would_cite":false,"duration_ms":118203,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"DNS lags behind Safe Browsing checks 79% of the time","keywords":[],"falsifier":"If browser instrumentation showing the actual internal timestamp of the GSB safety decision were compared against the FIN/RST timestamp and the two diverged systematically, the measured timing gap would be an artifact of connection lifecycle semantics rather than a security-relevant window.","tokens_in":5129,"feed_emoji":"⏱️","tokens_out":1047,"duration_ms":150532,"temperature":0.7,"pith_summary":"The paper measures a timing gap between Google Safe Browsing (GSB) connection closures and final DNS resolution responses during browser navigation. Using packet captures in Chrome across 203 domains, the authors find that in roughly 79% of cases the DNS response arrives after the GSB-related connection has closed, with median delays of 67-79 ms and maxima exceeding 2.4 seconds. The central object is the timing gap metric, defined as the difference between the transport-layer closure timestamp of the GSB-related TLS stream and the arrival timestamp of the final DNS A/AAAA record. The authors argue this gap creates a security-relevant precondition: if an adversary can manipulate DNS resolution (via cache poisoning, resolver manipulation, or on-path position), the browser may reach a safety decision before the final network endpoint is fully established, potentially creating a mismatch between the domain that was checked and the endpoint that is ultimately contacted. The paper does not claim a complete browser bypass but identifies the timing precondition as a foundation for further end-to-end attack validation.","feed_headline":"Safe Browsing checks finish before DNS resolves 79% of the time","feed_subtitle":"Packet captures reveal a recurring timing gap that could let DNS manipulators change the endpoint after the browser's safety check is done.","key_machinery":"The timing gap metric is defined as the difference between the timestamp of the TCP FIN or RST packet closing the GSB-related TLS connection (identified via SNI) and the timestamp of the final DNS A/AAAA response packet. For CNAME chains, the final record in the resolution sequence is used. The measurement pipeline clears DNS cache and browser state before each navigation, launches Chrome to navigate to a target domain, captures traffic with Tshark, and post-processes the trace to extract both timestamps.","core_discovery":"The paper's central empirical finding is that a positive timing gap between GSB-related query close events and final DNS resolution is not an anomaly but a recurring feature of standard browsing, appearing in approximately 78-80% of measured navigations across both general and CNAME-domain datasets. The gap exhibits a long-tail distribution: most instances are under 100 ms, but outliers exceed two seconds. This means there is a measurable, frequently occurring window in which the browser's safety-check infrastructure has concluded its connection-level interaction while DNS resolution is still in progress, leaving the final endpoint determination unresolved at the moment the safety check is (","pith_inferences":["The use of TCP FIN/RST as a proxy for GSB check completion is an indirect measurement: the browser may have completed its local hash-prefix evaluation and reached a safety decision well before or after the connection closes, meaning the measured gap could overstate or understate the true decision-to-resolution window. A controlled experiment instrumenting the browser's internal GSB API calls would","The security relevance depends on whether the GSB check result is bound to the domain name or to the resolved IP address. If GSB decisions are domain-based and DNS manipulation changes the IP while preserving the domain, the timing gap may be less exploitable than if the browser binds safety decisions to IP-level endpoints.","The 21% of cases with non-positive gaps (DNS resolving before GSB connection closure) may themselves be security-relevant, as they represent scenarios where the endpoint is determined before the safety check completes, potentially creating a different class of timing mismatch."],"forward_implications":["If the timing gap is confirmed as security-relevant, browser vendors may need to bind Safe Browsing decisions to the final resolved DNS endpoint rather than to the domain name alone, or trigger revalidation when DNS resolution completes after the initial safety check.","CNAME-heavy domains, which require multi-step DNS resolution, may be disproportionately exposed to timing-gap exploitation due to longer resolution chains extending the window.","The long-tail delays exceeding two seconds suggest that even low-frequency, high-latency DNS resolutions could create exploitable windows for targeted attacks against specific domains.","The measurement methodology could be extended to non-Chromium browsers to determine whether the timing gap is browser-specific or reflects a fundamental architectural issue in how safety checks and DNS resolution are scheduled."],"fun_headline_variants":["GSB query closures precede DNS resolution in 79% of navigations","DNS lags behind Google Safe Browsing closures in 79% of cases","Measurable timing gap between GSB and DNS in 79% of web traffic","GSB finishes before DNS resolves in 79% of captured browser flows","Google Safe Browsing ends before DNS resolution in 79% of cases"],"cache_read_input_tokens":0,"weakest_assumption_plain":"The paper assumes that the TCP FIN or RST packet closing the GSB-related TLS connection is a meaningful proxy for when the browser completes its safety check. Transport-layer connection closure does not necessarily correspond to the browser's internal safety decision point, which may be cached locally or completed at a different stage of the navigation pipeline. If FIN/RST timing does not track the actual safety decision, the measured gap reflects connection teardown behavior","fun_headline_variants_meta":{"raw":{"variants":["GSB query closures precede DNS resolution in 79% of navigations","DNS lags behind Google Safe Browsing closures in 79% of cases","Measurable timing gap between GSB and DNS in 79% of web traffic","GSB finishes before DNS resolves in 79% of captured browser flows","Google Safe Browsing ends before DNS resolution in 79% of cases","DNS resolution lags GSB closure by up to 2.4 seconds in 79% of cases"]},"model":"glm-5.2","effort":"high","cost_usd":0.0,"raw_usage":{"total_tokens":856,"prompt_tokens":478,"completion_tokens":378,"prompt_tokens_details":null},"tokens_in":478,"tokens_out":378,"duration_ms":19411,"temperature":1.0,"reasoning_tokens":251,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-08T15:24:52.880293+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"If browser instrumentation showing the actual internal timestamp of the GSB safety decision were compared against the FIN/RST timestamp and the two diverged systematically, the measured timing gap would be an artifact of connection lifecycle semantics rather than a security-relevant window.","supporting_citations":[],"review_version":1}