Support Safari browser

[namliz]

General information

• Operating system + version: OSX
• Browser + version: Safari 12

I did a quick search of the issues here and there doesn't seem to be any sort of plans for Safari. I'd personally be interested in this and am wondering if anybody else wants to collaborate on this.

[maximbaz]

If I'm right, Safari is not available on Linux, so I wouldn't be able to even test this myself, but I would be happy to see a PR and provide any assistance I can 😉

Most probably all you need to touch is install.sh script, and since Safari is based on Webkit, chances are, the setup will be almost identical to Chrome and Chromium.

Try to see if you can find out the root and non-root location to place native-messaging-host (and maybe also manifest) file and adjust the script accordingly.

Does Safari use *.crx files for extension, i.e. can you install chrome-browserpass.crx from releases page? If so, I would need to figure out how to publish the extension in webstore (is this the webstore for Safari extensions?).

[namliz]

I find your optimism when it comes to Apple endearing :)

So unfortunately the extensions webstore you link to is being deprecated in favor of hosting extensions on the Mac App Store. Behold: https://developer.apple.com/safari/extensions/

Neither does Safari use standard *.crx files or the Native Messaging API.

Additional links: https://developer.apple.com/documentation/safariservices/safari_app_extensions https://developer.apple.com/documentation/safariservices/safari_app_extensions/passing_messages_between_safari_app_extensions_and_injected_scripts

[maximbaz]

Ohh, the absence of Native Messaging API is really a game killer, I didn't expect this...

In such case, supporting Safari would require to rewrite literally everything, and we are already in the middle of rewriting everything (in a Safari-incompatible way 😄).

