If we are going to create a browser only for safenet.
Did we really wanted people to type www 100 times a day.
I would prefer to by default omit safe:?? or .safenet.
And use protocol denomination only when there is a deviation from the default.
Why use acronyms that only a select number of people know.
Why nfs: or snfs: when by using storage: the meaning is immediately clear for even grandma and therefore easier to remember…
Making things intuitive from the start instead of forcing non technical people the remember technical things.
1 Like
My thinking was that you might need more control and make it more JS friendly and more user friendly. The main difference being that you should ask users whether they want to do something instead of allowing the launcher to do it. “SAFEsites” should have a higher security barrier to entry than downloaded and installed applications.
For example, did you know that I can just provide the same application ID as the demo app and then I can do what the demo app does including access the files it thought were only for itself? I say don’t blindly forward anything. Make an idiomatic JS API that works best for the web. This can include promises, Uint8Arrays, an API to ask for user permission to do multiple things ahead of time instead of lazily, etc. However, if this is a point of contention, I’d suggest just leaving it off for now and just having normal read-only “SAFEsites” for now.
1 Like
Nope, only if they have a subdomain called “www”.
Agreed on the address bar. Just typing “foo” implies “safe://foo”. But for the actual paths in things like anchors and when you choose to copy the address and what not, the “safe://” should be in front of it. This makes links easier to share across all mediums and is what makes it a proper URL. This is no different than how normal browsers do things today btw, they just assume http.
I won’t speak to the other protocols.
3 Likes
For this do you not need the authorisation hash? i’m aware you can just pass auth credentials, but without the correct hash you wouldn’t be able to access anything (is what I’d understood).
Or are you saying that enabling a site to send what they will to the launcher, opens up this possibility, whereas we could avoid it?
Such that maybe enforcing, the app name to be the domain on safe: so safe://cretz would always show up as an app with cretz being the app name, to avoid spoofing?
I think some variation of this could make a lot of sense.
Yeh, that’s what I’m aiming for. I’ve a promisified lib of the API at 0.5 (GitHub - joshuef/safe-js), which is much nicer to work with. This is what I noted I’d probably aim to be implementing.
I’m totally open to switch the scope and add more in browser security, and JS features to make it more useful 
I’m going to be using it myself for building webapps, so more useful the better 
It’s useful to throw around ideas now, as they could shape potential implementations.
2 Likes
Nope. What if I wanted to use the same app on different computers as the same user? Does the data stored have to be auth-device specific? Your app auths with the launcher which just presents the user a friendly way to manage apps. There’s no backend piece (at least not last I looked). Meaning, I could just hit up the C FFI myself and do whatever an app could do. (of course, actual user auth is a backend thing)
I am saying that. Among other things such as being an idiomatic JS API like every other browser feature exposed to web pages.
I prefer a different approach. The browser is the app, not the safesite. I think the browser should provide the permission validation, not the launcher. The launcher is all or none (well there is 1 permission), whereas the browser should be much more granular.
Yes, if you want to support site-specific storage, you could store in a sub folder based on the domain. How CORS would work within subdomains should probably be like cookies (can’t go across the top domain, but can across sub domains ONLY if you opt in, e.g. .cretz instead of cretz).
I think that’s reasonable, but I would say there is probably more room for something safesite specific on the client side. I think the costs of trying to keep the API portable for node/server-side devs and safesite devs outweigh the limited benefits. Again, things like granular permissions (and the requesting of them) are a safe browser thing IMO, not a safe network or safe launcher thing.
2 Likes
My understanding that any auth of an app from any device will generate a hash that’s valid on that device, and give access to the data there. @Krishna_Kumar is that correct? can you expand on this perhaps?
Okay right I’m following you now.
I wonder of the knock on implication if every auth must be via a browser app. It could mean no dedicated mobile/desktop apps accessing the same data (as and when SAFE is ported to mobile).
I totally see where you’re coming from with the granularity. Thanks for clarifying
1 Like
That part is correct. What I am saying is the data isn’t device specific and those auth hashes/tokens are device specific. 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).
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. The concept of “app folders” is not really a safe network thing per se, more or less just a launcher thing. At least I think that is correct; will wait for @Krishna_Kumar’s reply.
But I don’t think it matters anyways. It would drive me crazy if I had to leave my browser to approve a safesite. Not to mention the granularity thing you acknowledged.
2 Likes
I feel for @Krishna_Kumar , as he will be bombarded with many API questions in the following days, weeks, months, possibly years… I know I already have several API discussions in the works. Hopefully his responsibilities become spread about to others as much as possible down the road as well!
5 Likes
Can I clarify your suggestion on permissions @cretz to make sure I understand. Please fix anything I don’t…
SAFEbrowser will provide a JS API which WebApps use and within this they will request whatever permissions they need, and since the browser manages these (knows the App URL and can store this in its own SAFE storage), Apps always have to go through the browser and there’s no way to spoof since each App lives at a different URL.
The permissions can then be whatever the browser API designs, and App permissions will be available once given from any device logged into the user account with a browser that understands them.
So users won’t go to SAFE Launcher when an App seeks write access, for example. The only time they will go to launcher is when the browser initially seeks permission (or indeed other desktop Apps seek permission) to access features on their SAFE account/storage.
This I like. It works brilliantly for Web Apps using this API (gives user lots of control, is secure/can’t easily be spoofed, operates across devices for everything using this API and authorised to access those permissions).
It leaves other Apps and Launcher permissions behind (they remain as now), but I don’t know if we can do anything about that.
Hope I’ve understood. It seems a good scheme and if we can establish it as a SAFE Web API standard for all browsers that would be brilliant and perhaps other Apps could still use it via an external library or container or something.
3 Likes
Close. (also, it should be remembered this is just my suggestion and in no way the “right” way)
No, this should not be stored in SAFE storage. Instead this is a browser-specific permission that should be stored on the device in the OS user’s profile (and even then, under the logged in safe username, but still local disk). Does that mean that you’ll have to approve the use of SAFE API features for a separate device even if you did it on another? Yup. But that is a good thing, because while we as humans don’t buy completely new devices regularly (and this is a one time thing), you definitely don’t want a site automatically having privileges to, say, write to SAFE from your phone just because you said they could from your PC.
Also, I suggest a terminology clarification. I recommend not using the word “app” to refer to a site in the browser. I know “webapp” has application-like connotations, but IMO apps are installed, communicate w/ safe or the launcher directly, and other things. I suggest “safesite”.
Yes except for what I mentioned above, the approved features are per device (and stored on the device, not on safenet). It’s also beneficial to not store on safenet because it allows auth-less browsing and permission approval. Though I do suggest if a user is not logged in with safe, the permissions just be stored in memory to prevent issues with shared computers…or maybe just require login for every user.
Yup. It does give the browser quite a bit of freedom to do bad things, but same problem with any other app since there aren’t very specific permissions in the launcher.
2 Likes
Thanks for confirming and clarifying and I get this is opinion/judgement. All good for debate and I certainly value your opinions. 
I’m not sure how bad this would be, but if we say yes its bad, the browser can handle that. It knows whether it is on a new device and so it can ask the user, or if the user has said don’t ask me on other devices for this/any safesite, skip the question.
The reason I like this is to minimise what is stored on the user’s device, particularly when it is sensitive/security related.
1 Like
This is a very good point and one I didn’t ponder well enough. By storing permissions related to a site, it shows that the site has been visited. This is one of the reasons I pushed for encryption using user key in the API. It is sitting in an RFC here after the suggestion as granted here. I still believe the permission config doesn’t need to be on safenet itself by default (nor do I support any writing to safenet by default), but I could get behind the option to have that as opt-in config storage for a “sync” type of approach across devices.
1 Like
Pasted here:
The Bit In-between
As you probably know, the URL syntax places a double slash (//) between the protocol and the rest of the URL:
http://eager.io
That double slash was inherited from the Apollo computer system which was one of the first networked workstations. The Apollo team had a similar problem to Tim Berners-Lee: they needed a way to separate a path from the machine that path is on. Their solution was to create a special path format:
//computername/file/path/as/usual
And TBL copied that scheme. Incidentally, he now regrets that decision, wishing the domain (in this case example.com) was the first portion of the path:
http:com/example/foo/bar/baz
So your saying that this scheme cannot be bypassed in the two current SAFEr proposals because @PaulFrazee has it baked into Beaker?
It would be interesting to hear from @PaulFrazee on this, since he built this pretty much from scratch.
Tell me there’s a way to break this madness
4 Likes
It seems like later when we build the mobile browser version later we can add the feature to limit downloaded data. It seems we are already seeing a shift towards synced browsers. I like the idea of having my favorite sites/apps available on any machine I use SAFE on.
It is very convenient to have the list of apps on a new smartphone that I have installed previously, so then I can just click the ones I want for that phone installed. I think SAFE can do it even better by my desktop/browser pulls up (when I’m logged in) exactly the same on any machine I use and when I close it there is no data I leave behind. All I have to do is install or favorite my preferred sites once and it is there anytime I log in to the SAFEnetwork.
Since we are building a SAFEspecific browser, why do we need anything other than the domain? No SAFE:(//) and no **.safenet.
RE url standards, the ‘//’
Following the generic URI syntax will make things easier. It’s a known scheme with a lot of compliant software.
To improve usability, you can insert ‘safe://’ automatically if it’s not included by the user.
Eventually, Beaker will need to apply a similar upstream patch. Electron disables the process-level sandbox, and Brave’s fork re-enables it. I’m not conversant in the details yet.
1 Like
@dirvine could you please pass comment on this issue, do we not have a chance for a fresh start?
Considering were headed towards a fully semantic system, I would have thought entering mranderson in the address bar would drop down a contextual list of public resources associated with that tag, giving priority to any resource associated with the public id: mranderson
The browser should be a resource directory to all public data…not just websites
6 Likes
The current POC doesn’t default to safe:, but I don’t see any reason why we couldn’t do this.
The problem arise if we have a ‘switch’ for regular http: access. BUT. There’s no reason we can’t still default to safe: and you have to specify http if you want to go clearnet. That would make sense
So you’d only type MrAnderson and you’d be on safe. But http://mranderson.com would get you to the clearnet. I like this
Interesting! Could be fun to explore how useful this is (probably quite?!)
7 Likes
Since we are building a SAFEspecific browser, why do we need anything other than the domain? No SAFE:(//) and no **.safenet.
Visual feedback: no need to type it, granted, but showing it is useful feedback.
5 Likes
I’ve updated the POC just now with safe:// being added by default. So now you can type your domain test.bluebird (which is still up), and you’ll automagically be routed to safe://test.bluebird.
That way, if you want to copy/share a domain, it’s got all the info you need and wont be confused with http / clearnet links.
10 Likes