SAFEr Browser(s) Proposal

[Krishna]

I was on a break, just resuming today.

@cretz

So what I’m saying is that while users have to accept apps, that is only per device. What an app stores is available globally to that user.

@cretz got it right. Authorisation tokens are tokens specific to a launcher session on a device. But the data stored by the app is in the network available globally for that user.

[betterthantrav]

@joshuef

Is an integrated version of the launcher desirable? Or is it better to simply allow the safe browser system to anonymously utilise safe, without the launcher needed? I’m leaning towards this idea right now.

What would be great is to be able to download one app that allows me to login to SAFE and browse SAFE sites. I would hope that the launcher and SAFE Browser would become synonymous.

Would a built in app store be asking to much

[davidpbrown]

Better error handling would be welcome:

Get requests through commandline wget see a clear HTTP error code, whereas Firefox and I expect others, suggests an error message that isn’t not so clearly stamped with the usual HTTP codes. I don’t know if then the SAFE browser can help users by at least declaring the HTTP code as header before barfing over them with SAFE-dev speak and cryptic network detail. From memory it’s just 404 and 410 that are most common replies and those from where subdomains and PublicID’s don’t exist. Something like “404 Not Found”; “410 Domain does Not Exist”, would do.

Edit: this should have suggested 400 not 410 ==HTTP Error 400 Bad request

[Blindsite2k]

All this excitement about creating a new prefix. It still makes me worried it’ll create compatibility issues. If I code my site to use safe:// links or safe: links instead of http:// links even if everything is all on the SAFE network this may still cause issues for someone that isn’t using the SAFE browser. To me it’s less about security and more about audience compatibility. Most people will still be using firefox and chrome and won’t be going that extra mile to download a special SAFE Browser. I think if we do decide on a federated protocol we should also build addons for other browsers that would allow them to interpret it. That or make sure the pac file and launcher can handle it. Whatever works.

[davidpbrown]

I guess the solution will be that http://test.bluebird.safenet == safe://test.bluebird where that safe:// is supported.

If everyone writes their links as the usual http:// then the SAFE browser can present then in a SAFE-centric way perhaps without confusion.

safe:// could be suggested as one step beyond https:// and http:// is misleading for the level of security being provided.

[joshuef]

@davidpbrown

I guess the solution will be that http://test.bluebird.safenet == safe://test.bluebird where that safe:// is supported.

I don’t think so. There needs to be a clear separation between which network you use.

While this is possible, and something I’ve toyed with. It’s only possible as long as .safenet doesn’t exist as a domain on the clearnet. Then we’d be just hijacking a Top Level Domain. Which is bad. It’s not something I think we should be looking to use, as it’s not future proof.

It’s important to remember that the current setup was for convenience of testing (at least as I understood it).

@Blindsite2k

I think if we do decide on a federated protocol we should also build addons for other browsers that would allow them to interpret it.

I think this is key. And something that has already been put forward and at least tested to some degree as I’ve seen by the MAID team.

Ideally, work done on this browser implementation should setup rules and patterns (and indeed code) that can be easily used to create these extensions (where the browsers allow it).

If a browser doesn’t allow, and it’s deemed acceptable, then hijacking a TLD could be one way around it. But I think it’s important to know what content is SAFE and what is not. Anonymity is a key feature of the SAFE network, and pages loading content from both protocols are no longer anonymous (there are many many ways of tracking a user via a simple HTTP request).

[davidpbrown]

@joshuef

There needs to be a clear separation between which network you use.

I’ll answer in this way, though not convinced and expect you are correct…
Normal URLs I wonder already fall within .earth and in zones where others like .mars are used, that extension becomes visible. So, I was thinking not that .safenet is the usual earthbound URL top-level domain but one step beyond that… indicating that it is a different network.

For example, bluebird.safenet could be bluebird.safenet.earth and then a clearnet site but bluebird.safenet.SAFE would never be confused with the clearnet network; in the same way that bluebird.safenet.mars would not be confused with clearnet.earth.

I wonder that SAFE is not just a new protocol like https:// that can be applied to any and all websites; it is as you’ve noted a different network. However, it would be great, if safenet addressing could fall within the URL protocol.

Another likely bad idea, would be that the URL protocol that .safenet uses could be one using a forbidden character, so that it fails as a normal URL - but as suggested I think that’s a bad idea.

[joshuef]

Hmmmm.

.safenet is in itself a workaround for clearnet browsers (where a custom protocol isn’t possible cough chrome cough). Right now my aim is for a set of standards of how SAFE access would ideally be.

.safenet may be a solution for accessing SAFE via an extension in one of those browsers, it’s not itself a reason to complicate what could be a set of standard ways of addressing SAFE content: safe:.

In that same way, any extension of clearnet browsers could easily parse safe: links and replace them with https://.....safenet. Which would, as I understand, address some of @Blindsite2k’s concerns about maintaining sites.

I think if it’s wanted, then it’s relatively trivial to setup for an extension to do this. But the gold standard should be distinctive and clear. It should be (IMO) how we want the SAFE network to be, which is secure at its base level.

As such, for an immediate SAFE browser, I lean towards safe: as a solution for identifying network content, and if that’s accepted / standardised, then the extension ecosystem of other browsers could (would/should) allow for this.

[anon40790172]

@joshuef

As such, for an immediate SAFE browser, I lean towards safe: as a solution for identifying network content, and if that’s accepted / standardised, then the extension ecosystem of other browsers could (would/should) allow for this.

I don’t know how feasible this is. But supporting both safe: and safe:// would be nice. Some might get confused by only the : even while the // don’t really add a thing from a tech point of view.

