Discussion: safe: or safe:// protocol versus .safenet domain

Development
1

During the SAFE Browser Q&A with @joshuef yesterday, we discussed SAFE protocols (safe: and safe://) and domains (.safenet) from 4:52 to 12:04.

For anyone who wants to listen to that part, click here to download a recording of the Q&A. It’s an Ogg file, so you will need to use a software such as VLC media player to play it. So before reading the rest of this post, you might want to listen from 4:52 to 12:04.

First of all, we discussed the possibility of using safe: in the SAFE Browser. It would make it really clear that you are using SAFE and that it’s a new protocol different from HTTP.

Then we talked about using safe: in existing browsers (e.g. Firefox and Chrome). We think it would be possible to build a Firefox extension that supports safe:, but not a Chrome extension. And so if we want to build a Chrome extension for browsing SAFE websites, we would end up using .safenet for Chrome. And it might also be a problem if we want to build extensions in other browsers, I’m not sure.

Having both safe: and .safenet would make it more complex for users and developers. And so assuming that we want to have a Chrome extension, it would make sense to focus on .safenet in order for all SAFE URLs to be consistent.

But I’m not convinced that we really want to have a Chrome extension. Personally I think it would be fine if we tell users that they need to use another browser (e.g. a SAFE Browser).

Around 11:18, I suggested that safe: links would still be clickable in browsers such as Chrome, but they would open in your SAFE Browser. It would be similar to what happens when you click on a bitcoin: link and it opens in your Bitcoin wallet. Or a magnet: link that opens in your torrent client.

I’m also concerned that it’s not a good idea to encourage users to browse SAFE using existing browsers (e.g. via a Chrome extension) and I agree with @Seneca that there are many security benefits to using a dedicated browser:

Here are some of the questions I think we need to discuss:

  • Are we OK with using safe: or safe:// even if it means that we wouldn’t be able to build SAFE extensions for some browsers (e.g. Chrome)?

  • What if some developers decide to build a Chrome extension that uses .safenet and it becomes popular? Or is this unlikely to happen since the SAFE Browser could be installed at the same time as SAFE Launcher and so users wouldn’t feel the need to have a Chrome extension?

  • What are the security issues if we decide to support SAFE in existing browsers (e.g. via a Chrome extension)? Is it really worth the effort or should we focus on a SAFE Browser?

Also, if we choose to fork Brave, we would have to use .safenet, at least until the following issue is solved:

With Beaker, we don’t have this issue, so it would work fine if we decide to use safe:

Considering that each option has pros and cons and that ideally we would like to be consistent about using the same option everywhere, which option do you prefer?

20 Likes
2

I began my arguments here:

https://forum.autonomi.community/t/safer-browser-s-proposal-donation-address-in-op/10336/167

Check that thread to get a better picture of what I think on the matter. That’s partly what triggered this new poll.

3 Likes
3

Thanks @frabrunelle for explaining this clearly for the (less technical) members here, very useful :slight_smile:

6 Likes
4

Since I’ll probably be part of a very small minority voting for the “.safenet” option I’ll add my few cents worth on why I think it’s actually the correct option.

I think safenet + clearnet mixing is a great way to drive adoption enabling hybrid services and use cases.
Indeed this comes with a mixing of security models but it also let content creators utilise the substantial ongoing investments that actually goes into modern browsers and their runtimes.

Effort that is totally infeasible to mirror in a reasonable way, a separate browser, if it aims to work and feel like users regular browser of choice will end up being inferior in every conceivable way.

There’s in my mind roughly two sensible options either the “SAFE Browser” needs to be similar enough to mainstream browsers to almost be indistinguishable (not very likely to happen) or it needs to be substantially different as to not be compared to it.

Which leads to my opinion on “safe://” such a thing should be utilized for something different enough from the regular clearnet as to not be compared to it or likened to it. Essentially something like gopher://
different markup, different rules, no crossover.

This would give users two options for accessing safenet

  1. Mixed (plugin/proxy) mode where the regular web rules applies but content is free and publishers are protected by the network.
  2. safe:// and a browser/reader that uses a protocol and set of constraints radically different from how html and javascript is used on clearnet. This gives superior control over how resources are linked, loaded and accessed without doing to much deep plumbing.

One route for option two would ofcourse be to leverage the rendering and layout capabilities from an existing browser project without bringing the network, plugin, etc bits into play.

Just my thoughts.

2 Likes
5

I understand your concerns about adoption rates, but I see it the other way round. I think, once SAFE is out of beta, stable and has proven that it’s scaleable it will draw a LOT of attention. At this point adoption rate won’t be a concern anymore, because there will be so many valuable apps and use-cases that current browsers might even consider to implement the new protocol safe:// I think this is the ultimate goal which should be targeted!

Think about the crome-typical browser tabs (on top of the window). At first it was strange but now every browser has it. Ultimately it will be the same with safe://

Sticking with the .safenet TLD and therefore “abusing” the http prefix is just irritating as SAFE could in fact be seen as a new protocol/infrastructure and won’t help achieving the goal pictured above.

6 Likes
6

I’m not a technical person, but I’ve been thinking about this debate for a while now.

My initial instinct was that access and ease of use were by far the most important issues.

Having pondered it for a while I think I’m actually with the dissenters now.

This is a new internet! The world will need to adapt a little, we mustn’t compromise the first impression we give or the security users enjoy for the sake of ‘making it easier’… although obvs we need to make it as easy as possible where that doesn’t involve compromises.

‘safe:’ sends a very powerful message imo.

Early adopters will likely be very security conscious, so i’d like us to send a clear message of what this is and keep it as secure as possible too.

I contributed 1btc to the browser and I’d like to see safe: and not .safenet. Although I would have given either way and will not complain regardless of what is decided. I really appreciate the work being done, but I would be happier if it were ‘safe:’

I’m prepared to be wrong though, it definitely isn’t an easy call. :confused:

15 Likes
7

It’s a tough choice really. It’s too bad we have to make a choice at all. I would be fine having both the option to use the “guaranteed” secure SAFE(r) browser and the option to use a plugin in other browsers. Reading the pros and cons and the cases that people make for both sides I lean towards the choice for safe:// if a choice has to be made.

I do think it will hinder adoption if we choose to go with a dedicated browser and the safe:// protocol. A lot of people are lazy and security isn’t a concern for a lot of people. I mean heck there’s countless people doing everything while signed in to their Google account :confounded:

3 Likes
8

Stirring the pot and not necessarily what I think we should do…

safe:

This is nice in that anyone seeing a safe: URL is given a strong hint that it is not a web URL.

For example “safe:metaquestions” versus “metaquestions.com” or “http://metaquestions.com” etc.

Or “safe:blog.metaquestions” versus “blog.metaquestions.com” or “http://blog.metaquestions.com” and so on.

Lots of us (me me me anyway :slight_smile:) like the cleanness and bold “this is safe” message of this, though as @Viv points out in the topic which @Pierce links above, it doesn’t necessarily improve security in the way we might assume (because people can still build bridges from legacy browsers and what not).

In the past I’ve been advocating things based on my hope that by supporting legacy browsers we would piggy back on all sorts of things that would help adoption of SAFEnetwork. I am no longer seeing this possibility, and so reconsidering. In fact, I wonder if we might be better off in this respect by ignoring them and just trying to provide the cleanest user experience with our own browser. If others want to build crappy links from old browsers that’s fine too, but when people search out SAFEnetwork, if we have the best or rather easiest solution, that’s what most people will use: they’ll follow our guide, download our client. Later, rival clients will follow (just as happened with Netscape, Internet Explorer and Chrome etc), but they’ll have to improve on the standard we set at this point in time in order to succeed.

So, and not wishing to make @cretz choke on his breakfast, this leads me to consider merging the browser and launcher. For two reasons:

  • security is not only about making bad things really really hard. It is also improved by making the right thing the easiest thing for users to do. And if to get on SAFEnetwork you just download one client, and that is the one and only place you log in, and is both able to browse the SAFEnetwork and authorise third party SAFE Apps, why would you use a legacy browser which also needs a launcher and/or plugin?
  • this approach gives a vastly improved user experience IMO - and a much easier to understand and follow route to adoption than: download a “launcher” (a what? what does it do? what does it “launch”?..confusing IMO) and then set up one of several options (a plugin for my browser, oh wait I’m using chrome so I need a proxy, what’s a proxy, what’s a plugin…granny will never get on SAFEnetwork I’m afraid :wink:) just to begin browsing the network. Eughhhh! Horrible.

A big question for us is how these choices affect user experience (both to get started and to use SAFEnetwork) because ease of adoption is so important. We just should not ignore this is my concern.

But TBH I’m wondering if this single step download the SAFEnetwork Browser (with built in launcher) might be the smoothest and easiest route - and therefore maximise adoption anyway.

13 Likes
9

Any existing open source browser can be made to work with safe://, i don’t know about the closed ones and their plugin/extension architecture.

It might not be as elegant and simple as installing a plugin if you are right about this restriction in chromium, some people have claimed otherwise when this has been discussed previously.

First step then is to start lobbying the chromium developers, make clean good pull requests implementing custom protocol support for extensions. If this does not work even after the network has properly launched and has a sizeable user base and most other browsers have the support, then other methods could be looked into.

MANY people are going to insist using only one browser. Go look at the reddit discussions about openbazaar, the only real criticism that is cited again and again is the separate browser. Numerous people directly say that because of it they are not interested in the project.

The only way this could be overcome is if safe already took over the world, which is hard if many refuse to use it. Because the popularity needed is not only that of google+, which has failed. It is that of facebook, only it has managed such a network effect that people use it despite hating it.

1 Like
10

@frabrunelle I think a poll is premature. We need to define the options and their properties and debate them first. I’m not ready to vote at this point.

5 Likes
11

Agree. More time needed to digest and discuss.

3 Likes
12

I agree. Some effort should be put into making absolutely sure what the situation is with chromium currently. Otherwise this aspect could be ignored but unfortunately it is the most popular browser today. If only firefox had not gone full retard and held it’s place as no.1 this would be a non-issue.

1 Like
13

The use of .safenet came from the desire to maintain compatibility for 3rd party browsers and their respective plugins. This IMO should be abandoned altogether. I think encouraging users to install plugins for browsers that in most cases are designed to breach a users privacy would be a disaster. The maintenance overhead is ridiculous and the security issues are serious. We risk acclimating users to the inferior plugin system.

A browser is just as easy to install and is neatly maintainable. Why divide our mental and physical resources to support extensions that will each have their unique issues and will always be subject to the 3rd parties changes. Every time you receive an upgrade from chrome/firefox/etc, it could possibly undermine the security provided by the plugin. The developers would have to keep up with the release cycle of these browsers when they could be making useful apps for the network.

4 Likes
14

Sure, I’ll remove the poll for now :slight_smile: But it would interesting to do one at some point.

7 Likes
15

It could be a one step setup that installs both the launcher and browser at the same time. Though separate, they could intelligently invoke each other when needed. This would create an almost seamless experience. If I were to try and visit a SAFE url, I’d be informed by the browser that I need to log into the launcher. It would then open my launcher for me to enter my credentials and vice versa.

4 Likes
16

The Tor network has their own browser specifically because they understand the poor security of browsers. It would make sense for us to start with a browser that has the same security measures in place as the tor browser as otherwise we really can’t claim to have the same level of security (or better) than Tor. The clearnet has many vulnerabilities - a good proportion of those happen at the user/browser end.

As, I believe, Safenet will be using javascript extensively and as javascript is one of the ways that makes clearnet users vulnerable to attack, having a separate browser for the clearnet and Safenet only makes good sense.

I do not see any strong case for .safenet (shared clearnet browser) – allowing use of an insecure browser would attract a lot of criticism from members of the Tor community who we need to woo to Safenet in order to jumpstart the transition.

There is also a large issue of being able to use TLD’s in Safenet - which will be important for many organizations/companies to maintain their brand identity in Safenet.

4 Likes
17

I’ll make it simple.

My vote will go for whatever results in greater adoption.

No adoption, no Maidsafe.

If Maidsafe loses steam from the latest round of pump it risks being relagated to the techno-boneyard and forever banished from the new technology blogs.

Maidsafe will evolve into being everything to everyone, but it first needs to get out there and into the hands of all the early adopters who will bring new ideas and fresh sets of eyes. Too much narrow thinking on this forum. Way too few smart people to make these hard and fast life/company altering decisions.

Get the product out. Attract more people. Increase the braintrust.

EDIT: Quicker and greater adoption,

18

Adoption rates depend on the behavior of people - and you can’t know that in advance, there are reasons on both sides as to what will drive adoption. So the best option is to do what you do know will make a difference - maintain a secure network - the point of SAFEnet in the first place.

1 Like
19

We do know enough about human behavior. We know for a fact that clunky will not work. Many people on this forum cannot see the forest for the trees. There’s something new every day in technology. The more this “safe” internet is made “different” from the incumbents with extremely deep pockets, the greater the risks.

Debate this all you want. Bit dont lose sight of the fact that there is a clock ticking louder and louder.

Get it out to as many people as you can and do the fine tuning it in the wild.

Im not suggesting a substandard release, Im suggesting perfection and utopia dont exist in reality.

1 Like
20

@Pierce:

It could be a one step setup that installs both the launcher and browser at the same time.

It is certainty possible to maintain the separation and create a smoother experience, but I maintain all in one will be a better experience in the end.

This is because:

  • there would be no launcher, which is a source of confusion in itself that we would seek to keep hidden from unsuspecting users. Why bother?
  • it requires all development of the two apps (and all thinking about what they do and how) to keep the other in mind, and drive for a unified experience. This is much harder with two apps (especially with different people working on each) than one, and ultimately will cause problems = not be as good as one App.
1 Like