WhatsApp Down in Some Regions
xn--allestrungen-9ib.de
xn--allestrungen-9ib.de
> When you proceed to access our site, the companies listed in the Cookie Consent Tool will use cookies and other technologies. This is further explained in our Cookie Notice.
None of those are links, and the only button is "Agree and access site". How do I find the Cookie Consent Tool and the Cookie Notice, without having to click "Agree"?
I found their privacy page here: https://xn--allestrungen-9ib.de/privacy.html.
Interestingly, that has a link to a cookie policy that links to speedtest.net's cookie policy (https://www.speedtest.net/de/about/cookie-policy). I think downdetector is offered by Ookla, so that probably is their cookie policy?
speedtest.net's cookie policy leaves something to be desired. In the english translation it has:
> If you prefer that we do not collect information that will help us determine which advertisements we are best serving you, click this icon.
But I don't see an icon there, or anything clickable. In case it's a mistranslation here's the original german:
> Wenn Sie es vorziehen, dass wir keine Informationen erfassen, mit deren Hilfe wir ermitteln können, welche Werbung wir Ihnen am besten anzeigen, klicken Sie auf dieses Symbol.
Based on that, I have no idea how you can manage your cookie preferences to express a desire not to be tracked.
It seems to be an absolutely flagrant violation of GDPR, and I would encourage a German citizen to bring a case to the German data protection authorities.
Do they need to specify these other technologies, which they are and how they are being used?
edit: push notifs came through. inbox not loading however
edit 2: seems to be fully restored. all my homies are responding to messages
Also, widespread outages like this are seldom the result of insufficient capacity. They are almost always a perfect storm of several failures within systems that are individually build to handle adverse conditions. An example might be a bug within a task scheduling system that inadvertently scales down some critical service which in turn leads to something else failing to reach consensus or read configuration or who knows what. The point is that each of these components is designed and built to handle failure but something the holes in the cheese line up and the whole thing fails.
In this case since IG, WA and FB were affected it's reasonable to guess the failure was in some shared component like load balancing or task placement, though (as hinted at above) the origin of the fault is not necessarily in that component directly.
What they did was purposefully remove redundancy they had, in order to be able to track people more (in order to profit more) and possibly scale easier. Doing nothing would have been easier but yet they still did it.
Bear in mind WhatsApp used to maintain a userbase of 200 million with 50 total employees (not even just developers).
Lol, I'd believe you when they did purchased the service but the countless amount of times it went down since then obviously proves that they cannot even maintain the services when they are folded together on the same infrastructure.
It was a long time ago Facebook employed the best of the best. Seems like it's mostly average developers and infrastructure people there now just trying to hold up the house of cards they built.
OR, get people on Matrix or similar so we can actually stop jumping ship when our centralized dear service stops acting in our best interest.
Decentralisation is the right answer. Unfortunately we always cannot convert or move others every-time we say the word 'Matrix' or 'Element/Matrix', which leaves the user confused with the client and the protocol. It is close to the GNU/Linux naming all over again and that did not catch on.
If you want others to make the switch to (Chat client that uses Matrix) without confusing them, then at least avoid telling them to: 'Use Matrix' which is like saying 'Use MTProto' or 'Use libsignal'. The client's name is always mentioned but this is why compared to Signal or Telegram the name 'Element' sounds totally off, even without mentioning the protocol.
For example: Almost everyone has heard of 'Bitcoin' and it's decentralised. That works. No need to mention 'Blockchain' or any of that jargon. So let's have a user-friendlier decentralised client that does not need to mention the protocol's name.
Then it's up to us nerds to find the best client for our non-hacker friends and family.
Matrix being federated does absolutely nothing to solve this problem since there's no failover if a user's homeserver goes down. It just limits the potential blast radius but if matrix.org went down Matrix might as well be down for most people.
> There is no single point of control or failure in a Matrix conversation which spans multiple servers: the act of communication with someone elsewhere in Matrix shares ownership of the conversation equally with them. Even if your server goes offline, the conversation can continue uninterrupted elsewhere until it returns.
So right now, if you're trying to message someone via either whatsapp, facebook or instagram they will all fail, most likely because of the same issue as they are run by the same company. If you were on Matrix, you would for sure be able to find a way of reaching this person even if servers go down, that's the entire point of federation in the first place.
True, but it makes a difference between a single Homeserver not working any more and the entire global service. This likely won't ever happen.
> matrix.org went down Matrix might as well be down for most people.
not really (afaik less than a third of public(!) users use matrix.org)
Also consider ongoing developments of distributing accounts on multiple servers (which may also reside on your device) for P2P Matrix. This gives additional redundancy.
No, let's continue relying on a single centralized service for the whole world.
This means that even with Element (the matrix client) all of your notifications when your phone is locked are going from your server to the centralized dev push system run by the Element devs, then to another centralized system run by Apple.
Either could have an outage, although I think APNS (the apple side) has close to 100% uptime since launch, which is quite a feat.
It's better to choose a fight you can win.
1) Notifications being down is a smaller problem than the service not working at all.
2) there are indeed alternative push systems that allow plugging different push systems (see Unified Push - though not yet supported by Element)
We actually decentralized them decades ago, it's called email
On the other hand, at least Element is decentralised thanks to Matrix, but unfortunately suffers from a naming dilemma and is unfriendlier than the rest of the chat alternatives.
We need an alternative that is a mixture of both: Open source, Decentralised (Likely uses Matrix underneath) and is extremely user friendly and competes on security and features.
Germany