Feedback request: Safe layers, layering Safe apps within the Safe Browser

General
1

Hi everyone,
an idea has been growing in my head for some times and I finally took the time to put it into words. I’d like to know what you think from a technical point of view but also more generally about the merit of the concept.

Here it is:

What?

Safe layers are application that runs within the Safe browser. They are almost exactly like a normal Safe web app: they are written in html/javascript/css, they have access to the SAFE API, they cannot modify the browser anymore then normal Safe web app can. But there is three key differences with normal Safe web apps.

First, you don’t access them through an URL inside the main window of the browser. Instead they are installed locally from an immutable data. The immutable data also contains a link to a structured data owned by the developer of the layer. When he makes an update, the version of the layer is updated and the user is now free to update or not to the latest version. This means the update process is more formal then for normal web pages and offer an extra level of security that could be used to add trusted certification at some point.

Second, they aren’t displayed inside the main window but instead, over it. They are a layer over the content of the main window, like a popup(a useful one…). Their size and position can be set by the user. They can be docked on the side or they can be shown full screen and multiple layers can be used at the same time.

Third, more importantly, they are aware of the current URL of the main window. They cannot change the content of the main window, but they react based on which url the user is viewing. For example, a discussion layer would change its topic automatically to show the topic related to the current page. A store layer would change its products listing based on what the page is selling. A “tip” layer would change the tip recipient to send the tip to the owner of the page. These are just a few examples but the possibilities are endless.

So the owner of the web page has no control over what is happening inside the layers of the user but can decide to officially support it by providing the necessary information to the browser.

For example, the owner can give a link for the discussion layer so it knows where to find the official appendable data that contains the official discussion. This discussion would be controller and moderated by the owner and the discussion layer would label it as being official. That said, the discussion layer might not stop other conversations to take place in other channels though.

The owner can provide a wallet id that is then used by the tip layer to forward all tips to his wallet. Or even a list of products that would be used by a store layer.

The goal is to enhance web contents with highly customizable and reusable community driven features.

mockup.png613×548 41.3 KB

Why?

A new security paradigm
The Safe network works differently than the normal web and requires a different approach on how security is handled.

On Safe, everything needs to go through the Safe Launcher. If a user wishes to comment on a blog post, he needs to first authorize the web page to post the comment on his behalf. If the user comments on multiple forums, each of them will be asking for authorization. This proliferation of authorization request leads to what is now called “Auth fatigue” where the user doesn’t pay attention to these requests anymore because he’s accepting them too frequently.

The concept of layers spin the situation around. You authorize the layer, an application that you trust, once, and you can then proceed to interact with any content of the network without having to give your trust to the owner of the content in question.

In other words, as you navigate through Safe, the content of the web page changes, but the layers you use stay the same. It’s just the context inside which they operate that changes.

Automatic enhancement of all Safe content
By adopting and promoting the use of layers, it means that any web pages found on Safe is automatically enhanced with all the features provided by all available layers the community created.

There’s no need to create your own implementation of a discussion forum and ask your users to trust you with their API access. You can simply point them to a layer that does it instead. You don’t need yet another store implementation, you only need to provide a json with a list of your products in it for example. Receiving tips from your users is only a matter of giving your wallet id to the tip layer.

Layers fully embrace the concept of reusability. Developers don’t need to reinvent the wheel for every project. And every new website is automatically enhanced with all features of all layers.

Of course special cases exist and some websites need to do something very specific and requires a direct API access. This is still supported and layers will also enhance these websites. One key difference is that these websites won’t need to request a wide range of permissions since most of the common features are already handled by the layers, they can only ask for the specific API access they need to do their specialized task.

Mixing clearnet and other networks with Safe
Allowing a website from the clearnet to access features of the Safe network is a sensitive subject and with good reason, it is the user’s privacy and anonymity that is at stakes. On the other hand leveraging the immense content of the clearnet makes the Safe network useful from day one and help solve the chicken and egg problem.

With layers it is now possible to do it without risk of compromising the safety and the anonymity of the user. Websites never interact with layers directly. They only provide, through the Safe browser, information for the layers to use. But they cannot know if a layer is using the information or not. Even better, they don’t interact with the Safe browser directly either, they just provide the information in a known place and the Safe browser is the one responsible to look at the data.

For extra precaution, the Safe browser would reject all API call made from a website that is not stored on Safe. If you want to enjoy the full power of Safe, your website needs to be stored on it.

