Pages:
Author

Topic: Anonymity: Death of the Stateless Web - page 2. (Read 4089 times)

full member
Activity: 154
Merit: 100
November 20, 2014, 02:51:03 PM
#23
I am still unconvinced that HTTP is going to die - IMO it is going to *change* (perhaps too gradually for the OPs liking) and things like CIYAM Open are starting to show just how far it can change (to become a "secure" and stateful protocol).

I am not convinced it needs to die. For example I think perhaps it can even sit on top of an high latency network anonymity layer as it does on Tor now, just sans the exit nodes.

My point is HTML5 is no longer in control. The web browser stranglehold is evaporating finally! Yahoo! So we are free to innovate on prior assumptions of low latency. Apps can more intelligently deal with high latency if the incentive is worth it (true anonymity). Users will drive the demand.




That could be argued for any OS - yet web apps have become more and more predominant (especially in business - if you don't have a web version of a business app now you are *dead* and you just need to look at any major ERP system to see this).

I think the goal there is cross-platform support. The difficulty is that many of those "web apps" are just ActiveX programs, negating any cross-platform capability beyond Ms Windows iterations. I suppose easy updating is a benefit as well.

Businesses are conservative (with their internal apps) because maximizing adoption is not their goal (a category error unless they get push back from employees but web apps aren’t that far behind yet). So they want the most accessible and most ubiquitous platform.


Quote
I’m ecstatic that most of the votes are No. This means I am still (even 10 years hence) far ahead of most people. I assume most people haven’t quite yet grasped why HTML (static documents, a 100% immutable declarative language) was a special case that would not apply forever into the future. Humans are like that. They project the present into the future, without thinking about what made the present and what changed.

Well, that is obviously where we disagree. I believe that there should be a separation between code and data. I will be sticking with HTML 4.01 Strict, despite the W3C making HTML5 a recommendation. IMO, you simply can not have a secure web-browser if it runs arbitrary code. (HTML5 got rid of the DTD declaration: meaning that changes to the standard can be implemented without updating the standard changing the version number)

You suffer the same myopia that the W3C did when I tried to explain to them that cross-site script injection was a non-security hole, but rather the holes in the outer sandbox were the problem. And by limiting what code sites could load, we were not increasing security but decreasing functionality and creating kafkaesque, security theatre.

Android finally got it correct and each app runs in an process sandbox, so bad code can’t do anything external to the app. The app can only write to its private section of the file system, unless the user has authorized other permissions.

W3C had effectively moved an operating system concern into user mode. What a fucking load of unnecessary tsuris!

The same myopia I was battling 10 years ago on W3C discussion lists. I gave up! It is like an irrational religion.

Despite it's history of security vulnerabilities, (and the run-time being bundled with browser tool-bars), I think JAVA (including applets) is a better approach to running untrusted code in a sand-box. Leave HTML to serve up static web-pages. The problem is that developers do not like it because the users get fine-grain control over what the software can actually do. For example, the user can prohibit network or disk access.

Separation of code and layout+static content is a good programming paradigm for semantic reasons, but it is orthogonal to the security sandbox issue. And this is how it is done by default on Android with XML resources and code.

On Android, I can choose from dozen languages that run on the JVM, including Jython (Python), Java, Scala, etc..

The entire web page should be sandboxed in its own process and let the developer do what ever he wants. For static web pages, you don't need to spend a process on each one. It is as if the W3C never made the fundamental categorical distinction between a long-lived (stateful) app and a stateless static web page.

You know why? Because they (just the EU beaucrats) didn’t want to lose control and give up their importance and power. Also because they believed in some religious purity of a declarative (immutable) nirvana paradigm (where everything is so purely defined, semantic, and contained, etc).

The top-down, oppressive, religious micro management by the W3C was really a drag on my creativity.
legendary
Activity: 1008
Merit: 1001
Let the chips fall where they may.
November 20, 2014, 02:24:52 PM
#22

That could be argued for any OS - yet web apps have become more and more predominant (especially in business - if you don't have a web version of a business app now you are *dead* and you just need to look at any major ERP system to see this).


I think the goal there is cross-platform support. The difficulty is that many of those "web apps" are just ActiveX programs, negating any cross-platform capability beyond Ms Windows iterations. I suppose easy updating is a benefit as well.

Quote
I’m ecstatic that most of the votes are No. This means I am still (even 10 years hence) far ahead of most people. I assume most people haven’t quite yet grasped why HTML (static documents, a 100% immutable declarative language) was a special case that would not apply forever into the future. Humans are like that. They project the present into the future, without thinking about what made the present and what changed.

Well, that is obviously where we disagree. I believe that there should be a separation between code and data. I will be sticking with HTML 4.01 Strict, despite the W3C making HTML5 a recommendation. IMO, you simply can not have a secure web-browser if it runs arbitrary code. (HTML5 got rid of the DTD declaration: meaning that changes to the standard can be implemented without updating the standard changing the version number)

Despite it's history of security vulnerabilities, (and the run-time being bundled with browser tool-bars), I think JAVA (including applets) is a better approach to running untrusted code in a sand-box. Leave HTML to serve up static web-pages. The problem is that developers do not like it because the users get fine-grain control over what the software can actually do. For example, the user can prohibit network or disk access.
full member
Activity: 154
Merit: 100
November 20, 2014, 02:23:42 PM
#21
hamiltino, yes (from your Youtube slander) ignorance is bliss and you are suffering from it. The slick salesmanship marketing videos you linked to did not address the technical issues in my second reply to herzmeister.

Specifically afaics MaidSafe has no designed ability to deal with the bandwidth economics. Please don’t post more redundant noise (herzmeister already posted one of those slick marketing videos that lack sufficient technical details) in this thread until you've done your homework. This is a moderated thread and I will delete obnoxious or excessive noise. High signal-to-noise ratio content is always welcome, most especially if it teaches me something I didn’t already know, changes my mind on some issue, or helps me to see how others are thinking about things.


Update:

I see he edited his message to remove the links to the marketing videos and he instead inserted a link to some vague forum post that doesn't address the bandwidth economics issue at all.

Here are the links he deleted from his post:

https://www.youtube.com/watch?v=Jnvwv4z17b4&list=UUhDck5R_C9i6XTrS66tbwOw

https://www.youtube.com/watch?v=txvKSeCaEP0&list=UUhDck5R_C9i6XTrS66tbwOw


Also I see David Lavine confirms my assertion that MaidSafe doesn't provide IP anonymity:

https://www.youtube.com/watch?list=UUhDck5R_C9i6XTrS66tbwOw&feature=player_detailpage&v=_NBrIJrULaM#t=177

Because you only need to compromise the 4 nodes closest to you (i.e. analogous your entry guard nodes in Tor).

Also he never answers the question as to how consensus is reached:

https://www.youtube.com/watch?list=UUhDck5R_C9i6XTrS66tbwOw&feature=player_detailpage&v=fmW9feSp0xM

He side-steps the issue of how disagreements within the local set are resolved. Shrinking the set to any membership larger than 1 means you still need a consensus mechanism. Yet another example of him being vague.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
November 20, 2014, 02:23:07 PM
#20
I am still unconvinced that HTTP is going to die - IMO it is going to *change* (perhaps too gradually for the OPs liking) and things like CIYAM Open are starting to show just how far it can change (to become a "secure" and stateful protocol).
full member
Activity: 154
Merit: 100
November 20, 2014, 02:12:14 PM
#19
I had an inkling with the "agree or disagree with OP" poll; but dismissed it.

I’m ecstatic that most of the votes are No. This means I am still (even 10 years hence) far ahead of most people. I assume most people haven’t quite yet grasped why HTML (static documents, a 100% immutable declarative language) was a special case that would not apply forever into the future. Humans are like that. They project the present into the future, without thinking about what made the present and what changed.

Remember I was telling everyone in 2013 that Tor was not anonymous because of timing analysis due to being a low latency network and Sybil attacks on the relay nodes by national security agencies. And everyone thought I was crazy. And now we see new research that says 81% of the users can be identified. Sigh.
legendary
Activity: 1008
Merit: 1001
Let the chips fall where they may.
November 20, 2014, 02:08:27 PM
#18
btw, welcome back Anonymint  Cool (now I'm sure)

I had an inkling with the "agree or disagree with OP" poll; but dismissed it.

Missed the screen-shot of the mad-max thread.
full member
Activity: 154
Merit: 100
November 20, 2014, 02:05:11 PM
#17
However there are always things developers would like to do which fit within a security sandbox model (e.g. Android OS‘ s sandbox) but which can‘t be done with the standard features provided by slow moving web standards. For example, tighter integration with other apps. On Android OS, I can write an Activity, Service, ContentProvider, or Intent which can interact with other apps in the system within the security model. I explained some the ramifications of this more deeply.

Okay - I read that (thanks for the link) - but am still not really convinced that we are talking about something that is much more than what MIME already allows you to do (i.e. I could use a different PDF viewer in my browser if I plugged it in so I am not *stuck* with any particular one and the same for any other MIME type of content).

There are features you can do on an app today that you can’t do yet in HTML5. This will also be the case in the future, because the web standards will always be moving too slow because they are top-down managed (e.g. by such as my old nemesis Ian Hickson and Daniel Glazman of Apple). For example, the ability to control the entire screen space or the Activity queue for the hardware back button on Android, etc.. Being able to access the external SD card. Not being limited to 5MB for the SQL database, etc, etc, etc..

I was trying since 10 years ago to get them over at W3C to make the web standards with a more open and orthogonal security model like Android has and more flexibility so we could write apps (that is how far into the future I was able to see, way before anybody thought of smartphones I was already envisioning it). I got tired of arguing with them. My name is listed on the CSS2 standard for example for my contribution on the discussion lists.

Yeah eventually the web browser can standardize popular features that apps do, but they will always be several years behind the innovation. And thus apps will win.

Decentralization scales faster than top-down. 10 years of lost time is proof of that!

The web browser won for static documents because there wasn’t that much you could do with them that would be so much more awesome in an app. Thus lack of fragmentation and the ability to "write once, run every where" was a more important consideration. But the dissatisfaction with the browser ever since DHTML (e.g. the move to Flash) has been rising in a pressure cooker and now apps have been the release valve and there is no turning back! And with Android taking 50 - 80% marketshare globally, soon it will be a no brainer. You will write to the web browser when you can get by with it and it is easier. You will write an app when you need the best user experience. Once we tack on high latency network anonymity, the pressure to move to apps will increase.

I am no iOS fan btw (in fact I have a Samsung Galaxy S3) so let's not get bogged down in iOS vs Android (I am more interested in why you think HTTP is going to end up being scrapped).

Living in China I can tell you that HTTP is about the *only* protocol that doesn't get *blocked* here (I cannot view HTTPS from numerous overseas websites without going via a proxy).

And also I would never trust anything on Android in China (nor iOS).

We might still be able to run the traffic over HTTP, we can probably just wrap the high latency functionality around it. I was thinking a little about the tradeoffs, but not too in depth yet.

Spend some time on mobile in a web browser versus an apps so you can experience the reason user’s prefer apps for things they access everyday. For the odd website they access infrequently they won’t bother with an app, but we developers can make app installation more seamless with visiting a website to overcome this.

That could be argued for any OS - yet web apps have become more and more predominant (especially in business - if you don't have a web version of a business app now you are *dead* and you just need to look at any major ERP system to see this).

Yup that is what I would expect even though I don’t have any experience in those markets.
 
In the future, users won’t even be able to discern whether they are in web browser or an app, and thus apps will have won.

I'd agree - except turn it around the other way - you won't be able to tell a web browser app from an app - so apps will have lost. Smiley

My implied unstated reason is because apps have more functionality and the app innovation will be leading the web standards which follow, e.g. if apps popularly and successfully move to adopting a high latency network anonymity model, then web standards will be forced to follow. Thus apps won.

Writing apps for web is *much easier* and with tools like CIYAM it will soon be hundreds of times easier than writing using some normal app framework (please look into Software Manufacturing http://ciyam.org/docs/methodology.html which I have been working on for many years).

I agree getting started writing an Android app took even me (a very accomplished programmer) several days. And I am about 2 weeks into it with only about 1000 lines of code accomplished. But I lost of lot of time perfecting my use of Scala to develop on Android with.

But it should be possible to entirely emulate everything you can do in a web page or web app, and add hooks to more things that can be accessed via JavaScript interface to the native system. Perhaps you can explore this for your framework at the opportune time.

As always, paradigm shifts open up a lot of new opportunities. Not one size fits all, which is the whole point. So rapid development environments that provide the best of HTML5 with some benefits of app-side, might be popular, but I am not signing up for thinking that marketing out.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
November 20, 2014, 01:34:41 PM
#16
Spend some time on mobile in a web browser versus an apps so you can experience the reason user’s prefer apps for things they access everyday. For the odd website they access infrequently they won’t bother with an app, but we developers can make app installation more seamless with visiting a website to overcome this.

That could be argued for any OS - yet web apps have become more and more predominant (especially in business - if you don't have a web version of a business app now you are *dead* and you just need to look at any major ERP system to see this).
 
In the future, users won’t even be able to discern whether they are in web browser or an app, and thus apps will have won.

I'd agree - except turn it around the other way - you won't be able to tell a web browser app from an app - so apps will have lost. Smiley

Writing apps for web is *much easier* and with tools like CIYAM it will soon be hundreds of times easier than writing using some normal app framework (please look into Software Manufacturing http://ciyam.org/docs/methodology.html which I have been working on for many years).
full member
Activity: 154
Merit: 100
November 20, 2014, 01:31:43 PM
#15
@op

We heard these same things in 1997.

Please view this 1997 wired magazine link......

http://archive.wired.com/wired/archive/5.03/ff_push.html

Among the possible reasons that did not prosper are because it was too narrowly focused on rich media, there were not these hardware features of smartphones that required breaking out of the web sandbox to fully leverage, and web browser vendors in cohorts with the W3C were eager to keep developers inside a restrictive sandbox.

The difference is Android has already displaced the web browser on mobile, so this isn’t conjecture. Now it is just the PC and laptop yet to conquer.

If I want to receive SMS message notifications on Android, I need to program for Android OS not a web app (or maybe there is or will be a web standard hook for it, but there will always be new things for which there are not).

For example Facebook recently required everyone to install their mobile app so they could give uniformly better chat features to all on the network.

Spend some time on mobile in a web browser versus an apps so you can experience the reason user’s prefer apps for things they access everyday. For the odd website they access infrequently they won’t bother with an app, but we developers can make app installation more seamless with visiting a website to overcome this.

In the future, users won’t even be able to discern whether they are in web browser or an app, and thus apps will have won.
legendary
Activity: 1764
Merit: 1007
November 20, 2014, 01:29:52 PM
#14
btw, welcome back Anonymint  Cool (now I'm sure)
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
November 20, 2014, 01:26:22 PM
#13
However there are always things developers would like to do which fit within a security sandbox model (e.g. Android OS‘ s sandbox) but which can‘t be done with the standard features provided by slow moving web standards. For example, tighter integration with other apps. On Android OS, I can write an Activity, Service, ContentProvider, or Intent which can interact with other apps in the system within the security model. I explained some the ramifications of this more deeply.

Okay - I read that (thanks for the link) - but am still not really convinced that we are talking about something that is much more than what MIME already allows you to do (i.e. I could use a different PDF viewer in my browser if I plugged it in so I am not *stuck* with any particular one and the same for any other MIME type of content).

I am no iOS fan btw (in fact I have a Samsung Galaxy S3) so let's not get bogged down in iOS vs Android (I am more interested in why you think HTTP is going to end up being scrapped).

Living in China I can tell you that HTTP is about the *only* protocol that doesn't get *blocked* here (I cannot view HTTPS from numerous overseas websites without going via a proxy).

And also I would never trust anything on Android in China (nor iOS).
full member
Activity: 154
Merit: 100
November 20, 2014, 01:25:28 PM
#12
sr. member
Activity: 280
Merit: 250
Brainwashed this way
November 20, 2014, 01:25:11 PM
#11
@op

We heard these same things in 1997.

Please view this 1997 wired magazine link......

http://archive.wired.com/wired/archive/5.03/ff_push.html
full member
Activity: 154
Merit: 100
November 20, 2014, 01:18:15 PM
#10
CIYAM, yeah you can do really cool apps even within the walled garden of what is provided by web standards. For example, as you may know Blockchain.info was upgraded and now their wallet is fully encrypted client-side instead of server-side.

However there are always things developers would like to do which fit within a security sandbox model (e.g. Android OS‘ s sandbox) but which can‘t be done with the standard features provided by slow moving web standards. For example, tighter integration with other apps. On Android OS, I can write an Activity, Service, ContentProvider, or Intent which can interact with other apps in the system within the security model. I explained some the ramifications of this more deeply.

This transition to apps as a more general sandbox than the more limited web browser sandbox is epic and is underway in a massive paradigm shift. We could now leverage this to provide high latency network anonymity so we can do Tor correctly.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
November 20, 2014, 01:02:32 PM
#9
As you can use HTML 5 along with .js crypto to have encrypted stateful apps work over HTTP (such as CIYAM Open) I am not quite sure why you think that HTTP is going to disappear in favour of something like Android (or are you just a fan of Java or Android in general?).

Quite likely I've missed something in your "wall of text" so perhaps you could just focus on this one question in order to make it clearer to me what your point is.
full member
Activity: 154
Merit: 100
November 20, 2014, 12:54:32 PM
#8
I do make the point in the OP that the web is already moving towards stateful because of the advantages applications can offer over a walled garden (meaning inflexibility or inability to change and extend some aspects of what is available by default) stateless or limited stateful HTML5 model. And my point is that provides an opportunity to do network anonymity correct with high latency, since Tor is ostensibly doomed by its low latency requirement as outlined in the OP.

Cookies are very limited form of state insufficient for the level of sophistication that apps are adding over the walled garden web browser.

The OP is talking about IP address anonymity, which is Tor’s raison d’être. So I don’t know why you are conflating this aspect of network anonymity with the nonencryption of public data which was never intended to be private. Sorry if I may be blunt (in spite of your reply constituting praise by faint damning), your understanding of the issues is too limited to fully comprehend. But hopefully this reply will help move you along towards the next level of understanding. One could say the OP post is responsible for readers not getting it, because it is written in a modular generative essence style where not every instance of ramification and implication is spelled out and readers have to take the modular variables presented and formulate all the ramification permutations. But really if I tried to explain it to people are not yet up-to-speed, it would need to be about 10 pages long. And I don't have time for that right now. But I guess that is what this dicussion thread is for.

P.S. No insult intended. Thanks for the feedback.

legendary
Activity: 1008
Merit: 1001
Let the chips fall where they may.
November 20, 2014, 12:33:58 PM
#7
Epic OP, though it appears to drift off-topic at the end.

The solution for anonymity for the requester of public files and for anonymity of the server is to make the improvements to onion routing that I have laid out in the OP, to build out the Stateful Web, and for the servers to be hidden services.

For some reason I was getting the opposite from the OP. Ie: the web is no longer stateless because it is being asked to run Applications that obviously need to store state. Cookies were invented as a way to store state without stupidly long URLs. However, since privacy-conscious people block such cookies, those long tracking URL are used anyway.

The latency brings up an interesting point. if you want to be anonymous, maybe you should consider reading information months or years old. The Archive Team tries to extract useful information from these new 'apps' before they are shut-down and deleted.
full member
Activity: 154
Merit: 100
November 20, 2014, 11:51:25 AM
#6
P.S. I see we have more n00bs voting No and understandably too timid to reveal their myopic or irrationally biased justification. Perfect. The record will be here for when they get to eat humble pie.

It's not only about cloud storage, it can also replace the web and all the other use cases of the internet today (mail, messaging, media streaming, etc). It's just a question of time really until this "new web" goes viral and the old web will become pretty obsolete, much like the BBSs of yore, simply because it will be much easier and secure to use (first and foremost, no passwords and single-point-of-failure web-servers anymore). Conceptually, encrypted P2P clouds will abstract content and services away from location. This also will enable many use cases we can't even think of yet today. It's the next logical and necessary step in the evolution of networked computing. It'll also scale much better, and bandwidth and computation can be economically incentivized just as well. http://www.youtube.com/watch?v=Wtb6L7Bg3zY

Slick marketing has caused you to think these systems will be able to do things which they can not possibly do based on fundamental technical issues in their designs.

I saw that video nearly a year ago. My point remains from my prior reply to you upthread that MaidSafe and Storj are based on minimizing the amount of duplicate hard disk space employed for redundancy and their economic unit is backed by hard disk space. Afaik, they have no mechanism to charge for bandwidth used[1], rather only a quid pro quo exchange of equivalent proof-of-storage (via their verify algorithm I presume), thus they are not applicable for serving files to the public-at-large. They simply are not designed for hosting web sites. That is not their target market. Their design and target market is personal storage for your (or your enterprise’s) files (possibly shared with a few other people, but not the public-at-large) which you are access perhaps up to several times per day, but not 1000s of times per second. And afaics, they don’t solve the anonymity of the requesters IP address for data that is public to the public-at-large.

You miss a fundamental economic point that bandwidth is orders-of-magnitude more costly than hard disk space at any scale above a few accesses per day on average, yet bandwidth is also amazingly inexpensive too (which means it is very hard to pay-per-packet as you need some form of sub-micro-payments system or to trade in kind bandwidth-for-bandwidth).

The solution for anonymity for the requester of public files and for anonymity of the server is to make the improvements to onion routing that I have laid out in the OP, to build out the Stateful Web, and for the servers to be hidden services.

For MaidSafe, I suppose clients could pay per access directly to nodes on the DHT, but the technical design for where the data is stored appears to be based on randomness combined with a ranking algorithm, that does not factor in incentives to compete for the greater orders-of-magnitude revenue from selling bandwidth or in the absence of payment-per-access as is the case in the current design, then the incentive to game the system to not store fragments that are accessed frequently. There is a very complex game theory analysis that needs to be made of the system. In short, I suspect MaidSafe’s model is too complex to fully model and characterize. They can’t be using a quid pro quo exchange of bandwidth because the reciprocal exchanges would not be fungible in real-time, i.e. the other party may not possess a data fragment that the counter party needs at that instant (due to the randomized requirement of the fragments that is the fundamental feature of the system, there is no way this could be made fungible). I suppose that since only the owner of the original data can determine the address of a fragment, then DDoS on a fragment will cause the fragment to get blocked.

The concept of storing a file on multiple servers so we don’t have to depend on just one, is orthogonal, has always been the case with corporate scale servers, and such algorithms can be adapted to different architectures such as multiple hidden services or sitting behind one hidden service.

MaidSafe’s self-encryption and splitting a file up into sand grain sized (in terms of DHT address space collision probability) fragments is useful because in theory it means even the server nodes have no way to know anything about—and thus can’t discriminate against—the content of the data it is serving. And in theory the user doesn’t have to evaluate the reputation of any server node as would be necessary for traditional server. In theory this feature could be very valuable for files shared to the public-at-large. But traffic analysis can be used to correlate these fragments for files that have high traffic public-at-large access.

But I think that valuable portion of the system design can be split from the portion that tries to manage how many copies are stored on the system. So I think instead a flat economic model can be employed to incentivize multiple nodes to store the fragments. And put the decision of this choice and algorithm strategy in the hands of the client. This would be much less complex (easier to prove formally), much more decentralized, and much simpler. Then each node could sit behind a hidden service for sufficient IP address level anonymity.

The technical specifics of MaidSafe’s design is very sketchy and vague at this point. I seriously doubt whether they can handle the complexity and deliver the reliability they claim. The MaidSafe MaidSafe system is a complex state machine (layered on top of a DHT) and I have not seen a formal analysis of all possible states including DDoS and the game theory of attacks on it. To debate this would go into more technical detail than I care to enter right now on this forum.

In terms of David Lavine’s analogy to an ant colony, note each ant has 250,000 brain cells of entropy to configure itself uniquely within the colony (not just the 4 categories Lavine wants to presume) and the collective state machine of the ant colony has the 10 million brain cells of a human brain.

Also listening to David ramble on, he is not person who can hit directly to the generative essence of an algorithm with precision. Rather he rambles on vague analogies. He appears to be smart (salesman with some technical acumen) but appearing tousled and lacking of the eloquent sharp precision of a highly accomplished engineer. For example, never did he address any bandwidth economics which should be one of the first things out of his mouth in a presentation.

Accomplished engineers can readily detect bullshit. I smell some but I think he believes in his work even if can’t quite pull it all together further than vague explanations. About a year ago I tried to read technical descriptions at their website and it was a maze of vagueness and technobabble without complete formalization and citations.

[1]G.Paul and J.Irvine, A Protocol For Storage Limitations and Upgrades in
Decentralised Networks.
http://strathprints.strath.ac.uk/49515/1/Paul_Irvine_SIN14_upgrades_in_decentralised_networks.pdf

Quote
which showed that only 1% of network users
were providing 73% of the network bandwidth needed to
Permission to make digital or hard copies of part or all of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. Copyrights for third-
party components of this work must be honored. For all other uses, contact
the Owner/Author.
Copyright is held by the owner/author(s).
SIN ’14
Sep 09 - 11 2014, Glasgow, Scotland UK
ACM 978-1-4503-3033-6/14/09.
http://dx.doi.org/10.1145/2659651.2659724.
share les. In an earlier study carried out on the Gnutella
peer-to-peer network, Adar et al. presented in [1] that 70%
of users were not sharing any les, and that 1% of all users
were actually providing responses to over half of network
requests.
Early peer-to-peer networks were more focused on con-
serving bandwidth, since they were typically designed for the
purpose of sharing popular les between users quickly, with-
out relying on a central server. The MaidSafe decentralised
network, while focused more on the provision of storage,
faces similar challenges, where malicious users could poten-
tially use up all of the storage capacity of the network.
legendary
Activity: 1764
Merit: 1007
November 20, 2014, 07:07:53 AM
#5
It's not only about cloud storage, it can also replace the web and all the other use cases of the internet today (mail, messaging, media streaming, etc). It's just a question of time really until this "new web" goes viral and the old web will become pretty obsolete, much like the BBSs of yore, simply because it will be much easier and secure to use (first and foremost, no passwords and single-point-of-failure web-servers anymore). Conceptually, encrypted P2P clouds will abstract content and services away from location. This also will enable many use cases we can't even think of yet today. It's the next logical and necessary step in the evolution of networked computing. It'll also scale much better, and bandwidth and computation can be economically incentivized just as well. http://www.youtube.com/watch?v=Wtb6L7Bg3zY
full member
Activity: 154
Merit: 100
November 20, 2014, 12:49:17 AM
#4
Some significant incoherence in the OP has been corrected. Please try re-reading it.
Pages:
Jump to:
© 2020, Bitcointalksearch.org