first the article jumped the gun when saying it's by Hetzner/Linode, as it as much could have been done by the carrier the data-center connects to and from what I know about German espionage/wiretapping by police law that would be far more likely
second pretty much _every_ country has laws which require carriers to help them wiretap in case of an investigation with appropriate court orders
thirdly even if it went through Hetzner/Linode instead of carriers it wasn't done "a move from them" but something they where legally binding ordered to silently tolerate
lastly if as unlikely as it seems it was not lawful interception of police or similar then they (or a carrier) would have been hacked, i.e. there is absolutely no chance that server providers will do such an attack on their own violation, especially Hetzner (they also don't have the legal means to get the necessary certificates)
That "lawful" interception allows certificate issuance to be a means of wiretap completely undermines any trust one should have in CAs. It seems that an alternative is greatly needed.
The fact that they were legally required to MITM their customers does not make them more trustworthy (in the sense of unlikely to do it in the future), just the opposite!
Of course that applies equally to any other cloud host (modulo jurisdiction games) but that does little to restore my interest in running my software on other peoples computers.
It's not about "other peoples computers" (there is no evidence of the system itself to be backdoored). If you are running on your own hardware in your own house, you still need an ISP that can do exactly this time of MITM.
Or, presumably, using other people's internet peering, since the MITM was outside of the XMPP server host.
I think jurisdiction games is all you have, because outside of that there's going to be _someone_ close to you network-wise who will fold when faced with a lawful intercept order.
yes it applies to pretty much any datacenter and carrier in the world
but that's why running thing at home doesn't help that much, because it also applies to carriers, too
and when it comes to sizing data it tends to not make much difference whether they physically size disk at your home or in the data center, actually if legal order for a sizure like that is confirmed by a judge it's normally applied to all the computers such a person has, both at home and in datacenters
Truly sorry that we missed these instances of "open-source" references. We scrubbed the use of open-source in most places, but forgot about our home page, which might sound weird as the home page is... well... home page. The truth is that our web site is not our primary focus at the moment. Rather we are putting almost all our effort for building the product (You can watch all of it in GitHub).
We don't claim to be "open source" rather we are open and free as in you can see the code and host it yourself if you want. The restriction is that license does not allow building a managed service out of it.
I suppose because they are an ELF feature rather than a language feature?
Anyway you can (and should!) use -fvisibility=hidden and add __attribute__((__visibility__("default"))) to public symbols when writing a C library. It will make calls between non-visible symbols faster because the compiler doesn't have to generate code to handle ELF symbol interposition.
You might also want to compile with -fno-semantic-interposition since no one actually needs semantic interposition for symbols used and defined in the same library so you might es well disable it even or public functions.
And link with the `-Bsymbolic` or `-Bsymbolic-functions` linker options to save on the indirection when calling public functions within the same library but across object files.
All compiler flags are non-standard because the C standard does not concern itself with them at all.
That said, there are effectively two standard compiler interfaces: MSVC and GCC and everyone else emulates one or both of these.
Similarily, symbol visibility is not something that the C standard cares about because it doesn't even care about libraries in the first place. Again, for all platforms that have symbol visibility (e.g. PE and ELF based ones, although the details differ) there is a defacto standard for the compiler flags and attributes to control the visilibity: the MSVC and GCC extensions.
You can (and should!) use a linker version script instead to ensure you're not accidentally leaking any exported symbols from other static library dependencies ;)
Not surprising, though. The issues surrounding if/how a system provides libraries of any kind (static or shared) are completely implementation-defined. The Standard doesn't have anything to say about them at all except for the program-wide symbol scope rules.
Well, it's also much harder to crack down on voter fraud like voting on behalf of dead people. I would say paper voting has a larger attack surface for the average voter.
Those things are overwhelmingly less common than you are pretending, make very little difference, are substantially easier to prevent than attacks on electronic voting, and are trivial to detect.