Safe layers can be seen as an omnipresent overlay that transcend all type of protocols accessible through the Safe browser like safe://, http://, ipfs://, etc.

One global community
With layers, discussion isn’t spread in isolated island anymore. News can be spoken about directly at the source. Information can be debated about and fact checked directly where it is propagated making the conversation available to anyone stumbling upon it.

People you interact with in one location could be found in another one. As you travel around the network your web of trust travels with you allowing you to meet familiar people with common interest and making relationship stronger. It’s the opposite of what we are used to.

Community hub around a subject will still exist but will always be over shadowed by the layer system allowing anyone to add their opinion on any matter. Self-curation through your web of trust will assure you that you stay clear of unwanted content.

Layers over layers over layers…
Why stop at one layer though. We could have multiple level of layers. For example, a “rating” layer is a good candidate to be used within other layers. Rating can be applied to shop items, discussion topics, art work, etc.

What’s next?

Without a doubt this is a big endeavor. This is not a feature that can be completed on a weekend. What is presented here is a long term vision and the goal of this post is the see if the community feels like it would be interesting to investigate further.

A proof of concept could be made with the first layer being a discussion one. Most of the features are already in place inside the Safe browser for a basic POC to be created. What’s missing is:

  • A button in the navigation bar that pops up a new layer window which automatically loads a web page from URL. (local install through an immutable data would come later)
  • A layer window that stays over the main window.
  • A event the layer window can listen to be notified when the url of the main window changes or when a tab changes.
  • Access to the SAFE API.

So that’s it. What do you guys think, worth exploring further or not?

7 Likes
2

A lot to take in on a Sunday evening David, but I think well worth exploring. I’ll need to read it again before I can muster some intelligent thoughts, but…I’ll be back :slight_smile:

2 Likes
3

Interesting ideas. I think with safe net we should reappraise the role of the browser at a deeper level too. It is good to see this sort of thinking going on.

When we have a data stored which can follow people between devices, we erode the need for servers. As web browsers were born out of a client/server architecture, we must surely question its position in this brave new world. The fact that we are using a browser to talk to a local host server speaks volumes about this sea change.

4 Likes
4

I think you are describing Browser Addons. But you are restricting them – by not allow the modification fo the content. Thus making the most popular browser addon(s) of our time incapable of doing its job: AdBlockers.

Sure, we don’t need AdBlockers on SAFE (or maybe we will, who knows?) but I don’t see why you’d do that restriction. And while I appreciate the sentiment of “secure updates”, the case of browser and their addons have show that users do explicit updates exactly zero times in their life: if browsers aren’t updating them automatically they will never be updated and security vulnerabilities never get fixed.

Lastly, I am a bit wary about add-ons providing main functionality. While I very much like what you are talking about and think it’d be a great proposal, we have to face that fact that browser addons have been – and for the lack of any evidence to the contrary – will always be pro-user territory. Thus if commenting or discussion would only be available through such an addon, rather than a core functionality of the web-site, you will be excluding the majority of the viewers – especially first time visitors. It could work for limit-group side-channel activity, but not to provide core functionality. It is one of the strength of the web-app, that you download it and the browser is the only API it needs to do all its things.

A technical difficulty we are facing with this, is that beaker – the browser SAFE is based upon – doesn’t support addons at the moment. Especially since there is a cross-browser-spec for web extensions that if implemented would allow what you are describing but also be able to run basically any other existing chrome and future firefox addon.

I think having this in, would be amazing. And then we could how people are actually using this capabilities, what they’re building, what we might want to restrict and where to help with further APIs.

2 Likes
5

Hi @ben, thanks for the feedback!

That idea came when I was making SafeNote. I wanted to create a sidebar addons by injecting the html directly on the content of the page. At first that’s how I did it and it worked pretty well (except for the css mixing together with the page’s css…). But then a thought occurred to me, what’s stopping the page from reading the content of the sidebar? Nothing and that was a problem since it meant I couldn’t guarantee that the app was secure and then I dropped the idea. Instead I used the less flexible popup feature provided by the addon API. So that’s the reason why I added that, it’s debatable but I think it’s the safe way of doing it.

About AdBlocker, well, layers and addons are not mutually exclusive. Also, I think ad blocker intercepts problematic calls instead of modifying the actual content of the web page so it’s not quite a problem, we could have an intercept layer for example. Also, if an ad blocker is considered primordial it could be integrating directly inside the browser as a basic feature.

