Future of a SAFE Browser and node/webAPIs


#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.


#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.


#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.


#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.


#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.


#29

What I mean is really that it would be great to have all documentation for the APIs in Rust in addition to JavaScript, together with examples, so that it would be easy to get started and developers would be encouraged to take this route.

When someone writes a web app, writing it in Rust normally wouldn’t even cross their mind.

If there was a page to get started writing web apps in SAFE that would describe some basic and then have something like two big buttons, click here to get started with JavaScript and click here to get started with Rust, that would then go to some page with some basic examples and API documentation.


#30

Aha, thanks for clarifying.

Yeh makes sense. And probably good even to note that Rust or other languages can be compiled to webAssembly so you can run a webapp instead of having to go through setting up a desktop/mobile app etc. :+1:


#31

Several tricky issues related to usability in this topic. Biting them off one at a time:

  • managing app usage costs (PUT costs)

I think we should try to keep this (and everything else!) very simple and use familiar and proven models where they already exist. For app data usage and costs, we have mobile phone billing systems and data management on mobiles as proven, very widely used and familiar models. These work well, people are used to them, and it is essentially the same problem so I think we should consider doing something very similar.

The problem they solve is the problem we want to solve as a user:

  • I need to monitor and control my spending

To achieve this, mobile companies offer either pay as you go usage, or fixed monthly allowances for a regular monthly fee.

These models are already familiar to anyone with a mobile phone (ie virtually all SAFE users) and should be fit for this purpose because it is essentially the same problem.

  • Pay as you go - this is essentially the default on SAFE: topping up a wallet as needed. The UI needs to make monitoring this unobtrusive and easy. In addition, we can provide the option of setting a…

  • Monthly (or whatever) total spending allowance. Here the browser limits the overrall spending for all apps once a limit is reached, but that limit is reset each month. So if you stay within it you don’t need to do anything - fire and forget! It’s simple and works well for most of us I think. If the limit is hit, you are notified and decide what to do: increase the limit per month from now on, or just for this period, or stop!

This avoids the complexity and effort of managing individual app limits, but as with your mobile phone we could provide a way to look at per app PUT usage as well. So a user can find out what is using up the allowance they set and choose what to do about it. (This might be tricky technically, so perhaps not practical or at least not available in the early implementation, but I don’t think it is essential - see next).

I think some of us might think we want individual app allowances, but I’d be very surprised if we made use of them. In fact, I think we’ll very rarely even look at what data individual apps use, and instead tend to make adjustments to our behaviour or app selection based on how much data our overall activity is consuming, and how much we want to spend per month.

How often do you look at individual app data consumption on your phone? I know I very rarely look at this - maybe twice ever. I do though keep an eye on how much of my monthly data allowance I have used and from time to time that can affect how much streaming video I watch, but not very often.

I’m interested to know whether this is true for you, or if you have different experiences of monitoring data usage on your phone.


#32

I just look at the general usage from time to time, never per app for the simple reason that I know that the only app that uses significantly more data than any other is YouTube. What I do monitor more frequently is battery usage, because that’s a resource where there sometimes is significant difference between different apps and sometimes there’s a single app quickly draining the battery. If I topped up a wallet in the browser, but it got emptied suspiciously fast, I would check per app usage to see if I could find the culprit, but apart from this I would probably never check.

It might be worth having a look at Brave Payments also. In Brave you can fill up a wallet with BATs and it will give the money to sites based on how much you use them.

Antoher thing that I’ve mentioned before in the other forum is that there’s a few HTML5 features that could use specific implementations for SAFE. I wonder how that might work with the different options. Not stuff needed from day one, but something to keep in mind.

An example is the HTML5 Geo API. To make this work with SAFE in a way that is completely anonymous and private, there would need to be database of IP to country mappings located on the SAFE network. Since the browser application knows the ip address of a user, the location of the user would be looked up by the browser fetching the relevant part of the database from the SAFE network, maybe there would be a single MD for a single IP range or something like that, and then return the country code to the JavaScript API method. In Chrome, and I think also Firefox, this works by sending the IP address to Google to lookup the location, that’s obviously not ideal.


#33

I would like the benevolent dictator, @dirvine to put the foot down and give the directive of Safe: only development from here out regardless of the tech utilized.

