SAFEr Browser(s) Proposal

With all due respects, I find it unnerving when SAFE things I put money into seem to suffer from mission creep. As a non tech “simpleton” I want SAFE to be safe as possible out of the box. It seems to me there has to be a careful balance between gaining mass adoption through ease of use and making a SAFE technology available to those who seek the benefits of security and privacy. Smartphones are generally easy to get to grips with but most people don’t want to know what goes on under the hood and most don’t care about privacy or security. IMHO people who come to recognise and value what SAFE can offer will be willing to put in a bit of effort to set it up.

1 Like

Heh, No, you haven’t.

You’ve a lot of good points.

For me what was leaning me towards .safenet was the ability to have a feature complete, privacy centric browser like Brave. As well as portable code. But as you note (here and above):

Extensions are, perhaps, not desirable. And if that’s the case, then yeh, .safenet doesn’t make sense.

2 Likes

Personally I’m not convinced that we should continue to use .safenet. Sure, it would let us support more browsers (e.g. Chrome), but do we really need to support as many browsers as possible?

I’m pretty sure I would prefer to use safe: (simply because it looks better and makes it clearer that SAFE is a new protocol different from HTTP) even if it means that we can’t support Chrome.

Chrome users could simply download and use the SAFE Browser.

I think we need to have a longer discussion about this. I just created a new topic called Discussion: safe: or safe:// protocol versus .safenet domain.

10 Likes

Want to remove it you have to build chromium yourself.

1 Like

Oops sorry the question I raised caused so much confusion :slight_smile: . Let me start of by saying it should be completely fine to use “safe:”. I do think most of us are in the same page here but maybe some clarity is needed for why that question was raised and what it achieves in reality. What I was hoping to prevent was regressing back to approaches we specifically moved away from about a year back and looking through the last few posts, one thing I dont follow is how is “safe:” or “.safenet” have anything to do with security directly.

Either approach is basically syntactic sugar from what we followed in that discussion and one had the added point of being incompatible with a few other browsers(note few, not every single external browser). Now when we had safe_firefox_addon, not able to find the forum discussion thread, but maybe @happybeing can spot that one cos I remember a bunch of UX points were raised then and I do remember specific discussions about not using an approach that isolates targeted users and that was when I think the protocol idea was switched to .safenet.

Main reason for that question was to make sure we had a motive to intentionally move back into that scope again and it was considered in the discussions.

While I do get the idea of “recommend people explicitly to use the SAFE browser”, I dont see how this syntactic url notation enforces that, cos if we wanted this, I’m guessing we need to do more to absolutely restrict usage from any other browser as some browsers also allow the override of the protocol. So are we ok with these browsers having extensions if someone builds it in this case?

Also dont know about “enforcing” either “SAFE Browser” or “No Browser”, thinking about it, you can easily scale that idea to say “Operating Systems” which can also compromise a users endpoint privacy. Now would we then enforce “Either use a linux mint distro from source you compile” or “No SAFE network for you”? option one with OS would certainly be more safer than windows or OSX I’d guess?

This question was to justify we had discussions for this version of syntactic sugar if anything for url identification when say “Tor” for example doesn’t do the same. So it was merely to make sure we don’t miss anything out if anything than switch the plan around :slight_smile:

In terms of either url syntax notation, personally the motivation to use the SAFE Browser against plugins with proxy apps is we as users wouldn’t need to run a separate proxy and it no longer needs to be bundled with the launcher and the SAFE ecosystem is presented via the browser bundle securely that helps me remain anonymous. The url itself doesn’t do much for that or properly if anything I’d guess.

10 Likes

A link to an article concerning advice for the timing of security warning pop ups: People ignore software security warnings up to 90 percent of the time
Maybe not that relevant to the discussion .safenet vs safe:, but also something to take into account.

Yes but discourage is different to restrict completely IMO. and it didnt seem like we were proposing options to “discourage”, most of the points were along the lines of “enforce complete restriction from other browsers cos they’re not safe” and my main point was if this was the “overwhelming requirement” then the “safe:” syntax doesnt really achieve that for all external browsers and the requirement might need to get met by something else.

