One thing that could be better communicated is that the SAFE Network has never actually been based on a browser. Previously a fork of the Mozilla, then Beaker and others have been put forward by the dev team as an access platforms. Current version of the SAFE browser is being developed as a means of having a secure experience without leakage to the clear net. Anyone who wants can eventually build whatever browser they want for access, or none at all for access via IOT. Just need to use the network protocols to connect and read/write.
EDIT: No, don’t take it down. Maybe do a follow up on some points, but leave it regardless. Will do much good, either way, I think.
Even though the access of the SafeNetwork from ‘clearnet’ browsers through extensions/add-ons sounds like it may be practical and functional to the initial popularization of the SafeNetwork… the fact is that it would undo the security advantages of the unique design of the SafeNetwork.
In short it would be an enormous security risk.
We have enough phishing on the clearnet, let’s keep the SafeNetwork Safe.
As you can see, it is rampant in the wild.
Allowing SafeNetwork extensions on clearnet browsers would allow traditional ‘hacking’ methods to compromise SAFE users.
Thinking out loud here, it seems like the best way to protect against malicious/fake third-party extensions for SAFE Net (or extension takeovers) would be for MaidSafe to provide and market its own. Otherwise a very convincing-looking fake one will inevitably appear and trick a lot of people. As I understand it though, maintaining an extension is a lot of work, especially across multiple browsers.
We could strongly caution users not to download extensions for SAFE at all, but you know some people will be tempted by the convenience, or see it as a new form of VPN service. Then they’ll get pwned. Again, just my opinion.
I think that the demography of users who would even think about jailbreaking as an option, might have already switched to the Android ecosystem by now.
I’m inclined towards extensions because of the potential to off-load a significant amount of browser logic development and cross-platform concerns. I’d like to hash out the security issues that are unique to extensions and which do not apply to our current browser software.
Using the webRequest API, a SAFE extension could intercept HTTP/S requests and prevent fulfillment. The question is whether this is acceptable according to Add-on Policies. If this behavior violates extension policy then the rest doesn’t even matter.
As far as difficulty of development, the Firefox team makes their API’s in common with Chrome and Opera, with some minor differences in the prime configuration file. So cross-browser support would become our concern instead of cross-platform support with much less effort, iff we didn’t need what extensions call Native Messaging.
Leading into the next issue: relying on dynamically linked libraries, which we do in safe_app_nodejs and the browser to call safe_app, safe_authenticator and system_uri operations.
We’d need an executable running natively, which the extension can communicate with using Native Messaging, to call operations exposed by our dynamically linked libraries.
This wouldn’t be difficult just time-consuming to rework communication and authentication flow, let alone the the QA to ensure that the extension correctly handled installation and registration of native binaries according to platform. Although the time spent may balance out by time saved from offloading onto Firefox and Chrome.
I’m also inclined to conclude that we shouldn’t put time and effort into extension development at this particular time because I think the time would be better spent on things like low-level data migration and management tools, improving the RDF API, and in general support for developers over end-users.
Just a quick thought from me. I think that an add-on could have potential to ease entry to the SAFE-network and become like a “entry drug” before regular people will become addicted to the SAFE-browser. So even though it might not be optimal in every way regarding security, it might be very important for SAFE-network adoption rate, if a minimum level can be achieved, like choosing if to allow http requests and so on.
I am not a developer so my comment here will probably not make any sense (if it every does : ))
but since the formal release of beta may still be sometime away, isnt is too quick to advertise development on SAFE. Is there a chance that many developers come excitingly, get disappointed and do not return?
Also - even if the beta gets released in 2019 and does not see any adoption right away - request to SAFE team is to stay committed on its course as adoption will ‘eventually’ follow. May even take a year after full launch. Things take time to spread out and gain momentum.
If we position the APIs and network appropriately, and therefore set expectations, then we should be ok. We do still need people using the tools we provide so they can be continually improved so we should encourage development, but do so in our usual open way.