5 ms·

Safari Extensions JS

sctb 8y ago
We've updated the link from https://developer.apple.com/library/archive/documentation/Tools/Conceptual/SafariExtensionGuide/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/To... to this, which has more detail.
deleted 8y ago
[deleted]
bangonkeyboard 8y ago
The title was changed from "Apple Deprecates Safari Extensions in Safari 12 and macOS 10.14 Mojave". Using the original page title buries this news.
slowmovintarget 8y ago
"Safari Extensions" have been deprecated in favor of "Safari App Extensions". Not sure what the major differences are, but a quick site surf turned this up: https://developer.apple.com/documentation/safariservices/safari_app_extensions/converting_a_safari_extension_to_a_safari_app_extension https://developer.apple.com/documentation/safariservices/saf... hmm... "distributed through the app store".
- bangonkeyboard 8y ago
  Safari App Extensions are less capable in various ways than Safari Extensions, and many currently available and widely used JS extensions cannot be converted to them. As an example: uBlock Origin is a Safari Extension that simply could not function as an App Extension due to lack of APIs. It is present in the Safari Extensions Gallery, which is deprecated in Safari 12. However, the current version of uBlock Origin is broken. The only fix at this time is to install an older, developer-signed release from the homepage, which is physically impossible in Safari 12.
- floatingatoll 8y ago
  Safari Extensions appears to run as JavaScript code in an internal webpage instance that has unrestricted DOM access to your tabs and their content. Safari App Extensions appears to separate “in-page JS code” from “out-of-page Objective-C code” and introduces a sandbox that protects the in-page JS code from inspection or alteration by the out-of-page ObjC code. If I understand that correctly, then I feel this is a clear security win. It forces extensions to run in-process (with DOM access) only the code that they shipped at build time, with only a simple data structure channel available to communicate with their out-of-process component. I’m not sure what attacks on Safari using the old extension model led Apple to sandbox and secure this, but given the “App Store” hint, it seems likely that in-browser malware extensions exist and are being installed into Safari without user consent to spy on surfing and exfiltrate data for tracking. This would be a gold mine for a government-backed attacker, as the extensions are silent once installed and effectively invisible to most users. By introducing mandatory App Store review of all extensions, Apple could then analyze the in-page JavaScript code to ensure that it does not perform malicious actions. This explicitly protects against advertising and tracking attacks: any that escape initial analysis will be reported by users and security researchers. As we’ve seen on iOS, when someone finds an attack vector in one app, Apple can find and destroy all apps that exercise that vector. They would now be able to do the same with any malicious extensions that somehow survive the App Store review process. As an end-user, I’m very glad to see this. I sympathize with uBlock users, but ultimately I do not want unreviewed code in my browser. I am not qualified to evaluate whether an extension’s latest update is safe or malware-infected, when a single compromised release could be used to spy on that userbase. To those who would attack Apple for requiring extensions to go through review, keep in mind that Apple didn’t invent this review-required approach, and I believe they aren’t the first to market with it either. To those who believe that sandboxing and reviews are morally unacceptable, I respect your position but ultimately disagree with it. Protecting me from coin mining and tracking and credentials theft attacks is more important to me than having the freedom to easily run arbitrary code in extensions. It’s still possible, but it requires Xcode to be installed and operated regularly. I feel safer as a result of this change. Thank you, Apple.
ethansinjin 8y ago
In my opinion, this move makes a lot of sense. The Safari Extensions Gallery was laughably outdated, similar to the Dashboard Widgets Gallery: https://www.apple.com/downloads/dashboard/ https://www.apple.com/downloads/dashboard/ Switching to App Extensions brings Safari Extensions closer to how they behave on iOS.
bjornstar 8y ago
This makes me sad. It was relatively easy to maintain a cross-browser extension that supported Chrome, Firefox, Opera and Safari. All browsers roughly supported the same WebExtension like format and I could use the same code with relatively few browser specific paths. I don't understand the move towards requiring xcode instead of going full WebExtension support. I'm scared that I will be unable to support Safari users without a macbook in the future.

