{"id":"2252ea03-6eab-4733-8366-a2578e12f342","arxiv_id":"2508.19544","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"WebEyeTrack keeps gaze estimation fully in the browser by pairing a compact CNN with iris-scaled metric head pose and MAML-based few-shot adaptation, reporting 2.32 cm error on GazeCapture.","lead":"A browser-based eye-tracking framework combines a lightweight neural network, head-pose estimation, and few-shot personalization to track gaze with only nine calibration points. It claims accuracy comparable to much larger models while running in real time on phones and laptops, with all data staying on-device.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 2.32 cm claim is not established for the deployed browser pipeline: it relies on dataset intrinsics K (Sec. 3.1) whereas the browser path explicitly omits K and uses a landmark homography (Sec. 4.1); Table 1 also mixes few-shot and zero-shot evaluations.","rationale":"The reader's conditional verdict is appropriate. I focused on the gap between the GazeCapture evaluation, which uses K-projected metric head pose, and the browser deployment, which explicitly avoids K and uses a homography; this gap is load-bearing because the paper's contribution is a browser-deployable system, not a dataset-only model. The absence of any within-dataset deployment-mode accuracy number means the central 2.32 cm claim may not be reproducible in the actual environment. The Table 1 mixing of few-shot BlazeGaze with zero-shot baselines is a real secondary problem: even the literal best-error claim is not supported (AFF-Net reports 2.30 cm on GazeCapture), so 'SOTA' needs a controlled calibration protocol. I do not see internal inconsistency that warrants rejection—the architecture, losses, and open-source release are plausible and partially verifiable—but the headline accuracy needs re-scoping or additional measurement. The proposed check directly separates intrinsics-dependent accuracy from deployment accuracy and would settle whether the concern lands. Since the reader already calls for conditions of this kind, no verdict change is needed.","tokens_in":11354,"tokens_out":8379,"duration_ms":76959,"concrete_test":"Using the released repository, re-run the GazeCapture evaluation with the deployment code path: disable all use of K (Eqs. 2 and 6), estimate metric head pose from MediaPipe's relative transformation and iris-scale face width (Eq. 5 plus the homography normalization described in Sec. 4.1), then adapt with k=9 MAML support samples and report mean PoG error on the held-out query set. If the resulting error is materially above 2.32 cm (for example, closer to the 7.24 cm Eye of Typer figure), the headline accuracy is an artifact of dataset intrinsics and the claim must be re-scoped to the non-deployed setting.","verdict_should_be":"UNCHANGED","load_bearing_attack":"For the central claim to hold, the same BlazeGaze pipeline that runs in the browser—MediaPipe landmarks, homography warp, no camera intrinsics—must deliver accuracy close to 2.32 cm on GazeCapture after k≤9 personalization. The paper does not show this. Section 3.1 builds metric head pose by reprojecting MediaPipe UVZ landmarks with the dataset intrinsics matrix K (Eq. 2), then uses K again in the radial Procrustes objective (Eq. 6) to refine t′. Section 4.1 states that the deployed normalization avoids PnP and camera intrinsics, replacing them with a homography from MediaPipe landmarks. No experiment quantifies the accuracy loss when K is replaced by the homography/relative-pose path. The cross-dataset Eye of Typer result, 7.24 cm, is the only number produced in a browser-like setting, and it is more than three times the headline error; while part of that gap is domain shift, the paper provides no decomposition separating deployment-pipeline loss from cross-dataset loss. Without that decomposition, the headline 'SOTA performance with an error margin of 2.32 cm' cannot be attributed to the actual system. A second, compounding issue is that Table 1 reports BlazeGaze after per-user MAML adaptation (Sec. 4.3, k=9 support) while most baseline rows are published zero-shot errors; 'SOTA' is therefore not a controlled comparison. The open-source code is a point in the paper's favor, but it does not by itself establish that the deployed pipeline reaches 2.32 cm.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"WebEyeTrack is a browser-based eye-tracking framework that combines MediaPipe facial landmarks with a metric head-pose reconstruction stage, a lightweight CNN gaze model called BlazeGaze, and MAML-based few-shot personalization using at most nine calibration samples. The paper reports within-dataset point-of-gaze errors of 2.32 cm on GazeCapture, 4.56 cm on MPIIFaceGaze, and 7.53 cm on EyeDiap, with very low computational cost (0.15 GFLOPs, 0.16 M parameters, 0.88 ms CPU delay in Table 1), and a cross-dataset evaluation on Eye of the Typer showing better temporal stability than WebGazer after a 20-minute session. The authors provide open-source Python and JavaScript implementations.","tokens_in":1397,"tokens_out":1431,"duration_ms":63380,"significance":"If the reported numbers hold, the paper makes a practically useful contribution: it demonstrates that a very small CNN with on-device few-shot personalization can reach accuracy comparable to much larger gaze-estimation models, while preserving privacy and running in a browser. The open-source release, the direct cross-dataset comparison with WebGazer, and the temporal-drift analysis are genuine strengths. The significance is somewhat tempered by the evaluation-protocol gaps described below, but the core idea is plausible and the requested additional experiments are within the scope of a revision.","major_comments":[{"comment":"The headline comparison is not controlled: the BlazeGaze rows are produced after per-user MAML adaptation with k=9 support samples (Section 4.3), whereas most baseline rows appear to be published zero-shot errors. Table 1 therefore conflates the effect of personalization with the effect of the model architecture, so the claim of SOTA performance is not directly supported. Please report BlazeGaze errors with and without the per-user adaptation, and for each baseline indicate explicitly whether calibration or few-shot adaptation was used; alternatively, retrain or re-evaluate the strongest baselines under the same adaptation protocol.","section":"Table 1 and Section 5.2"},{"comment":"The 2.32 cm GazeCapture result is obtained using the dataset camera intrinsics K in Equations (2), (3), and (6), while the deployed browser pipeline deliberately avoids camera intrinsics and PnP, replacing them with a homography computed from MediaPipe landmarks (Section 4.1). No experiment quantifies the accuracy lost when the K-based pose pipeline is replaced by the homography/relative-pose path. The only browser-like evaluation, Eye of the Typer (7.24 cm), confounds this pipeline substitution with cross-dataset domain shift, so it cannot establish that the deployed system achieves the abstract's SOTA performance with an error margin of 2.32 cm. Please add a controlled ablation on GazeCapture that runs the exact deployed pipeline, including MediaPipe landmarks, homography warp, and no intrinsics, and reports the resulting error after the same k=9 personalization.","section":"Section 3.1 vs Section 4.1 and Abstract"},{"comment":"The paper states that the iterative radial Procrustes update converges to the minimizer of the reprojection objective in Eq. (6), but no convergence argument is provided, and the update rule in Eq. (8) is a clipped scalar heuristic rather than a standard Procrustes step. Because the metric head pose is a direct input to the personalized gaze regressor, this is a load-bearing component. Please provide a proof of convergence to a stationary point of Eq. (6), or an empirical validation against PnP or alternative head-pose fitting baselines, or an ablation showing insensitivity to the initial depth z0, the step size beta, the clip threshold delta_max, and the iteration cap.","section":"Section 3.1, Equations (6)-(8)"}],"minor_comments":[{"comment":"The abstract says \"as few as nine calibration samples (k < 9)\", while the method sections state k <= 9 and use k = 9 in experiments; please harmonize the notation and the inequality.","section":"Abstract vs Section 3.2 / Section 4.3"},{"comment":"The loss weights beta_r, beta_g, beta_c are said to be empirically determined for each dataset, but their values are not reported; please list them for each dataset for reproducibility.","section":"Section 3.2, Eq. (9)"},{"comment":"The symbol K-prime is used in the Reproject operation but is never defined; please specify whether it is the inverse of the intrinsics matrix or another quantity.","section":"Section 3.1, Eq. (3)"},{"comment":"The notation c_i is undefined; the preceding text describes a single center c between matched projected and original landmarks, so please clarify how the index i enters the center term.","section":"Section 3.1, Eq. (8)"},{"comment":"The abstract reports 2.4 ms on an iPhone 14, while Table 1 reports 0.88 ms and 1137 FPS on an Intel i7-11700F CPU; please state the exact hardware and measurement protocol for each number so the reader can compare them.","section":"Table 1 and Abstract"},{"comment":"The row label \"Mnist\" appears to refer to a gaze estimation method rather than MNIST digit classification; please verify the name and the associated citation.","section":"Table 1"}],"recommendation":"major_revision","confidential_remarks":"The repository's availability makes the requested controlled ablation feasible, and I would support acceptance if the authors demonstrate that the deployed homography-based pipeline on GazeCapture remains close to 2.32 cm after k=9 personalization, or if they scale back the headline claim to a within-dataset pipeline-agnostic accuracy number. The protocol mismatch in Table 1 also needs to be disclosed even if no additional baseline training is performed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick read of the WebEyeTrack paper. The core thing to know: it is a real engineering contribution. The repo is open, the model is 670KB, inference is 2.4ms on an iPhone 14, and the integration of MediaPipe landmarks, metric head pose, and on-device MAML personalization is clean. The genuinely new pieces are BlazeGaze (BlazeBlock-based CNN) and the iris-scaled metric head pose refinement. The few-shot meta-learning itself is inherited from FAZE and SAGE, both cited, but the complete browser-deployable system is new and working.\n\nThe headline 2.32 cm on GazeCapture is the within-dataset number after per-user calibration. It is obtained with the dataset's camera intrinsics (Sec. 3.1, Eq. 2). The deployed browser pipeline explicitly skips intrinsics and uses a homography from MediaPipe landmarks (Sec. 4.1). No experiment ties the two together. The only browser-like number, the Eye of Typer cross-dataset result, is 7.24 cm, more than three times larger. Domain shift explains part of that gap, but the paper does not decompose it. The reader's stress-test is on target: the abstract's 'SOTA with 2.32 cm' cannot be attributed to the actual browser pipeline as delivered.\n\nSecond soft spot: Table 1 compares BlazeGaze after few-shot personalization (k=9) against published zero-shot errors for most baselines. That is not a controlled SOTA comparison. The caption should flag which rows are few-shot. It is a presentation flaw, not fatal, but it matters for interpretation.\n\nThe radial Procrustes refinement is under-derived. Eq. 6 defines the objective, but the update rule in Eqs. 7-8 looks heuristic. A standard PnP baseline or a clear derivation of the clip-based depth update would make it more convincing. Minor, but worth asking for.\n\nWhat the paper does well is ship. The code, architecture, and training details are specific enough to reproduce. The temporal drift analysis against WebGazer (20% vs 49% error increase over 20 minutes, with a Mann-Whitney U test) is a nice practical result.\n\nThis paper is for HCI and applied CV readers who care about deployable gaze tracking, not for someone expecting new gaze science. It deserves a serious referee. The authors should either add an ablation subtracting the intrinsics-based within-dataset pipeline from the homography-based browser pipeline, or reframe the abstract so 2.32 cm is attributed to the model under standard normalization rather than to the deployed browser. Either fix makes it a solid accept.","headline":"A genuinely useful systems paper with open code and a clean few-shot gaze pipeline, but the 2.32 cm headline belongs to the within-dataset evaluation with camera intrinsics, not the browser deployment that uses a homography, and the paper never quantifies that gap.","tokens_in":12286,"tokens_out":2832,"would_cite":true,"duration_ms":27078,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that a browser-based gaze tracker with a 670 KB model and nine calibration samples can reach 2.32 cm point-of-gaze error, matching much larger models.","keywords":["gaze estimation","eye tracking","few-shot meta-learning","on-device personalization","head pose estimation","browser-based inference","lightweight CNN","point-of-gaze"],"falsifier":"Run the deployed JavaScript pipeline on a GazeCapture-style test set where each user's screen distance and camera parameters are known, and compare its point-of-gaze error to the 2.32 cm reported with intrinsics-based preprocessing; a median error well above 3 cm would show the browser pipeline does not deliver the headline accuracy.","tokens_in":11141,"feed_emoji":"👁","tokens_out":7496,"duration_ms":65485,"temperature":0.7,"pith_summary":"This paper argues that high-accuracy gaze estimation no longer requires specialized hardware or cloud GPUs. It presents WebEyeTrack, a browser pipeline that combines a lightweight CNN called BlazeGaze, metric head-pose estimation from facial landmarks, and on-device few-shot meta-learning, so each new user's gaze model is personalized from at most nine calibration samples. The authors report 2.32 cm point-of-gaze error on the GazeCapture benchmark and 2.4 ms inference on an iPhone 14, with all computation staying on the device. If this holds, eye tracking becomes a practical, privacy-preserving ingredient for ordinary web and mobile applications.","feed_headline":"2.32 cm gaze tracking in a browser after nine clicks","feed_subtitle":"A 670 KB model adapts to each user on-device, runs in 2.4 ms on a phone, and keeps video frames private.","key_machinery":"The load-bearing pieces are three. First, BlazeGaze, a 670 KB CNN built from lightweight BlazeBlocks, maps a 128x512 eye-region image into a 512-dimensional embedding. Second, a metric head-pose estimator converts normalized facial landmarks into centimeters by assuming a fixed 1.2 cm iris diameter and then iteratively solves for the camera translation using radial Procrustes alignment, so head rotation and position enter the gaze regressor as explicit inputs. Third, first-order MAML: after representation learning, only the small gaze multilayer perceptron is adapted, using support sets of no more than nine samples, which makes personalization cheap enough to run in JavaScript on a phone.","core_discovery":"The central claim is that a deliberately small model can match or approach state-of-the-art gaze accuracy while remaining fast enough for real browsers. BlazeGaze encodes a warped eye region into a gaze-aware embedding, feeds that embedding together with a metric head pose into a three-layer regressor, and is trained in two stages: first a reconstruction-plus-gaze objective builds the embedding, then the decoder is discarded and the regressor becomes a MAML meta-learner. At deployment, a new user provides a short calibration grid and a few gradient steps adapt the regressor on-device. The paper reports that this system reaches 2.32 cm point-of-gaze error on GazeCapture, 4.56 cm on MPIIFaceGaze, 7.53 cm on EyeDiap, and outperforms the leading browser baseline in a 20-minute typing study, with error rising only 20% over the session versus the baseline's 49%.","pith_inferences":["An implication the paper leaves implicit is that the headline 2.32 cm figure is measured with dataset camera intrinsics, while the deployed browser pipeline substitutes a homography from facial landmarks; a direct head-to-head test on the same subjects would quantify how much accuracy that substitution costs.","Because the iris diameter is fixed at 1.2 cm for every user, metric head pose could be biased for children or adults whose iris size differs; measuring per-user iris scale during calibration is a natural extension that might improve accuracy.","The encoder stays frozen during meta-learning, so the personalization ceiling is set during representation learning; unfreezing it on-device could recover extra accuracy at higher computational cost.","The two-stage representation-plus-meta-learned-head design is generic enough that it could be retargeted to other per-person regression problems, such as hand or body pose, using the same calibration-plus-on-device pattern."],"forward_implications":["Gaze tracking can run fully in-browser on consumer phones at interactive rates; the reported 2.4 ms inference on an iPhone 14 implies real-time head-tracking applications face no latency barrier.","Privacy-sensitive users gain a usable gaze signal because no video frame or calibration data needs to leave the device.","The nine-sample calibration requirement lowers the cost of personalization enough that gaze could be added to ordinary websites, education software, and assistive interfaces.","Head-pose awareness gives the system temporal stability: in the 20-minute typing study, error grew only 20% versus 49% for the browser baseline, so drift no longer forces constant recalibration.","The 670 KB model footprint makes the tracker embeddable in pages and mobile apps without large download or update costs."],"supporting_citations":[{"why":"Provides the GazeCapture dataset and its camera intrinsics, which the 2.32 cm benchmark and the reprojection preprocessing depend on.","marker":"Krafka et al. 2016"},{"why":"Supplies the few-shot adaptive gaze estimation formulation, MAML training scheme, and initial loss weights that BlazeGaze adapts.","marker":"Park et al. 2019"},{"why":"Introduces BlazeBlocks, the lightweight mobile-friendly architecture BlazeGaze is built from.","marker":"Bazarevsky et al. 2019"},{"why":"Provides the real-time facial landmark and face mesh pipeline used for landmark extraction and relative head pose.","marker":"Grishchenko et al. 2020"},{"why":"Defines the open-source browser eye-tracking baseline that WebEyeTrack is compared against.","marker":"Papoutsaki et al. 2016"},{"why":"Supplies the Eye of the Typer dataset and the 20-minute typing protocol used for cross-dataset temporal evaluation.","marker":"Papoutsaki et al. 2018"},{"why":"Gives the 1.2 cm iris diameter constant used to convert normalized face meshes into metric scale.","marker":"Wen et al. 2020"},{"why":"Provides the Procrustes analysis that the iterative metric head-pose refinement is based on.","marker":"Gower 1975"},{"why":"Supplies MPIIGaze, the in-the-wild gaze dataset used for training, evaluation, and normalization baselines.","marker":"Zhang et al. 2015"},{"why":"Supplies MPIIFaceGaze, the full-face webcam dataset used to train and test BlazeGaze.","marker":"Zhang et al. 2016"}],"fun_headline_variants":["Browser gaze tracking hits 2.32 cm error with nine calibration clicks","On-device few-shot eye-tracking runs in 2.4 ms on a phone","WebEyeTrack: small model, on-device adaptation, private gaze","Nine samples personalize browser eye-tracking to SOTA accuracy"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The browser version uses a simpler geometric shortcut instead of the camera calibration used in the benchmark, and the paper never measures the accuracy lost to that shortcut, so the headline 2.32 cm may not be what real users get.","fun_headline_variants_meta":{"raw":{"variants":["Browser gaze tracking hits 2.32 cm error with nine calibration clicks","On-device few-shot eye-tracking runs in 2.4 ms on a phone","WebEyeTrack: small model, on-device adaptation, private gaze","Nine samples personalize browser eye-tracking to SOTA accuracy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000443,"raw_usage":{"total_tokens":2229,"prompt_tokens":915,"completion_tokens":1314,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":531,"completion_tokens_details":{"reasoning_tokens":1234}},"tokens_in":531,"tokens_out":1314,"duration_ms":9375,"temperature":1.0,"reasoning_tokens":1234,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T16:50:18.253463+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the deployed JavaScript pipeline on a GazeCapture-style test set where each user's screen distance and camera parameters are known, and compare its point-of-gaze error to the 2.32 cm reported with intrinsics-based preprocessing; a median error well above 3 cm would show the browser pipeline does not deliver the headline accuracy.","supporting_citations":[],"review_version":2}