mapx-
commented
1 year ago @gorhill
Open PinkDuck opened 1 year ago
mapx-
commented
1 year ago @gorhill
gwarser
commented
1 year ago This works also in the other way around.
https://example.com/https://duckduckgo.com/?q=https%3A%2F%2Fexample.com%2F&ia=webexample.com in wiki widget on the rightbeacon neither by ||duckduckgo.com/t/ or *$ping,3p because it's called from whitelisted example.com context.See also: https://github.com/uBlockOrigin/uBlock-issues/issues/2363
gwarser
commented
1 year ago Still not blocked when navigating to whitelisted page.
Still blocked when navigating from whitelisted page.
Trying with:
||duckduckgo.com/t/$badfilter
*$ping,3p,badfilter
*$ping,strict3pBecause looks like *$ping,3p is correctly not applied now. On example.com beacon has duckduckgo.com context, so is 1p.
Similarly, with *$ping,1p.
PinkDuck
commented
1 year ago A key issue can be seen at CanIUse/keepalive in that some user agents (Firefox included) claim Fetch API full support, but actually a Fetch during beforeunload/unload does not have guaranteed network delivery and can be seen failing with NS_BINDING_ABORT. So I added user agent detection to compensate by using Beacon API directly, the first of these which does not get blocked, though the second ping does oddly.
gorhill
commented
1 year ago Still not blocked when navigating to whitelisted page.
I am aware, this is another issue in a different code path, not as easily fixed.
The difficulty with the trusted-site scenario is that disabling uBO is a test against the top-level context, and by the time the beacon is processed by uBO, the top-level context has changed.
This is the details I get re. ping/beacon requests (in chronological order) in Chromium/Firefox when navigating from duckduckgo.com to example.com, so this is the information uBO has to deal with:
Prerequisites
I tried to reproduce the issue when...
Description
Student lesson data in a commercial system is being blocked by uBO when navigating away from an active lesson. The system first attempts a fetch() request, which fails in NS_BINDING_FAILURE then falls back to sendBeacon mechanism using text/plain JSON content. However, the async delay in sending beacon means the host can be a non-Trusted Site by the time it gets intercepted by uBO. So either the EasyPrivacy list needs an exception for this particular site, or uBO could be adjusted to allow ping requests sent to Trusted Sites when processing privacy lists.
Example blocked item extract from uBO Logger:
URL(s) where the issue occurs.
https://www.ljcreatelms.com (uBlock disabled) sendBeacon after navigate to https://www.edp24.co.uk/news (uBlock enabled)
Also https://www.ljcreatelms.co.uk/ and https://lp1.ljcreatelms.com/
Screenshot(s)
uBO version
1.46.0
Browser name and version
Mozilla Firefox x64 108.0.2
Settings
Added "www.ljcreatelms.com" (without quotes) to Trusted Sites, confirmed uBO inactive at that site
Notes
Tried disabling uBO in Firefox Extensions, issue did not occur Tried navigating to another trusted site, issue did not occur Only navigating from trusted to untrusted blocks the Beacon being sent back to Trusted Clearing Firefox Cache (Everything) seems to increase the likelihood of occurrence Not an issue using either AdBlock or ABP with respective EasyPrivacy/tracker options Noticed Firefox Fetch API keepalive support bug and direct use of Beacon during beforeunload succeeds