phicoh

I'm not an expert, by dry air has a very low heat capacity. So you get a house with cold walls, floor and roof. And the dry warm air is rather ineffective in transferring heat to the walls, floors, etc.

In contrast, if you have underfloor heating, you have a relatively large surface filled with warm water that heats up the floor. And then you have an even bigger surface that transfers heat to the rest of the house.

In the end the house is more easy to heat because it doesn't depend on an airflow to reach all parts the house.

The situation with respect to condensation: look at historical data for the dew point during the summer season. That as low as you can get. For example, I'm in The Netherlands and our system is set to 18 degrees Celsius.

The amount of cooling this way is limited. Though the nice thing is that it tends to keep the house cool. There is no cold airflow.

With respect to government grants. Sometimes you can buy units that can only heat to get the grant. But a simple change enables cooling after the unit is installed.

Think about if it happens (or does not happen) every 6 months and you can never plan ahead.

And daylight saving is a local problem. In my country the rules have not changed for more than 4 decades.

The other problem is that most systems use time zones and daylight saving mostly as a presentation format. Only time that is explicitly for human consumption deals with time zones. Internally computers mostly use UTC.

The problem with leap seconds is that computers often represent time as some number of seconds since an epoch. That requires a stable conversion between year-month-day-hour-minute-second to seconds since epoch.

And that's where leap second are a problem. Because future leap seconds a undefined, this conversion is undefined for dates in the future.

That then results in a collection of hacks to let it work most of the time.

Where I live, civil time is currently off by about one hour and 41 minutes, compared to solar time. It is safe to say that essentially nobody cares about solar time with more precision than one hour. If you want to know about sunrise or sunset, you just look it up. Noon is mostly irrelevant.

The problem with leap seconds is that any conversion between TAI and UTC for a time stamp more than 6 months in the future is undefined.

If we did the same thing with time zones or leap days, that some committee would only announce changes a few months in advance then people would get very upset.

The how is simple, all devices will be required to be as locked as iphones. No apps on your device unless approved by the vendor. Open source is fine as long as you jump through the hoops to submit it for review.

I wonder if they are going to kill open source chat applications.

In my experience, meeting people in person at the coffee machine or at lunch creates way more social cohesion compared to exclusively using mail, chat, and video conferencing.

This is important even in bigger organizations, because you want to catch errors early on. It helps if people bounce ideas off colleagues to see if there is anything they missed.

With people you barely know, if it is not your responsibility to comment, why bother? Better to get get some work done, then to read the chat all day.

Personally, I think about two days per week at the office is best for this purpose. But that may very from person to person.

Where do you find an attack on a registrar account in the following attack: https://freedom-to-tinker.com/2022/03/09/attackers-exploit-f...

I can't find it.

Maybe you can be a bit more specific and explain how exploiting BGP can change the CAA record in a DNSSEC secured zone?

ACME validation with dns-01 relies only on DNS. Routing does not matter other than to create DoS.

It seems you miss something, maybe because you don't consider DNSSEC as something that gets actual use.

With DNSSEC, somebody can reroute traffic all they like, they cannot generate fake DNS responses that are DNSSEC valid for DNSSEC secured victim domain. So if the CAA record is properly set to only allow the dns-01 validation method for ACME, there is simply no way to obtain a false certificate even if the attacker controls all of BGP.

Here is a recent attack showing the lack of resilience in the CA ecosystem: https://freedom-to-tinker.com/2022/03/09/attackers-exploit-f...

With password resets your own mail server is not involved. STARTTLS or not. In the absence of DANE, mail servers will not require or validate certificates. So the reset link will get to the attacker in the vast majority of cases.

It's a common misconception that DNSSEC is not needed if you have TLS. Two reasons come to mind: 1) CAs will happy issue TLS certificates if you can spoof DNS. In the past you would have to spoof MX records, with letsencrypt (or other CAs that implement ACME) you have to spoof the A/AAAA of the domain you want to attack (and deny the existance of CAA). Surprisingly it is almost never mentioned that the security of TLS is completely dependent on an extremely insecure protocol like DNS. 2) The only thing that comes close to practical email security is DANE. With DANE you can tell the sending mail server that TLS is available (to prevent downgrade attacks) and what the certificate or key is. Even if you don't use email for communication, many systems include email verification as part of a password reset procedure.

If you set the CAA correctly, then letsencrypt will limit validation to the dns method. Together with DNSSEC that is enough to prevent issuing certificates in case of a route hijack.

That's not correct. If you set the CAA correctly you can limit certificates to for example letsencrypt and dns validation.

An attacker can get around that if a CA does not use DNSSEC validation to check the CAA. But that would be a problem with the CA system.

BGP hijacking also works on a small scale. If you don't use DNSSEC and somebody hijacks the prefix(es) that host your DNS, they can obtain a letsencrypt certificate and redirect all your traffic.

If you don't have a CAA record and somebody hijacks the prefix(es) where your webserver is hosted, they can also obtain a letsencrypt certificate and redirect your traffic.

As an undergraduate I had to use Modula-2 in the first year programming courses. It was a decent language for teaching programming, but I don't recall anybody who liked it. Those in systems programming quickly switched to C the next year.

It may still be useful for teaching. Low level enough that you can teach memory allocation, etc. Simple enough that you can cover most of the syntax in an introduction course.

The fun part is that the actual uuencode format has the file mode in octal after the word begin. Somebody at microsoft decided this was optional and that begin with two spaces and then the filename should also be the start of a uuencoded section. Of course also without checking if there was any content that was actually encode in that format.