My view is that SAFE Browser is a way for Devs to kick the tires and should be maintained as such through to launch…end of mission.

If there is a budget to go beyond a dev browser, then I really think Maidsafe should be looking to capitalize/ monetize the effort and maybe concentrate on mobile app development.

Use the marketing outreach to invite the big browser companies to build for SAFE. They are going to be here eventually anyhow, give them a heads up technology briefing.


#34

I look at battery usage per app very regularly. But data usage per app, never. This is because battery is scarce (for me) but data is not. And I also know roughly the data use for each app anyhow (and have fortunately never had a rogue data-consuming app).

The main difference I see with safe vs mobile is that replacing used credit may be harder than just with recharging phone credit / battery. Maybe not…?

Also the motivation for attackers to drain a safe account is (slightly) higher since they (slightly) benefit from that draining action (by increasing demand for safecoin), whereas draining mobile phone data / battery does not benefit them.

Still, I agree with you that mobile pre/postpaid model is a good one and should fit the safe network nicely.


#35

A lot to think about.

However, IMO, a SAFE// only browser with no clearnet seems the SAFE way to go. Let other teams external to MAIDSAFE develop plugins/extensions for other browsers allowing clearnet access - it will happen if MAIDSAFE doesn’t provide it AND it will both increase the security perceptions of people regards to the SAFE network while reducing the burden of maintaining browser compatibility with everything clearnet related. To my mind that seems a win-win for MAIDSAFE and SafeNet.


#36

Tyler, I agree with most of this but there’s one downside I see. Not having the option of a well designed security conscious (ie MaidSafe designed) option pushes people towards less secure solutions to this issue.

That’s bad because 1) it puts more people at risk, which means more bad experiences and more stories of bad experiences 2) bad experiences with SAFE will tarnish SAFE regardless of which tool was used, 3) We can’t say, "to keep yourself SAFE you should use the official SAFE Browser even for clearnet access"which means it is our / MaidSafe’s fault really.

So I’m not convinced yet.


#37

but we could say :
“What were you doing in clearnet ? To keep yourself SAFE you were warned to only use the official SAFE Browser and stay within the Safe network.”

This applies within the safe network I think. I don’t think Safe is a solution to fix the old rotten web. If other people / companies try to do that and fail, that will be their responsability.


#38

@nice I appreciate the arguments here but I don’t think they help address the issues I’ve raised. People need to use the internet, you and I will continue to need it for a long time so we have to look at what the effects will be and the usefulness of saying “what were you doing on the clearnet?” Its not helpful to them and doesn’t solve the problem. Same goes for saying you’re only safe using SAFE Browser. It doesn’t solve the issues I raised.


#39

Sorry if I expressed it too vaguely or a harsh way again…
What I mean is that I do not think a well designed, security conscious option exists that mixes Safe and the clearnet in the same window / program.
The base is so large that there will inevitably be a point were is leaks and conducts to bad experience.

As you point it out, some people will certainly try to develop solutions that do put more people at risk, and that will create bad experience and tarnish the Safe network.
My point is that I think it would be worse if Maidsafe tries to provide such a tool, fails, creates bad experience, and has to endorse the reponsability, than if Maidsafe clearly states that they keep away from this, and leaves the responsability to others. I think it would even be important that when it happens, Maidsafe can oppose their clear stance as not being involved / endorsing mixed networks solutions.


#40

Maybe it’s just my own experiences here, but no matter what browser MAIDSAFE uses ultimately … I will still use it ONLY for SAFENet and I will use my normal browser solutions for the clearnet. I believe that the way I go about it is probably common amoung techie people, but not so much amoung others. In the next couple of years however, it will only be techie people using SAFENet so IMO, not sure how important it is for MAIDSAFE to devote time/energy to a solution that isn’t needed. I’m not saying that they should never build such a multi-purpose browser, but right now, I don’t see why it ought to be a priority.

Also, I don’t really see/understand your point about more people being at risk if MAIDSAFE doesn’t develop a strong solution … because having any solution (strong or not) will not preclude bad solutions that look good. Assuming that SAFENet becomes popular, then it will be inevitable that plugins will be developed for major browsers – the only hope here IMO is that there is someone to vet these projects and insure they are properly coded.

Personally, no matter what, I will still always be looking for a SAFE// only browser option as to my mind that will always be the most secure tech.