Support Safari on macOS

[carumusan]

I use Safari as my main browser for privacy and other reasons. Would be useful if I didn't have to switch browser to use frame.

[floating]

We will look into supporting this, thanks!

[matkam]

I was able to convert and run the extension.

It seems to almost work, but is getting blocked due to having mixed content:

[Warning] [blocked] The page at https://frame.sh/ was not allowed to display insecure content from http://127.0.0.1:1248/. (js.5a3378ac.js, line 1156)

[Error] Not allowed to request resource
	send (js.5a3378ac.js:1156:2103)
	send (js.5a3378ac.js:1142:2128)
	_send (js.5a3378ac.js:1140:2213)
	e (js.5a3378ac.js:1160:979)
[Error] XMLHttpRequest cannot load http://127.0.0.1:1248/ due to access control checks.
	send (js.5a3378ac.js:1156:2103)
	send (js.5a3378ac.js:1142:2128)
	_send (js.5a3378ac.js:1140:2213)
	e (js.5a3378ac.js:1160:979)
[Log] Setup Error:  – {message: "JSON Parse error: Unexpected EOF", code: undefined} (js.5a3378ac.js, line 1160)

[floating]

Yes, this was the problem initially because Safari doesn't treat localhost as a secure origin, which it should and other browser do.

[matkam]

That is a bit of a pain, but the restriction could potentially be worked around. Frame could serve https with a self signed cert, and the user would have to explicitly approve the cert on their system. Frame would be the way to get Web3 on Safari as Metamask doesn't even support Safari.

[floating]

Yeah! We're open to this solution but haven't had the time to implement something like this yet.

[theethernaut]

+1 on this feature request!

[thegostep]

+1 would make me switch from chrome (and metamask)

[rewtraw]

Desperate for Safari support!

[anukul]

@floating I would be open to implementing the solution suggested by @matkam. Go Frame!

[matkam]

Please do @anukul! I had promised it for @floating a while ago but haven't been able to find the time. Here's where I left off:
You can modify https://github.com/floating/frame/blob/master/main/api/http.js#L132 with:

var options = {
  key: fs.readFileSync('/path/to/key.pem'),
  cert: fs.readFileSync('/path/to/cert.pem'),
  // ca: fs.readFileSync('/path/to/ca.pem')
}

module.exports = {
  http: () => http.createServer(handler),
  https: () => https.createServer(options, handler)
}

and https://github.com/floating/frame/blob/master/main/api/index.js with:

const { http, https } = require('./http')
const ws = require('./ws')

ws(http()).listen(1248, '127.0.0.1')
ws(https()).listen(1249, '127.0.0.1')

The idea is to either have a UI element for the user to provide a self generated cert, or some UI where a user can generate a cert and enable Frame on HTTPS. @floating also found this tool that might help: https://github.com/FiloSottile/mkcert

[0xt3rtium]

Is that really the right way to go? Ability to swap out certificate seems like a potential vector for users to get rekt.

Did anyone verify if latest Safari is still affected? Guessing from webkit bug 171934 it was a deliberate decision though to not allow it.

[goosewobbler]

@matkam just a thought, could it be possible to use HTTPS with a generated cert by default for all browsers? That way you don't necessarily need any more UI just for the Safari case.

EDIT: on second thoughts that approach might be just adding a lot of scope for cert errors and l was also assuming cert generation could be automated via mkcert, which looks unlikely. I might poke around at this issue when I get time...

[matkam]

@goosewobbler I think requiring cert generation would add too much extra friction for most users, though it could add a bit of extra security. It could be a good idea to have it be an option for all browsers, and required for Safari.

[goosewobbler]

Started looking at this, draft PR here, can discuss any implementation details there.

[goosewobbler]

Thought I'd update this ticket, after trying a few things the proposed implementation has changed a fair bit and we're now looking at a UI-less approach using our own cert generation service to provide clients with self-signed certs, which avoids the problem of users having to manage Frame access to openSSL or us having to do something crazy like bundle mkcert. The idea is to have wss via self-signed cert as the default for all, with graceful fallback to ws/http when there is no valid cert.

Currently working on the problem of assigning trust to self-signed CAs in the various OS's / cert stores in a way that (a) can be automated and (b) requires minimal user input. After this the plan is to create a working E2E prototype using the modified Frame and browser extension, connecting to the dockerised cert service on Flux.

[goosewobbler]

Another update to this, it's now possible to make a Frame Safari extension without using WSS; the WSS support work has been parked. We're currently going through the Apple Store submission process for the Safari extension.

[sigurdarson]

Any news on the app store submission?

[goosewobbler]

@sigurdarson We're blocked by the nature of our extension as a bridge / companion to Frame - Apple store guidelines require a certain level of standalone functionality which we don't currently fulfil. We have some ideas about how to work around this but there have recently been higher priority things to work on. If you have any suggestions about extension-specific features you would like to see, we would love to hear them.

[0xF16]

Any news on the app store submission?

@sigurdarson For the time being, you can build your own version on MacOS with Xcode. I'm running Frame Companion like this for the last 3 days and so far it works well.

[gpxl-dev]

Hey @0xF16 - any pointers on how to achieve this. Not looking for step by step as appreciate that would take a lot of time, but generally what to clone & build would be handy!

[0xF16]

Hey @0xF16 - any pointers on how to achieve this. Not looking for step by step as appreciate that would take a lot of time, but generally what to clone & build would be handy!

Hey @gpxl-dev, I do not remember which site I have followed but I believe it was this one: https://iboysoft.com/news/convert-chrome-extension-to-safari.html
The downside of this is that every time there is a new version, you have to convert it again. Also every time you close Safari completely, you have to "Allow unsigned extensions" in Safari on and on.