feature: configuration suited to the Safenetwork backend

I'm still working with the old widget at the moment and not aware of what you have changed in the new widget, but I have some issues with the old one that might feed into this while it is being worked on.

These are very specific to the SafeNetwork backend that I have prototyped, but not yet pushed here (still chasing some bugs and waiting for the SAFE API to stabilise). So this request is not a priority, but it would be good if it can be considered and maybe catered for.

Aside: earlier issues regarding CSP failures (due to inlining CSS in the widget) no longer apply, at least for the time being because the preferred way of browsing SAFE websites is to use the custom SAFE Beaker Browser, which means there is no longer a local web proxy involved. SAFE API is instead accessed using safe-js JavaScript library that talks directly to launcher using FFI. These issues might re-occur at a later date, because it will still be possible for someone to create plugins that enable other browsers (Firefox for example) to access websites on SAFE.

Context

As noted in the aside, web apps on Safe Network will now be accessed using SAFE Beaker Browser. This provides a more secure browsing environment than using existing browsers with a web proxy, because by default SAFE Beaker Browser disables all non-SAFE URLs. So no http/https etc. So a website or web app loaded from SAFE can only access resources on SAFE (ie using a "safe://" URL such as safe://myfd.rsports which is a live, buggy work-in-progress, demo of the myfavoritedrinks RS.js app).

This means that for most RS.js apps on SAFE Network, the only applicable backend will be SAFE itself and there is no value in supporting anything that requires http/https etc access. In fact, to have such "clearnet" URLs or features visible in the UI (i.e. the widget) is unnecessary and will confuse users.

Feature: Ability to disable all non-SAFE features/resources

I'd like the widget to be able to operate in a way that hides all non-SAFE features. So for example, the ability to disable display of fields related to input of remote storage server credentials, and to use just one SAFE related icon rather than both SAFE and RS icons. With the old widget I can add the Safenetwork icon (as you can with Googledrive and Dropbox), but the widget shows the RS icon as well, and that icon is actually needed in order to access "disconnect".

So it would be useful to have a way to access all widget commands, but with only the Safenetwork icon displayed, and no way for users to access any http/https URLs is needed.

I expect that the status/error messages will largely be applicable as is because accessing SAFE network is largely similar process from a user perspective. Authentication currently happens outside the website/app, in "SAFE Launcher". This is currently under review and will change, but I think not in ways that affect the widget, so I think the only functionality required is "connect/disconnect" and display of suitable error messages, and any relevant "in-app" functions (such as "Get me out of here").

Sorry, but this would completely remove user freedom and choice, which is the very goal of RemoteStorage as a protocol and remoteStorage.js as a library. So if you want to do this, you'll need to maintain your own fork in my opinion.

Unfortunately, if there's no proxy at all anymore, then that means we can't even add SAFEnet support to rs.js core, because nobody would ever be able to use it in their normal browsers and with installable Web Apps using normal browser engines. That's all our target users basically. I don't see why anyone working on core would want to spend time on something they don't use themselves and that their users can't use either.

Perhaps you can explain how that would make sense for us. And also if the Maidsafe project seriously thinks that the majority of Web users, device and browser vendors, and developers of all kinds will switch to a single new browser and network and ditch all of HTTP forever.

Sure, I can see there are some issues here. Maybe this isn't suitable for "core", but let's explore it a bit.

Firstly the reason for the restriction is to empower users. SAFE stands for Secure Access For Everyone and is about ensuring privacy and user control of their data, and I do believe the goals of both projects are entirely compatible. There may indeed be a loss here (immediate flexibility) as well as a gain (all the benefits of SAFE network), but not a complete loss because the http restriction is optional.

By default, SAFE Beaker will offer the highest security it can, but the user will be able to opt out of this when they choose (e.g. something like "open unSAFE tab"). But by default they will be as secure as possible from malware, tracking and other "evils" :smile:. But an unSAFE tab would exposes them to all the current security issues associated with the web, from simple trackers in embedded URLs, cookies, XSS attacks, analytics etc. that the security conscious developers are constantly fighting, and their adversaries are constantly trying to exploit.

The reason for this request then, is that while in secure mode, it would be unhelpful (confusing) to have things enabled that won't work. There is no reason though, not to provide a way for the user to access such features when an RS.js website/app is open in unSAFE mode (a bit like none-Incognito / Incognito modes in current browsers). So including this in the core would allow the app developer to choose to support either/or/or both, and to have the UI adapt accordingly. The user gets the best of both worlds.

I could do this as a fork of course, but I'm hopeful that the aims of RS and SAFE are aligned enough that you'll agree its good to include SAFE as an option for existing RS.js apps and users. From where I sit, I think that for some time to come people will want a way to use clearnet and/or SAFE, so having a solution that allows data to be moved between SAFE Network and RS servers would be preferable, although just having the ability to port RS.js web apps over to SAFEnetwork is probably enough incentive for me to implement this as a fork.

I hope this answers the how it might make sense for you to support SAFE Network, because it isn't completely either-or, and we don't want to restrict users. The intention is that when users are using SAFE Network, the default should be secure (end to end encrypted, no XSS), private (no tracker URLs/cross site accessible cookies etc) and accessible (no DDoS, no external censorship).

Users and vendors don't have to ditch http to get value from SAFE network, but when using it they should be confident that it delivers Secure Access For Everyone. Consider this though: at the present time the internet and its services are on what to me is a frightening trajectory of ever larger outages and more serious security breaches, as well seeming ever closer to becoming a cyber battlefield between nation states. Users and business are being exposed to ever greater threats from criminal malware (ransomware, DDoS extortion, data theft etc) and civil oppression (surveillance, censorship, and media control etc).

The way things are going at the moment, it is entirely possible that users and vendors will either want to get off the current internet, or have to find a functioning alternative. I'm not predicting that is what is going to happen, but at the moment I can't see how the existing infrastructure can be secured, or indeed anyone who is capable of dealing adequately with these growing problems (security services, government or industry). Maybe it is all being secured out of sight, but if so, my guess is not the open and freedom enhancing ways that I would want and most open source folks would subscribe to. So again, having a way for developers and users to migrate from RS services to SAFE Network could be important to you too.

Regardless of my opinion about all of this, we need one-backend UX flow anyway: https://github.com/remotestorage/remotestorage-widget/issues/12

If you're saying HTTPS is unsafe by default, even with TLS 1+ using proper, forward-secret e2e encryption, then I don't know what to respond exactly. Billions of people are using it in a safe fashion today, and the standards to make it more bulletproof just keep on coming (e.g. CSP, which you yourself experienced with this very widget; or the Web Crypto API, which allows us to keep servers from handling unencrypted data). "Secure Access For Everyone" is an important consideration in today's and especially for tomorrow's Web already.

Glad to hear it! :smile:

I think https etc are important and valuable, but not enough. I'm not at all optimistic about securing "tomorrow's web" based on existing infrastructure despite the useful improvements that are being made. If it can be done that would be fantastic, but I believe the "holes" are too numerous and not just about physical security. I also don't believe a voluntary approach is very effective when users are dis-empowered by default, and reliant on numerous others to act in their interests when those others are already finding massive value in acting against those interests.

So while I don't speak for the project or MaidSafe I can see that the approach fits with creating maximum security by default, and making the relationship between user and application/service explicit. With the user informed and in control about who has access to their information, making it hard for any abuse to remain hidden for long, even harder to hide the source, and extremely difficult to do at scale. The current internet infrastructure has inherent difficulties in these respects.

I would add that both have a massive holes in their story when they claim "informed and in control", because "informed" is nigh-impossible for lay people and "in control" is only 100% true when they're informed. So I think there's an inherent protector role that we as software/infrastructure engineers are stuck with, if we like it or not, and claiming that in a decentralized blockchain future all users are entirely their own full node and ultimate guardian of their data is a bit of a naive idea.

In any case, I just find it sad that SAFE people think it's reasonable to call the entire Web "legacy" and "unsafe" everywhere now, and want to show "this is unsafe" warnings for perfectly secure connections and origins. Browsers already do that, and are regularly introducing even stricter rules for what counts as safe. Soon, anything on the Web not using a reasonably secure TLS connection will already be marked as insecure for end users, and blocked by default. I'm all for co-existing and using other protocols for certain use cases, but apparently the SAFE engineers are not.

(By the way, check out Ethereum's Mist wallet/browser for an example of combining the existing Web with new blockchain technology in a very useful way.)

I think you are misunderstanding me and the reasons for what I've said, and now are misrepresenting me and the entire project. I agree with you about "informed" and "in control" for example, and today wrote at length about the importance of usability and ease of security in a discussion on authentication for the SAFEnetwork, which is being redesigned as we speak. See my post here: https://forum.safedev.org/t/rfc-46-new-auth-flow/294/8?u=happybeing This is my natural position: better security for as many users as possible, rather than maximum for a few. So you might well persuade me, but not until you understand what the project is actually doing and why, and are can engage with that rather than say things like this, which seems unconnected to what I've said or the SAFE project:

...and claiming that in a decentralized blockchain future all users are entirely their own full node and ultimate guardian of their data is a bit of a naive idea.

That's why I think you are making unwarranted assumptions. And you generalise things like this to "safe people"?

I think it would be better to focus on the decisions you object to, for you to understand the reasons for those decisions, and then to make the case for alternative choices. I can see valid arguments, and have argued in that direction myself, but as things stand I think you are overly optimistic about the current internet and the measures you've mentioned. I see them as very important, and think we need something fundamentally better in the longer term - for lay users, and no blockchain in sight :-). I admit though that I'm not very knowledgeable about all these issues and what is happening to address them. My reasoning is more big picture in this respect, but I can follow the technical arguments as well if you want to make them.

So as you feel strongly about this why not find out more about the risks that were considered, and why the balance at present is where it is? It is wrong to keep saying I'm saying https/TLS are not safe, because of one feature of the safe browser being on by default. It is not anyway set in stone, maybe it will be changed to "Open secure browsing tab". Nothing is fixed, everything is open to discussion and debated in depth. In one view, it's a feature that was introduced to help lay people who don't understand the full risks, and so are protected by default. In another it can be seen as having negative side effects. By all means let's dig into this.

You'll find that if anything characterises "safe people" it is a desire to get the best solution for Everyone - we take the E in SAFE very seriously! (SAFE = Secure Access For Everyone).

HTTP etc are valuable and essential improvements. Please come over to the safe forum and explain why you believe this decision is counter productive, and going to hurt users overall. I don't know web security well enough to debate this adequately on my own, and I am in any case open to your argument. I do say though that while keeping the pipe secure is a solid improvement, it is a) piecemeal, so leaves holes that lay people will be hurt by for a comfortable time, and b) ignores risks that are present in a system that will remain centralised and therefore exposed to risks outside the client-server transaction.

By the way, SAFEnetwork is not just about privacy or surveillance, but also service resilience, energy efficiency (ecology), transparency, redistribution and empowerment. People are regularly surprised when they dig into it, so it might be worth you bdelving further into it.

You seem to think SAFEnetwork will be hard for lay people to adopt and use ("bitcoin full node"), but (Secure) Access For Everyone is a serious and achievable goal: no blockchain, full client on mobile and IoT devices, and usability in line with existing user capability and expectations. If not, most people won't use it. It has to be better, not just more secure.

So you have not convinced me yet, but we've hardly touched on the issues IMO. I am though I believe already in agreement with regard to what is fair to expect of users, and how it is up to us to do our best on their behalf.

I know good arguments can be made for better usability against better security - I've made them myself, and not just at the above link.

If you think we made a bad decision for SAFEnetwork, the forum is a receptive place to raise your concerns and make your case: https://safenetforum.org I can assure you that safe people :-) don't wish to harm or adversely affect other important efforts which share our goals.

Thanks for the suggestion to look at Myst, I haven't myself since the very early days so it is a good idea.

Sorry, but writing book-length comments that merely repeat the previous points isn't helping much. I gave a few technical pointers that back up my opinion, and you managed to address none of them.

I said nothing about hard to adopt or hard to use. "Informed" is impossible to ever reach 100% imo, no matter how you package that thing. End users won't understand the technical foundation and thus are not entirely informed. Ever.

Also, my main point was that claiming that HTTPS and today's Web are entirely unsafe and not possible to make safe for everyone (which ironically is the goal of everyone working on it) is naive at best and dangerous for your project at worst. In my opinion, if a project can't coexist nicely with what literally billions of people use today to get all their stuff done online, then I don't see how it makes the world a better place. But that's just my opinion, and I don't have to spend much time on any particular technological experiment to reinforce it. I'm merely trying to give you feedback on "we'll mark all your stuff unsafe", and you can either take it or leave it. I'm not trying to influence you in any direction or to convince you to adopt my opinion.

I do find it hard to be concise, sorry about that, so I've tried keep this short :-)

My point is that your feedback is still not addressing the reality of what I've said or the SAFE project itself. At the same time I agree that there is a good argument in line with what you say. I guess I'm activated by what seems to be your having made your mind up to see the project in very negative terms, without having adequately understood me or the project. This is probably my fault, so I apologise for that too.

I will continue to work towards success of both projects and to foster ways for them to coexist and interoperate in ways that are consistent with their goals. And to give users as seamless an experience as possible should they wish to combine them.

If you want to gain more understanding of SAFEnetwork, I'm happy to help with that here or on either forum - but this I think you agree is not the easiest place for this kind of discussion.

I perfectly understand the basic ideas and concepts of SAFEnetwork. You seem to think that if I just read more about it, that would change my opinion on the security aspects of the Web. SAFEnetwork is not the only project trying to completely replace the Web; there's also GNUnet for example. I have the exact same issue with their rethoric in regards to HTTPS and DNS.

your feedback is still not addressing the reality of what I've said or the SAFE project itself.

I still don't understand how that's the case. My feedback doesn't regard the SAFE project itself at all. It regards their opinion about the security of the Web and marking it as "unsafe" for all their users, thus refusing to co-exist with it, according to your description of the situation.

remotestorage / remotestorage-widget

feature: configuration suited to the Safenetwork backend #11

Context

Feature: Ability to disable all non-SAFE features/resources