What needs to be built into the SAFE client is a “message log” showing the plaintext version of app network requests. At least that way we can visually see what’s being sent over the wire, while the data-on-wire is still fully encrypted through the SAFE client.
I’d also like to see a “Manually approve all network requests” option/app, that can be set per-app, and when that app makes a network request you get a notice asking to allow/deny/block all.
But there are a lot of confusions here. I have said many times, I don’t believe the web proxy should be in the launcher. I also don’t believe it should be enabled by default. I also don’t believe CORS headers should be on the API. I also don’t believe apps should register with the launcher from inside the browser (these are not apps, the browser is the “app” here). Unfortunately there seems to be many people making JS frameworks to work inside of a browser and contact the API which I believe is wrong.
The key: stop using your normal browser for non-HTTP browsing. Stop making sites that reference HTTP (or web sockets, or webrtc, or anything). And finally, we need something that blocks all of these anyways. It’s a known thing and we’re just in the infancy of the client side part of SAFE (sadly, everyone I read on this forum is moving towards the stock browser and I very much believe against it).
I am excited to see where you take it, as you know it’s been a huge concern around the forums to have a better SAFE browser.
I fully agree, however I believe this is a 12-18 month temporary solution. The ultimate protection would be a SAFE OS, which is inevitable.
I think it’s strictly too hard and security-averse to try to “turn off” privacy-invasive features of any browser. That’s kind of why SAFE was built, to have everything “off” by default, where you are giving up zero information about yourself, and you have to manually give out your information to be identified.
I was also hoping to do this (I need it for my browser project) and I was hoping to abstract it from node and the browser (I figure using browserify + https://github.com/request/request should be fine). I was also hoping to write it in TypeScript.
If we were to demand everyone used a custom OS, virtually no one would bother with safe net. If it only worked with some special browser, most people would not use it and it would require custom browsers for each OS (including phones, tablets, TVs, etc). We have to be pragmatic about what can be achieved, an order to give the project enough thrust to get off the ground.
There are plans to use a browser plugin and only have safe: URLs, but this isn’t easy on Chrome, requires a specially built Firefox and cannot work on IE at all AFAIK. Therefore a proxy makes good sense, to deliver a MVP.
When we have new plugins, browsers and OS, sure let’s use them, but if we demand them and wait for them, we will never get off the ground.
The fact is, web sites can provide rich content to a wide range of platforms. Browsers are getting progressively more powerful, to the point where many people are becoming OS agnostic. The line between OS app and browser app has become increasingly blurred, especially with the likes of ChromeOS, FirefoxOS and Ubuntu Touch pushing this further. Why shouldn’t an app boot from a browser? If it is cross platform, fast and user friendly, who cares if it is a native OS app?
Personally, I like the idea of websites registering with the launcher. I suspect more permissions will be applied, much like when you use an Android app - you choose what can break out of the sandbox and when. This paradigm will no doubt be stretched further as plugins and new secure OS take shape.
I like the concept that the launcher can be the door man, vetting what can and can’t be done via the API. This could result in hugely powerful web apps, which further blur the definition of where an app should boot from.
For example, the launcher could flag all safe coin transaction attempts to authorise them. No more trusting a web wallet or even a local binary - just pipe them all through the launcher and let it handle it. The user gets a standard, known, experience and can be sure rogue apps aren’t doing stuff they shouldn’t.
Rome wasn’t built in a day and we need an MVP first, then grow it from there. Let’s get something working and then worry about how to improve it, based on feedback.
I never have and never would suggest this approach (strawman).
I disagree and would not have made my comment if I couldn’t write code to prove it was fairly trivial to remain pragmatic and safe. I don’t agree with the browser plugin approach either. My comments are rooted in real world technological choices as opposed to just simple forum commenting.
That’s why I suggest the web platform without reuse of your existing browser or proxying connections on someone’s local computer.
Then make that opt in or a separate app. Breaking out of the sandbox is way easy today.
I am not arguing against the launcher. I am arguing against the proxy and the ability for a localhost port to be accessed by my browser by default when installed.
It’s important to understand the difference between level of effort vs paths taken. There is effort being invested in the proxy that could be repurposed. Quite often you see this while people are working to provide interoperability with emerging systems: the initial interoperability layer becomes “too depended on to fail”. This is not a level of effort discussion IMO.
If the proxy and the access-localhost-api-from-your-browser is the easiest way and the level of effort is too large for an alternative, just make those opt in. Too much work has been done on this project with regards to safety/privacy to not apply similar designs to the frontend.
@Traktion So you’re talking about the launcher being an interactive, “opt-in” firewall, asking the user to consent to each app. That reminds me a little of ZoneAlarm, from years ago, which I found a bit annoying. But I could accept that if it’s in a good cause, so to speak.