o-

That sounds exactly like the new autopilot system they describe in their USENIX paper.

Talk: https://eventsonair.withgoogle.com/events/autopilot-research...

Paper: https://research.google/pubs/pub49174/

Great, I feel like an idiot. I advocated slack, because it granted the freedom to choose a client. Now I helped lock-in others.

Suggestions for alternatives, that I could migrate to? The requirements are: mid sized teams, desktop and mobile, all major os. People used web based client, native clients, irc gw, and bots. We need search and archive. Self-hosting is an option.

It still happens sometimes, that I don't regret diving into the comments section of an article. This thread was such a gem.

Thank you.

Chronology of scoops published on that site at [1]. Some headlines translated:

* Leak of AfD (right-wing populist German party) internal chat, which reveals Nazi quotes.

* Article showing collaboration between a neonazi and police in Leipzig.

* Outing right-wing arsonist who was also a police informant.

* Research on the Identitarian Movement, revealing organizational structure.

* Leak of customer data of a Nazi online shop outing parliament member as customer.

No wonder they made some good enemies.

[1] https://twitter.com/Chronik_ge_Re/status/901033270133096452

In theory there are alternatives where you do not need to trust the server. The keyword is proxy re-encryption (e.g. [SELS]).

On the other hand schleuder exists today and can be used by normal people (for example without having a custom private key per list, as you need afaik for [SELS]).

The other often overlooked fact about schleuder is that it's also a re-mailer. You can use it in a one-to-many setting, where the external party does only know the cryptographic key and email address of the list and a group of people can communicate with this person using schleuder as the proxy. This is a great alternative to shared mailboxes and a feature that is probably impossible with proxy encryption.

[SELS] https://slagell.info/Adam_J._Slagell/Past_Projects_files/khu...

I fully agree with your analysis. But cryptocurrencies are just the latest tool that will serve well the interests of the demagogues. Technocracy will not improve affairs that we don't resolve as a society in the first place. More powerful tools means just more power to those who can afford the longest lever. Any other interpretation is just a blatant neglect on the history of technology.

"It's a great thing," Pate tells me. "It beats the alternative. Rather than sitting in your tiny little cell, you get to come out here."

Completely voluntary to work there though, of course.

I believe from looking at the fix [0] I was able to trace back the origin of the bug. This is my (unverified) theory. Can anybody familiar with serpent confirm?

There is a catch-all [1] function in the public API (why???) of the wallet contract which uses delegatecall to delegate to the library class.

"In a similar way, the function delegatecall can be used: the difference is that only the code of the given address is used, all other aspects (storage, balance, ...) are taken from the current contract." [2] (again, WHY???)

So calling through this catch-all function the "internal" modifier on "initMultiowned" does apparently not prevent it from being called, since the delegation happens from a function inside Wallet.

So the "attack" is to just tell the wallet to reset its owners to myself. This would be so embarrassingly trivial, that it's more like picking the money up from the floor, than a "heist".

This wallet contract is insane and the programming language too. Why would a language for such a critical application have such super unsafe constructs? This can't be true. Please, serpent community, talk to your local PL people!

[0] https://github.com/paritytech/parity/pull/6103/files [1] https://github.com/paritytech/parity/blob/02d462e2636f1898df... [2] https://solidity.readthedocs.io/en/develop/types.html#addres... [3] https://github.com/paritytech/parity/blob/02d462e2636f1898df...

This is a great idea [your edit]!

And its already being developed by some (not protonmail though). See https://github.com/ehloonion/onionmx