As a web developer being able to access the users content stored on the safenet on their behalf is a crucially important thing. I am very happy having this provided through the api.safenet-endpoint rather than connecting to localhost (makes it also much cleaner imho), but I am not sure what the actual difference is between the two at the moment (is there any?).
Whether that is provided by the launcher or any other part within the eco-system is not really that important to me. The launcher just feels like a “natural” place to have these authenications handled.
I am not concerned about many of the issues raised here about the launcher providing it. I explained how the supposed cors-issue is largely circumvented by requesting a user-authorization before hand and that most issues brought up against web-apps (as a general thing) are bogus and have little to do with the setup in question in the first place. Providing any kind of programmable API (and the launcher offering the HTTP-API with proxying-support is really just that) to local and web-apps needs to take care about rate limits and such anyway to make sure bad actors don’t bring it down easily. That is a separate issue though and one that any API will face.
Similarly I feel that bringing up “XSS” as the all-on-evil-from-the-web is hugly simplifying the world-view here: any programme that executes code entered by the user will be prone to this problem. Remote-Code-Execution is a problem in all development environments, but in the web it will at least be contained to the app in question, rather than taking over your entire system (as it could for any locally run app) – the key logger example mentioned elsewhere is simply not possible via the web. Mixing and matching the problems mentioned here as supposed “problems” that only the web and the launcher providing to the web face is hugely misappropriating them. Considering that these supposed problems are claimed against an API-change that doesn’t help to protect from them but will cause huge harm to the web-app-development-ecosystem is not constructive. I will sustain from continuing this discussion.
I am however deeply concerned by the mixed-protocol-problem and think that needs to be addressed indeed. While I understand the choice made for now (as stated before), safenet can not accept a system that allows such easy data-leakage.
And I was unaware that I unwillingly contributed to that with the Ghost in the Safe App: even in its default theme (‘decent’) this currently pulls in a font from google-fonts via HTTP 
. Thus allowing Google to track (and we know they do) the source of the include, the font and even if it is only the IP address, if they can link it, they know the article you’ve just read. That is indeed unacceptable.
This is a big issue indeed and one that I as a web-developer am very concerned about to get right from early on. Providing sane defaults from the core team and promoting good citizenship is a good starting point. Scraping the web-access to the content is not an appropriate solution however.
Though I like the proxy idea I am afraid that in its current state it is too generous indeed. We really need to strictly restrict access to *.safenet-pages to *.safenet-access to ensure the privacy claims hold true. I understand that isn’t easily possible in the current setup (at least if you want to allow the users to still use the normal web with the same browser). I, for one, will enforce that from now on with the following uBlock Origin Rule (which should work in any browser): blocking any non-*.safenet-URL on any given *.safenet-URL (you can add that here, if you run uBlock Origin, too)
||$domain=safenet
@@||safenet^$domain=safenet
Maybe instead of providing a general proxy-file, the team should provide a uBlock Origin Configuration for now? I am happy to continue the discussion on how to harden the privacy concerns of the browser users without having to sacrifice browser based applications (that is an unacceptable and unnecessary trade-off).