Pages:
Author

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

full member
Activity: 154
Merit: 100
November 19, 2014, 01:12:13 PM
#3
I as an expert programmer with a reasonably deep understanding of the technical issues, assert that those who vote ‘No’ without posting any justification in the thread don’t have correct logic.

Note it is quite normal that I am usually 5 years ahead of most people in terms of seeing a budding trend. They are caught up in old paradigm thinking and can’t grasp my insight. If the ‘No’ voters aren’t willing to discuss their logic, then they are not likely correct.

Time for Bitcloud / Storj / MaidSafe

Those are not primarily trying to solve the anonymous networking problem, and certainly not general anonymous networking to any dynamic web site or service, e.g. a forum. You are comparing Apples and Oranges.

They are to some degree trying to address the problem of anonymous hosting for the static resources of the web.

But they have a fundamental design error or choice that most people don't realize.

Their economic models are fundamentally (and apparently irrevocably) based on the quantity of storage, not the bandwidth transferred. Thus these are decentralized clouds for saving low traffic personal files, not for serving high traffic content of web sites.

P.S. Returning readers note I have continued to edit the OP. In particular, note additions to the “Latency Incompatible With Stateless Content” section and footnote3.
legendary
Activity: 1764
Merit: 1007
November 19, 2014, 10:38:41 AM
#2
Time for Bitcloud / Storj / MaidSafe
full member
Activity: 154
Merit: 100
November 19, 2014, 03:42:04 AM
#1
    Anonymity: Death of the Stateless Web
    by UnunoctiumTesticles

    To garnish more interest an apt title could have been, “Tor Is Not Anonymous—Web Paradigm Shift Underway”. I am referring to antithesis of the computer science term stateful—not to being without a nation-state.

    Googling “death of the web browser” returns many articles claiming smart phone apps are replacing the web browser1. For example, Facebook’s app provides a more optimized experience than browsing the web site on the phone. However, I posit that more content instances2 are being added to and accessed from the traditional web than are being solely accessed from apps; for example, the posts to blogs and forums. My assumption seems intuitively valid for at least two reasons. Two finger typing blog and forum posts on small screens is highly inefficient and error prone. Secondly, new web content instances are being added much faster than new apps because writing HTML is much easier than programming the Android OS or iOS. Even if there exists an app that facilitates authoring popular categories of stateless content, the data format of that stateless content would become a standard MIME type (whether it was an open standard or reverse-engineered because of the content popularity), that app is a content browser, and web browsers could support the content MIME type.

    The balance will tip in favor of apps because:

    • Android apps are coming to your laptop and PC8.
    • To supplant the web browser because apps can often provide a superior experience. I enumerate some possible improvements provided by apps in The Stateful Web section below.
    • As the demand for anonymity on the web grows, the stateless web browser must be replaced by apps because network anonymity requires high network latency and only apps have the capability to provide a reasonable user experience when there is high network latency.

    Anonymity Requires Latency

    There are two fundamental types of anonymity mix networks: private information retrieval (a.k.a. PIR or “everyone sees everything”) a la Bitmessage and Chaum mixes such as onion routing a la Tor.

    PIR although low latency is not anonymous for any practical internet packet model because it would be impossible to dynamically adjust anonymity set groupings which balanced the traffic between all set members without revealing correlations that destroy the anonymity; also any practical design would not be entirely decentralized. Also PIR requires a high bandwidth burden on the clients since each client must receive all the server responses for all clients in the anonymity set.

    Onion routing is fully decentralized and does not require a high bandwidth burden on the clients. Although it also suffers correlations (intersections) from servers which dynamically exit the network, but if the persistent hidden services are the routing servers (which is not the case in Tor nor I2P) this will be a much less frequent event than the dynamically (constantly changing) balanced groupings required by PIR.

    The following frequent Tor attacks render Tor extremely unreliable, but could be fixed in an improved onion network.

    1. Timing (traffic) analysis3 enabled by the requirement for low latency, thus not inserting random delays in relaying at each routing server. Dummy (a.k.a. cover or padding) traffic is more wasteful, ineffective if not global, thus not a decentralized solution.
    2.Anonymity set is egregiously too few at only 3 hops. Hidden services have 6 hops, but only 3 while initializing the rendezvous relay of the circuit.
    3.Entry, exit, and relay routing servers provide bandwidth for free; thus are likely provided by national security agencies which have the financial incentive to unmask anonymity on a wide-scale.
    4. No DDoS prevention; thus inexpensive4 spamming causes exit node banning, exacerbates the three prior items in this list, and makes hidden services unsuitable for high traffic sites.
    5.Exit nodes are a massive security hole because national security agencies have backdoors to important servers and SSL certificates5―ideally only hidden services should be allowed.
    6.Intersections from servers which exit the network.
    7.Hidden services which are not also routing servers, have an identifiable traffic pattern where many more packets are outgoing than incoming due to the incoming be requests for content.

    Fixing #1 and #2 requires a high latency design. Fixing #2 - #7 requires clients paying per packet for (and to) the hidden services in order to incentivize them to be also the routing servers. If users select only hidden services they are familiar with for routing, this prevents a Sybil attack against the network.

    So a high latency design with pay-per-packet economics can be truly anonymous, but it will require a stateful web at the client provided by apps. Whereas, Tor was designed to work with the existing stateless web employing low latency, exit nodes (instead of exclusively hidden services), and the stateless web browser. As a result, research claims up to 81% of Tor users can be identified3.

    Latency Incompatible With Stateless Content

    Web content—even often when cached to check the current server file timestamp—requires HTTP retrieval from the host server. Network latency delays the user on every click in a stateless web browser, which could be on the order of double-digit seconds per click on a correctly designed, high latency, anonymous network. Even Tor’s slightly increased latency—albeit lower than required for true anonymity—can be maddening tsuris.

    Tor admits latency is a problem for hidden services (with its still tiny anonymity set of only 6 hops) and that solutions will likely come from restructuring the paradigm (“protocol” or “JavaScript hacks”). And Tor admits that supporting the “low latency web” is a “hard problem” that they “still don’t know how to do it correctly”.

    Demand for Anonymity Increasing

    Global police socialist nirvana cometh3 6.

    The 1878 Posse Comitatus Act forbade the use of armed troops on USA soil, but now it is openly violated by the legal switcheroo shell game of reconstituting the “peace officers” (a.k.a. police) so they are now effectively paramilitary. Even in Europe for example Switzerland is increasing gun control (oh grasshopper please understand why a lack of private arms means Putin’s ground forces can run over Europe like a hot knife through warm butter).

    The Stateful Web

    Strategies for minimizing the user’s perceived latency will vary and require client-side programming to be installed as client-side app. For example, a forum would persistently cache posts client-side, keep a persistent server-side record of cached posts for each client, and push new and edited posts to the client when the client is viewing a page which requires the updates.

    Note that latency doesn’t reduce throughput, so clients might be optionally programmed to preload updates and other predictive strategies such as a search engine initiating loading of the top results before the user clicks to view each of them. Rarely updated content (e.g. images, videos) could aggregated by hidden service hub servers which could continuously push7 updates to client caches.

    HTML5’s Offline Web Applications and Web Storage is moving in the direction of the stateful web, but it lacks the interfaces, design, programming, and programming language flexibility of the Android OS which also has a superior security model. Android OS is coming to your laptop and PC8.

    App installation is normally as simple as clicking to confirm that approve of installing the app and the app’s requested permissions. Note most apps in the Android security model don’t need any special permissions at least those developed for the latest Kitkat version.

    The title and content of this epistle is not about the death of all stateless content, rather I think it quite explicitly says death of the Stateless Web. This salient distinction is that per the Unix design principles of least presumptions, orthogonality, and separation-of-concerns, the content and rending model (e.g. HTML) shouldn’t have a monopoly over the transport model (e.g. HTTP). The Web is becoming more general, stateful, and the transport layer is detaching from market dominance by the rendering layer. This creates new opportunities and possibilities.


    1I found interesting data for smart phone penetration by region and country.

    2As opposed to the less meaningful bandwidth consumption comparison.

    3https://en.wikipedia.org/wiki/Onion_routing#Weaknesses
    https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#Traffic-analysis_attack
    Research claims 81% of Tor users can be identified.
    Timing analysis in conjunction with compromising the entry guard nodes and DDoS on exit nodes were possible attacks employed in the recent unmasking of hundreds of hidden services by FBI-ICE-Europol.

    4http://blogs.wsj.com/tech-europe/2012/11/05/where-to-rent-a-botnet-for-2-an-hour-or-buy-one-for-700/
    http://www.networkworld.com/article/2168696/malware-cybercrime/black-hat--how-to-create-a-massive-ddos-botnet-using-cheap-online-ads.html

    5http://falkvinge.net/2013/09/12/the-nsa-and-u-s-congress-has-destroyed-ssl-we-must-rebuild-web-security-from-the-ground-up/
    http://www.reuters.com/article/2013/09/05/net-us-usa-security-snowden-encryption-idUSBRE98413720130905
    http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html

    6



    7The onion routing circuit can be reused indefinitely.

    8https://en.wikipedia.org/wiki/Chrome_OS#Support_for_Android_applications
    http://www.zdnet.com/could-an-android-desktop-replace-your-windows-pc-7000024837/
    http://www.howtogeek.com/howto/22665/run-android-on-your-netbook-or-desktop/
    [/list]
    Pages:
    Jump to: