Closed filbo closed 4 years ago
Apple said:
New submissions to the Safari Extensions Gallery will be accepted until the end of 2018.
If it's going to be deprecated/eol'd why on earth would they want to do this? I literally just documented this installation process in the last week.
Apple's official 'we're getting out of the browser business, just shoot us now' announcement.
If only this were a real quotation. ;)
Can authors of userscripts rely on any hope of Tampermonkey bridging over this ridiculous gap and continuing to work on Safari 13?
I'll port Tampermonkey to this new technology if it's doable with reasonable effort. My second child was born these days, therefore it might take a little bit.
I'm not a MacOS user, I use it only to debug Tampermonkey. Does anyone know or can estimate when Safari 13 will be released?
Does anyone know or can estimate when Safari 13 will be released?
I've never looked into this as that platform is my least utilized, and liked, however they do make announcements at https://developer.apple.com/news/ from a quick search.
Your question is 'when will 13 be the normal consumer browser', i.e. 'when will current Tampermonkey fully stop working for random Mac users?' -- right?
Not 'when can I get ahold of Safari 13 to test this crap?', which is what I started to answer as 'when can I get ahold of any version of Safari which would display this fecure?'
Along those lines I had written the following (before realizing I was answering the wrong question):
====
Judging by https://twitter.com/digital_saas/status/1003910017953640448 -- Mac OS 'Mojave' is out in beta and apparently (as one might expect) comes with the beta of the next Safari, i.e. 12. If you have a virtualization environment on your Mac, you could install the beta in that.
There's also https://developer.apple.com/safari/download/, which currently claims to be offering release '57' (?!?), posted May 28th, which might be new enough. I don't have a Mac to try it on. (Hmm, I downloaded and busted it apart and it appears to be build '13606.1.18' which the Internet says is only Safari 11.2. Also, the associated Release Notes haven't even mentioned Extensions since release 44, and 'App Extension' isn't mentioned at all. And I am now angry at Apple for having a beta series whose version numbers are completely unrelated to the release product's version numbers, and no dates in the beta log!)
====
Returning to your real question: careful parsing of https://wikipedia.org/wiki/Safari_version_history shows that Safari N.0 has been released along with Mac OS 10.(N+2).0, for Safari versions 6 through 11. Therefore Safari 13 will likely accompany Mac OS 10.15. Mac OS since 11.7 has been released on a fairly regular 12-month cycle, so we can predict official release of Mac OS 10.15 + Safari 13 around 2019-09-01, ~15 months from today.
@derjanb Developer signed .safariextz extensions are "unsupported", and any such extensions will be removed and cannot be reenabled when Mojave launches in September. Safari Extension Gallery Extensions are "supported", but get disabled by default, and support for them will likely be removed with macOS 10.15 next year.
Here's what the RN for Beta 1 says:
Returning to your real question: careful parsing of https://wikipedia.org/wiki/Safari_version_history shows that Safari N.0 has been released along with Mac OS 10.(N+2).0, for Safari versions 6 through 11. Therefore Safari 13 will likely accompany Mac OS 10.15. Mac OS since 11.7 has been released on a fairly regular 12-month cycle, so we can predict official release of Mac OS 10.15 + Safari 13 around 2019-09-01, ~15 months from today.
@filbo Thanks. This was exactly what I was looking for. :) Given this timeframe, I'm confident to port Tampermonkey (if technically possible).
Developer signed .safariextz extensions are "unsupported",
@yashendra2797 I do have a official developer certificate from Apple (99€ per year), but my request to be added to the app store was denied some years ago. So yes it's signed by me, but by using a certificate from Apple. From what I've read the difference is that developer self-signed extensions are not updated automatically while developer(-via-apple-certificate)-signed extensions are updated. So at least at this point there is a difference which makes me hope that "developer-signed .safariextz extensions" means the self-signed unofficial ones.
So at least at this point there is a difference which makes me hope that "developer-signed .safariextz extensions" means the self-signed unofficial ones.
Yeah but Apple is trying to make the MAS the only way to have an extension work on Safari, and for every extension wants you to make a pseudo app.
That reminds me, couldn't you theoretically use a cert to make an app and use that to push extensions? You can disable Gatekeeper in macOS, and if its anything like installing an app, you could maybe use that to push an extension, unless Apple simply closes down Safari from any and all non MAS shenanigans.
@filbo
I don't have a Mac to try it on.
macOS 10.13.5 as of yesterday Your Safari Technology Preview download link yields this UA externally after installation:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.2 Safari/605.1.15
Right clicking and opening with Safari Technology Preview... yields installation success and also script incercept/injection for runtime occurs as expected.
Ping me with a mention if a test is needed. I usually keep that system up to date (whenever I connect to it) but rarely use it.
@Martii the 'Safari Technology Preview' is pre-11.2, while the version people are getting in their Mac OS Mojave betas is pre-12. As far as any of their doc seems to indicate (though actually they're just completely unclear about it), these new-degraded 'Safari App Extension' things are new with 12. So if you want to provide @derjanb with a test platform for that, you would need to upgrade your whole OS on that test machine to pre-Mojave; or install that in a VM. (Unlike other x86 OSes, Mac OS insists that it may only be installed into a VM on official Apple hardware; while I'm sure there are software workarounds for whatever copy-protection-ish method they use to enforce this, the most straightforward route to having a Mac OS VM is to do it on a Mac.)
I think I got that @derjanb does have his own Mac. Probably the best route (in his copious spare time...) is for him to install a Mojave VM on his own machine. Not upgrade the whole OS, because then he'd lose the ability to easily support the majority of Tampermonkey-on-Safari users who will be on the current official release version.
@filbo
or install that in a VM.
Haven't had much luck with that in vbox or even getting a download medium that doesn't crap out (Apple has a bad history of deleting their installation files much like Adobe)... but that's usually under Linux. Not sure the machine is good enough for a VM though... and never again will I waste thousands of dollars on a machine that can be outperformed for much less. :) So when it dies it'll die... or more likely be eol'd like they did my PPC from the Intel switch.
need to upgrade your whole OS on that test machine
Test bed is definitely not for that. Even though it's rarely used I usually need release status instead of beta/alpha (or whatever apple is calling it these days... I'm old school).
Thanks for the intel.
@derjanb The wording is: 'Safari no longer supports developer-signed .safariextz packaged legacy Safari Extensions. At first launch of Safari on macOS 10.14, if users have any legacy developer-signed extensions installed, they will be notified such extensions are no longer supported. These extensions cannot be reenabled.' -- I would take that to mean that your extension will stop working; will only work if you can get them to accept it into their 'store' (Safari Extensions Gallery).
They should accept it, as otherwise Safari will completely lack any ability to run the large pool of userscripts extant in the world (as there is no official 'Gallery' port of Violentmonkey or Greasemonkey, nor do those seem likely); and this is a large impairment for a browser. However, they might take that as a feature, i.e. keeping riff-raff external code out of their walled garden.
And their statement is that while the technology (.safariextz) will keep working through the Safari 12 / Mac OS 10.14 timeframe, the delivery mechanism you're using (developer-signed .safariextz not hosted in the 'Gallery') is completely disabled ('cannot be reenabled') starting with Safari 12.
Either way, it seems clear you're going to need to get into the 'Gallery' -- probably within 3 months (with an Apple-corporate-signed .safariextz) if Safari 12 users are going to have a userscript runner at release time, and definitely within 15 months (with a 'Safari App Extension') for Safari 13 users.
Bleah.
They should accept it, as otherwise Safari will completely lack any ability to run the large pool of userscripts extant in the world (as there is no official 'Gallery' port of Violentmonkey or Greasemonkey, nor do those seem likely); and this is a large impairment for a browser. However, they might take that as a feature, i.e. keeping riff-raff external code out of their walled garden.
This is what I got 3 years ago when I tried to submit Tampermonkey to the Safari Extensions Gallery:
Honestly, I'm not sure whether they would accept Tampermonkey this time...
What's ironic is other browsers can run extensions on macOS... so this is two-faced for fact. Reminds me of the litigation against IE and integration into the OS... perhaps it's time to create another one for apple. And people wonder why apple products are my least favorite... bloated and beyond egocentric imho.
Anyhow... they should elaborate more on why instead of a generic scripted response. You will never know until you try.
@derjanb There's at least one extension relatively newly on the Gallery at the moment which has a feature for injecting custom scripts. I won't name it in case it wasn't meant to be approved since it's not the main goal of the extension, but also isn't a hidden feature so but it might indicate they've changed their stance. Also thanks for the link to my blog post, that solution works perfectly for me in the meantime and by the number of views I'm getting on that post it seems like other people too!
It is obvious that you cannot 'address' the 'issue' per se; you cannot remove the ability to run 3rd party scripts from a tool whose entire and only purpose is to run 3rd party scripts.
The alternative approach is to present that this is a capability which is widely desired and used in the real world. Include whatever download statistics you have for Tampermonkey-on-Safari (which is entirely through your own properties, since they haven't put it in the 'Gallery'); and perhaps similar statistics re: Chrome, Opera, Edge, even Firefox -- giving both broken out and combined stats for 'store' vs. your own site, since in some of those cases it is downloadable from both.
Including stats for multiple browsers shows broad as well as deep interest. I think >10M downloads and 4.69 stars (right now) on Chrome Store should be at least a little persuasive...
In resubmitting, I would recommend referencing both of these Wikipedia pages: Userscript (on the general concept) and Wikipedia:User_scripts/List (as an exemplar of what they're for, why people want and use them).
HOWEVER, before doing that, someone(*) ought to update the Wikipedia pages Userscript and Userscript_manager to mention Tampermonkey & Violentmonkey, and de-emphasize Scriptish (which appears to be effectively defunct). The wiki pages are something like 3-5 years stale. (Do mention Violentmonkey in the wikipedia page, as it is another currently viable solution and again demonstrates broad interest in such capabilities.) (* Not me, I am not a Wikipedia editor...)
@grgarside, your linked 'how to install safariextz-like-Tampermonkey in new degraded Safari' page is currently in flux due to (1) not starting automatically, (2) user reporting settings being lost on restart. Would you mind posting a comment here when these issues are resolved? In the end I'll be wanting to refer Social Fixer users to that as a temporary pinprick through the veil of stupidity being drawn over Safari...
@filbo I've updated the article with what I can, ⑴ an AppleScript for automatically running the extension and ⑵ a way to avoid the settings being lost by locking the preferences file. I will continue looking for improvements to the process — if I end up having to write a completely separate app for managing these kinds of extensions then so be it! Let me know your thoughts
I think >10M downloads and 4.69 stars (right now) on Chrome Store should be at least a little persuasive...
>10M weekly users! 😉
HOWEVER, before doing that, someone(*) ought to update the Wikipedia pages Userscript and Userscript_manager to mention Tampermonkey
Tampermonkey was listed some time ago but removed including some other extensions with the comments "removed obvious advertising and promotion" and "rmv link spam". So naming the script manager that is used by maybe 90% of all userscript users is SPAM/advertising. 😂
However, I'm working on submitting Tampermonkey to extension galery again. We'll see how this works out. If it succeeds, then I can start to investigate the new Safari App Extension API. Otherwise it doesn't make sense to work on this if there is no chance to be hosted by Apple.
Well they may get some constructive negative PR from an official source if they aren't clearer on why. Saying a Safari extension would damage a mac is ludicrous imho. If that's ever true that would be apples responsibility/fault exclusively for not fixing their security issues... sticking their head in the sand and say it is secure isn't a wise idea. ;) I wish you good luck @derjanb :) *crosses things*.
I am unfamiliar with app extensions and have been reading conflicting information. However, while it appears Safari App Extensions are the only way forward, some developers are saying that you can distribute an app binary outside of the Mac App Store that contains a Safari App Extension using Developer ID. They don't necessarily need to be approved by Apple in the MAS to be able to run on our machines.
Theoretically, Tampermonkey could be distributed as a signed (and eventually notarized) app package that contains the extension. This is assuming, of course, the API makes it technically possible for Tampermonkey and userscripts to run at all.
Is anyone more experienced able to confirm if Safari App Extensions can be installed outside the MAS with Developer ID?
I was able to build a macOS containing app with a Safari app extension, and gave the signed app to a friend. He was able to open the app and have the extension install automatically, though he had to manually tick a checkbox in Safari's preferences to actually enable the extension. No app store required, though $99/yr Mac dev certificate still required. So I don't think you necessarily have to have MAS approval to release an App Extension, unless Apple changes this policy in the future.
Still it seems like a serious amount of work may be required to port non-trivial legacy extensions like tampermonkey for safari. I've been porting a few .safariextz extensions I use for myself to the app extension model, just to see how this works. The simple ones that just inject a start/end script are easy. But the App Extension API (currently) provides no Javascript-friendly global.html / background.html. Code that used to be in global.js / background.js has to be rewritten in native Swift or Objective-C code, to run in the app extension's native process. Seems like a lot to ask browser extension devs to do for a niche browser.
But the App Extension API (currently) provides no Javascript-friendly global.html / background.html. Code that used to be in global.js / background.js has to be rewritten in native Swift or Objective-C code, to run in the app extension's native process. Seems like a lot to ask browser extension devs to do for a niche browser.
I hope that I can embed something like a WebView that loads my background page with the possibility to send messages to native Swift or Objective-C. This is how the Android apps are working...
Note that Safari App Extensions are also available on macOS 10.13, so you can develop and test there without having to use the 10.14 beta or the Safari Technology Preview.
Post a link and I'll send $20 towards your developer account ;) hopefully others would join too.
All apps have sandboxes. Extension runs within the sandbox of the app which installed it. Same approach as on iOS. Creating downloadable extension installer should be a long-term solution. uBlock have just released their "app" on Apple Store. For TamperMonkey it would have to be manual download.
Please do your best to find a way to make it work. Safari 12 seems to much faster than Chrome and I don't want to g back to that resource hog.
I don't mind donating too but I think that if you publish it to Appstore you can charge like $1 for it and nobody will complain. As long you don't try to make a profit out of it, people would be happy to pay a little bit for assuring that development continues and that we can use user scripts in Safari.
As signing a Safari extension currently already requires a developer certificate, which requires a $99 developer account already, is the $99 actually the problem here?
is the $99 actually the problem here?
No, I already do have a developer account to sign Tampermonkey.
It looks like either Tampermonkey is not notable or I'm a bad Wikipedia editor or maybe even both. 😞
Anyway, I've submitted Tampermonkey to the Safari Extensions Gallery again. Unfortunately there is no field to add some notes for the reviewers. We'll see what happens.
@derjanb
or maybe even both
There's at least one error in there:
Without reading Wikipedia's full guidelines I wouldn't know what they mean. Seems comparable to GM's though.
Safari Extensions Gallery again.
Hope it passes for the Safari folks. :) *crosses things again*
@derjanb as a former Wikipedia contributor I would encourage you to read these before submitting the article again:
Wikipedia's Notability guidelines which determines if a subject is notable enough to get its own article.
IMO more important in this case, Wikipedia's conflict of interest guidelines or the Wikipedia's simple conflict of interest guide. As you are the main contributor of Tampermonkey, I would strongly discourage you to contribute to Tampermonkey's article.
Before this passes Apple blessing, can you please provide a small howto on how to load it on "Safari Technology Preview"? I am sure it must be a way to load it from outside the appstore for development purposes, something similar to the Chrome feature.
@ssbarnea Please see https://github.com/Tampermonkey/tampermonkey/issues/558#issuecomment-395570798
as a former Wikipedia contributor I would encourage you to read these before submitting the article again:
@alphachung I don't have any plans to submit the article again.
Did you hear back from Apple?
Any updates from Apple? I am also curious about the license aspect as I initially had the impression that tampermonkey was using an OSI approved open source license but I just observed the warning from the readme about GPLv3 and the "proprietary license" (without even a license body, a top secret license?). I am not a big supporter of GPL due to its distributions issues (app store), so I was hopping to hear that the new license would be something like MIT or BSD like, which do not posses the same limitations.
My first submission was rejected on 2018-07-21 because the "Description" manifest field was missing (it wasn't necessary in 2014). I've fixed this two or three days later and now I'm waiting again.
@derjanb Thanks for the update. In its current form is not practically possible to use the tampermonkey safari workaround because every time safari reloads (Safari TP version does this often...), you lose the extension and you need to add it again. Even worse each time the extension starts from zero, without any scripts, so you need to import them from somewhere. A real PITA thanks for Apple, clearly made it such way that you cannot use it for more than testing.
Are there any plans top port Tapermonkey as native Safari App Extension ?
I'm a huge fan of Tampermonkey for Safari. I use it daily with many, many scripts. I'm able to get the current version to work on Safari 12 just fine with the Safari Extension Builder, but I can't create an actual extension because I don't have a developer certificate. Am I correct in understanding that a person with a certificate would be able to build a copy of the extension that doesn't throw the "Unsafe extension" error, or does this require a huge rewrite? A user pointed out above that it should still be possible to distribute an "app extension" outside the app store-I hope this is the case, as I can't imagine Apple approving it (although of course they should).
@prohtex as far as I know all Safari Extension will be no longer supported in future. The author of an Extension needs to port it to a Safari App Extension which needs to be built with XCode. see: https://developer.apple.com/documentation/safariservices/safari_app_extensions/converting_a_legacy_safari_extension_to_a_safari_app_extension
Besides Tampermonkey, there is NO script blocker for safari 12 I know of available :/
@daslicht 1Blocker works well and Safari 12. It would worth mentioning that Tampermonkey is a not really a script blocker, is more of a script injector and probably this is why Apple is delaying the approval. I am in the process of dropping Safari 12 due to this issue, even if I love its speed, still I really need a way to run custom JS on some websites.
Apple is not going to approve Tampermonkey. The question is, can it be distributed outside the app store? It sounds like it can.
For clarity: if Tampermonkey was converted to a Safari App Extension (which may not require a complete rewrite, just some [admittedly rather complex] wrapper code to run the JS under JavaScriptCore in a separate process), it would be possible to distribute it outside the App Store. Safari 12 does not provide a way to install non-Gallery extensions without user action on every launch.
Ok, but I’m using Omnikey and Ghostery, neither of which is an app extension, without issue.
@ssbarnea I know that Tamplermonkey is a script runner, i havnen said anything else. I just mentioned that there is now JS blocker I know of. 1Blocker can selectively block JS like JS Blocker ?
@rcombs the Gallery will be deprecated as well. App Extensions are distributed through the App store in future.
As far as I'm aware, there's been no indication that Developer ID-signed Mac apps will stop being able to include Safari App Extensions at any point.
Good news: Tampermonkey finally made it into the Safari Extension Gallery: https://safari-extensions.apple.com/details/?id=net.tampermonkey.safari-G3XV72R5TC 🙌🎉
Oh great! I've been waiting for weeks. Thanks @derjanb!
Just donated to support this awesome project. Nice work @derjanb
Hi,
Apparently .safariextz style extensions are deprecated (but still operable) in the upcoming Safari 12, and 12 is 'the last release to support them', so either Safari 13 or possibly 12.1(?) will completely drop them. See https://developer.apple.com/documentation/safariextensions for details.
The replacement schema is at https://developer.apple.com/documentation/safariservices/safari_app_extensions/building_a_safari_app_extension, with supposed conversion doc at https://developer.apple.com/documentation/safariservices/safari_app_extensions/converting_a_safari_extension_to_a_safari_app_extension
As far as I can tell, this is Apple's official 'we're getting out of the browser business, just shoot us now' announcement. Instead of adding support for WebExtensions (even borked support like in Edge), they're jumping a fleet of buses over an ocean of sharks, off into some weird Neverland where every browser extension has to have a bag-on-the-side MacOS native app attached to it. But I may be misreading. It's sure as heck presented like that, anyway.
Be that as it may:
Can authors of userscripts rely on any hope of Tampermonkey bridging over this ridiculous gap and continuing to work on Safari 13?