[joshuef]

@anon40790172

ut supporting both safe: and safe:// would be nice. Some might get confused by only the : even while the // don’t really add a thi

Totally! When I’m writing safe: it’s comparable to http:, the rest of the URL structure remains.

The // as it stands right now in the POC, is totally optional.

Sorry for the confusion!

[davidpbrown]

I’ve think you’ve got it right, whichever way it’s considered.

It seems to fall well within the URI Syntax, which suggests that the two slashes are optional for schemes. safe: then is just new scheme.

There is then no more a risk of confusion with use of single colon for :port than ever there was.

Normal browsers will work with any link because they are within an anchor not because they are of a certain format.

It’s all good

[whiteoutmashups]

Not sure if I’ve read this entire thread, but are you building in a Launcher? So people will only need your browser to browse & PUT to SAFE?

EDIT: I see it now. It’s a stretch goal of 20,000 MAID. Definitely hope this is achieved! Will make the browser much stronger

[joshuef]

@whiteoutmashups Yeh, the initial stretch I’ve described would be to enable anonymous browsing, at least.

It’s not yet clear if a fully-fledged launcher, in the browser is desirable. But right now full auth / permissions / logs etc is out of the stretch scope (though I’m not averse to adding it if there is demand). I figured we’d be better placed to know how this will be used down the line. Though if you have thoughts as someone who is developing apps, please let me know!

[joshuef]

Just to clarify a point I saw over here from @Anders, right now this proposal is for desktop browsers only. More specifically, I’ll be looking to get as much as I can into a fork of this repo.

My intention is for all work to be easily portable to any other browsers, such that an android implementation would be much simpler. But I’m not well versed in android or iOS dev, so I just want to be clear and up front that android brave development should not be expected from this proposal.

[joshuef]

Something further to: [quote=“cretz, post:27, topic:10336”]
So, say you have app X (as in that’s it’s name, ID, etc), and the user via the launcher gives accepts X to use the launcher API on their behalf. Then X stores something in it’s “app folder”. Then my app comes along (say it’s a different computer) and says it is X and the user approves it. Now it can see what was stored by the real app X. This just means that while a user has to accept it, there is no true verification for an app (nor should there be).
[/quote]

I’ve been mulling the idea (can’t see/remember if I mentioned it above), but perhaps a SAFE browser should have a standard way of enabling safesite requests to the API.

As such, we could say that any site requests have to have the site domain as the ‘app’ name in the auth request (ie. you never provide an ‘app’ name as a safesite, this comes from the browser…):

app: {
            name: <safe://mysafesite.mydns>,
            id: packageData.id,
            version: packageData.version,
            vendor: packageData.vendor
        }

If we set this as a standard method of accessing the data on the browser level, that should prevent other sites spoofing this data to access the ‘real’ site’s data.

This would of course only protect you inside the SAFE browser, it wouldn’t stop other apps pretending to Auth as a site when you run them. But I’m not sure there’s any way around this, or that we’d want that. At some point the user has to auth apps, so they will have to be paying attention.

I think in theory, this should probably behave in the same way as cookies, domain / sub-domain bound. (Though you could access data stored at safe://mysite via safe://subsite.mysite, for example.)

Thoughts, safesite devs?

---

All of which doesn’t touch on perms (default enabling of write etc) which @cretz noted above.

I was wondering if this should be addressed at the launcher level, but then you can always have different implementations of that, anyway, so this would fall to the launcher you’re using. As such, assuming we integrate some version of the launcher (the browser then becoming another launcher implementation…) the we would want some permission system for NFS read/write of SAFE data integrated into the browser.

Likely as well any other API options that we make available (does enabling DNS creating in the browser make sense?)

Are there other SAFE permissions we should be thinking about here? (as well as, I assume, a full battery of standard browser permissions for location/mic/camera etc).

All of which, as @cretz and @happybeing noted, should likely be encrypted in some form to protect the user’s device.

[et4te]

Tor was hacked due to a browser exploit. Why not use Servo instead which is written in the same language as the SAFE network and is resistant to exploitation?

[000]

Servo Browser by Mozilla Team :

Servo (software)

Mozilla releases first Nightly build of Servo, its next-generation browser...

Servo is the web-engine written on Rust. HTML.Browser is an experimental UI written on JS/CSS/HTML. Servo can also work with the current Firefox UI.

SERVO | HTML Web-Browser by Mozilla! The Next Firefox could be HTML!

Fastest browser engine by far at 500 FPS! Servo Webrender - CSS on the GPU part 1: Rust

Fastest browser engine by far at 500 FPS! Servo Webrender - CSS on the GPU part 1: Rust

Rust Language , lot’s of advantages regarding security covered in this talk : The Rust Programming Language - YouTube

[happybeing]

Because that wasn’t in the bid, the skills available for the bid or the budgeting. Using Servo would require a different skills base and might well take longer and cost more, so we can’t expect such a big change from the accepted bid.

If there had been a Servo based bid we could have chosen between the two but as nobody had the skills or desire to create a bid based on Servo we can’t expect something as fundamental as this to be changed.

[et4te]

Well okay, better would have been to mandate Servo in the first place. Any programmer can pick up this code base and investigate it for the demands of the Maidsafe project and this would be worth a larger budget and time span. Why not provide an incentive in terms of remuneration instead of expecting users to come up with proposals. Surely Maidsafe is more capable at assessing how much value it is worth to them. The browser isn’t something that should be rushed since an exploit here destroys all the security guarantees of the network.