Well, already a dozen requests today only.

Unfortunately, Safari 5’s support for extensions looks even more limited than Chrome’s.

So, no NoScript (nor FlashGot, nor any half decent ad blocker*, for the matter) as a Safari extension for the foreseeable future…

* Looks like ad blockers are actually possible, see Dave Hyatt’s comment below. Documentation of this feature is deeply buried inside a completely unrelated “Messages and Proxies” chapter, but whatever. NoScript is a very different beast though, and infrastructure to port just does not exist (yet?) :(

15 Responses to “Before you ask… (No NoScript on Safari)”

  1. #1 Dan says:

    Thankfully Chrome includes built-in what I like to describe as "NoScript Lite"-like functionality. Unfortunately it is not easy to whitelist an entire domain with all subdomains at once, plus the whitelist applies to any resources as long as the top url matches the whitelist, even off-site frames are allowed… hopefully Chrome will get the necessary APIs to get a NoScript-like extension.

  2. #2 Tiago Sá says:

    I think people don’t really grasp how immensely powerful Firefox add-ons can be. Chrome’s (and now Safari’s) add-ons are an outright joke in comparison. It’s phenomenal that their there, a great victory for the web, most definitely, but they can’t really compare.

    Basically, it’s as you say (or hint). Chrome and Safari won’t have advanced extensions in the foreseeable future. But I think it’s down to Google’s (from Chrome’s side, of course) stubbornness. NoScript is going to be ported for (to, or with or whatever) Jetpack, right? I’m hoping the available libraries will let us have out of process, seamlessly installing no-script :)

  3. #3 dafi says:

    Hi Giorgio,

    people continues to ask to port extensions on Chrome and now on Safari without understanding these browsers support extensions mainly for marketing reasons.

  4. #4 NZer says:

    I agree with the person above about Firefox’s extensions being very powerful however Chrome’s extension system will be far more powerful than Safari’s and will no doubt have the capability to support No Script and most other Firefox add ons in the future. Their are already around half a dozen experimental APIs at the moment and many more to come. Just look at the developer wishlist below.

    http://dev.chromium.org/developers/design-documents/extensions/apiwishlist

  5. #5 Mook says:

    NZer: The main reason Firefox extensions are so powerful is because API wishlists like that don’t come into play at all - you get to use the exact same things the application developers have to use, instead of being walled in to things they think "should" be exposed. It’s because of this that innovative extensions can exist - you’re not artificially limited to a set of things people who don’t build extensions have to set out. Any APIs you want would be things the main application developers don’t have anywhere. This also means it’s much easier to transition to writing patches for the host application (for example, to add the APIs you need).

    From this one should be able to derive my opinions on Jetpack as well ;)

  6. #6 Petri Sirkkala says:

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

  7. #7 Giorgio says:

    @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.

  8. #8 Dave Hyatt says:

    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.

  9. #9 Dave Hyatt says:

    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

  10. #10 Giorgio says:

    @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?

  11. #11 Dave Hyatt says:

    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.

  12. #12 Giorgio says:

    @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

  13. #13 Mark says:

    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

  14. #14 Spade says:

    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?

  15. #15 Giorgio says:

    @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.

Bad Behavior has blocked 6611 access attempts in the last 7 days.