> 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"?
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.
It would be, but that made me fall into the HN rabbit hole. One hour later, I know more about the hacks used in Duke Nukem 3D but my tasks are still uncompleted.
This is the paradise I live in every day. Never used it. I have however had to spent the last hour being asked when it will be back by three teenagers and a wife, none of whom appreciate it is nothing whatsoever to do with me. Grr.
Downdetector [1] shows some problems with other websites including Twitter and Microsoft as well. Doesn't seem like a cloud provider being down though.
quite rare on HN yes. there are loads depending on the region. if you have no use for them it's a good idea to block them with dnscrypt-proxy[1] or nfq[2] to avoid getting bitten by homograph attacks.
I looked at the headers returned from the server using developer tools. 503 is "Service Unavailable" and you often see it when a proxy can't reach the backend server.
These companies build for redundancy. Not in the sense of "we need 10 servers, let's have 10 more for redundancy" (that gets expensive when you have millions of hosts) but by scaling out across multiple regions/DCs/clusters/etc such that there is enough slack in the system to absorb failure of 1 or 2 resource units (DCs, fiber, whatever).
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.
IIRC there was a situation where google built a circular dependency in their own cloud services and they had massive issues bootstrapping the systems again after they went haywire
It's not just about adding redundancies. Redundancies don't protect you against bugs, and they're itself very complex, so they introduce more opportunity for errors. Even with best redundancy, you'll have incidents from time to time.
It doesn't help either that Facebook made three separate services that should have nothing to do with each other, talk to each other and all route their traffic through the same infrastructure.
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.
If you think that maintaining 3 completely separate stacks for 3 different services within the same company is making all of them more reliable, I don't think you ever worked on a big scale services.
No, I'm hinting at that have one company running these three services in the first place is wrong. Should be three independent companies as they are really three different services, but lord knows governments does nothing to prevent monopolies these days.
> They can absolutely maintain 3 different services
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.
Yes, I adjust my language depending the audience and since this is "Hacker News" after all and I mostly don't care about what client people use, as long as it's using Matrix, I find it's best to recommend the protocol itself.
Then it's up to us nerds to find the best client for our non-hacker friends and family.
Quick let's replace this centralized service that goes down sometimes with a group of centralized services that go down sometimes.
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.
I've been looking for data around how many people actually use the various matrix servers, but seems you have it already. Could you please link here so I can see it too?
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.
Pretty much. My main preference for Signal is that it's a charitable organisation. That and a few other bits. Phone number IDs are on the way out hopefully. The dream would be some kind of federated layer, but the charitable org thing is a good start for me.
This isn't the panacea you think it is. For example, on iOS all server notifications for an app must be proxied via Apple and have to come from the app developer's push certificate.
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.
This comes from from someone who enjoys the convenience of centralized services, but that honestly sounds to me like an argument for decentralization of mobile notifications too, not a refutation of the idea of decentralized messaging.
"We" can't decentralize notifications on iOS, only Apple can. It's not in their interest to do so (battery life, platform brand control via censorship), so it's probably a moot point.
This comes from someone typing this on an iPhone, but that sounds like an argument to drop this goddamn walled garden/prison. I’m literally sick of it.
You also can't use an iPhone without it constantly sending usage information to a half dozen different teams/departments at Apple, even if you've opted out of analytics, so there's that, too. I think I've bought my last iPhone, as well, after having had all of them.
And no. The same people won't flock to Signal after all of this, even though it is much more friendlier than Element.
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.
I think that's what domains get translated into when you're using a foreign language for the URL. It's to prevent IDN homograph attacks https://en.wikipedia.org/wiki/IDN_homograph_attack which basically tries to impersonate a legitimate URL with a fake unicode character.
I've always thought that there must be a better solution than to force all of the non-English speaking world to conform to our views though.
Chrome somehow solves it. If you visit the actual URL, it's allestörungen.de, which is quite nice. I wonder what the protocol is of when to decode the URL.
I believe it's more to do with DNS requiring using a subset of ASCII characters.
Punycode was devised as a way to encode Unicode characters into this subset of characters that DNS recommends.
You want to explain the problem or just shit on something you don't understand? I thought we were all here to learn and discuss with good intentions, but seems you're not...
Can you not make this an "blablabla ad hominem blabla"? It is absolutely obvious why this is terrible behaviour: the url that's previewed simply doesn't match the one you'd type in the address bar. The encoding is messed up despite Umlaute being part of utf8, and if you're parsing HN with your own code, you're in trouble because you need to account for encoding, which simply shouldn't be a thing in 2021. "HN should be about ideas, so instead I'll make this about you" is not just wasting every readers energy, it's blatant projection and beyond embarassing. PLEASE don't do this here.
Chill. Take a breather. I get it, I get where you're coming from, but you're going to get yourself banned or penalized if you keep this up. And that's really not fun.
Logically, you are correct. So if you're looking for someone to say you're right, here it is. But being right isn't automatically a win in a group setting. You have to phrase your ideas well.
HN is about performance art. And your performance leaves something to be desired here. It is what it is. It's also not the end of the world: simply start talking like you would to a colleague, instead of thinking of HN as an angry crowd out to get you.
> the url that's previewed simply doesn't match the one you'd type in the address bar
Thanks, finally an actual argument against it.
Well, to be fair, you have three representations of it that happens. What you see in the addressbar is not actually what goes over the wire anyways, so the current implementation (in your words) is actually better as that is what being transmitted.
If you were rendering the actual unicode characters there is a risk for "IDN homograph attacks" which basically is what you are hinting at to prevent as well, but your solution would make things worse, not actually better.
> It is absolutely obvious why this is terrible behaviour:
It’s absolutely not. You were ranting about a character set issue while the problem is unrelated to character sets - punycode is the solution chosen for domains that use non-ascii characters since that would open the space for attacks using similar looking characters. HN is absolutely capable of displaying “allestörungen.de”, no character set issue here.
> the url that's previewed simply doesn't match the one you'd type in the address bar.
I can type "xn--allestrungen-9ib.de" in my address bar and get to the same site. Not everyone uses a keyboard layout with umlauts to type allestörungen.
I don't care about your shitty punycode domain, I care about being able to see when a link is pretending to be "google.com" but is in fact some utf8 garbage.
> 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"?