It is the API, at least for me and for many of the extensions I use that were written by other people. WebExtensions don't give the access necessary to write the type of extensions I write, so... I can't write them.
It's not an issue of critical mass. I'd port them if it was possible (if only so I could upgrade off of this ancient version of Firefox), but it's not.
Assuming we're talking DV certs here, then you're already trusting the domain name registry -- and without DNSSEC you have no way to even detect an MITM on it. Adding DNSSEC and then skipping CAs to get the identity info straight from the source would be a massive improvement.
EV certs are a different beast, of course. With those, the CAs are providing a useful identity verification service that verifies your identity separately from DNS.
Time, yes. But the problem isn't time. The problem is that it's outright impossible to do lots of things with WebExtensions, because they just plain don't get the access to Firefox that they need (and if you try to work with Mozilla to get that access, they refuse to work with you, and instead accuse you of refusing to work with them).
No amount of time will help when the sandbox you're required to use just plain doesn't support what you need it to do.
This is going to get really bad if/when we get the tech to meaningfully read minds.
"You have the right to remain silent, but there's no point because we'll just read what you're thinking straight out of your brain, which is a physical object that we can look at as much as we want."
I'd hope that's obviously crazy, but as you say... US legal system.
Acceptance of electric cars was initially hampered by a lack of power infrastructure, but by 1912, many homes were wired for electricity, enabling a surge in the popularity of the cars. At the turn of the century, 40 percent of American automobiles were powered by steam, 38 percent by electricity, and 22 percent by gasoline.
For what it's worth, if you have a Thingiverse account you can turn infinite scrolling off in the preferences. Unfortunately they only show 12 entries per page so it takes forever to go through them all, but at least there's no infinite scroll involved.
You could just as easily argue that the fact that Linux works fine on other Ryzen processors, AMD's older processors and Intel's processors, and only segfaults on these specific Ryzen models, tells you that it's these processors that are broken, not Linux.
Of course -- and I shouldn't really have to explain this on Slashdot of all places, but neither of these observations actually tell you where the problem is. Doing that involves doing some investigation, and the fact that AMD appear to be accepting blame suggests that they've done the investigation and believe it's their fault.
So basically... you can write memory-safe software in C++, but it's much harder, some developers can't do it and the failure mode is that we get security vulnerabilities? This is not a very good argument for using C++ for software that needs to be secure.
That's nice, but it's also clearly possible to write non-memory-safe code in C++, because people keep doing it and it keeps ending up in released software. In Rust it's not. That's an improvement.
To be specific, since I also saw the/. thread from a few days ago and I know some people need a little help understanding this: Rust is a solution to some classes of IoT security problems. It's not a solution to all classes of IoT security problems.
Apparently this particular issue is a stack buffer overflow that leads to remote code execution, which seems like exactly the sort of bug that wouldn't have been possible if the library had been written in Rust. So, it would've helped quite a lot here.
I'm not suggesting you use both, I'm pointing out that indentation and alignment are two separate things, and using tabs for indenting doesn't mean to use them for alignment too.
I see you do feel the need to insult the programmers.
You might have missed the bit where C makes it unnecessarily complicated to understand what you're doing. If we can reduce that complication, we'd have more programmers capable of understanding what they're doing. Surely you don't think that's a bad thing?
I'm not convinced that removing unnecessary complexity will lead to more problems in the other parts of the program. If anything, it should lead to fewer problems because the developer has more attention available to find and fix those other problems. (Or, in an imaginary world where all programs are written by perfect programmers with no time limits, it would lead to programs taking less time to write, which would mean we could write more software for the same cost.)
Or maybe you haven't understood the first thing about Rust. It doesn't turn bad coders into good coders, it doesn't magically give insight to programmers without it... all it does is check the code you write for memory safety issues, and reject it if it's unsafe.
Many, many security vulnerabilities in C code are memory safety issues. Whether you feel the need to insult the coders of that code or not, the fact remains that in the real world we suffer from a great many security vulnerabilities that could've been automatically detected and rejected by the Rust compiler. If we insist on continuing to use C then we will continue to suffer from this class of security bugs.
You still need a security brain with Rust. The difference that Rust makes is that the compiler will make sure your code is free of memory safety issues, which means you can spend your security brain's limited bandwidth on other issues -- issues that can't be handled automatically for you by your computer. (Why would you ever want to waste time manually checking things that can be done automatically?)
I have no idea where this idea of "it's impossible to write insecure code in Rust" came from. It doesn't even claim to be able to do that.
The "solution" to having an unwanted government-maintained monopoly is for the government to stop maintaining the monopoly, isn't it? What other problem do you want a solution for?
You're completely correct. But in some industries, when there's no government involvement at all you are likely to end up with monopolies due to the economics of the industry in question. That's the other problem that we need a solution for (and that solution is for the government to step in and prevent that monopoly from happening).
I don't think we're talking about the same thing. The fundamental economics of doing last mile connectivity for internet access have nothing to do with whatever the US did or didn't do to Ma Bell. They're driven by the physics involved in digging cables and in transmitting data over those cables.
If the government doesn't prohibit it and it is profitable to do so, which in the case of last-mile, it isn't. It's a lot more profitable to refuse to share with other ISPs so that you don't have to compete with them.
We don't use enough soap to need dedicated soap selling stores next to every house, and the cost to produce and transport soap is relatively high compared to the cost of producing and transporting a packet. In other words, capital costs don't dominate the soap industry, making it different from last-mile internet access in a way that is very key to whether it's a natural monopoly or not.
Slashdot Mirror
That's reader mode, which is indeed great. I was asking more about the use of an apostrophe to mean "watch out folks, there's an 's' coming up!".
show's
Argh. Why.
It is the API, at least for me and for many of the extensions I use that were written by other people. WebExtensions don't give the access necessary to write the type of extensions I write, so... I can't write them.
It's not an issue of critical mass. I'd port them if it was possible (if only so I could upgrade off of this ancient version of Firefox), but it's not.
Assuming we're talking DV certs here, then you're already trusting the domain name registry -- and without DNSSEC you have no way to even detect an MITM on it. Adding DNSSEC and then skipping CAs to get the identity info straight from the source would be a massive improvement.
EV certs are a different beast, of course. With those, the CAs are providing a useful identity verification service that verifies your identity separately from DNS.
It's not. It's faster because of a months-long engineering effort to improve performance.
Proof: Fx57 still has the existing architecture, and ships with multiple extensions that use it. It's just us rubes that aren't allowed to.
Time, yes. But the problem isn't time. The problem is that it's outright impossible to do lots of things with WebExtensions, because they just plain don't get the access to Firefox that they need (and if you try to work with Mozilla to get that access, they refuse to work with you, and instead accuse you of refusing to work with them).
No amount of time will help when the sandbox you're required to use just plain doesn't support what you need it to do.
This is going to get really bad if/when we get the tech to meaningfully read minds.
"You have the right to remain silent, but there's no point because we'll just read what you're thinking straight out of your brain, which is a physical object that we can look at as much as we want."
I'd hope that's obviously crazy, but as you say... US legal system.
Neither does Firefox these days.
Well, not so fast. Wikipedia tells me:
Sounds like they were pretty attainable to me.
For what it's worth, if you have a Thingiverse account you can turn infinite scrolling off in the preferences. Unfortunately they only show 12 entries per page so it takes forever to go through them all, but at least there's no infinite scroll involved.
Why is this a reason not to do it? The entropy argument in the comic is already done with the assumption of full knowledge of the pattern.
You could just as easily argue that the fact that Linux works fine on other Ryzen processors, AMD's older processors and Intel's processors, and only segfaults on these specific Ryzen models, tells you that it's these processors that are broken, not Linux.
Of course -- and I shouldn't really have to explain this on Slashdot of all places, but neither of these observations actually tell you where the problem is. Doing that involves doing some investigation, and the fact that AMD appear to be accepting blame suggests that they've done the investigation and believe it's their fault.
So basically... you can write memory-safe software in C++, but it's much harder, some developers can't do it and the failure mode is that we get security vulnerabilities? This is not a very good argument for using C++ for software that needs to be secure.
That's nice, but it's also clearly possible to write non-memory-safe code in C++, because people keep doing it and it keeps ending up in released software. In Rust it's not. That's an improvement.
To be specific, since I also saw the /. thread from a few days ago and I know some people need a little help understanding this: Rust is a solution to some classes of IoT security problems. It's not a solution to all classes of IoT security problems.
Apparently this particular issue is a stack buffer overflow that leads to remote code execution, which seems like exactly the sort of bug that wouldn't have been possible if the library had been written in Rust. So, it would've helped quite a lot here.
There are plenty of ways to write memory-unsafe code in C++, so no, it's not no improvement.
I'm not suggesting you use both, I'm pointing out that indentation and alignment are two separate things, and using tabs for indenting doesn't mean to use them for alignment too.
I see you do feel the need to insult the programmers.
You might have missed the bit where C makes it unnecessarily complicated to understand what you're doing. If we can reduce that complication, we'd have more programmers capable of understanding what they're doing. Surely you don't think that's a bad thing?
I'm not convinced that removing unnecessary complexity will lead to more problems in the other parts of the program. If anything, it should lead to fewer problems because the developer has more attention available to find and fix those other problems. (Or, in an imaginary world where all programs are written by perfect programmers with no time limits, it would lead to programs taking less time to write, which would mean we could write more software for the same cost.)
Or maybe you haven't understood the first thing about Rust. It doesn't turn bad coders into good coders, it doesn't magically give insight to programmers without it... all it does is check the code you write for memory safety issues, and reject it if it's unsafe.
Many, many security vulnerabilities in C code are memory safety issues. Whether you feel the need to insult the coders of that code or not, the fact remains that in the real world we suffer from a great many security vulnerabilities that could've been automatically detected and rejected by the Rust compiler. If we insist on continuing to use C then we will continue to suffer from this class of security bugs.
You still need a security brain with Rust. The difference that Rust makes is that the compiler will make sure your code is free of memory safety issues, which means you can spend your security brain's limited bandwidth on other issues -- issues that can't be handled automatically for you by your computer. (Why would you ever want to waste time manually checking things that can be done automatically?)
I have no idea where this idea of "it's impossible to write insecure code in Rust" came from. It doesn't even claim to be able to do that.
Not if you align it correctly it isn't.
You indent with tabs and align with spaces. If your alignment messes up when you change the tab width, you screwed up your aligning.
Lucky for me that this particular industry is a natural monopoly then, isn't it?
I don't think there's much bullshit involved in arguing that natural monopolies will naturally lead to monopolies.
The "solution" to having an unwanted government-maintained monopoly is for the government to stop maintaining the monopoly, isn't it? What other problem do you want a solution for?
You're completely correct. But in some industries, when there's no government involvement at all you are likely to end up with monopolies due to the economics of the industry in question. That's the other problem that we need a solution for (and that solution is for the government to step in and prevent that monopoly from happening).
I don't think we're talking about the same thing. The fundamental economics of doing last mile connectivity for internet access have nothing to do with whatever the US did or didn't do to Ma Bell. They're driven by the physics involved in digging cables and in transmitting data over those cables.
If the government doesn't prohibit it and it is profitable to do so, which in the case of last-mile, it isn't. It's a lot more profitable to refuse to share with other ISPs so that you don't have to compete with them.
We don't use enough soap to need dedicated soap selling stores next to every house, and the cost to produce and transport soap is relatively high compared to the cost of producing and transporting a packet. In other words, capital costs don't dominate the soap industry, making it different from last-mile internet access in a way that is very key to whether it's a natural monopoly or not.