Thrawn wrote:I really think that Giorgio should take up the trademark issue here. Maybe taking out the fakes would spur Google to enable the real thing. Cease and desist letter?
Agree 100%. GµårÐïåñ and I have espoused that view several times. But it's Giorgio's call.
(Can't stop them from creating add-ons, but can stop them from infringing on a brand, trademark, and reputation.)
[...]
2nd if temporaly allowed top level domain, sometimes some 3rd party script also pull in simultaneously.
Noscript obviously does not have this problem.
Chrome + NOTscript also does not have this behaviour.
Latest Scriptno with webrequest api got this behaviour.
It sounds really bad: ScriptNo for Chrome can't protect you when you really need it most, i.e. when visiting an unknown website for the first time.
Regarding NotScripts, while it's not affected by the same bug, it's useless as well: try to visit this page, which exposes NotScripts for Chrome's inability to block inline scripts.
Yet another proof that the current "NoScript-like" extensions for Chrome offer their users a very dangerous false sense of security.
https://chrome.google.com/webstore/deta ... gaag?hl=en seems to block your noscripts test page as well as the flashblock test page. Does this mean Chrome is finally mature enough that you could make an actual NoScript extension for it? I ask as the lack of a NoScript alternative is the main thing keeping me from moving completely over to chrome.
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
This extension seems to be better than the existing solutions, I will give you that. However, that being said, it breaks Giorgio's example because he used a random extension chrome ID to try and make the POC work and since this blocks that, it blocks the POC. But if he were to write a method that would roll that ID on each load, it would beat you each time until you blocked it. I tested it and Giorgio's POC defeated the extension on first run, it was only on reload/refresh that it wasn't and Giorgio's POC showed the message that it was blocked. So take this "security" with a grain of salt, since NS in its true form, wouldn't be defeated like this, even once which is all a bad guy needs to inflict damage, one chance to get in.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~ ________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.1.0.0 Safari/537.36
ScriptDefender is another one that definitely seems to have *improved* over past attempts, but I still doubt the efficacy at this point. Anyone here had a look at it? Obviously it still lacks critical features of NoScript like XSS filtering, but I'd be curious to see if it falls flat on script blocking as well.
Hey my friend, been a long time. Thanks for the heads up, will give it a look over and see. BTW, the previous extension (HTTP Switchboard) has another fatal flaw, the choices are not persistent between sessions (meaning restarting the browser) - that's a mega giant failure and limitation. Just FYI.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~ ________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.1.0.0 Safari/537.36
I just gave that a go and it has a HORRIBLE interface, extreme lack of intuitive controls and contradictory behavior as a result. I much rather the interface of the previous one (HTTPSB) had it been able to persistently remember the choices. Not to the mention the informative display of items in the visual grid is very very nice. I have been working with the developer to improve their product short of selling out NS in the process. I am saving myself for Giorgio to get the ball rolling
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~ ________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.1.0.0 Safari/537.36
GµårÐïåñ wrote: BTW, the previous extension (HTTP Switchboard) has another fatal flaw, the choices are not persistent between sessions (meaning restarting the browser) - that's a mega giant failure and limitation.
That's a mistake I also made at the beginning. If you want to make your choices permament you have to click the corresponding padlock.
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.114 Safari/537.36
@tlu, ok I will give it another go and keep that in mind, thank you my friend. I so far prefer HTTPsb over the others incarnations much better as the resource display in the grid is fantastic. I will give her another go around, thank you.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~ ________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.1.0.0 Safari/537.36
Sigh. The spam filter refuses to ever let me post. Not going to bother rewriting all of that to figure out which bit it was anyways, I lost my Hungry Man pass.
qwerty017 wrote:https://chrome.google.com/webstore/deta ... gaag?hl=en seems to block your noscripts test page as well as the flashblock test page. Does this mean Chrome is finally mature enough that you could make an actual NoScript extension for it? I ask as the lack of a NoScript alternative is the main thing keeping me from moving completely over to chrome.
So Giorgio, as per this post above, any plans to release something for Chrome?
FF will prolly always be my main browser, but it'd be nice to see NoScript in Chrome too.
It seems the only "close but no cigar" alternatives are: HTTP Switchboard & NotScripts.
Thank-you.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
qwerty017 wrote:https://chrome.google.com/webstore/deta ... gaag?hl=en seems to block your noscripts test page as well as the flashblock test page. Does this mean Chrome is finally mature enough that you could make an actual NoScript extension for it?
WebKit-based browsers, including Chrome and Safari, run data URLs in a unique origin, which means they don't have access to cookies or other resources belonging to their parent. Not all browsers treat them that way, but that's what we do. [Ref. https://code.google.com/p/chromium/issu ... =142635#c7]
I believe though the chromium team is working toward better standardizing their implementation (issue 335489: "CSP 1.1: Get Blink up to spec."), i.e. data uris inherit the context of the parent, which would of course address the above proof of concept.
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/33.0.1750.152 Chrome/33.0.1750.152 Safari/537.36