I have zero practical experience with contacting abuse contacts. But my expectations would be very very low. For the hyperscalers you will get autmated responses and no way to make your point heard. For small ones there will typically be silence.
I've tried contacting various domains via their abuse and technical contact WHOIS info over the the years. Mostly small-to-midsize domains, including colleges. I've never gotten a reply, and I don't know if the emails ever went to a real person. Occasionally the issue I was reporting got fixed, but I have no idea if my email had anything to do with anything.
Openwrt is mentioned to be affected and we use openwrt in our product. Looks like our configuration is different enough that we are unaffected, but still I thought I mention the vuln in our company chat. Turns out that M$ Teams does not let me post the link. Like in China, the party knows what news are good for you.
Azure is most unreliable for me because of how terrible the UI is, plus ipv6[0]. Agents translating natural language queries/actions to Azure api calls is a lifesaver.
Define unreliable? Azure has a 99.97% historical uptime, AWS at 99.95%. Azure is #2 in market share, right beyond AWS. Engineer anecdotes about internal strife doesn’t equate to external reliability. I’m sure you can find AWS engineers complaining about AWS, or GCP, or insert company. (Also, Microsoft owns Azure and GitHub, so what did you expect?)
Where and how are you getting that reliability data? And what is it for? All services? A region? Everything averaged out? I know companies embarking on multi million dollar projects to add a backup identity provider to EntraID because it's that unreliable and it costs them money every time it's not working.
Azure was the cloud that had all global auth rely on a single DC in Texas (we learned when cooling failed there), and didn't have availability zones in most regions until not that long ago. They've also had a number of trivial cross tenant exploits. No, two us-east-1 outages that had minal global impact isn't comparable, we're talking about all auth for all of Azure using a single DC, not a region of 5 DCs having the control plane for global AWS services.
Neither security nor reliability are a priority. It's by far the worst big cloud provider, and it's not even remotely close.
It was a question, not a statement. Yes, you can find complaints about every company. I have never used Azure, but remember people complaining like in a sibling comment. I have used AWS for 15 years, some years even a lot. It's mostly working, although I also have my complaints. They have billed me for a VM after sending an email that it has probably failed. And yes, it was not working correctly. As we speak they have locked me out of my private account, not particularly important, and support can't tell me why. They are still billing. Nothing really surprising, the cloud is not your computer. And hyperscalers have no customer support worth the name unless you pay $$$.
What do those uptime numbers tell? For 95% of the problems I had the status page has no information.
I can't speak about the strength or weaknesses of the whole concept.
Out of curiosity I enabled DNSSEC checking beginning this year. I mostly noted nothing in my browsing. However, with 2 services I noted obscure problems that worked only partially. Some Jira plugins and Swedish railway SJ. I needed to excempt some of their domains from being checked to use their services. Of course you waste a couple of hours every time it happens because you don't think of DNSEC first when some web-based services behaves weirdly. There might be more requests not served to my browser, but I just never noticed or bothered to debug.
So not fit for general use. And even as an experienced developer it's not easy to understand why an exception would be needed. A bug in systemd? Incorrect data in DNS? A real attack?
Edit: I don't use standard DNS on port 53 at all. Blocked outgoing requests on that port. Everything DoH or DoT. Of course I need to trust those endpoints at least in repect to confidentiality. And most domains are unsigned. At least for those unsigned ones I need to just trust also in respect to integrity.
DNSSEC failures need to be louder. If websites that fucked up their DNSSEC would get the same error messages as websites that fucked up other parts of their security, people wouldn't be so eager to turn off security festures as workarounds.
Give SJ the option to turn off DNSSEC and their website will stay broken. Give people a "someone might be tampering with your connection" popup and they would start caring.
There are also other issues with DNSSEC that need working out, but I still believe it does much more good than it does bad. Leaving everything in the background with an easy-to-disable setting makes it next to useless.
Full ACK. As a part of this, DNSsec validation needs to be as close to the client app as possible and reasonable; definitely never off-host. (Caches can do additional validation, but that makes the error reporting complicated.)
corollary: the AD bit should never be relied on on anything actually on the network. Maybe on localhost, but even there it's questionable in UX results.
It's about time to question the whole off-host DNS resolver thing entirely. Fine if you want to have a cache, but the cache should return the whole record chain starting from the root in that case, so the client can validate it. Also fine to have an on-host cache that caches validation status.
2 days later support called me. The support person was professional and we tried a lot of stuff like different browsers, private windows etc. to no avail. He disabled MFA to narrow down the problem. I got an email confirmation about that and no OTP is asked anymore. So no doubts it was done correctly.
Now the situation is: I can change my password using the the forgotten password process. I get an email that the change was successful. But the new password does not work.
They promised to escalate and gave no estimates when something might happen...
Yeah, the tech powerhouse seems to refer to the US. There is no doubt that US dominates a lot of tech at the moments, China dominates a lot of manufacturing.
The US is a failing democracy ruled by ruthless liars and capitalists. China's surveillance and lack of freedom is beyond discussion. So EU not being a tech powerhouse still does not look too bad.
The link seems to be the minutes of a parliamentary debate about a multitude of topics. It does not explain what this tax is about and I guess there is another approval step in the senate (French is neither my mother tongue nor am I fowolling French politics)
That the current internet with social media and AI boom destroys democracies and the planet is a fact. Whether such tax is a good step to slow that down, I have not thought about.
Not very familiar with PDP history, but PDP-12 missing also caught my attention.
Regarding later heritage, to my understanding, several developers of the VMS kernel moved on to work on the Windows NT kernel. Whether it's really only coincidence that every letter of the acronym got shifted by one?
The first few versions of Windows NT had a very strong API resemblance with VMS, which is why Microsoft settled to pay to DEC a 9-digit $ amount, to avoid a legal battle. Though eventually that deal was less advantageous for DEC than it appeared from the amount of money, because it included the support of Windows NT for DEC computers.
The parts of the initial Windows NT API that did not resemble VMS looked liked cleaned-up versions of the UNIX API, e.g. the functions for handling file and device I/O.
The central role of asynchronous I/O in Windows NT was inherited from VMS, which in turn had inherited it from the RSX-11M operating system for PDP-11 computers (Dave Cutler had a major role in the development of all these 3 operating systems).
Whether VMS => WNT is a joke like IBM => HAL, is anyone's guess. A more certain thing is that IBM was named such as to be a hyperbolic substitute of the name of its main competitor, NCR (National => International, Cash Register => Business Machines)
At least the statement is not competently written.
They write that TLS certificates have potentially be exposed. That doesn't make sense. TLS certifcates are public. Probably they mean private server keys have been potentially be exposed. And after that the certificates are not only useless but dangerous (if the private is really in the hands of the attacker).
They write they have been revoked, OK. But they continue to be served until new ones are in place. Hmm? Well, no browser checks revocation anyway I guess.
Can anybody tell me it's not that bad?
reply