Open contribucious opened 1 year ago
1. Possibly use a dedicated parameter instead.
💡 Or … a new "comma-separated" advancedOptions
final parameter (code and wiki), which can include in it as={plaintext|base64}
or maybe encoding={none|base64}
— the former in the sense of "to store value as …", of course.
↪️ Probably both more flexible (especially to add support for the described variant in addition) and more future-proof. ☺️
But we can convert a scring to BASE64 using tools.
Of course. Even web tools, easily. But the goal is to have self-explanatory rules for these cases (that is, no need to have an additional comment describing the cryptic content to readers).
↬ It's mainly for adding clarity and transparency to public filters (i.e. those read by people), more so than for local filters. 🙂
Issue clarified just now (goal better explained). ✔️
Steps to reproduce
Goal
Replacing this rule (comment included): #ᴄʀʏᴘᴛɪᴄ
By this one (self-explanatory for readers): #ᴛʀᴀɴꜱᴘᴀʀᴇɴᴛ
_:writinghand: Remarks
Possibly use a dedicated parameter instead.
~~Consider in addition a variant that does not use
encodeURIComponent
for storing base64 value, for some websites reading the string directly inatob
.~~- That is, the stored value will therefore include==
instead of%3D%3D
at the end.↪️ Variant not anymore required. All situations will be handled correctly if this commit is finally merged:
get rid of encodeURIComponent for trusted-set-cookie-* scriptlets
. As raw/pure base64 value generated by AdGuard will always be readable by the website: whether the latter uses for reading atob, atob+decodeURIComponent, etc.Should also apply to:
trusted-set-cookie-reload
;trusted-set-local-storage-item
too.Hi and thanks in advance! :v: