[1] https://github.com/gorhill/uBlock [2] https://chrome.google.com/webstore/detail/ublock-origin/cjpa...
[1] https://github.com/gorhill/uBlock [2] https://chrome.google.com/webstore/detail/ublock-origin/cjpa...
I don't know what it does, but I bet it's not good.
To think that uBlock Origin itself was suspended from the store back in April because its icon resembled too much that of the other uBlock.[2]
[1] https://productforums.google.com/forum/#!topic/websearch/IFl...
Just so everyone is aware, you can use any email address as your company email address on the google play store without verification. This means when looking at an app, you see the email is support@legitcompany.com and think it's from them, but it's not.
Question for HN: back in the Napster days, were there likewise Napster clones ("napster"?) that purported to allow peer to peer music downloads but in fact had malware properties?
Search for something like "flash update" on non-Google/DDG search engines and look at the top ads if you want the general feel.
Both uBlock Origin and uBlock have similar code bases because they were "born" from the original uBlock (now called uBlock Origin).
Edit: not sure why I'm getting downvoted. Apparently this is an issue, as gorhill mentions, when selecting the leaky IP option. They should make the implications much clearer.
I agree, I opened an issue to address this: https://github.com/gorhill/uBlock/issues/773
Love the app, by the way. It's the single reason I have Firefox on my Android device instead of Chrome.
Do you happen to know WHY the leak breaks Hangouts? I'm assuming Hangouts now leverages the webRTC for connection--that's fine. But I was under the impression that the local IP leak was an unintended side-effect of webRTC, not a 'required component', if you will. Does having that checkbox on effectively break ALL webRTC components, or is it something specific with Hangouts' implementation?
Same here. My understanding is that the breakage of Hangout is unintended, as the original Chromium issue for the IP address leakage states[1]:
> This change causes WebRTC traffic to be forced through the same path that HTTP traffic would, i.e. the traffic follows the default route to the destination site.
In other words the purpose of the setting is strictly to prevent IP address leakage, not to prevent WebRTC from working.
[1] https://code.google.com/p/chromium/issues/detail?id=333752#c...
I tried FF on my phone, simply for uBlock, but it was just too sluggish to actually use.
> Can't recommend it more.
"I'm physically incapable of recommending it more often/strongly because I'm using my full strength to recommend it already"
> Can't recommend it enough
"I'm physically incapable of recommending it as frequently/strongly as it deserves because I have exhausted my strength in so doing"
would be positive or negative?
edit: Did you have default deny third party req?
Sounds annoying, though.