Erm.. Maddox and the Piratebay folks at the very least manage to post their hatemail / lawyer nastygrams while being tounge-in-cheek about it. Which is kinda fun and entertaining.
The way I understand things, you try to keep your source as posix as possible from the start and not write a Windows application for beta
Given that the Windows market share is at 90%+ it would be kinda counter productive not to make a Windows version if they want as many people as possible able to actually run the application.
For an application that is intended for porting to other systems, it does however make sense to separate the generic stuff and the OS-specific stuff. That is, have as much as possible of the javascript engine, html engine, network stack etc OS-independent (plain libc/STL in case of c/c++).
complains I don't have packages xorg-server, xvmc adn fontsproto. None of which are in the repos.
The driver/configure script are written for building on pretty much any distro that includes x11/xorg, so those are the X11/xorg names for the packages. The package names in your particular distro will be different.
F.ex. to find fontsproto, search for "x11 dev fonts".
For Ubuntu8.04: "xserver-xorg-dev" "libxvmc-dev" "x11proto-fonts-dev"
You might also need some other -dev packages, but the error messages from configure and some searching with synaptic will find them. In fact, installing the "xorg-dev" meta-package should install all of them.
And yes, I've just compiled it. Don't have ATI hardware, so can't tell if it works though.
Hi, Twitter. Forgot your login password or something?
What you ignore is that most OS vendors give you fairly good guarantees on a stable API/ABI. That is, they are not going to rip out the current sound API because someone went all "Oooh shiny! Pulseaudio rawks!".
RAM Doubler for the Mac was a real and non-snakeoil product. That was mostly due to the "classic" Mac OS doing a horrible job of managing memory, so the potential for improvement was huge.
There were similar products available for win3.x and Win9x, some of which at least tried to do what they advertised. The performance benefit of using them (at least the RAM-compression) was pretty much non-existent though.
Linux / OS X / WinNT already has quite decent virtual memory management so the potential performance benefit is limited.
Article submitted by SlappingOysters. User has a UID that can't be more than a week old. He has submitted one article, and written in total one comment - which also contains a link to the auzzie online game magazine. The user's email address is at derwenthoward.com.au, which just happens to be the publisher for said magazine.
The alternatives are (1) money changed hands, or (2) ScuttleMonkey is asleep at the wheel.
but do games need to be compiled to work with 64-bit instructions/memory use?
Yes. Just like any other piece of user mode software.
The 64bit OS will see and make use of all the RAM (Vista64 is artificially limited, but that is a marketing/market segment thing), while 32bit software will have (at most) a 4GB window into that RAM.
Now, let's put this in the context of the whole damned article. When the browser sees something wonky with a certificate, it makes you jump through hoops before accepting it. This is a Good Thing(tm) for all the reasons I mentioned above.
It is only a Good Thing(TM) if the browser treats wonky certificates the same way it treats CA-signed. As far as I can see, none of us have said that a browser should treat self-signed as equivalent to CA-signed. The browser UI should treat it the same way it treats in the clear http - that is, no padlock or other sign that the connection is trusted.
Self-signed is not useless. It stops passive eavesdropping, and we know that happens a lot out there right now. It moves eavesdropping to an active and detectable mitm attack.
Users need to know that their security is not as strong as it may appear and they can't trust that the website is who they claim to be.
THAT IS A UI ISSUE. The only thing achieved by the Firefox UI treating self-signed as the digital equivalent of the plague is that it is a lot easier to just use plain old passive eavesdropping-vulnerable, mitm-vulnerable, non-authenticated http instead of self-signed ssl.
That's a good point. I see a lot of people say that http is safer than https with an self-signed certificate because people are more likely to transfer personal info over self-signed https than regular http.
That is purely a browser UI issue. There is no reason why a browser UI can't handle self-signed ssl just like regular http - no padlock, no fancy blue address bar.
It is about getting as much of the internet traffic as possible away from plaintext and over to at least some form of encryption. With all the news about government tcpdumping and ISP deep packet inspection (Phorm, anyone?) going around, it makes absolutely no sense to me why you think plaintext http is somehow better than at least passive eavesdropper-resistant self-signed ssl.
..erm. How do you know today? Unless you ask specifically for https://google.com/ it will default to plain old unprotected plaintext on the wire http:/// for the bulk of the data transferred between you and google.
Besides, distinguishing between invalid/self-signed/expired certs and valid CA-signed cert is just an UI issue. For CA-signed, show the padlock. For others, don't.
Actually, the current padlock means two things - (1) the connection is encrypted, and (2) the server has a certificate we trust. It would actually make sense to split those into two icons, so that for example self-signed certs get encrypted but not trusted.
Self-signed certs are useful because they are better than the alternative - http. There is an incredible amount of traffic that goes over unencrypted, mitm-vulnerable, non-authenticated http today; if some of it would move to self-signed ssl instead, it would at the very least stop passive eavesdropping and make mitm attacks more expensive. That is a net win in my book.
so how about when the MITM changes the cert and resubmits your data to the actual site? The MITM has highjacked your session and you don't know about it.
So? Http is also vulnerable to this. If Firefox treated http with the same level of suspicion that it does self-signed ssl, you would have to click through 6 layers of warnings when you enter http://some.site.com/ and have a red blinking address bar.
Self-signed ssl is obviously not intended to replace CA/EV certificates. It is intended to get at least some protection for traffic that is sent over plaintext http today. Which is the higher risk, to be the victim of an active mitm attack or a victim of traffic eavesdropping? Sniffing the wire for plaintext is a lot, lot easier than to mount a mitm ssl attack.
Most of the time this is good enough, but when it comes to online banking, I'd rather be sure.
Sorry, but banking is a straw man in a red herring dress. No-one is arguing for replacing EV-certs with self-signed.
What we are talking about is Firefox deliberately making it difficult to move the bulk of web traffic from plaintext no protection http to eavesdrop-resistant self-signed ssl. Why is it that so many think that http is just fine, but self-signed ssl is somehow dangerous? Self-signed https is better than http. It stops passive sniffing. It makes eavesdropping an active attack that is both more expensive to implement and is detectable.
Is it because people think that ssl means that you get a padlock icon in your browser and that people then will trust it more than regular http? There's a simple UI fix for that, split the padlock into two icons; one meaning authenticated and one meaning encrypted. CA-signed ssl would show both, self-signed would only show encrypted.
The argument used in sweden by the pro-law people was that they won't spy on "us ordinary folks". If they implement massive mitm, that would be detectable and their argument would be shown to be a lie. Besides, doing mitm on a massive scale would make their network sifting more expensive; I don't really see a good reason why we should make their job easy by continuing to send plaintext when there exists an alternative.
Besides, it is not only sweden. You have the entire carnivore/echelon stuff, and probably every government out there is doing or considering doing the equivalent of a network grep on everything plaintext.
Government surveillance is far from the only reason. An other example is ISPs doing deep packet inspection, for reasons ranging from QOS based on content/protocol to delivering targeted ads (Phorm).
In fact, I can't really see any reason *not* to use encryption. Yes, self-signed is vulnerable to mitm. Yes, it does not identify who is on the other end of the ssl session. But both are also true for plain old http; with self-signed you at least get protection from passive eavesdropping, which is in itself a large improvement compared to what we have today for the bulk of web traffic.
Bovine fecal matter. Self-singed ssl is better than plaintext because:
(1) Fingerprint.
(2) To stop passive eavesdropping. Forcing Eve to do active mitm makes it more expensive, and it also makes it detectable (if you already know the fingerprint of the real cert).
Not to mention that it stops a lot of other crud that ISPs are looking at implementing today that involves deep packet inspection. Does Phorm ring a bell, for example?
Let's say I'm on vacation, pop into a public library to check my bank balance, and logon to my bank website.
Strawman argument. No-one is advocating that banks shouldn't use CA-signed certs.
Self-signed ssl is not for banks. It is for your random webforum, or say my home broadband router (which has no FQDN, and hence *can't* get a CA cert) that wants to use encryption to protect against eavesdroppers. In the very worst case, self-signed ssl is no worse than plaintext http; but for some reason, firefox decided to make it *harder* to use encryption than to do http plaintext.
It is known that eavesdropping happens on a large scale. Everything from that swedish wiretap law to phorm , to your neighbour listening to your wifi traffic. Why do you want to make encryption harder than it needs to be? Why do you want to make it easier to use old, stupid, vulnerable plaintext instead of providing at least some protection?
>In that case SSL is a wrong tool for them. If you want to have only encryption feel free to use (or define) a different protocol for it, but don't break the existing one that works pretty well for its intended purpose
How would it break the protocol?
Not to mention, what other protocol would you recommend for people that want to encrypt their web server traffic but for some reason can't get a CA-cert?
using a self-signed cert and telling the user the link is secured is *far* worse.
THEN DON'T TELL THEM. That is purely a browser UI issue. A self-signed certificate means that you can't be sure who is on the other end, so the browser UI should obviously not use the regular padlock in that case.
But that does not mean that encryption without identity is worthless. It is certainly a lot better than plain old http, because it stops passive eavesdropping. But for some reason, Firefox throws up that UI warning from hell when an self-signed cert is encountered.
So, tell me how I can get a signed certificate for my home broadband router that has no FQDN.
Encrypting to someone is useless or even dangerous when you mistake the identity of the receiver.
NO-ONE IS SAYING THAT SELFSIGNED SSL SHOULD BE USED FOR IDENTIFICATION. Sorry for shouting, but you are entirely missing the point. The alternative to self-signed is not a proper CA-signed certificate. The alternative is plaintext http. In the worst possible scenario, self-signed is no worse off than plaintext but for some reason firefox throws up all these warnings for self-signed when plaintext is even worse.
Self-signed protects you against passive eavesdroppers. We know that this is widespread today, take for example that Swedish wiretap law that had people on/. up in arms a while ago. It makes eavesdropping (1) a more expensive active mitm attack and (2) it makes the eavesdropping detectable. The only thing that this Firefox UI clusterfsck does is to slow the adoption of crypto and keeps internet traffic plaintext.
Sure, self-signed doesn't provide identity. Sure, it is vulnerable to mitm. But it *is* an improvement over plaintext http since it provides protection against passive eavesdroppers (and makes it possible to detect active eavesdroppers).
The thing that makes me annoyed at the current situation is that Firefox is making self-signed a lot harder than plaintext. That is bass ackwards.
So, why not separate the current padlock into two icons instead? One showing encryption and one showing authentication. Http would have none, self-signed would have encryption and CA-signed would have both.
Please reread what you are replying to. He is not saying that self-signed ssl should be used for identification.
Self-signed ssl (or I suppose you could call it anonymous encryption) is for stopping eavesdroppers. Sure, you can do a mitm attack - which is why you shouldn't use it for doing banking - but it will stop all passive eavesdroppers out there. That is an improvement over good old plaintext http, but for some reason the Firefox developers decided to make plaintext http easier than self-signed ssl.
Certs are fundamentally used to establish identity
Only for certs signed by someone you trust.
You are right that self-signed ssl isn't good for identity, but that does not mean that it is useless. What I find frustrating with this discussion is that some people seem to think that ssl is only useful for identity verification. That is not the case - encryption without identification is useful against eavesdropping. That makes self-signed ssl better than regular old http in the clear. But for some reason, Firefox decides to make it easier to use cleartext http than self-signed ssl.
Slashdot Mirror
Erm.. Maddox and the Piratebay folks at the very least manage to post their hatemail / lawyer nastygrams while being tounge-in-cheek about it. Which is kinda fun and entertaining.
Samzenpus isn't. Get over it.
The mod probably misread, thinking that he modded it unsightly.
The way I understand things, you try to keep your source as posix as possible from the start and not write a Windows application for beta
Given that the Windows market share is at 90%+ it would be kinda counter productive not to make a Windows version if they want as many people as possible able to actually run the application.
For an application that is intended for porting to other systems, it does however make sense to separate the generic stuff and the OS-specific stuff. That is, have as much as possible of the javascript engine, html engine, network stack etc OS-independent (plain libc/STL in case of c/c++).
complains I don't have packages xorg-server, xvmc adn fontsproto. None of which are in the repos.
The driver/configure script are written for building on pretty much any distro that includes x11/xorg, so those are the X11/xorg names for the packages. The package names in your particular distro will be different.
F.ex. to find fontsproto, search for "x11 dev fonts".
For Ubuntu8.04:
"xserver-xorg-dev"
"libxvmc-dev"
"x11proto-fonts-dev"
You might also need some other -dev packages, but the error messages from configure and some searching with synaptic will find them. In fact, installing the "xorg-dev" meta-package should install all of them.
And yes, I've just compiled it. Don't have ATI hardware, so can't tell if it works though.
Hi, Twitter. Forgot your login password or something?
What you ignore is that most OS vendors give you fairly good guarantees on a stable API/ABI. That is, they are not going to rip out the current sound API because someone went all "Oooh shiny! Pulseaudio rawks!".
You do understand PSU efficiency ratings, right?
SoftRAM/SoftRAM95 was non-diluted snakeoil.
RAM Doubler for the Mac was a real and non-snakeoil product. That was mostly due to the "classic" Mac OS doing a horrible job of managing memory, so the potential for improvement was huge.
There were similar products available for win3.x and Win9x, some of which at least tried to do what they advertised. The performance benefit of using them (at least the RAM-compression) was pretty much non-existent though.
Linux / OS X / WinNT already has quite decent virtual memory management so the potential performance benefit is limited.
Are you not yet familiar with Slashvertisements?
Article submitted by SlappingOysters. User has a UID that can't be more than a week old. He has submitted one article, and written in total one comment - which also contains a link to the auzzie online game magazine. The user's email address is at derwenthoward.com.au, which just happens to be the publisher for said magazine.
The alternatives are (1) money changed hands, or (2) ScuttleMonkey is asleep at the wheel.
but do games need to be compiled to work with 64-bit instructions/memory use?
Yes. Just like any other piece of user mode software.
The 64bit OS will see and make use of all the RAM (Vista64 is artificially limited, but that is a marketing/market segment thing), while 32bit software will have (at most) a 4GB window into that RAM.
[Citation needed]
I would guess that it is more an issue of baseband chip manufacturers not wanting to provide open documentation.
Now, let's put this in the context of the whole damned article. When the browser sees something wonky with a certificate, it makes you jump through hoops before accepting it. This is a Good Thing(tm) for all the reasons I mentioned above.
It is only a Good Thing(TM) if the browser treats wonky certificates the same way it treats CA-signed. As far as I can see, none of us have said that a browser should treat self-signed as equivalent to CA-signed. The browser UI should treat it the same way it treats in the clear http - that is, no padlock or other sign that the connection is trusted.
Self-signed is not useless. It stops passive eavesdropping, and we know that happens a lot out there right now. It moves eavesdropping to an active and detectable mitm attack.
Users need to know that their security is not as strong as it may appear and they can't trust that the website is who they claim to be.
THAT IS A UI ISSUE. The only thing achieved by the Firefox UI treating self-signed as the digital equivalent of the plague is that it is a lot easier to just use plain old passive eavesdropping-vulnerable, mitm-vulnerable, non-authenticated http instead of self-signed ssl.
That's a good point. I see a lot of people say that http is safer than https with an self-signed certificate because people are more likely to transfer personal info over self-signed https than regular http.
That is purely a browser UI issue. There is no reason why a browser UI can't handle self-signed ssl just like regular http - no padlock, no fancy blue address bar.
It is about getting as much of the internet traffic as possible away from plaintext and over to at least some form of encryption. With all the news about government tcpdumping and ISP deep packet inspection (Phorm, anyone?) going around, it makes absolutely no sense to me why you think plaintext http is somehow better than at least passive eavesdropper-resistant self-signed ssl.
..erm. How do you know today? Unless you ask specifically for https://google.com/ it will default to plain old unprotected plaintext on the wire http:/// for the bulk of the data transferred between you and google.
Besides, distinguishing between invalid/self-signed/expired certs and valid CA-signed cert is just an UI issue. For CA-signed, show the padlock. For others, don't.
Actually, the current padlock means two things - (1) the connection is encrypted, and (2) the server has a certificate we trust. It would actually make sense to split those into two icons, so that for example self-signed certs get encrypted but not trusted.
Self-signed certs are useful because they are better than the alternative - http. There is an incredible amount of traffic that goes over unencrypted, mitm-vulnerable, non-authenticated http today; if some of it would move to self-signed ssl instead, it would at the very least stop passive eavesdropping and make mitm attacks more expensive. That is a net win in my book.
so how about when the MITM changes the cert and resubmits your data to the actual site? The MITM has highjacked your session and you don't know about it.
So? Http is also vulnerable to this. If Firefox treated http with the same level of suspicion that it does self-signed ssl, you would have to click through 6 layers of warnings when you enter http://some.site.com/ and have a red blinking address bar.
Self-signed ssl is obviously not intended to replace CA/EV certificates. It is intended to get at least some protection for traffic that is sent over plaintext http today. Which is the higher risk, to be the victim of an active mitm attack or a victim of traffic eavesdropping? Sniffing the wire for plaintext is a lot, lot easier than to mount a mitm ssl attack.
Most of the time this is good enough, but when it comes to online banking, I'd rather be sure.
Sorry, but banking is a straw man in a red herring dress. No-one is arguing for replacing EV-certs with self-signed.
What we are talking about is Firefox deliberately making it difficult to move the bulk of web traffic from plaintext no protection http to eavesdrop-resistant self-signed ssl. Why is it that so many think that http is just fine, but self-signed ssl is somehow dangerous? Self-signed https is better than http. It stops passive sniffing. It makes eavesdropping an active attack that is both more expensive to implement and is detectable.
Is it because people think that ssl means that you get a padlock icon in your browser and that people then will trust it more than regular http? There's a simple UI fix for that, split the padlock into two icons; one meaning authenticated and one meaning encrypted. CA-signed ssl would show both, self-signed would only show encrypted.
But that would be detectable.
The argument used in sweden by the pro-law people was that they won't spy on "us ordinary folks". If they implement massive mitm, that would be detectable and their argument would be shown to be a lie. Besides, doing mitm on a massive scale would make their network sifting more expensive; I don't really see a good reason why we should make their job easy by continuing to send plaintext when there exists an alternative.
Besides, it is not only sweden. You have the entire carnivore/echelon stuff, and probably every government out there is doing or considering doing the equivalent of a network grep on everything plaintext.
Government surveillance is far from the only reason. An other example is ISPs doing deep packet inspection, for reasons ranging from QOS based on content/protocol to delivering targeted ads (Phorm).
In fact, I can't really see any reason *not* to use encryption. Yes, self-signed is vulnerable to mitm. Yes, it does not identify who is on the other end of the ssl session. But both are also true for plain old http; with self-signed you at least get protection from passive eavesdropping, which is in itself a large improvement compared to what we have today for the bulk of web traffic.
Bovine fecal matter. Self-singed ssl is better than plaintext because:
(1) Fingerprint.
(2) To stop passive eavesdropping. Forcing Eve to do active mitm makes it more expensive, and it also makes it detectable (if you already know the fingerprint of the real cert).
Not to mention that it stops a lot of other crud that ISPs are looking at implementing today that involves deep packet inspection. Does Phorm ring a bell, for example?
Let's say I'm on vacation, pop into a public library to check my bank balance, and logon to my bank website.
Strawman argument. No-one is advocating that banks shouldn't use CA-signed certs.
Self-signed ssl is not for banks. It is for your random webforum, or say my home broadband router (which has no FQDN, and hence *can't* get a CA cert) that wants to use encryption to protect against eavesdroppers. In the very worst case, self-signed ssl is no worse than plaintext http; but for some reason, firefox decided to make it *harder* to use encryption than to do http plaintext.
It is known that eavesdropping happens on a large scale. Everything from that swedish wiretap law to phorm , to your neighbour listening to your wifi traffic. Why do you want to make encryption harder than it needs to be? Why do you want to make it easier to use old, stupid, vulnerable plaintext instead of providing at least some protection?
>In that case SSL is a wrong tool for them. If you want to have only encryption feel free to use (or define) a different protocol for it, but don't break the existing one that works pretty well for its intended purpose
How would it break the protocol?
Not to mention, what other protocol would you recommend for people that want to encrypt their web server traffic but for some reason can't get a CA-cert?
using a self-signed cert and telling the user the link is secured is *far* worse.
THEN DON'T TELL THEM. That is purely a browser UI issue. A self-signed certificate means that you can't be sure who is on the other end, so the browser UI should obviously not use the regular padlock in that case.
But that does not mean that encryption without identity is worthless. It is certainly a lot better than plain old http, because it stops passive eavesdropping. But for some reason, Firefox throws up that UI warning from hell when an self-signed cert is encountered.
A proper certificate is around 10 bucks per year
So, tell me how I can get a signed certificate for my home broadband router that has no FQDN.
Encrypting to someone is useless or even dangerous when you mistake the identity of the receiver.
NO-ONE IS SAYING THAT SELFSIGNED SSL SHOULD BE USED FOR IDENTIFICATION. Sorry for shouting, but you are entirely missing the point. The alternative to self-signed is not a proper CA-signed certificate. The alternative is plaintext http. In the worst possible scenario, self-signed is no worse off than plaintext but for some reason firefox throws up all these warnings for self-signed when plaintext is even worse.
Self-signed protects you against passive eavesdroppers. We know that this is widespread today, take for example that Swedish wiretap law that had people on /. up in arms a while ago. It makes eavesdropping (1) a more expensive active mitm attack and (2) it makes the eavesdropping detectable. The only thing that this Firefox UI clusterfsck does is to slow the adoption of crypto and keeps internet traffic plaintext.
Sure, self-signed doesn't provide identity. Sure, it is vulnerable to mitm. But it *is* an improvement over plaintext http since it provides protection against passive eavesdroppers (and makes it possible to detect active eavesdroppers).
The thing that makes me annoyed at the current situation is that Firefox is making self-signed a lot harder than plaintext. That is bass ackwards.
So, why not separate the current padlock into two icons instead? One showing encryption and one showing authentication. Http would have none, self-signed would have encryption and CA-signed would have both.
Please reread what you are replying to. He is not saying that self-signed ssl should be used for identification.
Self-signed ssl (or I suppose you could call it anonymous encryption) is for stopping eavesdroppers. Sure, you can do a mitm attack - which is why you shouldn't use it for doing banking - but it will stop all passive eavesdroppers out there. That is an improvement over good old plaintext http, but for some reason the Firefox developers decided to make plaintext http easier than self-signed ssl.
Certs are fundamentally used to establish identity
Only for certs signed by someone you trust.
You are right that self-signed ssl isn't good for identity, but that does not mean that it is useless. What I find frustrating with this discussion is that some people seem to think that ssl is only useful for identity verification. That is not the case - encryption without identification is useful against eavesdropping. That makes self-signed ssl better than regular old http in the clear. But for some reason, Firefox decides to make it easier to use cleartext http than self-signed ssl.