Question regarding tldts-experimental reliability

[hicallmeal]

I'm just looking at the experimental version, and I was hoping to get some clarity on:

The drawback is that there might be some unlikely false positive (think bloom filters).

Sorry, bit of a newbie question.

My potential use case should be fairly simple I think.
It should mostly be obtaining the eTLD + 1, if I'm saying that right (drive.google.com -> google.com)

• private included.

For technical reasons, which I'm happy to explain after, I can't use the standard version.
But before that, I just want to know if the use case is appropriate and risk-free.

I just wanted to note - the Tries and Hashing.. just completely beyond me - any time I see that sort of thing,
I can't help but marvel in awe. So, kudos, just terrific

Thanks.

[remusao]

Hi @hicallmeal, in general it should be safe to use the experimental version of tldts but it really depends on your particular use-case. What would be the cost if the output is wrong? The likelihood of this happening is low but if it must never fail for any reason, that could be problematic. The experimental version of tldts has been used in production for a long time so it is battle-tested, but by design there is a (low) chance of output being imprecise. It'd be useful to know about your particular use-case in order to answer with full certainty.

[hicallmeal]

Of course, so to elaborate, perhaps imagine a password manager, where a user adds an account, and with it, a trusted link (e.g. the site where autofilling is pemitted or perhaps just to suggest the account when browsing). The addition might also happen automatically, without user input.
To do this, I would extract the eTLD + 1, then check against that.

So, of course, if the lib matched the wrong tld (I'm not sure how the false positive presents, sorry) for instance, it causes unexpected / incorrect behaviour.

Why not tldts
I'm developing an extension and my goal is to keep the size minimal and also require as little maintenance long term / work dynamically.

• Fetching the psl .dat means I don't have to keep updating the extension in the future
• It also means I don't have to include the .dat which lessens the size

For this, I was looking at a way to only include the logical parts of your library and store the data in extension storage, in its optimised form.
Just from what I've seen in testing, the way the tries file is structured requires javascript to process (assignment, etc) whereas the hashes are just an array, easily serializable. Since I can't eval the former (extension security policy), I have to go with the latter.

With that it's fairly easy to then include, which leaves my only concern at reliability (going by the readme).

[hicallmeal]

Just noting, if you think there's a better way, I'm all ears - I'm still at the mental mapping stage of implementation.

[hicallmeal]

Looking at it again, given the nature of the experimental, I don't think it's appropriate (from my understanding of the false positive nature), but I'd be happy to be wrong.

Looking at the standard version, I feel like the only possibility would be to store the decompressed tries, which storage-wise is fine, then retrieve and keep a reference to it during execution.

My understanding of doing that, though, is that it would be a bit slower (not a big deal for me), and possibly a heavy load on memory. Though, do I read correctly that the lib does that as well, but keeps the unpacked tries in a closure?

Perhaps storing and retrieval isn't that bad, I guess it still impacts storage retrieval time.