This is a very interesting topic and one that frequently arises as I speak to people about the SafeNetwork. The initial assumption is that the SafeNet is going to have to have ports / bridges or something that allow clear and unfettered access from the web. This is an understandable idea and often bogs me down a bit in explaining that such an approach would undermine the fundamental security and attendant benefits of the SafeNetwork. At the same time, I’ve often wondered if a public-facing, read-only, publishing type exposure would be possible? In that way, the content control would remain safe, and, if the author wanted, anonymous. No, I’ve no idea how to achieve this technically, above my pay grade I’m afraid, but I wondered if this notion were under any serious consideration?
I think what would be more useful than trying to create “virtual servers” or trying to port sites made for the clearnet would be simply data content republish apps. Apps on one’s computer to download content from the clearnet and then republish onto the safenet. Essentially copy and paste the content instead of try to port the site.
An out proxy system could possibly be created by app devs to do this. Nodes willing to route this kind of traffic will set a flag representing their choice. Routing would occur as normal but no data would be stored on the network/vaults. Might work.
The hacker can’t change the app code on the SAFE network, that’s true. But my example was about when the app code has been loaded into the memory of the hacker’s local computer. And the global meta data for the app is something that is modified by the code running on the hacker’s computer.
The hacker doesn’t have credentials to modify the global meta data. But the app code has! At least in some way, directly or indirectly via an app loader/launcher. The hacker modifies the code in the local memory so that the global meta data becomes corrupted or deleted.
The decentralized web server layer allows easy porting of existing websites into the SAFE network. The ordinary Web will remain a competitor for a long time even when a migration is starting from the current Web to the SAFE network.
So what will happen is just that the Web gradually becomes assimilated. And then governments no longer have centralized control over the access to web servers when they have been ported to the SAFE network.
Abuse in the form of hacking attacks is prevented by each server code snipped being run in 3 separate and pseudorandomly (for example with XOR addressing of some hash that is calculated dynamically for each request) selected farmers. The three selected farmers (the selection changes for each request) execute the server code snipped and there has to be consensus about the result of the execution to prevent the farming software from being hacked.
Farmers are compensated with for example servercoins, a cryptocurrency similar to safecoins. The farming reward is randomly distributed and farmers who execute the snippets fastest get a higher probability of getting coins than slower farmers to incentivize improving the overall performance of the distributed web server layer.
Servercoin has an unending inflation rate based on a fixed farming reward. The cost of running a safe web server is zero. Abuse of computing resources is prevented by bandwidth for communication being made more of a bottleneck than farming computing resources. Server code snippets have a fixed limited execution time, such as 10 seconds. And requests for running the snippets can only be done by clients.
EDIT: The limitation of bandwidth is a result of the server code snippets having to be sent (together with call parameters) from the clients. For heavier tasks, server code snippets can be executed directly and snippets can call other snippets but for this function there is a fixed cost of servercoins for each execution of the server code snippets.
@PeterRobinson I can imagine the frustration of those conversions, a bit like groundhog day!
The kind of publishing you describe will be possible from day one (so called static website generators can facilitate this), what’s more difficult is websites that allow content to be created through interaction with the user (comments on a blog, forum posts), or where content is generated in response to user input or interfaction or something else dynamic (search, word clouds, a real time clock are examples of these two).
These will happen in time - MaidSafe already demonstrated a way of allowing users to comment on a blog, which @Seneca plans to use to build a forum application. Not everything that the current dynamic web does will be possible from day one, but quite a lot of it, and more with time. Also, some things that the current web can’t do, or does badly, will also become possible when SAFEnetwork launches.
@Stark, I think @Anders has a point about breaking things by hacking application code on the client. This will be possible if applications are not designed well, which might happen as quick and dirty ways of solving the issue I just mentioned in my response to Peter, above.
If an app can modify data that other users of the app can see when they use the app (e.g. blog comments) this creates the opportunity for anybody to create a modified version of the app on their own computer, which when they alone run it, messes with the behaviour of the (unmodified) app run by other users - by messing with the data (what @Anders referred to as meta data).
Blog comments are a mundane example, to illustrate the issue. When developers build dynamic apps that are designed to involve multiple users, ensuring good behaviour of the app regardless of what may be done to the dynamic data shared by users of the app is going to be a significant headache for developers. This isn’t unique to SAFEnetwork though, spamming comments is an example that doesn’t require modification of the code. But access to the code lowers the bar for more sophisticated “messing” with apps, so it could be more of an issue on SAFEnetwork.
As long as both the app and the apps data are loaded/stored directly to safe net, we are still going to have more security than the traditional model.
Ofc, if people store the apps locally and the binaries get compromised, there will be an issue. Also, if the client machine is compromised heavily such that it can meddle with running apps, there could also be a problem.
Depending on how deep we go, the hardware could also be compromised.
Ultimately, we can only raise the barrier for security breaches and good safe net best use practices should help with that, IMO.
Thank you, very helpful.
This is really easy to do, you can have your clearnet web server to read the SAFEnet version of the web site and forward/return its content to the client of the clearnet web site.
If you look at the SAFE browser’s safe-app plugin it does a similar thing for static sites but within the browser, it just reads the content from the SAFE net using the provided URL and it returns its content to the browser for rendering: https://github.com/maidsafe/beaker-plugin-safe-app/blob/master/src/protocol.js#L38-L42
Many thanks bochaco.
@bochaco I had this idea the other day watching my lady having to sign in username and password multiple times for Netflix, Hulu, etc on the tv, right in front of me. This got me thinking. If apps like these were available via safe on a tv someday it would be very uncomfortable to enter your credentials that otherwise access not just sensitive information but your safecoin wallet. I think this will be a common occurrence for people being in public or next to a friend and feeling reluctant to sign in in front of them.
What if there was a way to make certain apps public facing but linked to a user without having to input all your sensitive credentials? I know this sounds crazy and I see unsolved issues but bare with me.
1: You go through initial account creation (in private)
2: Then you create a ‘public access’ account
3: You allocate certain apps to the public access account
Such as a Netflix or Hulu
So say when creating the public access account you obviously have to have some kind of credentials associated with your network account to authenticate to the network for these apps. Something unique but easily remembered plus a six digit pin could do, but what exactly? Perhaps use your publicID, just one network password, and a pin?
Would this create too many passwords etc to remember for people? Would this come off as confusing? To me it makes sense but maybe to others not at all. Just thought I’d throw this idea out there as to me I can see people feeling uncomfortable entering such important information in front of others. In my case it was in our home and between us it is fine. If on mobile it’s pretty easy to be discrete but I still think it could still have a use case. Opinions??
Hi @Nigel, I’m not sure I understand your idea.
Do you mean that somehow the apps you linked/approved/authorised with your ‘public access’ account (which I assume it’s just a simple SAFE account you create for this sole purpose) are then able to retrieve the login credentials needed for service they provide?
E.g., the SAFEflix app is able to read your SAFEflix user/pass from a MutableData stored with this ‘public access’ account in private?
Yes but as long as someone could not get their eyes on your actual network credentials! As that obviously would defeat the purpose of the security and ease of use of the public access account.
So really the main points are having a simple way to have access to apps linked to your account without ever exposing credentials or access to wallets in a public setting. It should only allow limited permissions as well.
Edit: okay I think I see a possible misunderstanding. [quote=“bochaco, post:35, topic:12788”]
which I assume it’s just a simple SAFE account you create for this sole purpose
[/quote] this public access account would actually be created inside an already existing account. I feel like the more I explain it the more confusing it seems unfortunately.
Let me know if you catch my drift. This isn’t something I want to waste your time on either as there are likely more pressing issues but I saw a use case and a light bulb immediately went off. Let me know if you’d like to go more in depth into this at all @bochaco as I think it’d be nifty down the road especially for authenticating safe apps on tv’s or the like. Maybe there are even easier solutions such as requests from specific or known devices that you can approve in your account later?
Sounds like you want a sub-account. One that has less permissions to the resources of the actual account. And then you specify what the sub-account has permissions to.
So if you log in with the actual account credentials then you get access to all including coins etc
And if you log in with the sub-account credentials then you have only access to some files/netflix/whatever you gave permissions for it to have access to
- Have 2 separate SAFE accounts.
- An APP that someone creates that send the 2nd account the IDs/datamaps needed for access to those things you want when credentials entry may not be as secure
- The 2nd Account then uses the APP to puts the IDs in place to achieve this.
Drawback would be that its a pain if you create something in the 2nd account because you have to then transfer IDs of any keys and (datamaps) of the files you create back to the main account
@neo you describe what I’m thinking perfectly. Really wish I had a knack for conveying things like this. Spot on.
I think there could be a much more simple solution to accessing the sub account and how the sub and master account share data though. Like I said earlier I really don’t see a huge use case for this till a bit later on but I personally think it could be extremely convenient and useful in the future.
I actually see that it could be used widely. Just that we will see people solve the problem by having two separate accounts and mail themselves the IDs for netflix etc. Basically doing it manually till someone builds an APP for this simplistic version of what you were describing.
I will for instance will have a “family” account that my kids can/will know the passphrase to so they can access things for the house, like purchased films, netflix, etc. And if someone else gets the passphrase then its inconvenience with either recreating a new “family” account or changing the passphrase if I was not locked out.