However, you are talking about bare metal programming which is a completely different matter. I completely agree with you on this, but these are things that are normally abstracted by the OS.
If you want to talk in this point of view, for me the problem is purely availability. If I was to develop bare metal, again I would select the raspi because once I learn how to program it and get my applications stable on it, I can be fairly certain that I can get it easily in large quantities and probably for a long time.
However I would like to hear more about why did go with arch programming (as in armv7) and not platform programming (as in raspi/bbb/whatever) and also, why not an OS on it in order to delegate the burden of arch specific stuff to the os devs?
Don't lie Maevius, LIMA is getting better and better and is Opensource. So no, not all modern GPU's need binary blobs.
Ha. Nice one. Indeed I try to deceive the readers of slashdot by lying in order to get them to agree with me.
I don't consider reverse engineered drivers as proper drivers because they usually they lack support and are some generations behind. Also that doesn't change the fact that GPUs come with blobs. Having said that, I have never used the lima ones. Seeing the x86 landscape though, I believe that the move of valve with steambox, the cooperation of canonical and redhat with nvidia and amd and Torvalds cursing everyone progressed linux graphics much more than some noble but nevertheless half-assed (not because the developers are incompetent, but because it is near impossible) reverse engineering.
And honestly, I would prefer all these developers to work in progressing projects like wayland which will get linux desktop out of the stone age, and some killer apps like XBMC, and the graphics companies will line up to give proper support
How can you be sure that you "solved" bugs in the closed part of the hardware? Oh, you can't.
It works doesn't it? I'm not planning on making a bitcoin miner with raspi so I don't care if there is an implementation bug that has a 10% performance hit and anyone who buys the raspi (or any embedded arm device) to work on GPU hacking is a bit wacky. What I care about is that power issues are fixed, all the devices are initialized correctly (I had an embedded linux device not properly initing the usb because a capacitor was not big enough so you had to manually change an smd cap), the GPIOs work as they should, I have an API of the GPIO in almost every normal language, I already have drivers (and tutorials) on how to drive LCD screens, loads of digital chips, I have plug n play ADC boards specifically designed for the pi.
I have a realtime operating system if I wish to do real time processing.
All modern GPU have binary blobs. As I said, a not-so-beefy, but open GPU would be my preference. This way, you can personally experiment with all kinds of creative ways of using, misusing and abusing the computing power in the GPU.
Wishful thinking. Although I personally don't care about GPU hacking, I'd love to see GPU hackers have access to the real hardware. That doesn't change the fact that there is no open GPU.
I've personally made the step from an ARMv4TDMI to an ARMv7 core and it was amazing how practically relevant the improvements were. It's not just a few new instructions here and there, but changes that made my work easier.
Although it's common sense that v4->v7 is a huge change, care to post some examples?
I'll grant you the media center thing, although I still use a proper x86 for media center in order not to be limited on anything.
However... The chinese thingies you talk about. What distributions can they run? Can they run java? Is there any documentation about the GPIO? Is there any GPIO? Can you overclock/undeclock them? Do you have any community documented hardware hacks you can follow? Is there a hardware compatibility list you can check before buying peripherals? Can you find packages (as in.deb) specifically targeted towards them in the wild?
You see, although I agree with you that if you want a "fire and forget" type of device, sure there are much better alternatives. But when you want a platform to hack, you want to have some things granted. I don't want to compile packages from scratch only to find out they don't work for some obscure reason. I need to know all the hardware bugs and errata before starting a project and finding that I cannot finish it halfway. The RPi is a stable and mature platform thanks to its community. And no matter how much people shout about it, this is the way it is and anyone who is serious about hacking and realises all the time consuming hurdles will agree with me.
The rest of the "moral" or "philosophical" issues are just noise from people who prefer to shout than hack (not implying that you are one of them, just saying)
Stallmann's predictions have been realized again and again.
Stallman is predicting that the world will end and is making a living off of it. And even broken clocks are correct 2 times a day.
The enormous blob in the processor and the USB driver is indeed a real problem for the RPI. We don't know what they have stuck into the blobs for their friends from N.S.A.
Aaah, the conspiracy theorist.... Sure, no problem. But can you actually back your claim up with actual facts or at least a plausible theory? I mean even if it the blob keeps data in the silicon itself about how many times I masturbated, how does it send it to NSA undetected? Ethernet/wifi seems a little hard to go undetected. Maybe the processor itself acts as an antenna and sends data?
The same way you are not paying for your TV, car, furniture, washing machine? I am pretty sure that you don't drink coca-cola because they don't release the recipe.
I don't mind open source purists, but the only purist is Stallman (and he is a fucking psycho). All the rest - you included of course - are lame hypocrites.
I undestand the aversion from locked platforms with the sole purpose of vendor lock-in or for example making money for stuff I could fix myself - see apple, oracle, microsoft products. But the development of the videocore never had that intent and this makes you an absolutist hypocrite.
It is not about the power! You have a cheap ass device that has a massive community that have solved almost all the bugs in the thing so any problem you have is a google search away. The foundation pays for ports of software to it. When you buy a new peripheral you can find quickly if it works with the pi and how to make it work. You can find lots of different enclosures and almost any other wacky thing you can think about.
Also...All modern GPU have binary blobs. On pcs, on phones, on tablets, on embedded. Get over it.
I think you are missing some points here. 1. The pi runs linux. You can use c/c++, python, perl, bash scripts, almost anything else you want (1a). You have hundreds of libraries to go with that. Also thousands of programs to pipe info. 2. You can connect a 3g, wifi stick or anything USB instantly 3. You lose absolutely no time on hardware design. It might just be me but I like have my hardware done and just worry about software 4. The community will point out almost all the hardware/software limitations or bugs of the pi and you know in advance what you are getting yourself into 5. You have portable code. If you program for linux, it runs on most hardware that runs linux (some recompilation required) 6. The community has started building addons (see arduino shields) which can achieve much more
As a software developer who used embedded linux and arduino class hardware, I love the pi because it solves all the problems I don't want to worry about. I also love that I don't have to test it on different hardware/software configurations. My target will always be raspberry/debian. I undestand that this is not what some people want/like but for "rapid" embedded development the pi is number one and because of its community I think it will be for a long time to come.
In passwords you can one way encrypt them (meaning, no key is kept) because you know that a person will remember and enter the password everytime.
The reason companies keep credit card data is so they can charge recurring fees automatically or the well known one click buy, so a computer must be able decrypt and use accordingly. If you don't keep the key, you defeat the purpose of the whole scheme. The only way to protect the data (without being truly secure) is to use a hardware security module along with high physical security (something along PCI-DSS standards)
To sum it up: There is NO true security. If you can't protect cardholder data, don't keep it
btw, somewhere in their website I read that the cards were encrypted but it suggested that the key was trivial to find.
It is possible to span a filesystem on multiple drives (see various LVMs, RAID etc) but is offtopic to the problem at hand (you cannot have 1 filesystem on your hard drive and your USB stick).
Given that hardlinks exist on the filesystem level, anything that is on a lower layer and transparent to this level (consider a driver for example that can handle hard disks, network paths, RAM etc. as 1 block device) can be on 1 filesystem and have hardlinks span across. But this purely theoretical, and a bit offtopic.
Mounting a drive to a folder has nothing to do with hardlinks (or inodes). This is on a much higher level. In order to span hardlinks on different drives, you should have 1 filesystem on 2 drives, which is not possible.
Apache doesn't serve https by default either, I think this has to do more with the configuration of the keys than the life of the *s protocols. Dying or not, it's secure, isn't it?
Although I agree with most of your post, mail servers have TLS support and if the client uses pop3s/imaps then the message is encrypted end to end. Although I don't have any real statistics from the corporate mail server from where I work, the admin is pretty confident that most mail is encrypted.
The main problem with OpenPGP on mail for me is that due to the unique key per recipient, if you add more than one recipient or cc, you have to encrypt the mail for each and every one of them. If you add some attachments it's pretty sure that you will hit the maximum allowed mail size of some mail server along the way.
Also, don't forget that at least I can easily setup thunderbird/enigmail. I don't even want to know the admin's response if he is ever asked to install/support a company wide openpgp installation
Although I would like this to work, I'm familiar with PCI-DSS and I'm pretty sure that it's your fault for keeping this data on a cell phone which is not PCI-DSS compliant and not the carrier's/CarrierIQ's
If you concentrate on the UI then you might have a point. However don't forget that firefox (and the other browsers) is average user oriented so phishing/spoofing etc are serious threats and the warning has the purpose to discourage the average user as much as possible. Considering that from an expert's point of view, unverified encryption doesn't make any sense, IMO nothing is lost by this warning anyway. I doubt that any malicious user could get a legitimate certificate to use for mitm, mainly because CAs that issue certificates do some background check. (Some social engineering might do the trick but that's a different subject) Don't get me wrong this warning was annoying me too at first, but then I just got into the habit of having my self signed certs on a flash drive and installing them on PCs that I use to connect to my secure sites. That is true for SSH as well.
Back in the days when this warning didn't exist I was in the habit of doing mitm on co-workers computers (who are IT professionals) as a prank. They just accepted the different certificate because of the habit of pressing OK to all the dialog boxes. From the day this big warning started appearing, they knew it was me in no time
Ok. Sorry If I upset you. After all the fucking, I finally understand that you are correct. No seriously. It's all about the UI. I will have a fingerprint and you will have a fingerprint and all of us will have fingerprints. And I will collect your fingerprint from the mail, oops not mail, as it is insecure. But wait you can put another fingerprint in your mail which will be near your email address. and all of that will go to your business card. Yes, a side effect will be that your business card will be like a billboard, but who cares? Come on fuck science, let's stick it the man!
On a more serious tone, I give up, I'm going out for beers. You can try it too, it might chill you out
Agreed. But self signed certificates are not the answer. A non-profit CA could be the answer, although it has its drawbacks because if there isn't at least some paperwork in order to issue a certificate then people will just certify their mitm keys. I think the only way for HTTPS to be widely used securely is a internet-wide PKI scheme the same way dnssec is starting to be deployed, but these are just wishful thoughts.
Don't get me wrong, I want to see HTTPS widely deployed as much as you but only if it's deployed correctly. And all this is just details because right now, not even the sites that have the budget to buy a certificate use HTTPS, I cannot expect from someone who doesn't to use it
Dude, first of all chill. You are gonna have a heart attack by the time you are 40.
treat the HTTPS that is using self signed certificate SAME as HTTP and encrypt the traffic.
That is not an argument, that is a statement. An argument is that they cannot be treated the same because they are not the same. And actually, there is absolutely no reason for the latter to exist as I mentioned in most of my replies above. SSH for example displays a message the same way, but it's oriented towards at least power users and not average people, it's implied that it is dangerous
Interestingly enough, you still don't have any Computer Science arguments, but you still rely heavily on insulting. As I mentioned before HTTPS without PKI is useless because it's security through obscurity. You think that by encrypting, you are safe, but sooner or later everybody will undestand how this thing works and ettercap will be a common program, which needs about 2 or 3 clicks to do a successful SSL mitm. If that happens, then HTTPS will be as useful as WEP, it will be only useful against passive sniffing, but guess what? If you do man in the middle you can go past that.
So in conclusion you still don't have any serious argument. Can you please try again?
Your comment, except from the purpose of insulting (which is irrelevant) has no meaning. Please try to answer again after reading about public keys, PKI, CAs. After that please try to read my comment again. After you comprehended the previous, please try to explain wtf is the relation of http which is insecure by design and https which is supposed to be secure, only if it is implemented correctly.
As I stated on another reply above, self signed certificates as well as ssh without a pre-shared public key are completely insecure and vulnerable to mitm attacks. I see no reason why it should be seperated as it's insecure either way, and I am pretty confident that if that happens, a while later we will see a new firesheep with SSL support. The only reason ssh has a different warning is because you are supposed to know what you are doing
encryption is based on keys and keys MUST use PKI in order to be effective. It's completely irresponsible to use a self signed certificate on a public website but for private networks it's completely acceptable to pre-share the certificate through secure means and your browser will be very happy.
And that is the right thing to do.
There are two cases in which the browser might display a warning, a self signed certificate or a man in the middle attack. Given that a client (any client) cannot distingish between the two, self signed certificates are completely insecure, so at the very least the web site is very poorly designed so it deserves the warning anyway. That is for public web sites because for private PKI you can pre-share the CA certificate through secure means and everything's cool
Browsers do not refuse self-signed certs, they just show you a very big warning. The reason for that is that the public key is certified with the certificate so the browser can verify it's authentic, and not a man in the middle attack. There is no way for a browser to know what certificates should be trusted and what should not, so the browser comes with some hardcoded public keys from known Certificate Authorities.
If for some reason you want to use your own PKI scheme, then you can bypass the warning, or add a private CA to firefox (I've never tried it, I only assume it is possible)
Concluding, encryption without verification is useless and more dangerous than plain HTTP because the user assumes that the connection is secure. Verification comes from a trusted source, either hardcoded or added by the user
Slashdot Mirror
Fair enough.
However, you are talking about bare metal programming which is a completely different matter. I completely agree with you on this, but these are things that are normally abstracted by the OS.
If you want to talk in this point of view, for me the problem is purely availability. If I was to develop bare metal, again I would select the raspi because once I learn how to program it and get my applications stable on it, I can be fairly certain that I can get it easily in large quantities and probably for a long time.
However I would like to hear more about why did go with arch programming (as in armv7) and not platform programming (as in raspi/bbb/whatever) and also, why not an OS on it in order to delegate the burden of arch specific stuff to the os devs?
Don't lie Maevius, LIMA is getting better and better and is Opensource. So no, not all modern GPU's need binary blobs.
Ha. Nice one. Indeed I try to deceive the readers of slashdot by lying in order to get them to agree with me.
I don't consider reverse engineered drivers as proper drivers because they usually they lack support and are some generations behind. Also that doesn't change the fact that GPUs come with blobs. Having said that, I have never used the lima ones. Seeing the x86 landscape though, I believe that the move of valve with steambox, the cooperation of canonical and redhat with nvidia and amd and Torvalds cursing everyone progressed linux graphics much more than some noble but nevertheless half-assed (not because the developers are incompetent, but because it is near impossible) reverse engineering.
And honestly, I would prefer all these developers to work in progressing projects like wayland which will get linux desktop out of the stone age, and some killer apps like XBMC, and the graphics companies will line up to give proper support
that have solved almost all the bugs in the thing
How can you be sure that you "solved" bugs in the closed part of the hardware? Oh, you can't.
It works doesn't it? I'm not planning on making a bitcoin miner with raspi so I don't care if there is an implementation bug that has a 10% performance hit and anyone who buys the raspi (or any embedded arm device) to work on GPU hacking is a bit wacky. What I care about is that power issues are fixed, all the devices are initialized correctly (I had an embedded linux device not properly initing the usb because a capacitor was not big enough so you had to manually change an smd cap), the GPIOs work as they should, I have an API of the GPIO in almost every normal language, I already have drivers (and tutorials) on how to drive LCD screens, loads of digital chips, I have plug n play ADC boards specifically designed for the pi.
I have a realtime operating system if I wish to do real time processing.
All modern GPU have binary blobs.
As I said, a not-so-beefy, but open GPU would be my preference. This way, you can personally experiment with all kinds of creative ways of using, misusing and abusing the computing power in the GPU.
Wishful thinking. Although I personally don't care about GPU hacking, I'd love to see GPU hackers have access to the real hardware. That doesn't change the fact that there is no open GPU.
I've personally made the step from an ARMv4TDMI to an ARMv7 core and it was amazing how practically relevant the improvements were. It's not just a few new instructions here and there, but changes that made my work easier.
Although it's common sense that v4->v7 is a huge change, care to post some examples?
I'll grant you the media center thing, although I still use a proper x86 for media center in order not to be limited on anything.
However... .deb) specifically targeted towards them in the wild?
The chinese thingies you talk about. What distributions can they run? Can they run java? Is there any documentation about the GPIO? Is there any GPIO? Can you overclock/undeclock them? Do you have any community documented hardware hacks you can follow? Is there a hardware compatibility list you can check before buying peripherals? Can you find packages (as in
You see, although I agree with you that if you want a "fire and forget" type of device, sure there are much better alternatives. But when you want a platform to hack, you want to have some things granted. I don't want to compile packages from scratch only to find out they don't work for some obscure reason. I need to know all the hardware bugs and errata before starting a project and finding that I cannot finish it halfway.
The RPi is a stable and mature platform thanks to its community. And no matter how much people shout about it, this is the way it is and anyone who is serious about hacking and realises all the time consuming hurdles will agree with me.
The rest of the "moral" or "philosophical" issues are just noise from people who prefer to shout than hack (not implying that you are one of them, just saying)
I think you are an a$$hole.
Thanks. I try...
Stallmann's predictions have been realized again and again.
Stallman is predicting that the world will end and is making a living off of it. And even broken clocks are correct 2 times a day.
The enormous blob in the processor and the USB driver is indeed a real problem for the RPI. We don't know what they have stuck into the blobs for their friends from N.S.A.
Aaah, the conspiracy theorist....
Sure, no problem. But can you actually back your claim up with actual facts or at least a plausible theory? I mean even if it the blob keeps data in the silicon itself about how many times I masturbated, how does it send it to NSA undetected? Ethernet/wifi seems a little hard to go undetected. Maybe the processor itself acts as an antenna and sends data?
The same way you are not paying for your TV, car, furniture, washing machine? I am pretty sure that you don't drink coca-cola because they don't release the recipe.
I don't mind open source purists, but the only purist is Stallman (and he is a fucking psycho). All the rest - you included of course - are lame hypocrites.
I undestand the aversion from locked platforms with the sole purpose of vendor lock-in or for example making money for stuff I could fix myself - see apple, oracle, microsoft products. But the development of the videocore never had that intent and this makes you an absolutist hypocrite.
Cheers
You. Still. Don't. Get IT!
It is not about the power! You have a cheap ass device that has a massive community that have solved almost all the bugs in the thing so any problem you have is a google search away. The foundation pays for ports of software to it. When you buy a new peripheral you can find quickly if it works with the pi and how to make it work. You can find lots of different enclosures and almost any other wacky thing you can think about.
Also...All modern GPU have binary blobs. On pcs, on phones, on tablets, on embedded. Get over it.
I think you are missing some points here.
1. The pi runs linux. You can use c/c++, python, perl, bash scripts, almost anything else you want
(1a). You have hundreds of libraries to go with that. Also thousands of programs to pipe info.
2. You can connect a 3g, wifi stick or anything USB instantly
3. You lose absolutely no time on hardware design. It might just be me but I like have my hardware done and just worry about software
4. The community will point out almost all the hardware/software limitations or bugs of the pi and you know in advance what you are getting yourself into
5. You have portable code. If you program for linux, it runs on most hardware that runs linux (some recompilation required)
6. The community has started building addons (see arduino shields) which can achieve much more
As a software developer who used embedded linux and arduino class hardware, I love the pi because it solves all the problems I don't want to worry about. I also love that I don't have to test it on different hardware/software configurations. My target will always be raspberry/debian. I undestand that this is not what some people want/like but for "rapid" embedded development the pi is number one and because of its community I think it will be for a long time to come.
In passwords you can one way encrypt them (meaning, no key is kept) because you know that a person will remember and enter the password everytime.
The reason companies keep credit card data is so they can charge recurring fees automatically or the well known one click buy, so a computer must be able decrypt and use accordingly. If you don't keep the key, you defeat the purpose of the whole scheme. The only way to protect the data (without being truly secure) is to use a hardware security module along with high physical security (something along PCI-DSS standards)
To sum it up: There is NO true security. If you can't protect cardholder data, don't keep it
btw, somewhere in their website I read that the cards were encrypted but it suggested that the key was trivial to find.
Let's say you encrypt them with the highest standard encryption algorithms. Where are you planning to keep the encryption key?
Ok, Let me clarify this.
It is possible to span a filesystem on multiple drives (see various LVMs, RAID etc) but is offtopic to the problem at hand (you cannot have 1 filesystem on your hard drive and your USB stick).
Given that hardlinks exist on the filesystem level, anything that is on a lower layer and transparent to this level (consider a driver for example that can handle hard disks, network paths, RAM etc. as 1 block device) can be on 1 filesystem and have hardlinks span across. But this purely theoretical, and a bit offtopic.
mmmmm no.
Mounting a drive to a folder has nothing to do with hardlinks (or inodes). This is on a much higher level. In order to span hardlinks on different drives, you should have 1 filesystem on 2 drives, which is not possible.
Apache doesn't serve https by default either, I think this has to do more with the configuration of the keys than the life of the *s protocols. Dying or not, it's secure, isn't it?
Although I agree with most of your post, mail servers have TLS support and if the client uses pop3s/imaps then the message is encrypted end to end. Although I don't have any real statistics from the corporate mail server from where I work, the admin is pretty confident that most mail is encrypted.
The main problem with OpenPGP on mail for me is that due to the unique key per recipient, if you add more than one recipient or cc, you have to encrypt the mail for each and every one of them. If you add some attachments it's pretty sure that you will hit the maximum allowed mail size of some mail server along the way.
Also, don't forget that at least I can easily setup thunderbird/enigmail. I don't even want to know the admin's response if he is ever asked to install/support a company wide openpgp installation
Although I would like this to work, I'm familiar with PCI-DSS and I'm pretty sure that it's your fault for keeping this data on a cell phone which is not PCI-DSS compliant and not the carrier's/CarrierIQ's
If you concentrate on the UI then you might have a point. However don't forget that firefox (and the other browsers) is average user oriented so phishing/spoofing etc are serious threats and the warning has the purpose to discourage the average user as much as possible. Considering that from an expert's point of view, unverified encryption doesn't make any sense, IMO nothing is lost by this warning anyway. I doubt that any malicious user could get a legitimate certificate to use for mitm, mainly because CAs that issue certificates do some background check. (Some social engineering might do the trick but that's a different subject)
Don't get me wrong this warning was annoying me too at first, but then I just got into the habit of having my self signed certs on a flash drive and installing them on PCs that I use to connect to my secure sites. That is true for SSH as well.
Back in the days when this warning didn't exist I was in the habit of doing mitm on co-workers computers (who are IT professionals) as a prank. They just accepted the different certificate because of the habit of pressing OK to all the dialog boxes. From the day this big warning started appearing, they knew it was me in no time
Only in retard land, where you live.
Seriously? What are you, 10? Your answer doesn't even make any sense
Ok.
Sorry If I upset you.
After all the fucking, I finally understand that you are correct. No seriously. It's all about the UI. I will have a fingerprint and you will have a fingerprint and all of us will have fingerprints. And I will collect your fingerprint from the mail, oops not mail, as it is insecure. But wait you can put another fingerprint in your mail which will be near your email address. and all of that will go to your business card. Yes, a side effect will be that your business card will be like a billboard, but who cares? Come on fuck science, let's stick it the man!
On a more serious tone, I give up, I'm going out for beers. You can try it too, it might chill you out
Agreed. But self signed certificates are not the answer. A non-profit CA could be the answer, although it has its drawbacks because if there isn't at least some paperwork in order to issue a certificate then people will just certify their mitm keys. I think the only way for HTTPS to be widely used securely is a internet-wide PKI scheme the same way dnssec is starting to be deployed, but these are just wishful thoughts.
Don't get me wrong, I want to see HTTPS widely deployed as much as you but only if it's deployed correctly. And all this is just details because right now, not even the sites that have the budget to buy a certificate use HTTPS, I cannot expect from someone who doesn't to use it
treat the HTTPS that is using self signed certificate SAME as HTTP and encrypt the traffic.
That is not an argument, that is a statement. An argument is that they cannot be treated the same because they are not the same. And actually, there is absolutely no reason for the latter to exist as I mentioned in most of my replies above. SSH for example displays a message the same way, but it's oriented towards at least power users and not average people, it's implied that it is dangerous
Interestingly enough, you still don't have any Computer Science arguments, but you still rely heavily on insulting. As I mentioned before HTTPS without PKI is useless because it's security through obscurity. You think that by encrypting, you are safe, but sooner or later everybody will undestand how this thing works and ettercap will be a common program, which needs about 2 or 3 clicks to do a successful SSL mitm. If that happens, then HTTPS will be as useful as WEP, it will be only useful against passive sniffing, but guess what? If you do man in the middle you can go past that.
So in conclusion you still don't have any serious argument. Can you please try again?
Your comment, except from the purpose of insulting (which is irrelevant) has no meaning. Please try to answer again after reading about public keys, PKI, CAs. After that please try to read my comment again. After you comprehended the previous, please try to explain wtf is the relation of http which is insecure by design and https which is supposed to be secure, only if it is implemented correctly.
As I stated on another reply above, self signed certificates as well as ssh without a pre-shared public key are completely insecure and vulnerable to mitm attacks. I see no reason why it should be seperated as it's insecure either way, and I am pretty confident that if that happens, a while later we will see a new firesheep with SSL support. The only reason ssh has a different warning is because you are supposed to know what you are doing
encryption is based on keys and keys MUST use PKI in order to be effective. It's completely irresponsible to use a self signed certificate on a public website but for private networks it's completely acceptable to pre-share the certificate through secure means and your browser will be very happy.
And that is the right thing to do.
There are two cases in which the browser might display a warning, a self signed certificate or a man in the middle attack. Given that a client (any client) cannot distingish between the two, self signed certificates are completely insecure, so at the very least the web site is very poorly designed so it deserves the warning anyway. That is for public web sites because for private PKI you can pre-share the CA certificate through secure means and everything's cool
Browsers do not refuse self-signed certs, they just show you a very big warning. The reason for that is that the public key is certified with the certificate so the browser can verify it's authentic, and not a man in the middle attack. There is no way for a browser to know what certificates should be trusted and what should not, so the browser comes with some hardcoded public keys from known Certificate Authorities. If for some reason you want to use your own PKI scheme, then you can bypass the warning, or add a private CA to firefox (I've never tried it, I only assume it is possible)
Concluding, encryption without verification is useless and more dangerous than plain HTTP because the user assumes that the connection is secure. Verification comes from a trusted source, either hardcoded or added by the user