rixtox

It's obviously for emacs users.

Hiding the full URL will redirect a lot of traffics back to Google's search engine because people can't easily figure out the source from a screenshot anymore.

How about Matriot?

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.

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.

[1] https://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagni... [2] https://github.com/sec-bit/zkPoD-node

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.

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.

Can someone write a patch worm that spread and fix the bug by exploiting the bug itself?