Submitted: 21 January 2019
Accepted: 15 February 2019
Review A: 4. Accept
Review B: 3. Weak accept
Review C: 2. Weak reject
4. Accept
3. Knowledgeable
This paper makes a case for decentralized web applications by discussing a few motivating applications and the corresponding enabling techniques.
I agree that web browsers have become the main entry point of computing and are replacing native programs in many places. In recent years, we can see techniques like browser OS and browser-based storage,
https://arxiv.org/pdf/1611.07862v1.pdf https://www.usenix.org/system/files/conference/fast18/fast18-xiao.pdf
but I don't buy the argument that browsers or the web should evolve into a fully decentralized form. P2P/decentralization is not panacea to many of the problems you raised in introduction such as privacy and security.
My main feedback is that the authors should connect Section 2 and 3, which will make the paper much more interesting and relevant. Let me elaborate this.
I like the applications discussed in Section 2. However, I don't find anything particularly interesting about these application -- all these application can be implemented as desktop/tablet software. Also, I don't really see anything special about the requirements listed in the section.
Section 3 is the most interesting section. I would suggest you to discuss the challenges of using existing web techniques to implement the applications described in Section 2 (which also makes Section 2 relevant). Now the connection is missing, and I feel the content in both sections very dry.
Overall, I think this is a decent, relevant paper to be discussed at EdgeSys. I hope the authors could focus on discussing the techniques, the challenges, and the experiences in building web-based P2P applications.
3. Weak accept
2. Some familiarity
Authors describe a set of application scenarios for decentralised client-centric web applications (multi-player games and enterprise level applications, such as a shared whiteboard), and a set of requirements needed for a decentralised client-centric web middleware that enables these applications. Among the identified requirements, they claim that such middleware should be fully based on standard browser technology and its JavaScript programming environment, and that the core functionality should focus on data-centric operations (storage, replication, synchronisation,...). They further comment on the existing technology in browsers to enable these middleware, such as WebRTC (that allows browsers to directly communicate with each other) and JavaScript threading, and on the need of a new security model in the browser to enable sharing data in a decentralised fashion. They implement a middleware (not clear if fully) and a client-centric app, and compared the time and bandwidth used to synchronise data in a classical client-server setting vs in the P2P setting, finding that current browsers are ready to allow decentralised, client-centric apps, since only the bandwidth required by the clients increases with respect to that in the client-server scenario.
POSITIVES
NEGATIVES
2. Weak reject
3. Knowledgeable
This paper argues that the client-server model for web applications suffers from two drawbacks: (1) users lose control over their personal data, and (2) cannot operate in disconnected settings. To counter these issues, the authors present a distributed/p2p we server using WebRTC connections between client web browsers. They discuss three use cases that motivate the design of the distributed web server: (1) eWhiteboard (a shared whiteboard that allows people in the same room to collaboratively draw and write ideas), (2) eDesigners (a web application for graphical templates that can be edited by several users at the same time), and (3) eWorkforce (an application that allows technicians who install network devices on customer premises to synchronise with their co-workers work plans, used materials and progress). They discuss capabilities of the modern browser in terms of supporting a distributed web application. They implement a prototype of the distributed web application, and evaluate it by deploying web clients and servers over their OpenStack private cloud. They find that compared to client-server, the p2p web application results in improved interactivity of updates, and low network usage.
The idea of distributed web applications via WebRTC is quite interesting. I appreciate that the design is motivated by real industry uses cases undertaken by the authors. Section 3 on browser capabilities for supporting distributed web applications is informative. However Section 4 jumps straight to the evaluation without providing sufficient details about the system architecture and implementation. The evaluation is adequate (given that this is early work) and the results are promising. However, the absence of architecture/design makes it hard to assess the system. Earlier in the paper the authors mention users' lack of control over their personal data as a motivation, and privacy/access control as (advanced) requirements, but it is not clear how their system addresses these issues. Another limitation, which the authors also note, is that the system still needs a central server for signalling. They do not discuss how consistency is achieved when users simultaneously edit the distributed web applications. The Related Work section seems adequate but does not highlight the novelty of this paper and its contributions with respect to prior work. How does the proposed model for enabling communication in disconnected settings compare with the delay tolerant networking paradigm?
Minor comments: