Future of a SAFE Browser and node/webAPIs

General
9

Definitely, AND no external , non clickable, requests either : webfonts, jquery, css, images, anything really. One such external request goes out, and we get a “AFE” browser : Access For Everyone, with the “Secure” part stripped out.

I suppose down the road there will exist two kinds of Safe browsers : one family that is HTTP clearnet disabled ( ie : there is no code inside to process http clearnet links ), sealed off from clearnet, with hardened and audited code. This family would passively handle security for users, and would be used in higher risk situations where security / privacy is the main goal.
A second family would allow both clearnet and Safe access, and would leave the responsability of security choices to its users : you are provided with a tool that can give you a secure environment, but you can open the fences if you want to, at your own risks. By mitigating security tolerance, this family would certainly help to grow awareness and adoption of the Safe network, with emphasis on the serverless aspect.

It should be be always kept in mind that Convenience is n°1 enemy when it comes to security and privacy.

6 Likes
10

What about a Rust browser (https://servo.org/) for a Rust network? :wink:

3 Likes
11

Sounds like with safemode on/off a safe site could sit in the background of a tab and wait for the user to turn off safe mode and then start sending connecting to http servers to sniff out the users ip adress.

I think it shouldn’t be a problem to support both safe and http in a single browser, but if it going to be secure then the tabs would have to be completely isolated so that it wouldn’t really be any different from opening sites in different browsers. To make it convenient the tab could switch mode based on the url, if a user typed safe:// something the tab could switch to safe mode and then if the user typed http:// it could switch to http mode. It shouldn’t be possible to switch mode by clicking links though as sites could attach identifiers to the url to link the http and safe identities.

edit: perhaps a reasonably secure way to make links clickable when visiting a SAFE site could be to open them in a Tor tab?

2 Likes
12

It would be great if the default API in the browser and what users would be encouraged to use would be Rust WebAssembly API. Of course many people want to use JavaScript, that’s fine for many use cases and there should be nothing stopping them from doing so.

The problem with JavaScript is when you make an app that deals with money, especially irreversible transaction like you have with cryptocurrencies.

On the web today it is rarely a complete disaster if you online bank has a couple JavaScript bugs, they’re extremely easy to make and can be hard to find unless you have very thorough test coverage of everything, but most of the important stuff happens on the server and transactions can be reversed after all.

With SAFE, the important stuff will happen on the client and transactions can’t be reversed. JavaScript is a recipe for disaster in this case. It’s not easy to write secure code in Rust, but it’s much easier than doing so in JavaScript. With Rust at least you have a compiler that enforces some things, with JavaScript there’s nothing enforced. You can have extensive tes coverage, use JavaScript Lint etc, but nothing forces you to do so, so many won’t. Even with all this, sneaky bugs that the compiler in Rust would detect, can go undetected.

People will make all kinds of apps and sites on SAFE and for many it won’t matter if they have even tons of bugs, but there will also be many where it is a big deal and for those Rust would be better.

Already Rust is kinda the default for native apps. Sure you can use node js and that’s great, but having Rust being the default language and what people are encouraged to use throughout the whole stack would have lots of advantages, not only in terms of security, but also code reusability etc.

3 Likes
13

Did you check out Vivaldi? Also has a strong privacy focus

1 Like
14

Dedicated browser would be good, and probably could use WebKit or Servo but what about all the functionality around just displaying sites? I don’t know which of them are included in rendering engines and which are not, but implementing things like developer tools, indexeddb, calendar for date input, video playback, webrtc… isn’t that too much?

Perhaps the only way is to drop browser support and just limit to native apps? There is one API less to maintain :slight_smile: When somebody wants to use HTML/CSS/JS, they always have Electron. What’s the advantage of web apps that we so desperately need? One post on the topic from a month ago:

1 Like
15

That post suggest improving the web rather than reverting back to old fashioned native apps. That is an interesting option, although it if it it’s too different from what people are used to it might be difficult to get a lot of people to develop for it, at least in the beginning.

There are several interesting points in that post which could be made true for SAFE

A clear notion of app identity

SAFE apps have ids

A unified data representation from backend to frontend

A dynamic site on SAFE is always rendered in the browser by JavaScript or WebAssembly, rather than on the server and the site connects directly to the database, so this would be a natural way of doing things on SAFE. Perhaps a binary version of JSON or something like that would work well.

Binary protocols and APIs

Perhaps protocol buffer could work for this.

Platform level user authentication

SAFE has this

IDE oriented development

This is a question of tools being developed. JavaScript isn’t well suited for advanced IDEs, but Rust could improve the process.

Components, modules and a great UI layout system — just like regular desktop or mobile development.

This touches to one of the core problems of the web. HTML and CSS is a big hack that’s not all that well suited for making apps, but it is improving all the time and improving this shouldn’t be the focus of MaidSafe I think.

16

Not read the post yet, but just came across Phuzzy Browser related to the SOLID / Linked Data project and reading this page had me wondering if there are some relevant ideas here. I’ll read more about it once I’ve read the OP but too busy atm:

http://phuzzy.link/

17

busybeing!

@joshuef, did you try and contact developer teams of browsers? They might be the best people to judge wether their product suits SAFE’s needs…

2 Likes
18

A fully featured browser is an inevitability for SAFE without the need to piggyback off existing projects. Let’s not attempt to endlessly tame large complicated beasts like Firefox. That is effort better directed towards building a custom and efficient browser who’s inner workings are of our own creation. Meaning less unknowns.

For a successful launch browser, we require a few things done well for rapid adoption. It should be able to stream music, video, follow links, post and display static/dynamic data at the very least. The control/options and display framework can be lifted from some other open source projects. At launch our commitment to security, privacy, and freedom should be clear to users. Most of which will be purists.

As time advances, so too will the browsers’ features. Likely keeping pace with the increase of novice or pampered users. Http access should be secondary in accordance to our desired paradigm change.

We’re persuing change. This not an endeavor to conform to current standards, but instead to break through while strategically balancing SAFEs’ presence by adapting to those who need hand holding. If we do as most projects, we miss an opportunity to create something easily sustainable as entry point to the network. Being open source in the first place means that these features (http, advanced rendering, etc) will be built or their creation assisted by the greater collaborative community. No doubt behemoths like Firefox will become entry points into SAFE at some point, but those that create the extensions will have spared @maidsafe_team frustrating and wasteful maintenance in addition to embarrassing security breaches.

Going with current mammoth browsers is analogous to driving a tricked out RV when all you need to do is get to work daily. Too many inefficiencies, complexities, and considerations just to accomplish simple tasks. With a small modular vehicle we can elegantly add advanced systems with the advantage of having it designed with high uncompromising security in mind. Let the ideals of SAFE run through it’s veins! Plant our flag! Let’s not embed ourselves in a reckless host and risk us being eaten along with it. Instead plant the seed in a fertile womb and watch SAFE browser grow :wink:

4 Likes
19

Based on observed ‘majority usage patterns’ most people most of the time want content delivery. Simple to install, simple to use, performant, no bullshit. Just attach the firehose to my face and let me drink up all the content. See 1% rule, but beware there are some real philosophical conundrums to be faced when exploring this idea.

Everything else is secondary to content consumption. Not saying I agree with this usage, but it’s what has been observed.

Rephrased as ‘would that be secure enough’ I would say very much yes for most people most of the time. I’m going to combine security and privacy together here, but without a ‘threat model’ the idea of ‘secure enough’ is pretty intangible. Who is this for and what risks are they trying protect against? This is not actually defined, but needs to be.

I think a safe browser should not have http. Most consumption happens on mobile / tablet, and that already means users are going into different apps for facebook / instagram / web browsing etc anyhow, so I think having web browser for http:// and safe browser for safe:// works best for most people most of the time.

Should there be workarounds / hacks? No. Build the firehose for seamless content delivery, and when people drink enough and want to start adding their own content they’ll be motivated to work it out. I really do think there’s a significant market for a read-only safe browser, at least to get people started and confident.

Mostly, I think a lot of user design / research is missing - usage patterns, threat models, perceived risks, actual risks, concerns, etc - without this the design is for ‘nobody’.

To start the collection of data with my own preferences: I would be happy with a very simple fast readonly browser that allowed private and secure consumption of all content on the safe network (html, video, audio, etc). Anything more than that (eg commenting, posting, uploading, buying etc) I’m happy to go to a specialized app or a different ‘more advanced’ safe browser with tweaks for privacy and interaction etc.

But make my consumption experience perfect. That is nonnegotiable.

7 Likes
20

As I read more I feel the case for a SAFE Browser built from scratch, only gets stronger.

1 Like
21

My preference: I’d be very unhappy about having to use individual apps for anything that needed posting data to the network. I don’t think I’d like to have different browsers for downloads and uploads either, but perhaps having a read-only mode could be nice, something that looked a bit like private mode in regular browsers, so that you could open read-only tabs or read-only windows.

4 Likes
22

Totally agree. I agree that a general browser with write-ability will (obviously) be required.

But my point is, when I’m 90% of the time just browsing, I don’t want to do that in what is essentially an iframe nested within my bank account. That’s simply not an ok way to browse. Even with login / logout as a toggle in a menu item probably isn’t acceptable if 90% of my use is just browsing. I don’t want to even have to think about that risk at all.

For a fully-featured browser, here’s my thoughts:

  • ability to rate limit apps so they can’t drain my account
  • easy way to raise the rate limit for an app for a specific limited amount of time
  • manage multiple accounts (identities) at once
  • manage which app is authenticated to which account
  • done in a way that does not lead to permissions / auth fatigue

This seems like a bit of a shitty user experience but I think it’s necessary if the browser is going to be nested inside a bank account, which is how it has to be for it to be useful beyond just browsing.

The reason I’m passionate about this is because I’ve seen a change in my own ‘use’ of the safe network: I don’t recommend it to people any more. I used to recommend it because the safe network was easy to use and unlike bitcoin, safe really could scale so everyone would be able to use it. But if it’s any harder to get my friends started than saying ‘install this app, type this url’ it becomes hard for me to recommend it, just like bitcoin wallets back in the day.

A simply designed browser directly solves my (and others) immediate marketing and sales problem. It’s much more than just a technical thing. Perhaps I’m extrapolating this idea too far, but given the chop and change lately in safe frontends, I think focusing on delivering simple stuff is probably a good idea.

6 Likes
23

Electron (which is what the current SAFE Browser is based on, and a few other larger desktop apps), is actually based upon chromium.

So any ‘from scratch’ browser we’d build (as we’re talking here), is actually most likely something built atop this. I think ‘from scratch’ is probably misleading, tbh. We’re not really going ‘from scratch’, more looking at a from scratch codebase / UI for the browser (atop electron/chromium). It’s not nearly as big a task as a true ‘from scratch’ build.

2 Likes
24

Yeh, that’s a concern.

That would be the ideal. But this is where concerns of browser detection/fingerprinting would come in. So you could access HTTP, ideally in a way that won’t affect any of your safe tabs, BUT, any site could (potentially) detect that you’re running the SAFE Browser. Which is another concern.

1 Like
25

Just to clarify, there’s not a significant difference between accessing network calls via WebAssembly (wasm) rust code in a browser and using javascript DOM APIs as we have now.

WASM needs to be access via javascript anyway to trigger functionality.

Rust code accessed via JS APIs is actually doing this same thing, just triggering the Rust code outwith of its window using RPCs.

26

Will give it a look, thanks :+1:

27

Not as yet, nope…[20chars]

28

Thanks @mav, some good food for thought there.

I think what you and @intrz are starting there as basic/required/advanced features is both useful for this decision and a good starting point think about where the browser could go. :+1: So thanks for that too.

3 Likes