sctb 8y ago

We've updated the link from https://developer.apple.com/library/archive/documentation/Tools/Conceptual/SafariExtensionGuide/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/To... to this, which has more detail.

deleted 8y ago

[deleted]

bangonkeyboard 8y ago

The title was changed from "Apple Deprecates Safari Extensions in Safari 12 and macOS 10.14 Mojave". Using the original page title buries this news.

slowmovintarget 8y ago

"Safari Extensions" have been deprecated in favor of "Safari App Extensions". Not sure what the major differences are, but a quick site surf turned this up: https://developer.apple.com/documentation/safariservices/safari_app_extensions/converting_a_safari_extension_to_a_safari_app_extension https://developer.apple.com/documentation/safariservices/saf... hmm... "distributed through the app store".

bangonkeyboard 8y ago
Safari App Extensions are less capable in various ways than Safari Extensions, and many currently available and widely used JS extensions cannot be converted to them. As an example: uBlock Origin is a Safari Extension that simply could not function as an App Extension due to lack of APIs. It is present in the Safari Extensions Gallery, which is deprecated in Safari 12. However, the current version of uBlock Origin is broken. The only fix at this time is to install an older, developer-signed release from the homepage, which is physically impossible in Safari 12.
floatingatoll 8y ago
Safari Extensions appears to run as JavaScript code in an internal webpage instance that has unrestricted DOM access to your tabs and their content. Safari App Extensions appears to separate “in-page JS code” from “out-of-page Objective-C code” and introduces a sandbox that protects the in-page JS code from inspection or alteration by the out-of-page ObjC code. If I understand that correctly, then I feel this is a clear security win. It forces extensions to run in-process (with DOM access) only the code that they shipped at build time, with only a simple data structure channel available to communicate with their out-of-process component. I’m not sure what attacks on Safari using the old extension model led Apple to sandbox and secure this, but given the “App Store” hint, it seems likely that in-browser malware extensions exist and are being installed into Safari without user consent to spy on surfing and exfiltrate data for tracking. This would be a gold mine for a government-backed attacker, as the extensions are silent once installed and effectively invisible to most users. By introducing mandatory App Store review of all extensions, Apple could then analyze the in-page JavaScript code to ensure that it does not perform malicious actions. This explicitly protects against advertising and tracking attacks: any that escape initial analysis will be reported by users and security researchers. As we’ve seen on iOS, when someone finds an attack vector in one app, Apple can find and destroy all apps that exercise that vector. They would now be able to do the same with any malicious extensions that somehow survive the App Store review process. As an end-user, I’m very glad to see this. I sympathize with uBlock users, but ultimately I do not want unreviewed code in my browser. I am not qualified to evaluate whether an extension’s latest update is safe or malware-infected, when a single compromised release could be used to spy on that userbase. To those who would attack Apple for requiring extensions to go through review, keep in mind that Apple didn’t invent this review-required approach, and I believe they aren’t the first to market with it either. To those who believe that sandboxing and reviews are morally unacceptable, I respect your position but ultimately disagree with it. Protecting me from coin mining and tracking and credentials theft attacks is more important to me than having the freedom to easily run arbitrary code in extensions. It’s still possible, but it requires Xcode to be installed and operated regularly. I feel safer as a result of this change. Thank you, Apple.

ethansinjin 8y ago

In my opinion, this move makes a lot of sense. The Safari Extensions Gallery was laughably outdated, similar to the Dashboard Widgets Gallery: https://www.apple.com/downloads/dashboard/ https://www.apple.com/downloads/dashboard/ Switching to App Extensions brings Safari Extensions closer to how they behave on iOS.

bjornstar 8y ago

This makes me sad. It was relatively easy to maintain a cross-browser extension that supported Chrome, Firefox, Opera and Safari. All browsers roughly supported the same WebExtension like format and I could use the same code with relatively few browser specific paths. I don't understand the move towards requiring xcode instead of going full WebExtension support. I'm scared that I will be unable to support Safari users without a macbook in the future.