Comments on: Before you ask… (No NoScript on Safari)

By: Giorgio

Giorgio — Tue, 15 Jun 2010 16:49:31 +0000

@Mark:
Unfortunately I don’t have the time to go deep in a discussion about it, but let’s just say the speed argument is gonna be an arms race for a long time if not forever (for instance, Firefox 4 is gonna have a mixed method/tracing JIT which aims to be at least on par with V8 and Nitro JIT).
On the other hand Firefox’s extensibility will be vastly superior for the foreseeable future (unless Mozilla decides to kill it outright in favor of Jetpacks) because Firefox exposes almost everything of its internals as a full-fledged cross-platform development framework, while Chrome/Safari extensions offer a very limited and shielded subset to extensions developers.

@Spade:
I did check the Safari extension documentation: it’s not my fault if ad-blocking features were buried deep inside a completely unrelated “Messages and Proxies” chapter!
Nevertheless, a NoScript porting is still impossible because Safari’s API can’t support it: this is obviously the main message of this post and therefore it doesn’t need to be revised. The only thing I’ll concede is that effective ad-blocking is actually possible, but NoScript is a completely different beast.

By: Spade

Spade — Mon, 14 Jun 2010 05:56:08 +0000

Pretty quick "no" answer for someone who didn’t even take the time to read the Safari Extension documentation. Care to revise your hasty initial answer?

By: Mark

Mark — Sat, 12 Jun 2010 00:57:40 +0000

Hello Giorgio,

As a longtime user of both Firefox & NoScript, I am curious as to the current situation of this "browser rivalry," more specifically, between Google’s Chrome and Mozilla’s Firefox. Would it be possible to share with us a few reasons as to why users of Firefox should not make "the switch" and not completely abandon it like many others have done?

Chrome, to me, seems very tempting. Its sleek and streamlined UI makes browsing much simpler, not to mention of course the main reason why so many have begun to use it: it’s speed. Firefox, even its latest trunk builds, have been lacking in the latest speed tests, including JavaScript and V8. Why should users stick to Firefox, and not use Chrome?

Thank you for your time,
Mark

By: Giorgio

Giorgio — Fri, 11 Jun 2010 22:21:07 +0000

@Dave Hyatt:
I’m not sure whether “beforeload” is the right mechanism to prevent script execution. Opera has some dedicated events available to privileged scripts, see http://www.opera.com/docs/userjs/specs/#evlistener
At any rate, “inline scripts/css” should include event handlers and style attributes.

I’m not sure what to suggest to intercept top-level document loads at the outermost level, since there’s no corresponding DOM element to fire the events on. Is this a requirement?

What would actually be needed is a general network interception framework, to implement things like ABE

By: Dave Hyatt

Dave Hyatt — Fri, 11 Jun 2010 18:33:39 +0000

I filed https://bugs.webkit.org/show_bug.cgi?id=40484 to cover beforeload needing to work on inline scripts and stylesheets. Should be easy to add.

There is no way to intercept top-level document loads, although you can intercept loads in frames/iframes by putting onbeforeload on the frame/iframe itself. I’m not sure what to suggest to intercept top-level document loads at the outermost level, since there’s no corresponding DOM element to fire the events on. Is this a requirement?

The event target is the DOM element triggering the load to be blocked yes. The event also has a url field that contains the URL being requested.

At the moment there is no way to make IP-based decisions. It’s possible we could add an IP field to the beforeload event, as long as there are no security implications from exposing that information to the Web page.

By: Giorgio

Giorgio — Fri, 11 Jun 2010 06:54:58 +0000

@Dave Hyatt:
That’s interesting, thanks.
Is there also a way to block inline scripts for a certain window/frame?
And can “beforeload” be used also to intercept top-level document loads?
Is the event target the DOM element triggering (or related to) the load to be blocked?
Is there any way to perform asynchronous DNS resolution (or to get DNS info from the browser’s DNS cache) to make IP-based decisions?

By: Dave Hyatt

Dave Hyatt — Fri, 11 Jun 2010 02:32:29 +0000

Specifically see the "Blocking Unwanted Content" section:

http://developer.apple.com/safari/library/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW1

By: Dave Hyatt

Dave Hyatt — Fri, 11 Jun 2010 02:21:05 +0000

We added the beforeload event specifically to enable selective blocking of resource loading. If this event is insufficient, let us know what enhancements you would require in order to get the functionality you need.

Thanks.

By: Giorgio

Giorgio — Wed, 09 Jun 2010 10:08:22 +0000

@Petri Sirkkala:
I’ve got no idea whether Saft is compatible with Safari 5 or not (if I understand correctly how it works, I guess an update is very likely to be needed).
What I can tell for sure is that Saft is not a Safari extension, no matter how its developers label it, simply because Safari did not support extensions before this week.
Saft is implemented as an Input Manager plugin or a launcher wrapping Safari, but it definitely doesn’t run inside Safari nor uses Safari’s extensions API.

By: Petri Sirkkala

Petri Sirkkala — Wed, 09 Jun 2010 09:18:47 +0000

Do you mean that Saft is no longer available for Safari 5?
- http://haoli.dnsalias.com/Saft/