Hi,
What is to stop someone putting up apps and webpages that snoop the IP address of a client machine and forward it to some spy site?
Such innovations as the Tor & Tails browsers are intended to prevent exactly that kind of attack. Surely if SAFE users are running the common browsers, they are in danger from such attacks.
Hmm, I suppose that’s part of what we would be looking for in a SAFE browser and a SAFE OS!
That’s going to be a bit of work, especially the OS.
Oh well, Rome wasn’t built in a day.
In the meantime, users will just need to learn a set of hygienic habits.
Some stopgaps come to mind: Tor browser (un-Tor-ed) or Iceweasel instead of the usual suspects, and a less snoopy OS such as Linux.
Yes, it’s step by step: first the network, then the client.
It will never be 100% secure but securing the network makes it much easier for people, by reducing the attack surface to the client, over which they have much more control.
The Devs already talked about a specialized browser for SAFE. That would only connect to. safenet sites or safe:sites. They use sandboxing to prevent any IP-sniffing etc.
If you’re concerned about this, do a separate browser install and change the .pac file to:
function FindProxyForURL(url, host) {
if (shExpMatch(host, "*.*"))
return "PROXY localhost:8101";
return "DIRECT";
}
That should prevent at least the most obvious methods of uncloacking.
Doesn’t the proxy forward HTTP requests too, currently or does it block them? Sorry, not at home to test.
It seems to block them.
Nothing.
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.
safe_launcher/web_proxy.js at 3cb7a7dd91ae4216ed43489fa42c9faadb775220 · maidsafe-archive/safe_launcher · GitHub shows it just forwards it, but I have not tried either. It may block them as a bug.
I plan on making something similar. I have already done it with GitHub - cretz/safe-poc-browser: Simple Proof-of-Concept Browser for SAFE Network where it blocks all HTTP calls and if you try to go to a top level HTTP page you get asked whether you want to open in your normal browser. I plan to expand this into a real product in GitHub - cretz/shrewd-old over the next coming weeks.
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 agree, at least if the user can then manage permissions on a per-website basis inside the browser.
It’s a matter of pragmatism. This is what we got right now, so we run with it for now.
Word. Technically my approach uses chromium, so technically I too am trying to “turn off” approach, but most things are off by default.
Ah. Ok. I was seeing frameworks and what not.
Well, I can only speak for myself of course. I made a native JavaScript implementation of the API.
Edit: No I didn’t!
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 + GitHub - request/request: 🏊🏾 Simplified HTTP request client. should be fine). I was also hoping to write it in TypeScript.
Edit: I actually might move to GitHub - ladjs/superagent: Ajax for Node.js and browsers (JS HTTP client). Maintained for @forwardemail, @ladjs, @spamscanner, @breejs, @cabinjs, and @lassjs. because request might bring too many deps when browserifying
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.
I didn’t mean to suggest that was your argument. Others have suggested such things though and I was addressing their arguments.
I look forward to seeing your alternatives, but I remain pleased that we have a working test net using a proxy.
Sounds great and I look forward to it. I think many will prefer to use their current browser of choice though, with all their plugins, bookmarks, etc though.
The defaults can be changed. Only proxying safenet content by default would help people easily tighten security. People could then configure their browser of choice to use this.
An installer which allows people to choose their preference would be ideal, including disabling the proxy altogether.
If the launcher notified and asks for permission, with a deny all option, would that suit?
I would be happy to give the choice on first load of launcher to opt in or out. People can decide their risk levels.
I am sure many in here regularly use Tor, VPNs, etc. Many others will just want a decentralised web and easy integration and little else. Safe net will offer different things to different folk.