These Telecoms are making WAY more money than they deserve.
...because random internet people are allowed to determine how much money others "deserve" to make. As long as they make it honestly, who cares? And when they're not making it honestly, are you saying it's OK as long as they don't profit too much from their dishonesty?
Risk it airlines, where there are no security checks to get on board and the only security measures are to detect when a plane has been hijacked and once confirmed a killswitch is activated to simply blow it out of the sky.
Or have a solid wall between the cockpit and the passenger area, or replace the killswitch with a forced-autopilot-to-the-nearest-airport switch.
My current solution to the problem is looking for a new job in a company that actually takes software development seriously. I just can't see any way of getting things here working the way I want. There wasn't even any revision control in place on the source code when I started.
The problem I'm finding is that the lack of structured development and design here is actually beginning to hurt me professionally: prospective employers, who have software development as a core aspect of their business, actually ask about this kind of thing.
Was the source control something you pushed for? If so, would presenting it as something like "worked to define development standards" help?
Non-free software is able to take people's freedom away when compared with free software. For instance, you can't (necessarily) edit and redistribute non-free software. This is clearly true and if you don't think so, please do explain why.
Less functional software is able to take people's freedom away when compared with more functional software. For instance, you can't use the missing functionality in the less functional software. Now if the less functional software happens to also be Free software, you can make a sacrifice of your time/money to add that functionality, but this just takes away your freedom to do other, more productive, things with your time.
Why is the "user-modifiable and redistributable" feature elevated to the point of it being wrong to not demand that feature over all other features?
And in all these ways, free software is directly comprable to free time, and my point was about the semantics of "free" in "free software".
Huh, it took me three or four times to get this. Not sure if it's unclear/confusing, or if I'm just being slow today.
This is also much the same logic as American libertarians who quote one of their founding fathers who said "someone who would exchange a little freedom to obtain a security deserve neither freedom nor security" or words to that effect. I find it one of the most abhorrent quotes ever uttered in support of a generally good aim, and I definitely disagree with it.
I thought it was "essential liberty" and "temporary safety", which I would paraphrase roughly as "DON'T PANIC (or you'll regret it).". It could also be taken to mean that increased control doesn't actually improve safety, so that exchange doesn't actually work.
Not remotely true. Free software is exactly the same as a "free society". In a free society, you're not free to do whatever you want: for instance, you can't take someone's freedom away from them
Please provide an example of how closed software (as opposed to closed formats/protocols, although even those don't do this very well, see samba, ntfs-3g, various old MS Office readers,...) leaves people less "free" than they would be if the software didn't exist. You can't tweak it to work better... but you still can't do that if it doesn't exist.
If you didn't do metallurgy in college, then you have no idea what you're talking about.
Um... I didn't do metallurgy in college, but I know that lots of other things get soft before they melt (butter, glass, "processed cheese food", plastic, solder,...) and I know what a blacksmith does (hint: heat up metal to make it softer, then hit it with a hammer).
This is an interesting idea, but it then requires people to get certs from all (or most) CA's.
CAs are part of the problem since the phisher can always choose which ones to use, so the solution should be something that doesn't rely on the site in question making the choice of who verifies there identity. The purpose of a CA is to say "this (online) identity is tied to that (meatspace) identity" (which few people actually look at, so it's effectively "...is tied to some (meatspace) identity")... if you can instead say "this online identity hasn't changed in X months, and doesn't change depending on your subnet", that (1) doesn't require the site owner to even know about whoever's doing the checking, and (2) is probably more useful for people who don't read the certificate details (ie, nearly everyone).
Further, the TLS 1.0 and later standards mandate that an unknown CA produces an alert that is always fatal, never a warning.
That doesn't automatically make it the right choice... having a CA isn't necessarily the only way to verify things.
The chain-of-trust mechanism with root CA's at the top is a mechanism that can provide real security; the behavior of particular actual root CA's may not be trustworthy, but then most user agents let you add and remove root CA certificates, and trust who you want to trust.
If a popular browser trusts one evil/incompetent CA, a lot of people are hosed. mybank.com is certified by trusted CA Idiotco so it must be ok, and nevermind that other people who haven't had their DNS poisoned see that it's signed by some more reputable source. The security of the system depends on the trustworthiness of all CAs. A better system would only rely on the trustworthiness of most of the trusted parties, if 9/10 verification servers say that that site isn't using the cert you see it using, you know to ignore (and maybe report for auditing) the 1 that says you're safe.
Hmm... don't have the site operator choose one trusted party to sign their cert, have the browser people choose several trusted parties on different network routes to ask if they all see the same cert and if the cert has changed. Then we can go back to having the purpose of CAs be to verify the meatspace <-> cyberspace connection, like they were always supposed to do.
* Hint: If they are really scared of the self-signed certificates, why do they have the "Permanently store this exception" box checked by default?
That's the one part that makes some amount of sense. It lets the browser really complain if the cert changes (of course, who's going to notice the difference, since it complains so loudly about unsigned certs in the first place...), which should only happen if someone's trying to MitM your connection or if the admin is an idiot and deleted the cert file.
The certificate authority check is there to prevent Dr. Evil from setting up a server in between you and your bank. In that scenario, you would connect to Dr Evil, get his key, encrypt your username and password using his key. Dr Evil then decodes the user/password and sends it onto the bank in another connection. Then he bridges the two connections, walks off with your password and you're none the wiser.
Or you could ask someone else or several someones (on network routes that Dr. Evil doesn't have access to) to connect to your bank and tell you what certificate they see it using and make sure they agree with what you see, which also handles the case when your browser trusts a CA that doesn't do their homework properly.
Sorry folks, given the way SSL certs work, there's something going on when someone has a self-signed cert.
Such as thinking that CAs can't be trusted to do their jobs right, and are no better (or perhaps even worse) than just checking if the cert hasn't changed in a month (perhaps by checking with several other servers not all run by the same people)?
Isn't scaring away inexperienced users from sites with questionable security the whole point of those warnings?
I mean a user friendly message that lets someone get past it really easily wouldn't exactly get the job done.
Plain http is even more questionable, and somehow it doesn't complain about that. Also, some people tend to think that CAs are more security theater than real security, and there are better ways to do things.
But if you're going to complain about C++ compared to recent languages here, make sure that you're talking about recent C++ too, and try to make sure the complaints are accurate.
Poor encapsulation. Things like this: class Foo_impl; class Foo { Foo_impl * _impl; }; should not be needed or useful.
The same thing that makes templates fast and flexible, also means that you can't dynamically link them.
No standard way to print a stack trace on crash/exception.
Can't link an executable generated with one compiler with an.so generated by another compiler.
No typesafe version of dlopen().
On the other hand templates and RAII are made of pure awesome, and all the newer languages seem to want to break my RAII and castrate my templates.
Ah, I thought I'd seen someone say they went ahead and did that anyway... do you know if CDDL has similar linking rules, or something else that would block the module approach from the ZFS side?
This story from last December had the exact same article. This was noted in the firehose entry, and somehow this still got posted. I thought that kind of thing was a major purpose of the firehose?
If (closed source) NVidia can link into the kernel without issue, I'd like to hear the logic behind why (OSI-approved) ZFS cannot.
NVidia doesn't mind when you link their code to the kernel. ZFS is GPL3, which says you can only link to GPL3 or things that can be treated as GPL3.
Also, why cannot a shim layer (like NVidia?) be used if there are actual conflicts?
There's no need, ZFS is open source so the end user can just compile the entire thing. The final linking just has to be done by the end user, since the result can't be distributed.
An unencrypted site is less dangerous than a self-signed one because the former isn't advertising that it's safe; the latter is. It's presenting the appearance of security,
That is entirely up to the browser, and how it handles the lock icon and colored address bar and whatever else it does.
with the reality of none.
Wooden doors provide no more security than open doorways, because anyone with a saw can cut through them. So we should ban wooden doors, and only allow people to use solid steel doors like a bank vault has.
I'm not sure if the *entire* web needs to use HTTPS. Secure connections are good when [...]
If you are simply reading a website, however, encrypting the entire transfer seems unnecessary. If you just open a browser to be able to read the front page of Slashdot, or another news site, or your favourite blog, does encrypting the data give you any benefit? I would argue no - if you only need read-only access to public information, http works fine because there's nothing that needs protecting.
The main benefit is that systematic meddling becomes much harder. I might not care what you post, but someone practicing a modern variant of McCarthyism probably would.
Yet authority-signed vs self-signed IS relevant when discussing self-signed HTTPS and unencrypted HTTP. Yes, I'll admit that self-signed HTTPS in more secure than HTTP. But that doesn't mean we should stop there and refuse to consider the alternatives. The alternative being authority-signed HTTPS, and it has the advantage of offfering more protection against MITM.
So why are browsers telling people to not consider alternatives, and only use unencrypted or CA-signed connections?
If you need a website that is invulnerable to MITM, use HTTPS with an authority-signed certificate.
What, you think the certificate authorities can't be conned into giving out invalid certificates?
If you don't need protection against MITM, use HTTP.
You're refusing to consider alternatives. What if you want to prevent snooping, but either don't care about MITM (much more involved) or don't trust the CAs? Why are you excluding the middle options?
Slashdot Mirror
These Telecoms are making WAY more money than they deserve.
...because random internet people are allowed to determine how much money others "deserve" to make. As long as they make it honestly, who cares? And when they're not making it honestly, are you saying it's OK as long as they don't profit too much from their dishonesty?
Risk it airlines, where there are no security checks to get on board and the only security measures are to detect when a plane has been hijacked and once confirmed a killswitch is activated to simply blow it out of the sky.
Or have a solid wall between the cockpit and the passenger area, or replace the killswitch with a forced-autopilot-to-the-nearest-airport switch.
My current solution to the problem is looking for a new job in a company that actually takes software development seriously. I just can't see any way of getting things here working the way I want. There wasn't even any revision control in place on the source code when I started.
The problem I'm finding is that the lack of structured development and design here is actually beginning to hurt me professionally: prospective employers, who have software development as a core aspect of their business, actually ask about this kind of thing.
Was the source control something you pushed for? If so, would presenting it as something like "worked to define development standards" help?
Non-free software is able to take people's freedom away when compared with free software. For instance, you can't (necessarily) edit and redistribute non-free software. This is clearly true and if you don't think so, please do explain why.
Less functional software is able to take people's freedom away when compared with more functional software. For instance, you can't use the missing functionality in the less functional software. Now if the less functional software happens to also be Free software, you can make a sacrifice of your time/money to add that functionality, but this just takes away your freedom to do other, more productive, things with your time.
Why is the "user-modifiable and redistributable" feature elevated to the point of it being wrong to not demand that feature over all other features?
And in all these ways, free software is directly comprable to free time, and my point was about the semantics of "free" in "free software".
Huh, it took me three or four times to get this. Not sure if it's unclear/confusing, or if I'm just being slow today.
This is also much the same logic as American libertarians who quote one of their founding fathers who said "someone who would exchange a little freedom to obtain a security deserve neither freedom nor security" or words to that effect. I find it one of the most abhorrent quotes ever uttered in support of a generally good aim, and I definitely disagree with it.
I thought it was "essential liberty" and "temporary safety", which I would paraphrase roughly as "DON'T PANIC (or you'll regret it).". It could also be taken to mean that increased control doesn't actually improve safety, so that exchange doesn't actually work.
OK, let me rephrase that...
You are implying that "non-Free" software is able to take people's freedom away from them. Please provide an example of this.
Not remotely true. Free software is exactly the same as a "free society". In a free society, you're not free to do whatever you want: for instance, you can't take someone's freedom away from them
Please provide an example of how closed software (as opposed to closed formats/protocols, although even those don't do this very well, see samba, ntfs-3g, various old MS Office readers, ...) leaves people less "free" than they would be if the software didn't exist. You can't tweak it to work better... but you still can't do that if it doesn't exist.
If you didn't do metallurgy in college, then you have no idea what you're talking about.
Um... I didn't do metallurgy in college, but I know that lots of other things get soft before they melt (butter, glass, "processed cheese food", plastic, solder, ...) and I know what a blacksmith does (hint: heat up metal to make it softer, then hit it with a hammer).
This is an interesting idea, but it then requires people to get certs from all (or most) CA's.
CAs are part of the problem since the phisher can always choose which ones to use, so the solution should be something that doesn't rely on the site in question making the choice of who verifies there identity. The purpose of a CA is to say "this (online) identity is tied to that (meatspace) identity" (which few people actually look at, so it's effectively "...is tied to some (meatspace) identity")... if you can instead say "this online identity hasn't changed in X months, and doesn't change depending on your subnet", that (1) doesn't require the site owner to even know about whoever's doing the checking, and (2) is probably more useful for people who don't read the certificate details (ie, nearly everyone).
Further, the TLS 1.0 and later standards mandate that an unknown CA produces an alert that is always fatal, never a warning.
That doesn't automatically make it the right choice... having a CA isn't necessarily the only way to verify things.
The chain-of-trust mechanism with root CA's at the top is a mechanism that can provide real security; the behavior of particular actual root CA's may not be trustworthy, but then most user agents let you add and remove root CA certificates, and trust who you want to trust.
If a popular browser trusts one evil/incompetent CA, a lot of people are hosed. mybank.com is certified by trusted CA Idiotco so it must be ok, and nevermind that other people who haven't had their DNS poisoned see that it's signed by some more reputable source. The security of the system depends on the trustworthiness of all CAs. A better system would only rely on the trustworthiness of most of the trusted parties, if 9/10 verification servers say that that site isn't using the cert you see it using, you know to ignore (and maybe report for auditing) the 1 that says you're safe.
Hmm... don't have the site operator choose one trusted party to sign their cert, have the browser people choose several trusted parties on different network routes to ask if they all see the same cert and if the cert has changed. Then we can go back to having the purpose of CAs be to verify the meatspace <-> cyberspace connection, like they were always supposed to do.
How well does that work if you can trick someone into loading the wrong package onto that USB key?
* Hint: If they are really scared of the self-signed certificates, why do they have the "Permanently store this exception" box checked by default?
That's the one part that makes some amount of sense. It lets the browser really complain if the cert changes (of course, who's going to notice the difference, since it complains so loudly about unsigned certs in the first place...), which should only happen if someone's trying to MitM your connection or if the admin is an idiot and deleted the cert file.
The certificate authority check is there to prevent Dr. Evil from setting up a server in between you and your bank. In that scenario, you would connect to Dr Evil, get his key, encrypt your username and password using his key. Dr Evil then decodes the user/password and sends it onto the bank in another connection. Then he bridges the two connections, walks off with your password and you're none the wiser.
Or you could ask someone else or several someones (on network routes that Dr. Evil doesn't have access to) to connect to your bank and tell you what certificate they see it using and make sure they agree with what you see, which also handles the case when your browser trusts a CA that doesn't do their homework properly.
Sorry folks, given the way SSL certs work, there's something going on when someone has a self-signed cert.
Such as thinking that CAs can't be trusted to do their jobs right, and are no better (or perhaps even worse) than just checking if the cert hasn't changed in a month (perhaps by checking with several other servers not all run by the same people)?
Someone did: http://www.cs.cmu.edu/~perspectives/.
Isn't scaring away inexperienced users from sites with questionable security the whole point of those warnings?
I mean a user friendly message that lets someone get past it really easily wouldn't exactly get the job done.
Plain http is even more questionable, and somehow it doesn't complain about that. Also, some people tend to think that CAs are more security theater than real security, and there are better ways to do things.
But if you're going to complain about C++ compared to recent languages here, make sure that you're talking about recent C++ too, and try to make sure the complaints are accurate.
On the other hand templates and RAII are made of pure awesome, and all the newer languages seem to want to break my RAII and castrate my templates.
Ah, I thought I'd seen someone say they went ahead and did that anyway... do you know if CDDL has similar linking rules, or something else that would block the module approach from the ZFS side?
Seriously, are the editors asleep?
This story from last December had the exact same article. This was noted in the firehose entry, and somehow this still got posted. I thought that kind of thing was a major purpose of the firehose?
WTF
If (closed source) NVidia can link into the kernel without issue, I'd like to hear the logic behind why (OSI-approved) ZFS cannot.
NVidia doesn't mind when you link their code to the kernel. ZFS is GPL3, which says you can only link to GPL3 or things that can be treated as GPL3.
Also, why cannot a shim layer (like NVidia?) be used if there are actual conflicts?
There's no need, ZFS is open source so the end user can just compile the entire thing. The final linking just has to be done by the end user, since the result can't be distributed.
The encryption provided by self-signed SSL is worthless: if someone could read the unencrypted traffic, they could MitM your SSL connection.
Only if they care enough to target you specifically. What about people sniffing everything that goes over a particular network link?
An unencrypted site is less dangerous than a self-signed one because the former isn't advertising that it's safe; the latter is. It's presenting the appearance of security,
That is entirely up to the browser, and how it handles the lock icon and colored address bar and whatever else it does.
with the reality of none.
Wooden doors provide no more security than open doorways, because anyone with a saw can cut through them. So we should ban wooden doors, and only allow people to use solid steel doors like a bank vault has.
I'm not sure if the *entire* web needs to use HTTPS. Secure connections are good when [...]
If you are simply reading a website, however, encrypting the entire transfer seems unnecessary. If you just open a browser to be able to read the front page of Slashdot, or another news site, or your favourite blog, does encrypting the data give you any benefit? I would argue no - if you only need read-only access to public information, http works fine because there's nothing that needs protecting.
The main benefit is that systematic meddling becomes much harder. I might not care what you post, but someone practicing a modern variant of McCarthyism probably would.
Yet authority-signed vs self-signed IS relevant when discussing self-signed HTTPS and unencrypted HTTP. Yes, I'll admit that self-signed HTTPS in more secure than HTTP. But that doesn't mean we should stop there and refuse to consider the alternatives. The alternative being authority-signed HTTPS, and it has the advantage of offfering more protection against MITM.
So why are browsers telling people to not consider alternatives, and only use unencrypted or CA-signed connections?
If you need a website that is invulnerable to MITM, use HTTPS with an authority-signed certificate.
What, you think the certificate authorities can't be conned into giving out invalid certificates?
If you don't need protection against MITM, use HTTP.
You're refusing to consider alternatives. What if you want to prevent snooping, but either don't care about MITM (much more involved) or don't trust the CAs? Why are you excluding the middle options?
Hey, cool, I got a new .sig .