Closed Bug 1358348 Opened 3 years ago Closed 3 years ago
Add 'throttle' flag to connection entry (tracking protection)
Tracking protection is bound to a host name only. Hence, we can throttle a connection entry (entries) bound to such host names as 'throttled' all the time. The information if a host is on the tracking protection list is first known in the http channel. How this information is carried down to the connection manager is yet to be decided. This bug should only provide the information that the entry should be throttled, not to implement the throttling itself.
Honza, could you define the priority of this bug? Thanks!
Putting in the P2 rank, since bug 1360580, bug 1360583 may have the same effect with less effort and side effects.
Priority: -- → P2
I think bug 1362071 will have similar effect, hence lowering the priority here.
Priority: P2 → P4
(In reply to Honza Bambas (:mayhemer) from comment #0) > Tracking protection is bound to a host name only. Hence, we can throttle a > connection entry (entries) bound to such host names as 'throttled' all the > time. > As you said TP only checked the host name, does that imply all transactions from the same tracking origin are in the same connection entry's pending queue? If yes, setting lowest priority to those transactions seems useless because the transactions in the same pending queue all have the same priority? Honza, could you correct me if I am wrong? Thanks.
That's true! I think first was Patrick pointing that out - priorities only takes effect within an origin, not globally. Hence I want two things: - postpone scheduling TP listed resources transactions until the whole page has been loaded (bug 1358060 hard-blocked by bug 1360581) - throttle those transactions (add the Throttleable class of service on those channels - bug 1360580, which to be 100% effective is blocked by bug 1360581 as well ; adding the class side by lowering the priority as we do now will work, but we won't throttle from the very beginning of the transaction lifetime) - OR, instead of bullet point 2, remember that the whole domain is tracking, so that every transaction scheduled on it should be automatically throttled (this bug, however we are going to implement it) The idea behind this bug is tuned for how the throttling is implemented NOW - subject to change very soon in bug 1365307 to be solely inside nsHttpTransaction - which is a bit farther from http connection manager and connection entry rendering this bug a bit pointless. Hence, it seems more logical to me to spend time on bug 1360581 and won't fix this one (hence also P4). I still don't fully understand how annotation, TP marking, classification and malware blocklisting works, to make a judgment on how easy/complicated it is to fix (or get the necessary info soon enough and in an optimal way). It seems to me that trying to mark a connection entry as tracking is the same amount of work as to mark a channel with the same information. We would just carry the tracker list information further, duplicating the information classifier already has.
We currently mark channel sooner as TP listed - bug 1360581. That's enough to achieve the same goal as established here unless we find out there is a major bad performance impact with that implementation. WONTFIXing this one.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
There is one more reason to not implement this: TP resources can be referenced from <head> and in that case we definitely don't want to throttle/deprioritize them. Hence, the selective marking of individual requests is needed.
You need to log in before you can comment on or make changes to this bug.