I think that's a red herring: the query is sandboxed DuckDB-WASM SQL (never executed as script), it's never injected into the DOM as HTML, and the page enforces a strict CSP that blocks inline script regardless. NoScript probably flags it because it's SQL-shaped text in a cross-site query string, and it matches its injection heuristic.
Statistics that live in your SQL
21–23 of 23 posts
Re: Statistics that live in your SQL
#22NoScript detected a potential Cross-Site Scripting attack from https://kolistat.com to https://bedeverewise.app . Suspicious data: (URL) https://bedeverewise.app/embed?autorun=1&query=WITH pois AS ( SELECT k, dpois(k, 3) AS pmf FROM range(0, 11) AS t(k) ) VISUALIZE k AS x , pmf AS y FROM pois DRAW bar ; so... no, thanks.
Both sites are from the same guy.
Re: Statistics that live in your SQL
#23Earlier quoted context omitted.
If you're interested, this isn't an alternative implementation of ggsql's syntax (I published this last year and it is based on a slightly modified layered grammar), but the SGL language is a similar take on the grammar of graphics + SQL idea: https://arxiv.org/pdf/2505.14690 . Currently implemented as an R package: https://sgl-projects.github.io/rsgl/index.html .
Well done for laying that down in that way! I'm just wondering how much it would be on my side to support that, since I can see that you support cases like "count(*)" and "group by" inside visualize. I can see you have a full bison grammar, I only have a custom parser at the moment, but at least your implementation is in C. But I'm happy to follow thomasp85.