translate.google.com: nuisance

[superlex]

Prerequisites

• This is NOT a YouTube, Facebook or Twitch report.
• I read and understand the policy about what is a valid filter issue.
• I verified that this issue is not a duplicate. (Search here to find out.)
• I forced an update of my filter lists. (Click the "Purge all caches" button while holding the 'Shift' key, then click the "Update now" button.)
• I did not remove any of the default filter lists, or I have verified that the issue was not caused by removing any of the default lists.
• I did not enable additional filter lists, or I have verified that the issue still occurs without enabling additional filter lists.
• I do not have custom filters/rules, or I have verified that the issue still occurs without custom filters/rules.
• I am not using uBlock Origin (uBO) along with other content blocker extensions.
• I have verified that the web browser's built-in blocker or DNS blocking (standalone or through a VPN) is not causing the issue.
• I did not answer truthfully to ALL the above checkpoints.

URL(s) where the issue occurs.

https://translate.google.com/
https://consent.google.com/m?continue=https://translate.google.com/&gl=IT&m=0&pc=t&cm=2&hl=it&src=1

Description

When I go to https://translate.google.com/ I'm redirected to https://consent.google.com/ .

consent.google.com##+js(trusted-click-element, button[aria-label="Rifiuta tutto"])
lets me going back to https://translate.google.com/, but is there a way not to be redirected?

Other extensions used

none

Screenshot(s)

Screenshot(s)

Configuration

uBlock Origin: 1.53.0
Firefox: 119
filterset (summary):
 network: 252968
 cosmetic: 174673
 scriptlet: 43314
 html: 1289
listset (total-discarded, last-updated):
 removed:
  user-filters: null
 added:
  adguard-generic: 79402-7230, 42m
  adguard-spyware: 63282-16999, 42m
  block-lan: 54-0, 42m
  curben-phishing: 76626-30, 41m
  adguard-social: 22003-174, 41m
  adguard-cookies: 28019-48, 41m
  adguard-popup-overlays: 25083-1025, 41m
  adguard-mobile-app-banners: 4732-9, 41m
  adguard-other-annoyances: 13755-64, 41m
  adguard-widgets: 2340-1, 41m
  ublock-annoyances: 5731-509, 41m
  ublock-cookies-adguard: 492-0, 41m
 default:
  ublock-filters: 36124-410, 42m
  ublock-badware: 7434-5, 42m
  ublock-privacy: 657-0, 42m
  ublock-unbreak: 2181-0, 42m
  ublock-quick-fixes: 139-7, 42m
  easylist: 75150-807, 42m
  easyprivacy: 32856-730, 42m
  urlhaus-1: 10900-0, 41m
  plowe-0: 3720-1, 41m
  ITA-0: 9968-22, 41m
filterset (user): [array of 453 redacted]
userSettings: [none]
hiddenSettings:
 trustedListPrefixes: ublock- user-
supportStats:
 allReadyAfter: 630 ms (selfie)
 maxAssetCacheWait: 479 ms

[krystian3w]

Maybe needed is early bake cookies: gorhill/uBlock@82c59b4 for .google.com?

---

---

---

Also check in AG these:

$cookie,domain=consent.google.*|consent.youtube.com

if still works trick with disallow subdomain to read/write cookies.
uBlockOrigin/uBlock-issues#2926

[krystian3w]

I removed =examplecookie as is pointless due I meant more about blocking read enabled cookies like functions for webpage in browser settings (premissions).

[superlex]

@krystian3w
I didn't understand, sorry.
Are you proposing to remove some cookies?

[krystian3w]

In first paragraph I suggest checking trusted-set-cookie created in global .google.com domain path a long works , reload at translate.google.* (for regional may need write 190+ variations/combinations where consent.* is regionalised) or anybody detect race condition with little chance of being faster than Google script.

In the second paragraph, this can be considered as deleting cookies if any have been created (but for me it's more about prohibiting reading new and 'browser supports cookies' functions in this way – it may be that this was never available for AdGuard and you have to dig around in the website preferences from the browser settings). It may just happen that it will be too difficult to maintain the regex to save useful cookies from the consent.* subdomain.

[superlex]

In first paragraph I suggest checking trusted-set-cookie created in global .google.com domain path a long works , reload at translate.google.* (for regional may need write 190+ variations/combinations where consent.* is regionalised) or anybody detect race condition with little chance of being faster than Google script.

Yep, but we can (trusted-)set cookie for google.com / consent.google.com / translate.google.com, not for .google.com, right?

In the second paragraph, this can be considered as deleting cookies if any have been created (but for me it's more about prohibiting reading new and 'browser supports cookies' functions in this way – it may be that this was never available for AdGuard and you have to dig around in the website preferences from the browser settings). It may just happen that it will be too difficult to maintain the regex to save useful cookies from the consent.* subdomain.

Almost for .com, then everyone can adapt the rule for himself 😊

[krystian3w]

IMO the best will be allow these path:

translate.google.com##+js(trusted-set-cookie, foo, bar, domain, google.com, reload)

If someone can confirm unlock these by: gorhill/uBlock@82c59b4 (may enough is all uses where these path with dot was added for lastest stable/beta).

[krystian3w]

I guessing only , domain, google.com can create cookies in .google.com path - Unfortunately, I can only rely on the demo from a month ago that gorhill wrote for the submitter.

[superlex]

But .google.com should be the domain, not the path..

[krystian3w]

Only my point is that in the .google.com space for subdomains it may be easier to read the status than checking for the main domain (without the dot) or the version with www..

The /\.google\.com/##+js( as such is not likely to make sense.

[superlex]

You're right.

[krystian3w]

It just seems to me, unfortunately, you can see that no one is combining whether it can be embraced by some (trusted-)set-cookie/localStorage.

It is possible that we have to spend our free time ourselves to analyze what storage or cookies created early enough deactivate the redirection (it will rather come out that these are server-side queries and only the creation of cookies/storage is left for us).

[superlex]

We will see AdGuard solution:

AdguardTeam/Scriptlets#389

[krystian3w]

Test these too: #23611

google.*##^responseheader(set-cookie)    
google.*##+js(cookie-remover, CONSENT)