flu kills many more people total but a much lower proportion of those infected.
ebola was a massively deadly up and coming disease with infection counts growing apparently exponentially. Fortunately it seems sufficient resources have been brought in to bring the outbreak under control before it got too big.
ebola also poses a grave threat to healthcare workers and early symptoms are difficult to distinguish from more mundane diseases. This makes it difficult to keep a healthcare system running properly in the face of an ebola epidemic (AIUI it is belived that deaths from this will be greater than the direct ebola deaths).
Radioactivity disperse under a inverse square law, so x of radioactivity 1 mile away = x/100 radioactivity 10 miles away.
Radiation in free space decreases as an inverse square law with the distance from the source but AIUI radiation direct from the ruins of the reactor isn't the main concern. The main concern is contamination with reactive fallout and while that will likely decrease with distance there is no reason to belive it will follow an inverse square law and it will be affected by many factors other than distance (such as local weather patterns.
Caching at the phone company is kinda pointless. The time you want proxy caching is when you have a fast local network behind a slow wan and want to reduce the traffic over the WAN.
Afaict the purpose of the phone companies proxy's is not caching. It's purpose at least in my experiance is to reduce bandwidth on the mobile network by reducing image quality.
In my experiance most proxies legitimate or otherwise just pass https through without caching it.
It's certainly possible to set up a proxy that decrypts and hashes https but it has a number of issues.
1: legal, in some jurisdications it may not be legal to interfere with the encryption of certain types of traffic or may make you liable if the information you decrypted leaks out. 2: client configuration, you have to explicitly add the certificate for every client. Having unmanaged client machines is not mutally exclusive with a legitimate desire to cache data. 3: security, your proxy just became a massive target for anyone wanting to attack your users.
There can be good reasons to use it but there are also a couple of reasons to avoid it.
1: overflows are "hidden", with a signed number overflow will usually* result in a nonsensical (very large negative) number, with an unsigned number overflows will usually bring you back to zero which is much less likely to be noticed 2: the rules for operations (especially comparisions) involving a mixture of signed and unsigned types are seriously counter-intuitive.
* Yes I know the C standard doesn't actually require this and modern versions of gcc are being retarded about it in some cases but for the most part it holds true
That's not "lack of diligence", that's a fundamental bootstrapping problem. CA's are meant to verify identities. If the identity you are trying to verify is not itself cryptographically verifiable, then the attempt to verify can be tampered with,
Agreed in general but I don't think a single email counts as "diligent verification". it's doing the bare minimum the browser vendors will let them get away with.
but the only way to solve that is to use harder to verify identities.
Specifically validating through multiple independent channels so that an attacker would have to compromise all of them to get the certificate.
The proper fix is to get rid of third party CAs entirely and integrate certification of domain ownership with the purchase of the domain.
Which is what EV certs do, and my own experience of getting one was pretty smooth.
EV helps a little but the web's page-by-page model works against it. The connection where a form is received and the connection where it is submitted are logically seperate and afaict there is nothing requiring them to use the same certificate. So an attacker who has a regular certicate for a domain that normally uses an EV certificate can avoid MITMing the initial connection (likely the request for the login form) and show the green bar. Then they can MITM the second connection and grab the form data.
I was dissapointed to find that HTTP strict transport security doesn't seem to do anything to address this.
The thing with academic articles is the people and who write the articles and the organisations they work for DON'T get any compensation from the journals. In many cases the reviewers don't either. This applies regardless of whether the paper is worthless drek or a major breakthrough.
People are getting pissed off with a model where research paid for primerally by taxpayers and performed by universities is locked up by journals for their own profit.
Most CAs are in the buisness of selling certs, startssl give some away for free but they clearly hope to upsell you to their paid offerings.
To get SSL everywhere it has to be trivial to get a cert, since we still lack a good micropayment system trivial basically means free. The existing CAs are not likely to help much with something that will disrupt their gravy train.
Taking on a contract like that is always going to be a big gamble, if it goes well the returns can be massive but if it goes badly it can sink your buisness.
Each party is always going to blame the other for the sinking, regardless of who or what was really at fault for the failure.
Afaict the highest version of LTO you can actually buy is LTO-6 with a capacitity of 2.5TB. I consider it highly doubtful that LTO-10 is much more than a set of goals/desired specifications on a roadmap.
Unfortunately whenever I try doing that on windows it just declares it's created a "temporary swapfile" anyway when I set the swapfile size for all disks to zero. Is there a hidden setting somewhere to really turn swap off?.
And crucially for this discussion conventional raid* does not protect against silent corruption because it doesn't know which copy is the good copy. I've found SSDs to be far more prone to silent coruption than hard drives were.
* Some filesystems with integrated raid features can protect against this but of course that means you have to use those filesystems which bring their own issues.
and the CA mechanism would work acceptably if CAs did their jobs diligently (which they don't all the time.)
They don't even pretend to, there are plenty of CAs who will hand you out a cert based on nothing more than sending an email to your domain (which of course is unencrypted and unauthenticated, remember you most likely don't have a cert yet....). If your hosting providers upstream ISP or a CAs upstream ISP is compromised by an attacker then they can easilly get the CA to issue them certs.
The design flaws in earlier versions of SSL/TLS were found through bitter experiance. In generally you are much better off using a well-known protocol and understanding it's flaws, limitations and what options are appropriate to your application than trying to roll your own, it's silly to belive that you are less prone to making design errors than the designers of ssl and TLS were.
And some of the things you have to be mindful of are characteristics of variable rate encryption in general not specific to SSL/TLS, for example the fact that compression can cause changes in the content of the message to change the size of the message and this can leak information after encryption would apply to basically any encryption system that provides cypertext at a variable rate (theoretically you are much more secure with a system that outputs cyphertext at a constant rate even when no plaintext is coming in but for most people that would be too high a price to pay)
From a time point of view if you own your own car then it's available pretty much instantly, if you use a rental service then even with automated cars you have to wait for the nearest available car (which may be some distance away) to reach you.
From a financial point of view things get interesting, on the one hand you will be paying (directly or indirectly) for the fuel burnt and wear and tear when the car is getting to you and you will be paying for what is likely a fairly new and expensive car and the rental company has to make a profit. On the other hand costs for parking, insurance and road tax are likely to be much lower.
How it works out overall will probablly depend on where you live, your risk profile (the cost of car insurance varies massively), how much you use a car and whether you insist on having a new shiny vehicle or are happy with something a bit older..
While this particular development doesn't affect it waterproofing is something that major phone vendors have been working on and they seem to have managed to make phones with a high degree of waterproofing (at least when new, I do wonder how the seals will age) without making them clunky as hell.
I can think of a few pros and cons of date code based versioning
pros:
1: they can give a quick indication of how old the software is to someone not familiar with the software and the history 2: they are less prone to bikeshedding over when it's appropriate to increase each component than multi-part version numbers. This is expecially true of large projects where different components move at different speeds. Single montonically increasing numbers
cons:
1: they usually end up much larger than a simple version number, especially if you want to leave the flexibility to perform frequent releases. 2: they can be misleading, especially when only a couple of date components are used making it not immediately obvious that the versioning is date based. Ubuntu is a good example of this, to those not familar with ubuntu releases the difference between 8.04 and 8.10 looks smaller than the difference between 8.10 and 8.04 even though both in fact represent 6 months of progress. 3: they caused a lot of fun arround the year 2000 as stuff that had been labeled 9x wasn't sure where to go, some stuff broke monotonicity and went back to 0x, some stuff broke monoticity and went to completely new naming or numbering schemes. 4: they make it tricky to handle software that has multiple branches supported at the same time. You can get arround this by using a hybrid system of date based and multipart but that makes the problems of long version numbers worse and can also be misleading (is the date supposed to be the date of branching or the date of release.......).
I guess it's people who get very little time off work and/or have inflexible work schedules. They go to work on the day before the holiday then when they finish work they set off for wherever they want to spend the holiday.
NM read in more detail, it seems they will be validating based on the ability to put a file on an unsecured webserver (which will make life a whole lot easier for a man in the middle close to the server).
Some people will stick with the established CAs for better compatibility with older browsers or for the green extended validation bar. It's also not clear whether this service will support stuff like wildcard certs (heck it's not even clear right now how they are planning to validate certificate requests).
but yeah if this takes off it's going to be a tough time to be a CA.
With fiber you can run a bundle of them, that gives you spacial multiplexing with essentially perfect channel seperation and a capacity that scales linearly with the number of fibers..
With free space you can put up multiple antennas but the signals they receive will be highly correlated. The result is that when you try and do mathematical elimination to create independent virtual channels the virtual channels end up very noisy. There are gains to be had from multiple antennas but the progression will be distinctly sub-linear.
Ideally one would use solidly authenticated end to end encryption for everything but that just isn't practical. The best you get is weakly authenticated encryption (ssl/tls) and often you don't even get that.
Given the choice of trusting a typical free wifi deployment (e.g. a radio link that is either totally unencrypted or encrypted with a password that is likely known to any attacker who puts in a moderate ammound of effort) and trusting an established fixed line IP or hosting provider I would consider the latter a much lower risk of having passwords etc stolen.
Of course if you believe you are likely to be tracked by the spooks that's a whole different ballgame.
Slashdot Mirror
flu kills many more people total but a much lower proportion of those infected.
ebola was a massively deadly up and coming disease with infection counts growing apparently exponentially. Fortunately it seems sufficient resources have been brought in to bring the outbreak under control before it got too big.
ebola also poses a grave threat to healthcare workers and early symptoms are difficult to distinguish from more mundane diseases. This makes it difficult to keep a healthcare system running properly in the face of an ebola epidemic (AIUI it is belived that deaths from this will be greater than the direct ebola deaths).
Radioactivity disperse under a inverse square law, so x of radioactivity 1 mile away = x/100 radioactivity 10 miles away.
Radiation in free space decreases as an inverse square law with the distance from the source but AIUI radiation direct from the ruins of the reactor isn't the main concern. The main concern is contamination with reactive fallout and while that will likely decrease with distance there is no reason to belive it will follow an inverse square law and it will be affected by many factors other than distance (such as local weather patterns.
Caching at the phone company is kinda pointless. The time you want proxy caching is when you have a fast local network behind a slow wan and want to reduce the traffic over the WAN.
Afaict the purpose of the phone companies proxy's is not caching. It's purpose at least in my experiance is to reduce bandwidth on the mobile network by reducing image quality.
In my experiance most proxies legitimate or otherwise just pass https through without caching it.
It's certainly possible to set up a proxy that decrypts and hashes https but it has a number of issues.
1: legal, in some jurisdications it may not be legal to interfere with the encryption of certain types of traffic or may make you liable if the information you decrypted leaks out.
2: client configuration, you have to explicitly add the certificate for every client. Having unmanaged client machines is not mutally exclusive with a legitimate desire to cache data.
3: security, your proxy just became a massive target for anyone wanting to attack your users.
There can be good reasons to use it but there are also a couple of reasons to avoid it.
1: overflows are "hidden", with a signed number overflow will usually* result in a nonsensical (very large negative) number, with an unsigned number overflows will usually bring you back to zero which is much less likely to be noticed
2: the rules for operations (especially comparisions) involving a mixture of signed and unsigned types are seriously counter-intuitive.
* Yes I know the C standard doesn't actually require this and modern versions of gcc are being retarded about it in some cases but for the most part it holds true
Yet even in places where shops are allowed to pass on the cost of credit card use to their customers few actually do so.
If you are going to have to pay a price with credit card fees built in may as well take the benefits from using the credit card.
That's not "lack of diligence", that's a fundamental bootstrapping problem. CA's are meant to verify identities. If the identity you are trying to verify is not itself cryptographically verifiable, then the attempt to verify can be tampered with,
Agreed in general but I don't think a single email counts as "diligent verification". it's doing the bare minimum the browser vendors will let them get away with.
but the only way to solve that is to use harder to verify identities.
Specifically validating through multiple independent channels so that an attacker would have to compromise all of them to get the certificate.
The proper fix is to get rid of third party CAs entirely and integrate certification of domain ownership with the purchase of the domain.
Which is what EV certs do, and my own experience of getting one was pretty smooth.
EV helps a little but the web's page-by-page model works against it. The connection where a form is received and the connection where it is submitted are logically seperate and afaict there is nothing requiring them to use the same certificate. So an attacker who has a regular certicate for a domain that normally uses an EV certificate can avoid MITMing the initial connection (likely the request for the login form) and show the green bar. Then they can MITM the second connection and grab the form data.
I was dissapointed to find that HTTP strict transport security doesn't seem to do anything to address this.
The thing with academic articles is the people and who write the articles and the organisations they work for DON'T get any compensation from the journals. In many cases the reviewers don't either. This applies regardless of whether the paper is worthless drek or a major breakthrough.
People are getting pissed off with a model where research paid for primerally by taxpayers and performed by universities is locked up by journals for their own profit.
I read that after panasonic took over they moved the eneloop production to china and quality took a nosedive, don't know if it's recovered.
Most CAs are in the buisness of selling certs, startssl give some away for free but they clearly hope to upsell you to their paid offerings.
To get SSL everywhere it has to be trivial to get a cert, since we still lack a good micropayment system trivial basically means free. The existing CAs are not likely to help much with something that will disrupt their gravy train.
Taking on a contract like that is always going to be a big gamble, if it goes well the returns can be massive but if it goes badly it can sink your buisness.
Each party is always going to blame the other for the sinking, regardless of who or what was really at fault for the failure.
And LTO-10 is 48TB/cart. Uncompressed, I assume.
Afaict the highest version of LTO you can actually buy is LTO-6 with a capacitity of 2.5TB. I consider it highly doubtful that LTO-10 is much more than a set of goals/desired specifications on a roadmap.
On linux I do just that.
Unfortunately whenever I try doing that on windows it just declares it's created a "temporary swapfile" anyway when I set the swapfile size for all disks to zero. Is there a hidden setting somewhere to really turn swap off?.
And crucially for this discussion conventional raid* does not protect against silent corruption because it doesn't know which copy is the good copy. I've found SSDs to be far more prone to silent coruption than hard drives were.
* Some filesystems with integrated raid features can protect against this but of course that means you have to use those filesystems which bring their own issues.
and the CA mechanism would work acceptably if CAs did their jobs diligently (which they don't all the time.)
They don't even pretend to, there are plenty of CAs who will hand you out a cert based on nothing more than sending an email to your domain (which of course is unencrypted and unauthenticated, remember you most likely don't have a cert yet....). If your hosting providers upstream ISP or a CAs upstream ISP is compromised by an attacker then they can easilly get the CA to issue them certs.
The design flaws in earlier versions of SSL/TLS were found through bitter experiance. In generally you are much better off using a well-known protocol and understanding it's flaws, limitations and what options are appropriate to your application than trying to roll your own, it's silly to belive that you are less prone to making design errors than the designers of ssl and TLS were.
And some of the things you have to be mindful of are characteristics of variable rate encryption in general not specific to SSL/TLS, for example the fact that compression can cause changes in the content of the message to change the size of the message and this can leak information after encryption would apply to basically any encryption system that provides cypertext at a variable rate (theoretically you are much more secure with a system that outputs cyphertext at a constant rate even when no plaintext is coming in but for most people that would be too high a price to pay)
It's meant to be, unfortunately we have learnt the hard way that the abstraction is leaky and people keep discovering new ways in which it leaks.
From a time point of view if you own your own car then it's available pretty much instantly, if you use a rental service then even with automated cars you have to wait for the nearest available car (which may be some distance away) to reach you.
From a financial point of view things get interesting, on the one hand you will be paying (directly or indirectly) for the fuel burnt and wear and tear when the car is getting to you and you will be paying for what is likely a fairly new and expensive car and the rental company has to make a profit. On the other hand costs for parking, insurance and road tax are likely to be much lower.
How it works out overall will probablly depend on where you live, your risk profile (the cost of car insurance varies massively), how much you use a car and whether you insist on having a new shiny vehicle or are happy with something a bit older..
While this particular development doesn't affect it waterproofing is something that major phone vendors have been working on and they seem to have managed to make phones with a high degree of waterproofing (at least when new, I do wonder how the seals will age) without making them clunky as hell.
http://www.digitaltrends.com/m...
I can think of a few pros and cons of date code based versioning
pros:
1: they can give a quick indication of how old the software is to someone not familiar with the software and the history
2: they are less prone to bikeshedding over when it's appropriate to increase each component than multi-part version numbers. This is expecially true of large projects where different components move at different speeds. Single montonically increasing numbers
cons:
1: they usually end up much larger than a simple version number, especially if you want to leave the flexibility to perform frequent releases.
2: they can be misleading, especially when only a couple of date components are used making it not immediately obvious that the versioning is date based. Ubuntu is a good example of this, to those not familar with ubuntu releases the difference between 8.04 and 8.10 looks smaller than the difference between 8.10 and 8.04 even though both in fact represent 6 months of progress.
3: they caused a lot of fun arround the year 2000 as stuff that had been labeled 9x wasn't sure where to go, some stuff broke monotonicity and went back to 0x, some stuff broke monoticity and went to completely new naming or numbering schemes.
4: they make it tricky to handle software that has multiple branches supported at the same time. You can get arround this by using a hybrid system of date based and multipart but that makes the problems of long version numbers worse and can also be misleading (is the date supposed to be the date of branching or the date of release.......).
I guess it's people who get very little time off work and/or have inflexible work schedules. They go to work on the day before the holiday then when they finish work they set off for wherever they want to spend the holiday.
NM read in more detail, it seems they will be validating based on the ability to put a file on an unsecured webserver (which will make life a whole lot easier for a man in the middle close to the server).
Some people will stick with the established CAs for better compatibility with older browsers or for the green extended validation bar. It's also not clear whether this service will support stuff like wildcard certs (heck it's not even clear right now how they are planning to validate certificate requests).
but yeah if this takes off it's going to be a tough time to be a CA.
With fiber you can run a bundle of them, that gives you spacial multiplexing with essentially perfect channel seperation and a capacity that scales linearly with the number of fibers..
With free space you can put up multiple antennas but the signals they receive will be highly correlated. The result is that when you try and do mathematical elimination to create independent virtual channels the virtual channels end up very noisy. There are gains to be had from multiple antennas but the progression will be distinctly sub-linear.
Ideally one would use solidly authenticated end to end encryption for everything but that just isn't practical. The best you get is weakly authenticated encryption (ssl/tls) and often you don't even get that.
Given the choice of trusting a typical free wifi deployment (e.g. a radio link that is either totally unencrypted or encrypted with a password that is likely known to any attacker who puts in a moderate ammound of effort) and trusting an established fixed line IP or hosting provider I would consider the latter a much lower risk of having passwords etc stolen.
Of course if you believe you are likely to be tracked by the spooks that's a whole different ballgame.