The first thing Microsoft did was route all traffic through their servers. No more routing via anonymous "volunteers" or off-shore peer-to-peer technology.
That's not true. Earlier this month I have seen my Skype calls get routed through peers, who were not participating in the call. That however resulted in very unreliable calls, so I got the machine running Skype onto a public IP address. With that in place I could see the traffic was going directly between me and the IP addresses of the people I was communicating with. At one occasion I did however notice other people's calls getting routed through my computer, now that it had a public IP.
Anybody using Skype can look at their own network traffic to verify my observations.
Why Skype hasn't started supporting IPv6 is beyond me. It is so abundantly clear how Skype user experience is suffering from NAT. They could even have a Teredo client built into the client as a fallback when all other methods fail. Teredo is the only standardized tunnel protocol I know, which can be implemented in user mode without administrator privileges.
That said, I've always wondered why FLAC does not have FEC capability built in. It makes sense for a lossless format to have some support for more reliable archiving.
Such features don't belong in the file format. They should be at the storage layer. Whether they should be in file system or block layer is not entirely settled yet, so you can find implementations with redundancy at either layer. Reliable storage should be the default behaviour provided by the file system regardless of what files you put there. There are people who store files with contents that have nothing to do with audio, and those files need just as much reliability.
As in, if you have a sample rate of 48,000Hz, you can play back a frequency of 24,000Hz
But can you do so reliably? If you sample twice per wave and the original was a sine wave, the values you are going to sample depends on the phase of your sampling. If you are lucky you'll sample the peaks and get alternating high and low values, which would allow you to reproduce the original frequency. If you are unlucky you'll sample zero points and get a zero value at every sample. In general my calculations says you'll end up with with the correct frequency but a random amplitude, which is not very useful.
With three or four samples per waveform you should be able to reproduce not only the frequency but also the amplitude. More samples would be needed to reproduce the actual shape of the waveform, though at frequencies of 20kHz and upwards I don't think you could tell the difference between different waveforms anyway.
Problem is the big companies won't want to bring that out, because it could hurt the sales of their other products (safer to sell an accessory than a replacement).
That's not a concern if they can also hurt the sales of their competitors' products.
So they needed some way of giving them internet access without making it pathetically easy for foreign powers to simply tap a couple key routers and see everything any soldier browses
A VPN connection going back home would be the most efficient solution to that problem. If you are really paranoid you set it up such that the endpoints send a constant stream of equal sized packets to each other, regardless of whether you have any data to send over the VPN connection.
There's room in my mind and wallet for a new player with better for the customer data use policies and an Android-like feature set.
I agree with that. I think the way to achieve this is to fork Android and distribute it without so many Google apps installed by default. The challenge is, what you are going to replace those apps with.
The customers still need to be able to download applications onto their phone, including those well known Google apps, to the extent they want those apps. I think Google Play is by far the largest app store for Android, so it would make sense to still have Google Play installed by default for those customers who want to download applications through that.
That leaves one question open, to which I don't know the answer. Can you use the Google Play appstore on an Android phone without needing low level services throughout the system, which communicates with Google?
I'd also like to see a bit more openness by default. Though Android is open compared to some other phone platforms, Android appears quite closed compared to other Linux distributions. If you buy a piece of hardware, you should have access to a root shell on it by default, no exceptions.
I'd also like to see users get more control over installed applications. First of all the set of permissions an app gets shouldn't automatically be whatever the developer decides to ask for. The user need to be able to decide for themselves, what they will permit an app to do. Ideally this is done in a way where the permission can be faked such that it is impossible to write an app which fails in case of the absence of a permission. For example if the app wants network access, but the user doesn't want to grant it, the app might not be able to tell the difference between lack permission or lack of coverage. Or if an app wants to send SMS messages, the user could be promted with a question where they can decide what happens to the SMS, for example send it, store it, or discard it.
Another important feature is the ability to downgrade an app. Getting updates that fixes bugs is great. New features are usually also nice. But occasionally updates introduce new bugs or simply change the app in ways that serves the interests of the developer but not the user. In such circumstances the user should be able to downgrade. Without the ability to downgrade at will, every update implies the risk of never being able to use that app the way you used to. This risk means keeping all your software updated is no longer a sound piece of advice.
Those two features could perhaps be done at a layer below the app store. If they could, then installing multiple app stores on the phone by default would make a lot of sense.
This would require the compressor and decompressor to contain an exact copy of the benchmark corpus, which would likely result in copyright problems.
How much are you allowed to optimize a compression algorithm for a specific input before it would be considered a violation of copyright? If I send you a gziped version of one of my DVDs, that compressed file would be considered a copyright violation, but the gunzip binary would not. You suggest at some point optimizing the compression algorithm would make the decompression code be a copyright violation rather than the input. You wouldn't need to have the entire output stored inside the decompression code to achieve the same result. It could come out as the result of a sequence of processing involving both the input data as well as fixed data within the decompression code.
Where to draw that line is an interesting question, but completely unrelated to the question about how to actually benchmark a compression algorithm. If there was no such thing as copyright, we'd still like a reasonable approach to benchmarking compression schemes. And you could try to game that definition in the exact same ways, copyright or not.
I assume it would run on whatever platform the drive's microcontroller uses, and compression on an MCU might not favor use of a multimegabyte corpus.
But the LTO standard doesn't specify a specific microcontroller to use. Also as far as I remember these drives had a quite significant amount of memory. I think you could write approximately 200MB of data to one model of drive before you'd have to wait for the drive motors to start running.
As I understand the claim being made, the original algorithm compressed a representative corpus of data
There are several problems with that sort of benchmark. The smallest of those problems is the question about who decides what is a representative corpus. The larger problem is that if the developers know what corpus will be used to benchmark the algorithm, they may look at that corpus when deciding what the algorithm should work like. In that case it is easy to intentionally or accidentally get an unfair advantage on that exact corpus.
It's hard to draw a line between what is cheating and what is just clever tricks achieving good compression in real-world scenarios. With knowledge about the corpus, it is easy to step over that line accidentally. Without any knowledge about what sort of data will be compressed, it is impossible to come up with a good algorithm for such data.
An example of something which is clearly cheating would be to define the compression such that if the input is identical to the benchmark corpus, then the compressed output is simply a single zero bit. Otherwise the compressed output is a single one bit followed by the input. On the benchmark you compress the entire input down to just one bit, that's the best compression ratio you could ever get on that input. On any other input the algorithm does not achieve any compression.
An example of something which is a good trick for real world usage is to initialize the compression state with a predefined input containing lots of substrings which are known to be common in practice. AFAIR the SPDY protocol does exactly that. To compress HTTP streams well, the state is initialized with substrings matching all the commonly used HTTP headers as well as other common strings such as content-types and encodings. By making such initialized state part of the protocol specification, both ends will have access to it at the start of the protocol, and in practice every HTTP stream will use substrings from that state, and thus there is a real benefit.
Though those two approaches may sound different, they are not all that different. Initializing compression state with likely strings is not cheating, and it also provides a benefit even if the exact strings in the state are not used, but some similar strings are used (and thus substrings of the state can be utilized). What would be the consequence if you knew a benchmark corpus and simply included that corpus in it's entirety in the initial state of the compression? If the algorithm was then asked to compress that corpus, it would simply need to specify an index to the beginning of the state and the length of the entire state, thus the corpus would get compressed down to just a handful of bytes regardless of its initial size. That's not the "perfect" compression ratio you could achieve by cheating and compress down to one bit, but it is still unrealistically good. Still, it is hardly cheating.
In certain scenarios you would get around that sort of "cheating" by measuring not just the size of the compressed data but also the size of the decompression code. That however requires somebody to specify on what platform the code will have to run. It also doesn't give a fair measurement in case the benchmark data is too small. So you need a large set of benchmark data. If bandwidth is small but the device in each end is powerful enough, it is not unreasonable to allow the decompression code to have a size on the order of 10s of MBs, if that can give a good compression ratio. But then you need a benchmark corpus of 100s of MBs to get a good idea about the performance of the compression, if you insist on including the size of the decompression code in the calculation.
Another approach to avoid cheating would be to have one representative corpus, which the developers can look at while designing the algorithm and another representative corpus, which will be used to measure its performance once finished. This sort of approach is well known to people working with machine learning. But having people agree on the correct corpus to use is somehow conflicting with the idea that developers will never see that corpus.
So this sounds suspiciously like the inflated connection speeds I remember from the modem days.
This sort of inflated numbers is completely alive to this day, but in different areas. One area, where I have seen it myself, is on tape drives. When LTO5 was being standardized the manufacturers could not keep up with the planned improvements in storage capacity (the plan was that forward from LTO3 each generation would double capacity and increase throughput by 50%). And with LTO6 they were falling even further behind planned capacity and throughput, so something had to be done. They have somewhat compensated for that by improving the compression ratio from a factor 2 to a factor 2.5. I have no idea what that number is supposed to mean though, as anybody with knowledge about how compression works will know that compression ratios aren't just some constant that you specify.
Bringing a delicious peanut butter sandwich to work for lunch is totally innocuous. Doing so with the full knowledge that Bob from Accounting is lethally allergic is...not.
If you get a new etag with new content that's the normal and expected use of etags. They could be tracking, or they could simply have updated their content since you first loaded it.
True, but since the secondary background probing would be started immediately after page loading has completed, there is only a very short period during which this could happen. So it would only happen in rare cases. The possibility that it could happen is why I would only disable caching for that site temporarily.
There can be dynamic content, which changes every time you access it. Such content shouldn't be send with an ETag in the first place. It is however an obvious candidate for use in tracking. It is easier to implement, if you don't have to worry about interaction with legitimate use.
Can SecretAgent detect tracking through ETags? Or will it disable ETags across all sites and thus slow down browsing by effectively turning caching off?
The way I'd detect it would be with some extra background probes after a page has been loaded. The background probes start once the browser has finished loading and has become idle. Then the browser could open another connection and request the same resources again without sending any information, that could be tracked. If it receives a different ETag or different content this time around, it empties the cache for that domain and disables caching for that domain for a few hours.
The same app submitted under thousands of names - in the hope that some will "buy to try"...
Yeah, that can hardly be called development. How much effort does one have to put into developing an app in order to produce something new? I don't think you can do much in one day.
Putting this number in some perspective, the oldest person ever lived for 44724 days. So nobody would reach 47k applications at one per day.
you don't see why Yahoo would take down a site arguing implicitly "it's okay to commit suicide"?
I sincerely believe that for every problem you try to solve through censorship, there exists a better solution. And I think freedom of speech is too important to take such a site down. But Martin Manley's right to publish this is much less important than everybody else's right to read it. There are other deceased people who have written much more harmful texts than this, which are not being censored. If you disagree with something, you present a different point of view rather than applying censorship.
I will not say this suicide was the right thing to do. But I think committing suicide leaving your friends wondering why is much worse than letting them know your reasoning behind. It would be even better if we could get those people to talk with somebody beforehand such that the decision to commit suicide is not something they are making all on their own. There may be alternatives. But we may need some changes to society to make that happen.
The concern about getting so ill or getting so old and worn out that you have only suffering left in your life is a valid concern. If any animal was in such a state you'd put it down because that is considered the most humane thing to do. Why do people have to be treated less humane than that? Martin Manley decided to put an end to his own life before it came to that. If he had believed he could be assisted to end his life once there really was nothing left to live for, he might not have been so proactive about it. In other words in a society a bit more positive towards suicide, Martin Manley might still have been alive today.
There are also stories about terminally ill people who travel to a different country just so they can legally be assisted in suicide instead of facing a slow and painful death. Some of those decide to take this final trip to die sooner than they would otherwise have done because they would otherwise be too weak to take the trip. Many would much rather have stayed home and lived for a few months longer among friends and family and then end life quietly when their health was getting too bad.
Finally being assisted in a suicide after having talked it over with your closest relatives plus a doctor and a psychiatrist would be the most humane way to end life for some people. When those people commit suicide on their own, it is a failure of society to treat them humanely.
It is even worse when a young and mostly healthy person end their own life. I don't know if I could ever be convinced that could ever be the right way to go. A friend of mine did that at the age of 31. I didn't see that coming. I don't know if I will ever stop wondering if there was anything we could have done differently.
it was a site that, in part, explained why he committed suicide.
I'm sure anybody who knew him would like to read it. That may very well include people who didn't know him all that well, so a website would be an obvious way to reach all potentially interested parties. A major part of the reason for creating the site may be to comfort those left behind. With that in mind I cannot see how anybody could think it was an acceptable move from Yahoo.
The problem is that they're using/dev/urandom when they should be using/dev/random./dev/urandom is a PRNG, and apparently (on Android, at least) not a very good one.
A Google employee who is involved with bitcoin told me, that the way the problem got fixed was by using direct reads from/dev/urandom.
That's really no reason to move customer domains. As a customer I'd immediately leave a provider, which moved my domains to a new platform without asking me first. Customers that want asp.net should have to choose so on their own. The only way you could suddenly move a lot of sites from one platform to another without breaking something would be if they didn't need any server side scripting in the first place.
It could be done with parked domains. But why would you want to do that (except as a marketing stunt to promote Microsoft)?
And since SHA1 has a fixed length, the 20 bytes with zero entropy you fed into it forced out some of whatever entropy the other 35 bytes contained. Luckily, in this case you only force out some of SHA1's chunk padding
Nothing is forced out. 55 bytes plus padding fits within a single block of SHA1 compression.
but you still aren't accomplishing anything useful by adding compile-time constants either.
I didn't propose usage of any constants.
Cryptography is something that really, really, really should be left for the experts rather than just hacked together on gut feeling.
I don't hack things together on gut feeling. I wouldn't have proposed an exact algorithm if there was a risk it could make security worse. Since the hash input has 21 bytes from the system random number generator, and the hash output is only 20 bytes, that output is going to have at least as much entropy per bit as the system random number generator produced in the first place (unless you find a vulnerability in SHA1). The remaining 34 bytes are only there to strengthen the random numbers in case the system random number generator, you would have used otherwise, does not provide sufficient entropy.
/dev/urandom is not a cryptographically secure source of random numbers.
Maybe you should actually have taken a look at the source before trying to educate somebody who has. It is clearly stated in the source, that/dev/urandom produces cryptographically strong random numbers.
/dev/random is (when correctly implemented). In fact, it's supposed to be better than the frivolous combining-bits-and-hashing scheme you propose.
LOL. You probably don't even know the difference between what I proposed and what/dev/random does. They are more similar than you imagine.
It is build on top of Linux, which has/dev/urandom. I'd like to know if this is a generic kernel bug, or if Android doesn't use/dev/urandom.
You could work around such issues in user code. You could for example have your own 20 byte random seed which you concatenate with 21 bytes from the system random number generator and 14 bytes from other sources (the later don't need to be high entropy, every extra bit helps). Now send the entire 55 bytes through SHA1 and store the output as seed for the next iteration.
Furthermore, failure to replicate results does not immediately invalidate the original work, as there can be all kinds of legitimate explanations. Either party may have simply made a mistake, or there may be some critical variable that isn't yet recognized.
Regardless of the outcome, the result of any attempt to replicate the result is worth publishing. A failure may be caused by something as trivial as the original researchers accidentally leaving out some step which was obvious to themselves. It may also be that the original researches have accidentally done something wrong, which invalidates the entire study. Whether it is one or the other will only be clear once multiple teams have tried to reproduce the results, and differences in outcome have been investigated.
This of course just means it is even more expensive and time consuming than you pointed out.
Keeping information about cryptographic designs secret, when it should be public, is in no way unique to NSA. Secrecy does not prove malicious intent, it does not prove incompetence, it does not prove presence of backdoors or vulnerabilities. NSA contributed to DES. The reasoning behind this contribution was kept secret. It took many years before somebody else figured out which security bug in the original design was fixed by the contribution from NSA.
Security grows as the floor[log_2[n+1]], so compared to 1DES, 7DES is 3 times as secure, and 15DES is only 4 times.
[citation needed]
This is why you never see chaining pass 3.
Wrong. The reason you don't see that is because the performance sucks, and because nobody really saw the need to increase the keysize even further, when the blocksize remained the same.
Chaining XORs tend to be a bad idea.
That's why you would alternate between DES and XOR. Using this method with two rounds of XOR and one round of DES is standardized. I don't know if it has been used with more rounds.
I don't buy your argument about block size, at least in counter mode, as you would have to have sufficiently large known plaintext to figure out what the actual output of the counter was at that point in the cipherstream
The value of the counter is not expected to be secret. Additionally, I don't think CTR mode is suitable for full disk encryption (which tend to be the case where the largest amount of data is encrypted using a single key).
The point I was trying to get at was more that AES was not enabled by advances in computing power as the GP stated, as that is quite illogical, AES is more easily computed than DES (even 56-bit DES), so it is advances in cryptography, and not hardware that we use AES today.
A more accurate way to state it is, that it is advances in computing power that created a need for AES. Today we have so much computing power, that DES can be broken by brute force, so we need something stronger.
As far as I know there has never been found an attack faster than brute force against DES. A weakness has been found in an earlier version of the cipher, but NSA provided a fix for this weakness before the DES standard was finalized. It is unclear how much NSA understood about the weakness before they provided the fix. Nothing was published about the weakness at the time, it was discovered independently many years later.
Slashdot Mirror
That's not true. Earlier this month I have seen my Skype calls get routed through peers, who were not participating in the call. That however resulted in very unreliable calls, so I got the machine running Skype onto a public IP address. With that in place I could see the traffic was going directly between me and the IP addresses of the people I was communicating with. At one occasion I did however notice other people's calls getting routed through my computer, now that it had a public IP.
Anybody using Skype can look at their own network traffic to verify my observations.
Why Skype hasn't started supporting IPv6 is beyond me. It is so abundantly clear how Skype user experience is suffering from NAT. They could even have a Teredo client built into the client as a fallback when all other methods fail. Teredo is the only standardized tunnel protocol I know, which can be implemented in user mode without administrator privileges.
Such features don't belong in the file format. They should be at the storage layer. Whether they should be in file system or block layer is not entirely settled yet, so you can find implementations with redundancy at either layer. Reliable storage should be the default behaviour provided by the file system regardless of what files you put there. There are people who store files with contents that have nothing to do with audio, and those files need just as much reliability.
But can you do so reliably? If you sample twice per wave and the original was a sine wave, the values you are going to sample depends on the phase of your sampling. If you are lucky you'll sample the peaks and get alternating high and low values, which would allow you to reproduce the original frequency. If you are unlucky you'll sample zero points and get a zero value at every sample. In general my calculations says you'll end up with with the correct frequency but a random amplitude, which is not very useful.
With three or four samples per waveform you should be able to reproduce not only the frequency but also the amplitude. More samples would be needed to reproduce the actual shape of the waveform, though at frequencies of 20kHz and upwards I don't think you could tell the difference between different waveforms anyway.
That's not a concern if they can also hurt the sales of their competitors' products.
A VPN connection going back home would be the most efficient solution to that problem. If you are really paranoid you set it up such that the endpoints send a constant stream of equal sized packets to each other, regardless of whether you have any data to send over the VPN connection.
I agree with that. I think the way to achieve this is to fork Android and distribute it without so many Google apps installed by default. The challenge is, what you are going to replace those apps with.
The customers still need to be able to download applications onto their phone, including those well known Google apps, to the extent they want those apps. I think Google Play is by far the largest app store for Android, so it would make sense to still have Google Play installed by default for those customers who want to download applications through that.
That leaves one question open, to which I don't know the answer. Can you use the Google Play appstore on an Android phone without needing low level services throughout the system, which communicates with Google?
I'd also like to see a bit more openness by default. Though Android is open compared to some other phone platforms, Android appears quite closed compared to other Linux distributions. If you buy a piece of hardware, you should have access to a root shell on it by default, no exceptions.
I'd also like to see users get more control over installed applications. First of all the set of permissions an app gets shouldn't automatically be whatever the developer decides to ask for. The user need to be able to decide for themselves, what they will permit an app to do. Ideally this is done in a way where the permission can be faked such that it is impossible to write an app which fails in case of the absence of a permission. For example if the app wants network access, but the user doesn't want to grant it, the app might not be able to tell the difference between lack permission or lack of coverage. Or if an app wants to send SMS messages, the user could be promted with a question where they can decide what happens to the SMS, for example send it, store it, or discard it.
Another important feature is the ability to downgrade an app. Getting updates that fixes bugs is great. New features are usually also nice. But occasionally updates introduce new bugs or simply change the app in ways that serves the interests of the developer but not the user. In such circumstances the user should be able to downgrade. Without the ability to downgrade at will, every update implies the risk of never being able to use that app the way you used to. This risk means keeping all your software updated is no longer a sound piece of advice.
Those two features could perhaps be done at a layer below the app store. If they could, then installing multiple app stores on the phone by default would make a lot of sense.
How much are you allowed to optimize a compression algorithm for a specific input before it would be considered a violation of copyright? If I send you a gziped version of one of my DVDs, that compressed file would be considered a copyright violation, but the gunzip binary would not. You suggest at some point optimizing the compression algorithm would make the decompression code be a copyright violation rather than the input. You wouldn't need to have the entire output stored inside the decompression code to achieve the same result. It could come out as the result of a sequence of processing involving both the input data as well as fixed data within the decompression code.
Where to draw that line is an interesting question, but completely unrelated to the question about how to actually benchmark a compression algorithm. If there was no such thing as copyright, we'd still like a reasonable approach to benchmarking compression schemes. And you could try to game that definition in the exact same ways, copyright or not.
But the LTO standard doesn't specify a specific microcontroller to use. Also as far as I remember these drives had a quite significant amount of memory. I think you could write approximately 200MB of data to one model of drive before you'd have to wait for the drive motors to start running.
There are several problems with that sort of benchmark. The smallest of those problems is the question about who decides what is a representative corpus. The larger problem is that if the developers know what corpus will be used to benchmark the algorithm, they may look at that corpus when deciding what the algorithm should work like. In that case it is easy to intentionally or accidentally get an unfair advantage on that exact corpus.
It's hard to draw a line between what is cheating and what is just clever tricks achieving good compression in real-world scenarios. With knowledge about the corpus, it is easy to step over that line accidentally. Without any knowledge about what sort of data will be compressed, it is impossible to come up with a good algorithm for such data.
An example of something which is clearly cheating would be to define the compression such that if the input is identical to the benchmark corpus, then the compressed output is simply a single zero bit. Otherwise the compressed output is a single one bit followed by the input. On the benchmark you compress the entire input down to just one bit, that's the best compression ratio you could ever get on that input. On any other input the algorithm does not achieve any compression.
An example of something which is a good trick for real world usage is to initialize the compression state with a predefined input containing lots of substrings which are known to be common in practice. AFAIR the SPDY protocol does exactly that. To compress HTTP streams well, the state is initialized with substrings matching all the commonly used HTTP headers as well as other common strings such as content-types and encodings. By making such initialized state part of the protocol specification, both ends will have access to it at the start of the protocol, and in practice every HTTP stream will use substrings from that state, and thus there is a real benefit.
Though those two approaches may sound different, they are not all that different. Initializing compression state with likely strings is not cheating, and it also provides a benefit even if the exact strings in the state are not used, but some similar strings are used (and thus substrings of the state can be utilized). What would be the consequence if you knew a benchmark corpus and simply included that corpus in it's entirety in the initial state of the compression? If the algorithm was then asked to compress that corpus, it would simply need to specify an index to the beginning of the state and the length of the entire state, thus the corpus would get compressed down to just a handful of bytes regardless of its initial size. That's not the "perfect" compression ratio you could achieve by cheating and compress down to one bit, but it is still unrealistically good. Still, it is hardly cheating.
In certain scenarios you would get around that sort of "cheating" by measuring not just the size of the compressed data but also the size of the decompression code. That however requires somebody to specify on what platform the code will have to run. It also doesn't give a fair measurement in case the benchmark data is too small. So you need a large set of benchmark data. If bandwidth is small but the device in each end is powerful enough, it is not unreasonable to allow the decompression code to have a size on the order of 10s of MBs, if that can give a good compression ratio. But then you need a benchmark corpus of 100s of MBs to get a good idea about the performance of the compression, if you insist on including the size of the decompression code in the calculation.
Another approach to avoid cheating would be to have one representative corpus, which the developers can look at while designing the algorithm and another representative corpus, which will be used to measure its performance once finished. This sort of approach is well known to people working with machine learning. But having people agree on the correct corpus to use is somehow conflicting with the idea that developers will never see that corpus.
This sort of inflated numbers is completely alive to this day, but in different areas. One area, where I have seen it myself, is on tape drives. When LTO5 was being standardized the manufacturers could not keep up with the planned improvements in storage capacity (the plan was that forward from LTO3 each generation would double capacity and increase throughput by 50%). And with LTO6 they were falling even further behind planned capacity and throughput, so something had to be done. They have somewhat compensated for that by improving the compression ratio from a factor 2 to a factor 2.5. I have no idea what that number is supposed to mean though, as anybody with knowledge about how compression works will know that compression ratios aren't just some constant that you specify.
Did you get that scenario from The Night Caller?
True, but since the secondary background probing would be started immediately after page loading has completed, there is only a very short period during which this could happen. So it would only happen in rare cases. The possibility that it could happen is why I would only disable caching for that site temporarily.
There can be dynamic content, which changes every time you access it. Such content shouldn't be send with an ETag in the first place. It is however an obvious candidate for use in tracking. It is easier to implement, if you don't have to worry about interaction with legitimate use.
Can SecretAgent detect tracking through ETags? Or will it disable ETags across all sites and thus slow down browsing by effectively turning caching off?
The way I'd detect it would be with some extra background probes after a page has been loaded. The background probes start once the browser has finished loading and has become idle. Then the browser could open another connection and request the same resources again without sending any information, that could be tracked. If it receives a different ETag or different content this time around, it empties the cache for that domain and disables caching for that domain for a few hours.
Yeah, that can hardly be called development. How much effort does one have to put into developing an app in order to produce something new? I don't think you can do much in one day.
Putting this number in some perspective, the oldest person ever lived for 44724 days. So nobody would reach 47k applications at one per day.
I sincerely believe that for every problem you try to solve through censorship, there exists a better solution. And I think freedom of speech is too important to take such a site down. But Martin Manley's right to publish this is much less important than everybody else's right to read it. There are other deceased people who have written much more harmful texts than this, which are not being censored. If you disagree with something, you present a different point of view rather than applying censorship.
I will not say this suicide was the right thing to do. But I think committing suicide leaving your friends wondering why is much worse than letting them know your reasoning behind. It would be even better if we could get those people to talk with somebody beforehand such that the decision to commit suicide is not something they are making all on their own. There may be alternatives. But we may need some changes to society to make that happen.
The concern about getting so ill or getting so old and worn out that you have only suffering left in your life is a valid concern. If any animal was in such a state you'd put it down because that is considered the most humane thing to do. Why do people have to be treated less humane than that? Martin Manley decided to put an end to his own life before it came to that. If he had believed he could be assisted to end his life once there really was nothing left to live for, he might not have been so proactive about it. In other words in a society a bit more positive towards suicide, Martin Manley might still have been alive today.
There are also stories about terminally ill people who travel to a different country just so they can legally be assisted in suicide instead of facing a slow and painful death. Some of those decide to take this final trip to die sooner than they would otherwise have done because they would otherwise be too weak to take the trip. Many would much rather have stayed home and lived for a few months longer among friends and family and then end life quietly when their health was getting too bad.
Finally being assisted in a suicide after having talked it over with your closest relatives plus a doctor and a psychiatrist would be the most humane way to end life for some people. When those people commit suicide on their own, it is a failure of society to treat them humanely.
It is even worse when a young and mostly healthy person end their own life. I don't know if I could ever be convinced that could ever be the right way to go. A friend of mine did that at the age of 31. I didn't see that coming. I don't know if I will ever stop wondering if there was anything we could have done differently.
I'm sure anybody who knew him would like to read it. That may very well include people who didn't know him all that well, so a website would be an obvious way to reach all potentially interested parties. A major part of the reason for creating the site may be to comfort those left behind. With that in mind I cannot see how anybody could think it was an acceptable move from Yahoo.
A Google employee who is involved with bitcoin told me, that the way the problem got fixed was by using direct reads from /dev/urandom.
That's really no reason to move customer domains. As a customer I'd immediately leave a provider, which moved my domains to a new platform without asking me first. Customers that want asp.net should have to choose so on their own. The only way you could suddenly move a lot of sites from one platform to another without breaking something would be if they didn't need any server side scripting in the first place.
It could be done with parked domains. But why would you want to do that (except as a marketing stunt to promote Microsoft)?
Apache runs on Windows as well, so this is no reason to choose IIS.
Nothing is forced out. 55 bytes plus padding fits within a single block of SHA1 compression.
I didn't propose usage of any constants.
I don't hack things together on gut feeling. I wouldn't have proposed an exact algorithm if there was a risk it could make security worse. Since the hash input has 21 bytes from the system random number generator, and the hash output is only 20 bytes, that output is going to have at least as much entropy per bit as the system random number generator produced in the first place (unless you find a vulnerability in SHA1). The remaining 34 bytes are only there to strengthen the random numbers in case the system random number generator, you would have used otherwise, does not provide sufficient entropy.
Maybe you should actually have taken a look at the source before trying to educate somebody who has. It is clearly stated in the source, that /dev/urandom produces cryptographically strong random numbers.
LOL. You probably don't even know the difference between what I proposed and what /dev/random does. They are more similar than you imagine.
It is build on top of Linux, which has /dev/urandom. I'd like to know if this is a generic kernel bug, or if Android doesn't use /dev/urandom.
You could work around such issues in user code. You could for example have your own 20 byte random seed which you concatenate with 21 bytes from the system random number generator and 14 bytes from other sources (the later don't need to be high entropy, every extra bit helps). Now send the entire 55 bytes through SHA1 and store the output as seed for the next iteration.
Regardless of the outcome, the result of any attempt to replicate the result is worth publishing. A failure may be caused by something as trivial as the original researchers accidentally leaving out some step which was obvious to themselves. It may also be that the original researches have accidentally done something wrong, which invalidates the entire study. Whether it is one or the other will only be clear once multiple teams have tried to reproduce the results, and differences in outcome have been investigated.
This of course just means it is even more expensive and time consuming than you pointed out.
Keeping information about cryptographic designs secret, when it should be public, is in no way unique to NSA. Secrecy does not prove malicious intent, it does not prove incompetence, it does not prove presence of backdoors or vulnerabilities. NSA contributed to DES. The reasoning behind this contribution was kept secret. It took many years before somebody else figured out which security bug in the original design was fixed by the contribution from NSA.
[citation needed]
Wrong. The reason you don't see that is because the performance sucks, and because nobody really saw the need to increase the keysize even further, when the blocksize remained the same.
That's why you would alternate between DES and XOR. Using this method with two rounds of XOR and one round of DES is standardized. I don't know if it has been used with more rounds.
The value of the counter is not expected to be secret. Additionally, I don't think CTR mode is suitable for full disk encryption (which tend to be the case where the largest amount of data is encrypted using a single key).
A more accurate way to state it is, that it is advances in computing power that created a need for AES. Today we have so much computing power, that DES can be broken by brute force, so we need something stronger.
As far as I know there has never been found an attack faster than brute force against DES. A weakness has been found in an earlier version of the cipher, but NSA provided a fix for this weakness before the DES standard was finalized. It is unclear how much NSA understood about the weakness before they provided the fix. Nothing was published about the weakness at the time, it was discovered independently many years later.