I'm supprised no one has mentioned the fair exchange problem: if A, B engage in an exchange protocol, say A sends data to B while B paying to A, how to achieve fairness using an asynchornous protocol. Without a third party, either one of the two parties has to be in a position of advantage where it can choose to walk off without fulfilling his part of the contract.
The problem still exists under "micro-transaction" scheme, but in a less exploitable sense: because each transaction only involves a small amount of money or data, it's probably okay if you encountered with a cheater with one or two transactions. You can just block them after catching them cheating.
But the cheaters can still exploit this problem for their own gain: they just repeat this scheme with all other users on the network, until they received the whoe file without spending anything.
I don't see this protocol preventing such exploitable scenario. In fact it's a very difficult problem to solve efficiently and without a traditional trusted third party. It's even been proved [1] that strong fairness is impossible without a trusted third party. However relying on blockchain as a thrid party, it's possible to achieve this, and there are implementations [2] out there, but the challenge is throughput. Most of these solutions can only handle kilobytes/s of throughput. The computational barrier here is the vast amount of modular exponentiations.
Great point. Not sure about state channels, but there are proposals for the Lightning Network. You could reveal a packet of data inside the payment confirmation itself, so it becomes atomic [1]. However, there are still issues: throughput, obviously, but then there needs to be a way to check the packet of data for correctness.
Yes, it's the basic idea of all the blockchain based implementations. The challenge here is you have to seal the data packet first, make a layer 2 commitment that has some kind of cryptographic binding to the data. Then you have to have a mechanism to atomically open the data while paying the contract. This can be done with some homomorphic properties of some cryptographic primitives but the computational cost is currently very high.
You could program the rules of the state channel used to provide payment exactly for the piece of the torrent provided. Like you point out, that would use a trusted third party to implement a fair exchange.
We considered doing that, but like you also point out, if you had to sign each piece of the torrent, it would slow throughput to a crawl.
I want to point out that E2E encryption on Web doesn't make your conversation more secure than regular HTTPS encryption without E2E encryption. The core to the argument here is the threat model. The whole point of using E2E on any conversation is to make sure that even the service provider cannot read your conversation. It's very clear that the threat model is againsting the service provider. However, the very same service provider of your conversation channel also provides the underlying encryption application on Web. That means, if the service provider wants to act evil, it's always possible to sneak you an application that steals your conversation by simply not applying E2E encryption, or just eavesdropping before encrypting.
The root of the problem is that Web application doesn't have a root of trust. As long as this problem is not addressed, E2E encryption on Web will always be meaningless.
Yes, your ISP could hack the binaries, break the HTTPS trust model somehow, and alter what you download, but practically speaking that isn't going to happen. Trying to build your system to defeat an adversary who has that kind of power ends up making it too cumbersome for the 99.999% use case.
What I don't understand is why the server needs to decrypt the traffic at all. Why not just have it rebroadcast the encrypted streams? The endpoints could exchange crypto keys with public key crypto and to the video server it would just be a bunch of bytes. Clients would turn on and off video streams from different clients based on network conditions and how much screen real-estate they have. Audio could even be encoded on a different channel so it could always be forwarded even if the video is not.
>What I don't understand is why the server needs to decrypt the traffic at all
In short, to make it scale for many (tens to hundreds) participants. Clever techniques like Simulcast[0] and SVC[1] allow that, but routing server must support it to meet different requirements of individual participants.
With media streams the provider typically wants to be able to recode the data to lower quality to fit the bandwidth available to clients with lower bandwidth / congestion etc.
There are ways around this but they are quite complex and place additional CPU overhead on each sender.
I think the key problem here is where and how do we establish a root of trust for Web applications.
Currently we have some form of root of trust for HTTPS/TLS, code signing, trusted execution, that the OS or browser or chipsets distribute a set of "trusted" root certificates. For the consumers, they are implicitly backed by the big companies that manage the screening, auditing, and distribution of these certificates. But of course, these certificates have limited use cases that not yet covering the end-to-end encryption application for Web.
One way or another, we have to start our root of trust at some layer, either it's hardware, OS, drivers, or applications. But in general, the lower the layer gets, the lower the risk would be. Because it's easier for an evil actor to target specific user in higher layers.
There are more to be solved than just the root of trust for E2E on Web. For example, even if we can use trusted execution environment on a Web application to ensure secure key generation and key escore, we still have to face the problem of how to input or present the cleartext data with the user. If we still let the JS code to handle the cleartext in any way, there could still be a chance that the distributor of the JS code might steal them.
With that said, not only should we have a root of trust, but we also have to trust the UI provider that operates on the sensitive data for user input or display. The lowest UI layer is usually the OS, so even we have hardware root of trust, but if the trusted UI is in the OS layer, we would still be throttled at the level of trust on the OS layer.
After McDonald's (China) was acquired, McDonald's (Global) banned them from using McDonald's and its phonetic name 麥當勞 in China. It then changed its name to 金拱門, which literally means Golden Arches. Chinese people found it so hilarious that it went so viral. News got over nine billion views. It was such a success for marketing, but it doesn't hold the same profile as before.
They sure seem different than the ordinary McD in other countries.
The McD online ordering website in China is https://www.4008-517-517.cn -- apparently "517" sounds like "I want to eat".
They sell a "Land, Air, Sea Warfare" combo menu which sounds ominous, but apparently it's commonly known "secret menu" item on ordinary McDonalds combining a Big Mac, McChicken and the McFish.
The problem still exists under "micro-transaction" scheme, but in a less exploitable sense: because each transaction only involves a small amount of money or data, it's probably okay if you encountered with a cheater with one or two transactions. You can just block them after catching them cheating.
But the cheaters can still exploit this problem for their own gain: they just repeat this scheme with all other users on the network, until they received the whoe file without spending anything.
I don't see this protocol preventing such exploitable scenario. In fact it's a very difficult problem to solve efficiently and without a traditional trusted third party. It's even been proved [1] that strong fairness is impossible without a trusted third party. However relying on blockchain as a thrid party, it's possible to achieve this, and there are implementations [2] out there, but the challenge is throughput. Most of these solutions can only handle kilobytes/s of throughput. The computational barrier here is the vast amount of modular exponentiations.
[1] https://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagni... [2] https://github.com/sec-bit/zkPoD-node