Recent submissions

Comment · 2 years ago
Comment · 4 years ago
Comment · 7 years ago
FWIW this is configurable. Edit `browser.tabs.tabMinWidth` in about:config
Comment · 8 years ago
Comment · 9 years ago
Comment · 12 years ago
Comment · 12 years ago
> Update: On a more detailed examination of those two states, I’m convinced the contrast here is due to differences in the sizes of the blocks. North Dakota’s blocks are more consistently small (StDev of 3.3) while South Dakota’s are more varied (StDev of 9.28). West of the Missouri River, South Dakota’s blocks are substantially larger than those in ND, so a single inhabitant can appear to take up more spaaaaaace. Between the states, this provides a good lesson in how changing the size and shape of a geographic unit can alter perceptions of the landscape.
Comment · 12 years ago
Comment · 13 years ago
First, it looks like this scheme is broken due to cpu constraints. However...

It had looked more like the encrypted bloom filter was intended to prevent the client from obtaining the list of registered users.

With (1) + (2), the server only has a few bits of information about each of the phone's contacts. It would be analogous to just having the area codes.

Comment · 13 years ago
Good point. Now I understand why they were suggesting bucketing.

I came up with this method for maintaining privacy while retrieving installed apps (to give app recommendations). Sounds like it might not translate across so well.

Comment · 13 years ago
What about this?

1) Client uploads a bloom filter with all contacts on phone

2) Server responds with a bloom filter with all registered contacts that match the client's bloom filter

3) Client displays contacts that match server's bloom filter

You can optionally trade contacts back and forth again with a larger bits/contact ratio to decrease false positives.

I think it works out so that in exchange for 7 bits of information about each contact from the client, you can reduce the server's response by a factor of 128.

Comment · 13 years ago
Comment · 13 years ago
It's not enough to find 33 independent questions that evenly split the world's population.

An optimal, though inelegant solution to that goal might look something like this:

"Is the {1..33}th bit of sha1(name : location : date of birth) 1?".

Clearly you'll have tons of collisions with that solution, as you would have with any solution using 33 independent questions.

To uniquely identify people, we'd either need to use more bits, or look very closely at the population and derive very specific questions.

Comment · 13 years ago
Interesting. I was going to complain, as I thought "probably" meant the probability of occurrence was greater than 50%.. That doesn't seem to be the case.

  Probably: almost certainly; as far as one knows or can tell
I would guess waynecochran thought something similar.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton