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.

Longer SSIDs are less likely to appear in rainbow tables.

If the SSID is long enough to be unique, it would be a waste of time to include it in a rainbow table in the first place. Once the SSID is that long, it is faster to simply brute force the password once you actually know the SSID. If we assume there are about 10^9 APs in the world, then SSIDs would need to be picked uniformly from a set of about 10^18 different values to avoid collisions. That means if there is 60 bits of entropy in the SSID, you don't benefit from adding more.

For the password OTOH a password with only 60 bits of entropy would be considered too weak to be secure. Aiming for 128 bits of entropy in the password is reasonable.

If you already have 60 bits of entropy in the SSID and want to add more entropy, then add the extra entropy to the password where it can make a difference.

I have 5-letter SSID and I've never seen a collision. It's even pronounceable.

That sounds entirely plausible, considering how many stick with the default. I didn't mention the length of mine, but it is a bit longer than 5 letters. I sticked with letters only and also ensured there was a combo of vowels and consonants, so the result in my case is also pronounceable.

The WPA key is based on a hash of both the SSID and the password, so it's a good idea to make them both fairly long.

Since the password is secret and the SSID is not, the password contributes more to the security than the SSID. As soon as the SSID is long enough to avoid collisions, there is no additional security to be gained from making it longer.

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.

I used a string of random characters as my SSID to reduce the risk of collisions. It is annoying when a device recognizes the SSID and attempts to connect to an AP where it doesn't actually have access.

The password to my AP is a different string of random characters, and it is longer than the SSID.

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.

asp.net

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)?

IIS runs on Microsoft Windows.

Apache runs on Windows as well, so this is no reason to choose IIS.

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.