same as above. It doesn’t. we had a firefox extension that worked with safe: ourselves last October. What we’re proposing is increasing the barrier for entry in “some” browsers, thats not achieving a more secure deliverable.

Don’t think I mentioned anything about plugins :slight_smile: any syntax format is delivered via the SAFE Browser which is a standalone system.

We shouldn’t underestimate users and what they’re accustomed to and how reluctant they’d be for “change”. There certainly are places where security requires the giving up of UX ease, we just need to face them as is than consider them as “simple enough”

Yes because of the browser, not the way we decorate the url and it doesnt have anything to do with the SAFE browser either way.

I think as I mentioned before, I just hope the average reader is clear enough on what we “get” out of a syntactic url enforcement as its not directly going to make them or the system any more secure. and that was my example to operating systems. If we used pthreads directly thereby keeping windows not compilable, it doesnt make the network any more safer. Same way if we choose a library thats cross-os compatible(depending on the lib ofc), it isnt making the system any less secure.

To reiterate, its not about how the url syntax is defined. “safe:” is completely fine. It’s just to make a future reader note that, using this is somehow not going to make the SAFE Browser or the network any more secure. For all the discussions, if the answer was “Oh we just like the way safe: looks compared to a .safenet”, I’d say thats completely fine than base it on a security notion which it doesnt really deliver on.

4 Likes

Yep, you should certainly get some sleep :slight_smile:

Not a problem and these discussions are very important to happen. Well that was the whole point of the Q&A is to make clear whats being proposed and “why” and not have things left to guesses. So thanks a bunch for chipping in too.

and I think thats the key point is having it detailed the specific motivation for a particular changeset. Like dev skillset doesn’t need to be advanced just by having to conform to a safe: syntax, if the target users were in firefox. It’s already been done.

Yes I am and I was because that was the only point that was mentioned as something that by itself enforces user security and I’m glad if we can see it isnt as so. and the requirement there “if needed” probably needs debated exclusively and then proposals for the same detailed.

There have been a few points that get mixed mentions like “Plugin/Extensions” vs “Dedicated Browsers”, “url syntax notation”, “restricting network access to any system that isnt sandboxed exclusively” and thats maybe where the confusion stems from, but my posts in this thread as I mentioned in the first one was just abt what was raised in the Q&A yesterday abt syntax notation and probe to figure out its motivation and clarify its purpose and not have it mask something else.

6 Likes

This changes very very little, to me.

I still feel like we were finally advertised “safe:” as we all wanted all along, and after sending the MAID, this offer was ripped back away from us.

2 Likes

@joshuef we are not looking for a browser with all the bells and whistles. All we want is a browser that can surf SAFE: sites and only SAFE: sites.

@frabrunelle it would also be nice to bundle this browser with the launcher/gateway.

3 Likes

Nothing has been ripped back.

There’s active discussion over here

Also (noted above, but also here for clarity, since I failed in that with the update last night):

So apologies for the alarm. My intent was only to open discussion on that, not to pull a fast one on anyone.


Heh, yeh, I’m getting this impression.

I’ll hold off on an update to the OP for a little longer, but the discussion over there and above, are very helpful

4 Likes

And we should all reallllly stop acting like we’re talking about anything other than chrome.

Chrome is the only browser that isn’t allowing custom protocols.

…why do we care about chrome so much? Baffles me. It’s just one browser.

4 Likes

We probably should care less about Chrome, but it has a big market share at the moment: Browser market share

Internet explorer used to have a big market share too :wink:

2 Likes

Important…

2 Likes

I get that this is about adoption but it’s also about overall usibility and bending everything for the sake of one browser is being overly accommodating to google. Google sucks and that’s part of the reason I’m here and use other browsers and DuckDuckGo as my search engine. Once I learned more about Google it drove me away. Stick with what is good for the users of the network and what other browsers will allow, safe:

2 Likes

Perhaps I missed it with all of the different conversations going on but could someone please explain what the benifits of a creating a SAFE browser is if the focus is on mass adoption through existing browsers.
My understanding is foggy at best.
ie. benefits of SAFEr using .safenet over other browsers.

1 Like