With its radically holistic approach to web development, the open-source UIX framework provides end-to-end messaging, data storage, reactivity and synchronization between backend and frontend combined in a single coherent package. The goal is achieving the best developer experience for newbies and professionals alike. PS: We don’t use npm!
Yeah, you might be correct with that. Our target audience are mostly (half) experienced web devs. Nevertheless we are working on a more broad and easier way to get into UIX. Feedback is highly appreciated.
UIX is our open-source full-stack framework for developing reactive web apps with restorable and shared state. Apps runs on a deno backend and supports both single- and multi page applications with frontend or server-side rendering and hydration. Getting started at https://docs.unyt.org/manual/uix/getting-started
The DATEX JavaScript Library acts as the backbone of UIX, providing useful functionality such as reactivity and cross-device data exchange. In contrast to frameworks like React, UIX provides direct wiring to the DOM for reactivity and does not need a virtual DOM.
So there's indeed an "indicative icon" on the start page that is always delivered. If the browser requests the icon when calling the demo.supercookie.me page, the write mode is invoked, but if the icons is already present in the cache the browser does not send a request and read mode is initiated. ~jonas
This idea was indeed my first approach, but favicons on the client side cannot be loaded from the F-Cache via JavaScript, but are ALWAYS requested from the server via get-request, which fortunately thus does not allow fingerprinting. ~jonas
To clarify, falsifying results was never my intention: During my work I tested Firefox (v 84.0) and everything worked fine under Windows & OSX.
Due to your feedback I've updated the table in the GitRepo and the website and added that the current FF version (v 85.0) is no longer vulnerable! ~jonas
Yeah, the demo page is using a ±800ms timeout on purpose.
I chose the threshold so that even with a bad internet connection, slow browser, etc. the favicon is requested without the redirect being faster than that.
So it is definitely possible to reduce the timeout significantly but it is not useful for demonstration purposes... ~jonas
Thanks for clarifying - I have also noticed the very doubtful action of the authors! But I can furthermore assure that I have nothing to do with the authors of the paper. ~ jonas