Indeed, I don't. But languages can be compared based on features. Even a language that doesn't exist can be described based on what features it needs to have. I'm not an expert in type systems, but there is a huge amount of research in how type systems can be described, what features you need to make a type system safe, etc.

If we compare C and PL/I then obviously the syntax differences between C and PL/I are mostly based on the taste of the language designer. But there are a lot of features in PL/I that simply have no equivalent in the C language. Either because when C was design they no longer needed to be in the language or because the features are move to the standard library.

In particular I/O is something that lots of language have as part of the language and C doesn't. So it is in many ways obvious why C a lot smaller than PL/I without losing any power.

But now we go in the opposite direction. We know what the safety outcome should be. So we can make a list of things that need to be in a 'C with safety', even if we cannot predict what the exact syntax will look like.

Obviously Rust has some features, like async, that are not needed for 'C with safety'.

But in my experience you need most of the other features. So any 'C with safety' will have a lot of the complexity of Rust. Though of course the syntax and defaults may be different.

At some point it becomes very subjective. Does a language need a UTF-8 string type, or is an array of 8-bit characters enough?

The research question would be, what is a minimal subset of Rust that still allows for programs that are commonly written in C to be easily written in this subset.

Some things, like the tuple type, or 'if let' can be removed, but is it still convenient to write programs without them? Closures are a bit tricky to see if they can be removed.

In any case, C struck a very good balance between being small and powerful. In my opinion Rust strikes a similar balance. Rust is a lot bigger, but it gives powerful tools to write reliable code.

I'm not saying anything about what is possible. What would be the amount of time it takes to create a new language, create a stable compiler, create a sizable community? It can easily be ten years.

There are lot's of organizations that are not going to wait ten years. And we still have to wait for the language to be designed in the first place to suggest that waiting might be an option.

And 10 years from now, the people who have running Rust code are no going to switch to a language that is similar to Rust but may have a slightly better syntax or otherwise be closer to C.

In my opinion, Rust, though large, is in some sense quite minimal. Lot's of features in Rust are actually needed to allow the compiler to statically reason about memory safety.

And this is why Rust is likely going to take over from C, not because it is the most C-like design, but because it can provide static safety guarantees.

There is considerable pressure, at least for internet facing code, to show that it is safe. And that is way to hard to do (and keep doing) for C.

Of course, somebody may come up with a brilliant design. But lots of organizations don't want to wait for that. They don't want to keep writing new code in C. And Rust has by now a mature compiler, a very active community.

Yes, both C and Unix are amazing designs. Far from perfect, but good tools for many jobs. In my opinion, it is now time for Rust to take over. But comparing Rust to C, it took a huge amount of improvement over C to replace C.

If you make software with a small team and you have about 2 dozen customers who pay for a support contract, then those contracts are actually surprisingly cheap.

At some point Firefox was quite effective at competing with Microsoft's browser.

So it happened at least once.

Assuming you are talking about IPSEC, that uses a model that is very hard to deploy.

The problem is that applications typically use TCP connections, but IPSEC works at the IP level. Early on, the (BSD socket) kernel API was basically fixed at the IP level instead of associating it with a TCP socket.

So the whole thing became too complex (also for other reasons). So SSL and SSH were created to have simple things that worked.

SSL took many iterations to get any kind of security, so IPSEC had plenty of time to get it right and take over. But as far as I know, there just never happened. It also doesn't help that TLS is trivial to combine with NAT, and for IPSEC that is quite tricky.

There is no quickly in the Google article. It took them ages to roll out 0x20. Cookies are not very well supported. And then the elephant in the room is the connection between the stub resolver and the public DNS resolvers.

The interesting thing is what happens when BGP is used to redirect traffic to DNS servers: https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bg...

DNS is where the web would have been if browsers basically didn't force websites to support HTTPS.

The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed.

At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important.

If all DNS client software would drop UDP source port randomization and randomized IDs, then lots of people would be very upset. Because DNS security was more important than claimed.

DNS cookies are also an interesting case. They can stop most cache poisoning attacks. But from the google article, big DNS authoritatives do not deploy them.

We should not think in absolutes, but in terms of tools. What risks come with using a certain tool.

In your Rust example, using C is like using a power tool without any safety measures. That doesn't mean that you are going to get hurt, but there is an expectation that a sizable fraction of users of such tools will get hurt.

Rust is then the same tool with safety measures. Of course it is still a power tool, you can get hurt. But the chances of that happening during normal operation is a lot lower.

I think xz is a good example where open source happened to work as intended. Somebody noticed something weird, alerted and other people could quickly identify what other software might have the same problem.

I think there is a fundamental difference between how corporations used to work and how open source typically works.

In a traditional corporation, people would come to an office. It would be known where they live. If you would require something like (code) review, it becomes a lot harder to plant something. Obviously not impossible, but hard for all but the most dedicated attackers.

In contrast, with open source and poorly funded projects. People don't always have money to travel. So the people working on an open source project may only know each other by some online handles. Nerds typically don't like video conferencing. So it is quite possible to keep almost everything about an identity secret.

And that makes it a lot more attractive to just try something. If something goes wrong, the perpetrator is likely in a safe jurisdiction.

I think a problem is that there doesn't seem any way to automatically check this. If we assume that anything that is used during build time can be malicious then figuring out those dependencies is already hard enough. Mapping that to organizational stability is one step further.