SAFEr Browser(s) Proposal

Community Proposals
183

So first, all in the proposal can still be debated / changed. This is just updated with what was spoken about yesterday.

To address concerns about .pac files from @whiteoutmashups and @nowfeelsafer.

Any browser implementation will still be proxyless

.safenet

Using this over safe: does not mean we have to have a proxy. This is talking about a url convention, not about removing the proxy-less nature of the browser.

I’ll write out something more on the why of this (and I believe @frabrunelle will be posting an update/summation of the convo yesterday) , just wanted to fire this in to address that concern.

184

We’re at $3660 at the moment :thumbsup:

185

Safe: vs .safenet

So first, and to reiterate above, .safenet does not mean a proxy is needed. Any SAFEr Browser will be proxy-less.

So, I note a lot of strong feelings about this, which is great. And I see I might have been too quick on the draw updating the OP. Apologies for that. Please don’t consider this update to be final.

So, the kickoff of this point raised by @viv was safe: is a blocker for a lot of browser extension implementations. And this is going to limit people’s access to safe.

Chrome / Brave do not allow custom protocols. So this limits potential userbase for SAFE.

.safenet can be applied across every instance, via extension or not. This allows us to keep a consistent user experience.

Safe browser implementation.

Any implementation of either of these setups doesn’t vary greatly in terms of implementation (it’s a matter of when to trigger launcher access in a url). But it does limit what we can use/fork as our SAFEr Browser.

A safe: browser would need to be Beaker fork (if I’m forking and not writing one from scratch…), which is a great browser, but it’s not the most feature complete. And if we’re aiming to have the SAFE browser be the main browser for users, then something more polished like Brave would be preferable.

.safenet enables a Brave fork As well as consistency across implementations (and so .safenet in other browsers bringing more people to the network).

So in the end, it’s kind of a question of ease of use vs safe:, which is limiting to both the scope and polish of the browser. (At least at this early stage).

This is a fair point and something we discussed. Enabling use in chrome/FF etc, we don’t have control over what other extensions are present.

Sorry you feel this way. This was tooootally not my intention here. Only to update on what we were thinking and ideally to bring in more feedback on this. Hopefully this answer at least clarifies the why of this.

This isn’t final, just an update. And it can all still all be debated. I’m really not here to try and pull the ole’ switcheroo. I just want to make a browser implementation that helps SAFE in the best way. Originally, this was to produce code that could be ported to other browsers easily.

As @Pierce notes, perhaps this in itself isn’t desirable?

6 Likes
186

This safe: functionality already exists in the beaker POC. I still didn’t manage to get the build up anywhere as I’m still waiting on a new router for the house :|.

But if you want to get into npm, you can pull it and build it (only tested on OSX so far!)

Also, it’s not yet safe only, just to be clear. It still allows clearnet etc, just operates without a proxy.

1 Like
187

Given the need for data storage of histroy/favs all user data on the network, which wasn’t in my original proposal, and the idea that the browser should either a) be packaged with the launcher eventually or b) clearly point the user to download the launcher. I decided to remove it as not needed.

There’s nothing to say it can’t be added to the browser later, but for now it kind of muddies the waters some, and doesn’t have a high prio compared to user data security, which will be non-trivial to implement.

1 Like
188

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
190

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
191

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
192

749×314 22.3 KB

Want to remove it you have to build chromium yourself.

1 Like
193

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
194

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.

196

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
198

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
199

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
200

@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
201

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