When trying to insert an entry into a full HSTS cache, the entry to evict is chosen as follows: - pick the entry with the smallest visited counter. - if there are more than one, pick the one that comes first in PLDHashTable enumeration order. One outcome of this is that when visiting a newly HSTS-enabled site with low hash value, it will be inserted into the cache (with counter 0), and then shortly evicted again as soon as one navigates to another unvisited HSTS-enabled page. I imagine this happens mostly for infrequently visited pages, but it could happen for relatively frequently visited ones as well since it takes a whole day for the counter to increase past zero. In practice, this hit me when trying to add unix.stackexchange.com and askubuntu.com to the HSTS cache using the Enforce Encryption addon. My SiteSecurityServiceState.txt consists of 426 (out of 1024) entries with counter = 0, of which only 3 occur above line 255. (The file is stored in hashtable enumeration order.) It seems like it would be a good idea to take last visit times into account in the eviction heuristic. Throwing out the oldest of all entries with the same counter would just postpone the problem until only a single entry with counter = 0 remains, but sorting by say "counter / max(today - lastVisitTime, 10)" could work.

Using the last visited time seems reasonable, if there aren't performance issues. We also might be upping the limits (then again, according to telemetry, having 1024 entries in SiteSecurityServiceState.txt is uncommon: https://mzl.la/28IWQew ).