No. I don’t want any website to be able to access any localhost port period. I guess right now all I’m fighting for is sane defaults or like you say, a choice. Remember there are two choices here: CORS for the API and whether the web proxy is on (the former being more dangerous, the latter being a deanon vuln). My biggest fear though is that people get hooked on this approach to developing apps, thereby leaving themselves open to harm. Maybe I should make a simple HTTP website that blows up /auth
Yeah, that is one option, but we can have all levels of flexibility.
We could have permanent opt-in or opt-out on a per application basis. We could have some operations always requiring confirmation on some apps, but not others. We could also have opt-out for everything.
It can act as a fully configurable gate keeper, much like an interactive safe net firewall as you point out. It could have modules which plug in for dealing with certain sites, structured data types and so forth too.
There could be multiple ways of interfacing with it from RESTful APIs, to super fast binary sockets. All of these could be opted in/out, depending on preference - a preference which could be set the first time an app tries to use said mode.
I see the launcher right now as a very basic implementation of something which could be extended indefinitely to suit.
I think if auth is easily exploitable, it will need improving. I can already think of issues (XSS to create attempt auth with the same name as the site it is injected into, for example), but these aren’t insurmountable, IMO. I am relatively comfortable with the concept, though.
We already have Bitcoin web wallets, banking sites, etc running in web browsers. Many of these are using little more than username/password authentication, maybe with 2FA as an option if you are lucky. We can do so much more out of the box than that with the proxy, so IMO, we can only improve the current situation.
It’s not just auth. The DNS stuff doesn’t even require auth to use. But it’s less about whether you think you can stick your finger in every hole in the dike, but rather whether the dike is required anyways. I think it is unfair to compare with other things running in web browsers since I can’t think of any of them that would ever dare to communicate with an external application running on your computer (at least not without getting laughed at by anyone security conscious). Things like Flash and ActiveX were bad enough. We cannot improve the situation by opening these vectors IMO, even under the guise of ease-of-use.
I am not blind to your concerns, but we do trust the web browsers themselves to be sufficiently sand boxed against a far greater number of possible attack vectors.
However we choose to integrate our web browsers with safe net, there is going to be a risk that it could be exploited. Whether we provide a local RESTful API end point or something tightly integrated into the browser itself, we still have to manage that gateway some how.
I look forward to seeing how you plan on mitigating these risks, along with what else Maidsafe can come up with. In the interim, I’m quite pleased that I can start playing around with web apps to get a flavour of what will be possible when we have a usable release.
Until you explicitly disable the sandbox with HTTP headers.
This is wrong and a dangerous confusion. There is a difference between providing a web platform and providing HTTP access.
Also dangerously confusing to compare opening up a local REST API to every website on the internet and just providing an API to locally installed applications.
You can already start playing around. The demo app is a perfect example. Why do you believe you can’t play around unless this vector is open?
Sure, but this is a delegation of security to a different sandbox. The browser must maintain its own sandbox, despite running scripting languages, mark-up, allowing downloads, people going to any internet site, etc. Arguably, the web browser itself is the most risky application we could possibly run, yet we use it daily.
We don’t need to open the REST API up to every website on the internet though (granted, the current version is, but it is early dev). We could have only allow access from the same domain, for example (e.g. safeapi.traktion.safenet), much like CORS is often deployed on web apps. This would narrow the attack vector to your own site being exploited (via XSS or some such).
Web apps have the biggest interest for me. The browser is ubiquitous for good reason and exploring/demonstrating what can be done within this environment is paramount, IMO.
I must admit I have quite some concerns about this too.
I think it depends if you want to include the “S” of Safe in the MVP , or not.
Without a dedicated, http:// ignorant, non leaking browser, and with a proxy that does forwards regular ( including external ) http requests, I would say that the MVP bundle would have to be called “Afe Network” : Access for Everyone. The proxy-jsnode-firefox/chrome solution is putting all the beauty of the design back to zero in terms of privacy. Some examples of trap safenet wep pages have been demonstrated in the first test days, and I suppose trap apps will be written and published very soon ( i wish I had the skills to make one, but I’m still struggling with registering a rust program to the launcher for now ).
If a phase is needed when the “S” for Safe is not here yet, but the rest does work, I would think that this should be heavily and very clearly announced when delivering the product to the public.
In this case It should be made very clear that in this phase the MVP should NEVER be used for anything sensible at this point. I am afraid some people in very repressive politic situations may think they have a solution to communicate ,and they just get jailed, tortured or what other terrible things. Not providing this warning , and risking “collateral victims” just because the network has to take off from the ground would be absolutely immoral, in my opinion. I mean, real victims. People being injured or killed for real, not flamed in a forum or not getting “likes” for their posts.
Then the launcher must have this big red popup when you start it, saying you " YOU ARE NOT SAFE - USE AT YOUR OWN RISK".
Then I wonder if it would really take off the ground ?
I suppose one of the questions is : what really means M-V-P. What is “minimal”. Does it include Secure ? It could be just sharing storage and bandwidth for a start, and this would be very legitimate. But then it has to be very clearly stated as such.
No, sorry, that’s not what I meant, I was tired when I wrote it. I created functions in native JavaScript to easily interface with the launcher through the API. That’s far less impressive eh.
most app development these days happens for mobile apps, so really while of course browsers are important, providing the right toolkit and documentation support for iOS and Android developers would probably yield better user adoption than trying to push a new browser.
Do you have a source for that? Personally, I spend more time in my browser on mobile, tablet and laptop. Tbh, I don’t always like the apps even when they are available, as it isn’t as convenient. Many apps are also just web apps wrapped in a container.
