A-91%
Quality Score
3
Pages
29
Issues
7.8
Avg Confidence
7.4
Avg Priority
9 Critical12 High8 Medium
>_ Testers.AI
AI Analysis
Messages.Google was tested and 29 issues were detected across the site. The most critical finding was: AI/LLM endpoints detected on page load (privacy risk). Issues span Performance, A11y, Other, UX categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).
Qualitative Quality
Messages.Google
Category Avg
Best in Category
Pages Tested · 3 screenshots
Homepage
messages.google.com.web
messages.google.com.web
Detected Issues · 29 total
1
AI/LLM endpoints detected on page load (privacy risk)
CRIT P9
Prompt to Fix
Action: Remove or guard AI endpoint calls on page load. Identify all network requests flagged as AI endpoints; replace with lazy-loaded, user-initiated calls guarded by a consent flag. Add a feature-toggle to disable automatic AI loading in non-consensual scenarios. Include CSP, SRI for external resources, and logs that only trigger on user action.
Why it's a bug
The console log shows multiple AI endpoints being detected and triggered on initial load, suggesting AI services are called or prepared without user consent. This can result in unintended data exposure and violates user privacy expectations.
Why it might not be a bug
If this environment is a debug harness where AI calls are simulated, the logs might reflect test instrumentation. In production, such calls would be unacceptable without consent.
Suggested Fix
Remove automatic AI endpoint calls on load; bundle or lazy-load AI integrations behind a user action or explicit opt-in. Centralize AI endpoints behind a consent-based feature flag; audit network requests and add proper CSP/SRI and telemetry opt-out.
Why Fix
Protects user privacy, reduces data leakage risk, and aligns with privacy best practices; improves performance by avoiding unnecessary network requests.
Route To
Frontend Engineer / Security Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTEDNetwork:
GET https://www.gstatic.com/_/messagesweb/_/js/k=messagesweb.mw.en_US.9aqCB2laVq0.O/...2
Third-Party Ad/Tracking Data Shared with ogads-pa GoogleAds Service
CRIT P9
Prompt to Fix
In the Messages web app, locate the outbound call to ogads-pa.clients6.google.com/$rpc/google.internal.onegoogle.asyncdata.v1.AsyncDataService/GetAsyncData (and any preflight OPTIONS or related POST requests). Requires a privacy-consent gate before making this third-party tracking/ad data request. Remove or sanitize any potential PII from the request payload, ensure no identifiers tied to the user are transmitted (or hash/anonymize), and implement an opt-in consent flow for cross-site tracking. If consent is not given, block the request and rely on first-party analytics only. Update privacy policy to clearly disclose third-party data sharing and provide user controls to opt out.
Why it's a bug
Outbound requests to ogads-pa.clients6.google.com for AsyncDataService/GetAsyncData indicate data is being shared with a third-party advertising/tracking service. This enables cross-site tracking and behavioral data collection without a visible consent indicator in the logs provided. Such data sharing can expose user behavior to a third party and may violate data minimization principles and regulatory expectations if not clearly disclosed and consented.
Why it might not be a bug
If the product relies on Google's ad/analytics integrations as part of its revenue model and the privacy policy/terms clearly disclose this data sharing, some teams may argue it is expected behavior. However, the logs do not show consent gating for this third-party data exchange, making it a high-risk privacy concern that should still be addressed.
Suggested Fix
Gate the GetAsyncData/AsyncDataService calls behind explicit user consent for third-party tracking. Ensure no PII is sent to the third party (strip identifiers, use data minimization, and hash/anonymize where possible). If consent is not provided, block the request or use a privacy-preserving alternative (first-party analytics). Add a clear privacy note and an opt-out UI control for ad/tracking data sharing. Review and remove any unnecessary data from the request payloads to third-party services.
Why Fix
Fixing this reduces exposure of user behavior to a third-party ad/tracking partner, supports user privacy by enabling consent and data minimization, and helps ensure regulatory and policy compliance while preserving user trust.
Route To
Privacy Engineer / Frontend Security Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
GET https://ogads-pa.clients6.google.com/$rpc/google.internal.onegoogle.asyncdata.v1.AsyncDataService/GetAsyncData - Status: 200; POST https://ogads-pa.clients6.google.com/$rpc/google.internal.onegoogle.asyncdata.v1.AsyncDataService/GetAsyncData - Status: N/A; OPTIONS ... - Status: N/ANetwork:
GET https://ogads-pa.clients6.google.com/$rpc/google.internal.onegoogle.asyncdata.v1.AsyncDataService/GetAsyncData - Status: 2003
Excessive network requests (74) on page load
CRIT P9
Prompt to Fix
Audit all network requests on the landing/pairing page. Bundle JavaScript/CSS into fewer files, eliminate unused assets, implement code-splitting, and lazy-load non-critical resources. Optimize font loading (subset, swap) and preload only critical assets. Add preconnect to critical origins and consider a small set of CDN-accelerated assets to reduce total requests.
Why it's a bug
The page loads 74 resources which can increase latency, parsing/compile time, and impact Core Web Vitals (LCP/TTI). Even with caching, large request counts flatten the user experience on slower connections.
Why it might not be a bug
Some requests are essential (fonts, third-party scripts, icons) for correct rendering and functionality; reducing them could degrade UX if not handled carefully.
Suggested Fix
Bundle and minify JS/CSS, remove unused assets, lazy-load non-critical resources, consolidate fonts, and reduce third-party scripts. Add resource hints (preconnect, prefetch) for critical assets.
Why Fix
Fewer, well-prioritized requests reduce render time, improve LCP/TTI, and lower data usage, especially on mobile networks.
Route To
Frontend Performance Engineer
Page
Tester
Tariq · Performance Specialist
Technical Evidence
Network:
Representative: GET https://messages.google.com/web/authentication - Status: 200; multiple assets from fonts.googleapis.com, gstatic.com, and messages.google.com/web/ (total requests: 74)