A crazy thought to consider would be to ditch the Native Messaging API and transform our native app to be a HTTP server, so that extension would be making HTTP calls to localhost instead of doing chrome.runtime.sendNativeMessage(). Code-wise it wouldn't be too hard, but I'm afraid of hidden stones that this would bring. Just the first thought that came to my mind is security, currently browser is taking care of restricting access to native app only to our extension, but restricting HTTP calls would become a new problem to solve (not saying that it's impossible, just saying that this adds work).

/cc @erayd for comments, but given the amount of work we already planned for v3, I feel we won't be supporting Safari any time soon.

[namliz]

I don't follow about the HTTP stuff.

If you plan to stick to runtime.sendNativeMessage() in Safari it maps to safari.extension.dispatchMessage and is not much different. (It might be worth checking whether we can just make a shim for this.)

The Safari way for callbacks would be: safari.self.addEventListener("message", handleMessage);

The Safari App extension can further just act as a proxy straight back to the browserpass app. So it is a bit of indirection but that's about it.

[maximbaz]

So Safari has something similar to Native Messaging API... Good to know 🙂 Also thanks for the additional links you added above.

Would you be interested in investigating this track, e.g. whether a simple shim will do, or how to make a Safari App extension that will act as a proxy to browserpass app?

I don't have a Mac to try, and to be honest there's too much other work on our plate that needs to be done. But I would be curious to follow your progress, and provide as much help as I can.

[namliz]

Yes, happily. If I could shim our way to supporting Safari that would be great, I'll look into it. I don't have a lot of spare time in the next couple of weeks but I'll try to get to this and check in with you.

[erayd]

@maximbaz I really don't want to move away from the native messaging approach. Calling the binary directly reduces the attack surface significantly.

If Safari has an API that allows us to continue with this approach, even if the actual API calls are different, I'm open to considering Safari support, but as I don't typically use OSX, I would prefer it if someone else handled the implementation. A shim that allows us to use the 'normal' API for the bulk of the project would be ideal.

Noting Safari has only ~5% of the desktop browser share (and ~8% and ~6% in the USA and Europe respectively), is it worth the hassle of supporting it? Note it will also require a maintainer to list it in the app store, and I believe that requires paying a fee ($99 US rings a bell, but I'm not certain).

[erayd]

One other thing to consider - tracking Firefox and Chrome allows us to use some fairly new APIs, as both browsers are aggressive on implementing new stuff. Safari is somewhat slower to gain new features, so adding Safari as a supported platform is likely to restrict what we can actually do to some degree.

[namliz]

~5% desktop browser share is all well and good but amongst the 'uses a password manager crowd' it is likely to be at least 33%+.

The second point is more pertinent, Firefox/Chrome release at a higher frequency. Is there any API in particular they have that you want for browserpass that Safari currently lacks?

[erayd]

@zilman

~5% desktop browser share is all well and good but amongst the 'uses a password manager crowd' it is likely to be at least 33%+.

Could you please provide a source for this claim? "At least 33%+" is oddly specific, and seems extremely unlikely, particularly noting that users of password managers (and in particular users of browserpass) tend to be power users who are drawn towards more capable software, not less. Safari, as far as I am aware, lacks a sufficiently powerful drawcard to account for that much of a market anomaly.

Browserpass in particular also has a user base with a rather high proportion of Linux users, and Safari isn't even available on Linux. As such, I'd expect that Safari usage would actually trend in the opposite direction and see less usage among browserpass users than all-users statistics.

There are no issues other than this one requesting Safari support, and no other users have commented here (although admittedly this issue was only opened nine hours ago). If the demand was as high as you claim, I would have expected to see previous issues filed on this topic.

The second point is more pertinent, Firefox/Chrome release at a higher frequency. Is there any API in particular they have that you want for browserpass that Safari currently lacks?

My comment was general - it wasn't written with a specific API in mind. Web standards move quickly, and Safari lags on making them available for use.

[maximbaz]

To summarize:

1. We will keep using Native Messaging API.
2. @zilman will investigate how feasible it is to add support for Safari browser by using their alternative to Native Messaging API, we will decide whether we want to merge those changes based on the list of findings.
3. Judging by this article, it costs $100 per year to publish a Safari extension to their Webstore — I won't be paying this fee myself, but if someone wants to donate $100 per year, I'm perfectly fine to publish the extension to their Webstore as well besides already doing so for Chrome and Firefox webstores. If not, I'll just be attaching the extension to Github releases like I already do for .crx file, and Safari users will not have auto-update of browserpass.
4. Neither @erayd nor I have the ability to use browserpass with Safari, so we will not be able to test the extension and thus will not promise that extension is working in Safari at all times — I can certainly ping the Safari support team (currently only you @zilman 😛) asking to test the extension in Safari before the release. By the way, I think we will change the sentence in README from "Works in recent version of Chrome, Chromium and Firefox 50+" to "Works in latest stable version of Chrome, Chromium and Firefox", because in reality we are not doing any matrix testing — if browserpass happens to also work in other browsers or other versions — great, but it isn't guaranteed.
5. During the development we want to use all the latest and greatest features available in Chrome and Firefox, whether it is new JS syntax, new APIs or something else. Doing testing and providing shims for Safari will be responsibility of the Safari support team.

Sounds fair?

[maximbaz]

I'll close this ticket for cleanup purposes because right now there's no actionable item for the team, but please do continue to keep the investigation and discussion rolling.

[adur1990]

Hi,

so, I wrote a Safari App Extension, called Passafari. First, I wanted to add it to Browserpass, but the APIs are totally different. Therefore, I decided to start an own project.

It is not available in brew or the Mac App Store so far, because it is a beta. So, any contribution and users are welcome :)

[erayd]

@adur1990 Thanks - having someone else do a safari extension is really useful :-).

If you can possibly do so, I'd recommend avoiding the need to give it your private key. There are two major problems with the current approach:

1. gpg is a standard system - it confuses me why you can't simply connect to the agent. I guard my key carefully, and do not disclose it to any application, no matter how well intentioned. This requirement alone would be enough for me to avoid using your extension, and I know many other people react similarly.

2. My gpg subkeys live on a hardware token (yubikey). Providing the key itself to your extension obviously isn't compatible with that - so how do you intend to support such tokens?

What is the technical block that's preventing you from simply using gpg in the normal manner via the agent? Most sandbox implementations allow you to declare connection resources (gpg agent just needs a single socket), so is this an option with safari?

[adur1990]

@erayd Thank you for your ideas.

The main Problem is, that it is not trivial to escape the sandbox for communicating with the gpg agent, at least I could not find any suitable way. If you have any further resources how to achieve this, please let me know. I am not happy with the current approach, too. But it is the only way I could think of.