https://github.com/GoogleChrome/samples/issues/928#issue-3888595467

[ahfuckit]

GoogleChrome/webstatus.dev#1456 (comment)
GoogleChrome/samples#928 (comment)

Unfortunately rather than address a matter with respect, or at all, when a consumer/user has a question, several parties have opted to get all content on CSingendonks account hidden from the public. All without a single response, or attempt to even acknowledge anything was happening at all, by multiple representatives, contacted through multiple channels of communication. All without a single response. The absence of any input from these individuals and organizations is unprofessional and does no favors to any of the involved (or not involved, rather). Please take 2 minutes to consider the information in this before making any assumptions.
In regards to WebStatus.dev's implimentation with Vaadin.. This shows how similar or dissimilar these are from eachother and projects with similar goals but unique executions.

Console & Fetch Interception: Both codebases override console methods with the same strategy (mapping log types to UI categories, grouping events) (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub). They also wrap fetch and XHR in confirmation prompts. The analysis explicitly states that “same override pattern, same typeMap, almost line-for-line match on message parsing and toast injection” (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub). In other words, the network-intercept code (prompts, conditional logic, promise wrappers) in WebStatus.dev is nearly identical to CNC’s (compare (ClientsideNetworkControl/core.js at CSingendonk · CSingendonk/ClientsideNetworkControl · GitHub) (ClientsideNetworkControl/core.js at CSingendonk · CSingendonk/ClientsideNetworkControl · GitHub) above with the description in (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub)).

safeStringify Implementation: Both codebases use a custom JSON serializer. Chris’s README notes that both implementations use the same depth parameter and cache strategy for circular protection (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub). This implies that one was likely copied from the other (or both from a common source) rather than invented independently.

UI Components: The structure of UI components (paused button, theme toggle, export button, draggable container) matches closely. For example, the pause/play toggle uses identical emoji icons and styling rules in both projects (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub). The “toast” notification container logic is also the same (custom element with shadow DOM, positioned fixed, animating in/out) (whoops/toasts.js at main · CSingendonk/whoops · GitHub). These are not generic widgets – the fact that their internal implementation and markup are parallel is telling.

Naming & Structure: The code uses the same class and method names. The README points out “specific function names, class names, and even internal helper methods are nearly identical” (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub). For instance, a function that formats log entries or a helper that filters events carries the same name and signature.

Importantly, timeline evidence supports derivation. Chris’s logs and code (in GitHub, blog posts, etc.) were public by late 2023 and 2024. The analysis shows that shortly after this, WebStatus.dev’s code began containing these same features. That project’s repository (for example, a Chrome extension or DevTools plugin) emerged later with the copied logic. Yet the WebStatus.dev code never credits Singendonk. In contrast, his code explicitly warns “NOT LICENSED… not for use, distribution, or copying… without permission” (GitHub - CSingendonk/ClientsideNetworkControl). This strongly suggests a license violation or at least omission of attribution.

No external documentation or release notes in WebStatus.dev mention Chris or his code, and there is no indication of open-source sharing. The analysis concludes that the overlap “is not generic enough to be coincidental” and points to “direct, derivative use of Chris’s custom code without proper attribution” (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub).
Timeline Discrepancies and Attribution

According to the documented timeline (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub), Chris’s implementations (CNC + initLogs) predate the similar functionality in WebStatus.dev. His repos (with headers, readmes, and timestamps) clearly show the UI and interception features in 2024. The WebStatus.dev code with matching behavior appears only later. Furthermore, Chris’s repos carry copyright notices and disclaimers (e.g. “© 2024–2026 Chris Singendonk – All Rights Reserved” (GitHub - CSingendonk/ClientsideNetworkControl)), whereas the third-party code has none of these attributions.

Thus there is evidence of copied variables, matching comment headers, and identical logic in WebStatus.dev after Chris’s code was public, without any credit. Under the CNC license (all rights reserved, no permission granted (GitHub - CSingendonk/ClientsideNetworkControl)), reusing that code publicly without consent would violate copyright.
Conclusion

The review finds multiple identical architectural and stylistic signatures between CSingendonk’s repos and the WebStatus.dev/Logdy environment. These include custom-element UIs built via JS templates (with inline <style> and Shadow DOM), identical drag/resize handlers, identical console/network interception logic (including prompt gating and use of a typeMap), and even the same JSON serialization routine. Coupled with a timeline showing Chris’s code coming first and WebStatus.dev’s later adoption of the same features, and the lack of any attribution in the latter, the only reasonable verdict is that the WebStatus.dev/Logdy code was derived directly from Chris Singendonk’s original implementations. This appears to be an unauthorized reuse (and likely a license violation), as Chris’s projects explicitly reserve all rights (GitHub - CSingendonk/ClientsideNetworkControl) and the duplicated code is “not generic enough to be coincidental” (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub).

Verdict: The technical overlaps and timing strongly indicate that the third-party projects copied CSingendonk’s code and UI designs. No attribution was provided despite clear evidence of direct code reuse. This suggests an infringing derivation of Chris Singendonk’s copyrighted software.

Sources: Analysis and code from CSingendonk’s GitHub repos (e.g. CNC, HTMLPanels, Whoops) (whoops/toasts.js at main · CSingendonk/whoops · GitHub) (htmlpanels/draggrip.js at A · CSingendonk/htmlpanels · GitHub) (ClientsideNetworkControl/core.js at CSingendonk · CSingendonk/ClientsideNetworkControl · GitHub), and the investigator’s documented comparisons in the wtf- repo (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub) (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub) (wtf-/vaadinInWebstatus.txt at main · CSingendonk/wtf- · GitHub) (GitHub - CSingendonk/ClientsideNetworkControl). These show the matching implementations and timeline facts cited above.