I see this more as a UI problem more then anything else. Layers could be updated automatically by default and user could change that settings to do it manually in the settings. Or it could be done like iOS if you prefer, ask do it manually every time you open your browser and give only three choices: now, do it later, ask me later.

First, thanks!

Second, that’s the reason I refrained from calling it addons or extension, I didn’t want people to judge it based on their preconceived idea of what addons are. It’s not because addons “will always be pro-user territory” that layers must be. Upon first install the browser could propose to the user a list of basic layers and ask him to choose one of each category. So it’s again more of a UI problem more then anything else.

Lastly, layers and addons and full featured website are not mutually exclusive. A website could offer a discussion forum and at the same time support, or not, a discussion layer. But I think most small to medium websites will prefer just supporting a discussion layer just like they are currently using the Disqus platform instead of rolling their own.

What I’m describing and addons have points in common but aren’t the same, either way they are not mutually exclusive. More importantly, last I checked the team behind the electron framework didn’t seem to be in a hurry to add support for web extensions, despite the popular demand, so I might be wrong but I wouldn’t count on that anytime soon.

1 Like
6

Yeah I was thinking about this too. In the end, what is the browser if not just the first layer. Tabs are just layers positioned side by side.

Though, what I like about the browser is that it allows us to decide how layers interact with one another, something that is harder to do directly on the OS. It also allow us to define what each layer is able to do, for example, they can’t make their own tcp connection, they always needs to go through the SAFE API. So I like the kind of controlled environment the browser provides.

If I push the idea further, the concept of layers within a Safe environment starts to feel like what the Safe OS could be and the browser could be just its first implementation, food for thought…

7

Yes, I agree. I would suggest that there are ways to sandbox apps without the browser, but I take your point that the browser does provide a useful foundation.

8

Perhaps this can also be achieved by allowing an app (the one running in the main web browser window) to be able to write data (maybe as immutable data?), in a predefined format, onto another app’s directory (the layer app’s directory).
The layer app needs to define the format and path where the data has to be placed within its own sandboxed directory (maybe we need a 3rd type of rootPath, e.g. ‘appsShared’, which is to share data between apps).

Thus I guess this would be analogous to your original proposal but using the layer app’s directory as the data bus instead of the browser. Then a layer app can be just an addon (or anything you want actually, even running in a separate device) but with this predefined way of sharing data with it.

…hmmm…did I just describe what the SAFEnet version of POSIX shared memory, pipes or even sockets, would/could be like?

1 Like
9

Interesting, I like the idea of doing all communication through the network. It does sound more flexible that way.

For example a website could store its information(wallet id, official forum, etc) inside a json file and a layer would read the information from there instead of asking the browser. Like you said a layer can be anything, not just an app inside the browser.

Then the browser just need to update a file inside a shared folder to inform other apps what’s the current url. It’s not gonna be optimal but until we have a faster and more secure way of doing it it could be just fine to build a few proof of concept layers. Food for thought…

1 Like
10

Yes! This is exactly what user end want. We’re heading towards social ecommerce. This would be painless, and easy.

I explained this idea to someone else, this is what he said to me.

I think it’s not a bad idea to implement a UI layer that interprets HTML into a window. But implementing Electron as it is is too bulky and would be more trouble than its worth.

I think it’d be better to implement an API from the ground up that draws the window.
One could open up a html:NewWindow/NAME URL and then write HTML data to the connection to draw up a window. From here a program could interact with the window by sending instructions to the API to modify the DOM, much like Javascript DOM APIs.
For sending instructions asynchronously, the same program could open up the same connection by calling html:Window/NAME, and assuming the current process has ownership of the window, or if the owner process gave this process permission, then the API will let it send commands to the DOM.

Honestly, it’s basically a web browser Layout Engine built into the DE

Another idea, tag layers. In safenet tag system. Any tag above 15000, can be tagged as an app. Theory here is to draw a layer, tag it, then the scripts will be run in that contained layer.

2 Likes
11

Yeah I like that. Each product could be a mutable data containing its description, pics, owner wallet id, etc. Someone else could link to it in a blog post or in a forum discussion, then the shop layer would detect the linked content is a product by checking its tag as you suggest and you could buy it directly on the spot.

I really need to rewrite the whole thing to make it more data-centric. I’m rereading now and I focus too much on the UI. The magic is in the data.

2 Likes