User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:184.108.40.206) Gecko/20060201 Firefox/220.127.116.11 (Ubuntu-dapper)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) Gecko/20060201 Firefox/22.214.171.124 (Ubuntu-dapper)
Thousands of users are pinging the phishing service significantly more than once every 30 minutes. Some users (<100) are pinging more than 1000 times an hour.
Does this state seem to persist at all through restarts? Like, will the same client stop and then restart pinging too fast?
This is for a list update, not a "check every URL" lookup? That interval is hardcoded, hard to imagine thousands of users hacking listmanager.js buried in our chrome. If it were taken from a pref I could believe a small fraction might tweak it to "be more safe".
Is old bug 115865 relevant here?
Can you tell us anything about the platforms these users are running on from their user agents? Is it all Windows? All Mac? any particular OS version?
(In reply to comment #0)
> Thousands of users are pinging the phishing service significantly more than
> once every 30 minutes. Some users (<100) are pinging more than 1000 times an
> Reproducible: Always
Have you verified these are really the same client and not just multiple clients you see as coming form the same IP address due either to natting or http Proxies?
I'm doing this analysis by looking at server stats, not particular clients, so I don't know if any particular OS/version is causing the problem. I also don't know if this is a function of restarts, etc. I have never had an actual client on hand that exhibited this problem. This analysis is based on cookies, so proxies shouldn't matter.
We should try to get the user agent strings. Also, maybe it's a bot or a cookie value that's being set on multiple computers (e.g., a company many have a standard image that includes firefox with a cookie). Do these users properly respond to back off behavior?
Certainly it has occurred to me that these aren't actual users. I was just to make sure that there wasn't a bug that was causing this behavior. I can try examining user agent strings to see if anything look suspicious.
Is it not possible to distinguish between full lookups and enhanced mode checks? We don't have enhanced mode on trunk anymore, but I could easily see 1000 pings an hour if someone's opening a lot of tabs... otherwise I have no idea what could cause this, though the new protocol should support the backoff commands.
(In reply to comment #4)
> I'm doing this analysis by looking at server stats, not particular clients, so
> I don't know if any particular OS/version is causing the problem. I also don't
> know if this is a function of restarts, etc. I have never had an actual client
> on hand that exhibited this problem. This analysis is based on cookies, so
> proxies shouldn't matter.
These are all full lookups, not enhanced mode requests.
Cookies are definitely set server side. However, I'm not in charge of the server that actually sets the cookies. I'll look into how exactly it's done.
We need to get FF126.96.36.199 out (jar: redirect xss bugs that's affecting Google among others), we can't hold the release to figure this one out. -> 188.8.131.52
Please renominate if there's more information on this, it seems incredibly unlikely to reproduce easily, given that its thousands out of tens o millions.
At the same time, if we get more info, we'll fix it...
I agree, this shouldn't hold anything up until we can conclusively figure out if something is wrong. I'll try and readdress this when I get more time, but unfortunately I'm a little swamped at the moment.
Could this be caused by an issue on the client side such as no write access to the url classifier database?
Not enough known to block a security release, but if this gets figured out let us know (assigning to a real person would be a good start).
Is this still a problem nowadays or can this report be closed as obsolete?
This hasn't been a problem since 3.0.