InformAction Forums

HSTS simply tells the client that this site should from now on for a certain time be only accessible through encrypted protocols.

Right, the idea is to prevent MITM attacks where you 'fake' the SSL. That's what SSL Strip does. HSTS doesn't allow the HTTP at all so the connection would either fail or use HTTPS.

But I thought this had to be both implemented by the server and the browser - so I'm unclear as to what NoScript does with HSTS.

Regardless I've updated the NoScript area of the guide to elaborate on the protections gained even with Scripts Globally Enabled.

NoScript had the user-customisable HTTPS enforcement feature for years and then provided HSTS support to Firefox 3.6 and earlier (native support landed in Firefox 4).

The server needs to be changed in such a way that is supports HTTPS on every page on this particular domain (and does not do dumb things like redirecting to HTTP on some pages) and that it informs the user agent that it would like to have this enforcement.

Gotcha, thanks.

is noscript out for google chrome Know ?

heavyweight wrote:is noscript out for google chrome Know ?

If you search the forum, it has been discussed, but the simple answer, NO, not yet.

I think one of the current issues is the asynchronous WebRequest API being the only current option. With the declarative WebRequestAPI there's a synchronous option.

Just an FYI as this API is new.

https://code.google.com/chrome/extensio ... quest.html

We've been aware of this and other API since v17 and 19 beta and that's why Giorgio has been trying to work on a port, it will be available when its available and when Google's crappy APIs catch up, so everyone just drop it and wait. Its not like if we had it we would keep it a secret, its getting old constantly asking for it.

It's a separate API from the WebRequest API, which is why I ask.

One of the issues with porting NoScript would be that you need Synchronous events. Chrome's extension system largely on supports asynchronous events for performance reasons. The WebRequest API introduced in Chrome 17 is asynchronous, meaning you can't use it to reliably block anything (see ScriptNo) and you'd have to rely on caching (see NotScripts and ScriptNo) to actually do it (ie: reload the page and it's blocked.) The new API, which I believe is currently experimental and only in Chrome 22 is synchronous meaning that everything stops until that extension says to continue.

Hence why I ask if this makes enough difference - new API = new capabilities.

But the declarative API doesn't provide enough apparently. Though I don't think it hurts to ask lol

Yes we know, Google's API are a mess and inadequate to say the least but we are giving it our best effort, we'll see if an equally reliable tools can be developed or not, if yes, good and we'll release it, if not, then we'll go back to the way it has been, which is wait and see when they remove their heads from their arse Our policy has been to do it right or not at all, we are not going the route of those knock off tools that claim to do it while clearly have been shown to fail miserably repeatedly.

any update on this yet ? i i'm waiting till the day comes just thought i would check in.

heavyweight wrote:any update on this yet ? i i'm waiting till the day comes just thought i would check in.

I'm sure there will be a major announcement when ready, but you also may wish to follow Giorgio's blog, http://hackademix.net/
on which he often gives advance notice, or first notice, of new projects, ideas, etc.

As Tom said, its being worked on when time and resources permit, if and/or when it becomes available, we will let everyone know. Its not like we build things to keep them a secret.

you are really genius.. dont waste time..just execute first the beta testing/unofficial NoScript for Google chrome..
trust me it will be >> in beta just fix it one by one ,, no need wait lah...from>>malaysian fan

(Merged with topic "NoScript for Google Chrome", and removed one phrase that could conceivably be taken as spamming for a particular musician or band, or one particular recording by that artist -- Tom T.)

Giorgio Maone wrote:May I ask you what, exactly, makes Chrome a better choice than Firefox for you?

If this question is still of interest -

The main reason for me would be its Sandboxed processes http://www.google.com/googlebooks/chrome/small_26.html

Speed and stability are factors ( using firefox with the usual barrage of security and privacy plugins makes it feel even worse than its best which cannot compare to chrome )

I used to love FireFox, but no more. I am no google fan either, preferring what I consider a better fork of the Chromium project .. Comodo's Dragon