Avast aquired "i-dont-care-about-cookies"

Thanks, corrected.

 

no BS please.
a) its not needed any longer -> XPI file -> signed

b) it undermines firefox security, any extension can install any crap or trojan extension whatever.

c) developer edition can do this with ease, but that edition is by purpose for people developing (also extensions).

 

agreed. i don't see why i'd want to install one more extension in fox only to enlarge the attack surface, while i can simply use dandelion sprout's annoyances list with ubo.

 

This one?
Is it really effective vs cookies warnings?

 

You can check the entire source, if you don't trust it.

 

i am with you but thats truly not topic here

the ZIP do NOT contain a folder "meta-inf" which means "signed", the XPI file do.

signing means it has run though a verification routine. the small time for signing means that is has been signed for private use or distribution elsewhere (i do myself for me). signing and releasing on AMO means a verification for few days.

changes between fork and releases can be compared with builds from the list
https://addons.mozilla.org/de/firefox/addon/i-dont-care-about-cookies/versions/

the current fork contains some older code, but current setups.
it is not proper formed for firefox.

 

i dont need to care about this, my statement concerns pointless disabling of signing verification, which is dangerous for native minds. you dont have any control what questionable extensions could install or not, you wont see any hint that malware has overtaken your browser. and there still exist such extensions.

 

He plans to go through the verification process.
We'll have to wait and see.
https://github.com/OhMyGuus/I-Dont-Care-About-Cookies/issues/7

 

yes, that is the one. i have yet to encounter a site where it fails to block them crappy cookie warnings.

 

he already did with the latest release from today

i wont use it - if i would be willing to do so. its code is not proper for firefox and it may fail. fork author is no expert.

 

Could you point out the flaw(s)?
Maybe you should inform him about that, so that he can learn from it.
(I would do it myself, if I were a coder)

Collaboration is the strength of open source.

 

manifest points out to crx which is chrome and some other minor nifties which should be corrected
"context-menu.js" do not cover firefox at all, compare with 3.4.3 from AMO.

at least you will find all versions on AMO, not in chrome store. manifest is exchangeable to fit each browser.

 

Reported.

 

also here
https://github.com/OhMyGuus/I-Dont-Care-About-Cookies/issues/12

currently i wont exchange extension, but a closer look to source at update is recommended. the domain may be killed in the near future then the fork wont get any updates if the source is scrambled like malwarebytes did with the overtaken hosts-file.net data.

 

Thanks, I managed to make it work, but I don't understand why it's not a standard filter. The reason why I always continued to use the standalone IDCAC extension is because I had the feeling that it worked better.

Cool, will check it out once it's on the Chrome Web Store.

 

It has indeed more functionality.

 

I'm not sure what you mean with this, but it was indeed easy to toggle it on/off. But for me it felt like it was blocking more of these stupid cookie approval pop ups, but perhaps it was my imagination.

 

The source is not on https://www.i-dont-care-about-cookies.eu/.
Instead the fork gets it straight from the extension files.

 

You're not imagining things; it is true.

 

But the thing is, how is this possible if uBlock is using the exact same rules? And the EasyList Cookie list also seems to be less effective.

 

The extension has advanced functions that cannot be applied by the more simple adblock rules in these lists.

 

OK thanks, I wasn't aware of that. So perhaps I will still need to use the new standalone extension in the future. Too bad that browsers don't implement this as a standard feature and even more worse that these dumb cookie approval dialogs exist in the first place, how dumb are people planning to get, whoever came up with this idea should be in jail!

 

the list are currently same as in the original (hash compare). but what about the future? what about stealing lists from original? this may be called reverse enginering. or if the new owner encrypts the list? currently it looks like javascript where obfuscated code is not allowed on AMO.

too many if then. i would recommend to observe and sit back and wait while using that extension. rules on AMO are strikt, no obfuscation, no tracking and more. but this could be obsolete for the chrome store.

 

Obfuscation is not allowed in Chrome extensions either.
However, I would not be surprised if Avast demands the original author to include some tracking...
(Chrome Store's policy states that the user must be informed)

When the fork maintainer runs diffs to spot changes between versions, he will notice and remove that code.

There is however more work to be done, since the original extension appears to have mediocre code quality, according to someone here...

 

The problem is that uBlock Origin can't fully replicate the abilities of the IDCAC addon.

Some websites need actual "clicks" to accept the cookie, and uBlock Origin can't do that... yet.