Should a library like this only do one thing and do it well, or should I add a 'fingerprint storage'?

[ilkkapeltola]

The thing is, for my work, I need to create a simple storage that can be used like localStorage, but using the fingerprint.

Let me explain.

There are situations where cookies are just not working anymore, namely when you need to hold on to some browser data about a visitor from a landing page to inside the product. The specific use case we have is about how we got the visitor to the landing page in the first place (Google Ads, organic search results, a facebook post, an affiliate etc.).

When we use cookies, we need to ask for consent and a lot of people choose not to consent.

I got an idea from how Matomo is implementing their cookieless, consentless analytics: They track short-lifespan fingerprints. Apparently this is ok and to be honest, it's not very intrusive either.

So what I'm considering is adding two functions to this library

• setItem(key, value)
• getItem(key)

That make a call to a small backend with the fingerprint etc. While fingerprint collisions may sometimes theoretically happen of course, it's fine in my use case. It's still better than nothing.

I have all the components needed and the added lines of code is pretty insignificant.

But at the same time I cannot help but think that ... maybe a fingerprinting library should just do fingerprinting, do the one thing well. And leave the storage problem alone.

I do want to provide this solution too, but, maybe it's then another repository? Another library, and see if it gets any traction?

Comments welcome!