More interesting is perhaps the access model they employ. To login, all you need is the United Mileage Plus number of the primary Red Carpet Club account holder. Now, having long questioned the wisdom of a luggage tag that displays these numbers, be it a "hole-punched" Mileage Plus membership card, or a more obvious oval-shaped Red Carpet Club tag, I'm even more wary now. But if you're in bind and need your airport wireless fix, odds are you won't have to walk far to find one available for the taking. As a matter of fact, I see two from where I'm sitting right now.I've yet to explore how difficult it would be to exhaustive search for valid numbers, or if multiple logins are permitted at a given time, or how far outside of the Red Carpet Club these numbers are valid, or... I also wonder how long it'll be until some poor schmuck is arrested for allegedly downloading child porn from an airport wireless network...
If this were a wired network this wouldn't be a security problem. After all, if you're inside the RCC, presumably you're an RCC member (unless you bought a day pass), in which case you should be entitled to use the network. But as Danny indicates, the wireless AP is probably accessible from outside the RCC, so if you sit outside the club, you should be able to get on the network, making it just a matter of having a valid mileage plus number, which you can get off of someone's luggage tag.
As far as exhaustive search goes, MP numbers are 11 digits long, but the first digit seems to always be zero, so this is a 10 digit space. I don't know how many RCC members there are, but Wikipedia claims that there are about 750,000 Premier and Premier Executive members, so let's say there are on the order of 200,000 RCC members, or 2*10^{-5} of the space. If the numbers are randomly distributed, you'd need to search about 100,000 numbers in order to find one. This could take quite some time (over a day at one per second). You might be able to get some leverage because the distribution isn't random. They seem to be issued in some kind of increasing sequence, though there seem to be too many numbers for it to be strictly sequential. If there's a check digit like in credit card numbers this would make the space a lot easier to search. (If someone knows the actual algorithm, please write in.) Of course, you only need to know a few valid numbers, so this might not be a totally prohibitive attack if reading it off someone's tag weren't so easy.
Three more thoughts:
1 See draft-rescorla-stateless-tokens for a description of some techniques for avoiding the need for a centralized cookie database. ]]>
IntroductionIn mid-2007 it was revealed [4] that Comcast was blocking peer-to-peer traffic (most famously BitTorrent) on their network by injecting RST packets to terminate TCP [7] connections. The BitTorrent community almost immediately discovered carrying BitTorrent over an encrypted tunnel (VPN or SSH) was not subject to blocking, thus completing another cycle of the ongoing arms race between peer-to-peer implementors and network operators. This paper explores some predictable next moves in the game and their consequences for the network.
This isn't intended to be comprehensive, because the request was for short papers, but I think it hits the high points. You can find the full note here. ]]>
netstat -a | grep LISTEN and get:
[49] /usr/sbin/netstat -a | grep LISTEN tcp4 0 0 *.3369 *.* LISTEN ...
Hmmm. What's 3369? Google doesn't know, so that's not good. I close Word and the port goes away and lsof confirms it's Word:
[52] /usr/sbin/lsof -i TCP:3369 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Word 8198 ekr 16u IPv4 0x6c4d66c 0t0 TCP *:3369 (LISTEN)
I shut down Word and my WiFi and restart it, but it's not listening now. Maybe I need the network on. Sure enough, I bring the WiFi back up and restart Word and now it's listening, but on a different port: 3828 this time. Stranger and stranger. Now ordinarily this would only be about a 4.0 freakout on a scale of 1 to 10, but it turns out that I only recently installed Office on this machine and was unaware of the following delightful property of MS AutoUpdate: it only installs one update at a time, no matter how many updates are pending. So, when you have 10-20 updates to install, and you're just letting update run itself, it takes forever to get uprev. The consequence of this is that I was loading random people's documents with some two year old (and vulnerable) version of Word. Who knows what malware I've had the joy of installing. This jacks things up to a freakout factor of about 6.2.
Next step: compare to another machine. It shows up on my
other Mac, which is a little comforting, but of course that
machine could be infected too. I double check with Hovav, who
is about as paranoid as I am,
and his copy of Office is is listening, but on some other
random port. That's sort of comforting. This is starting to look
a lot less like malware and a lot more like a feature of Word.
A little more digging
tells us the process name that is actually doing the listening.
It's Word (as I knew) but with some wacky argument starting
with -psn_0_.... Searching on this, we find out
that I'm not the only person who has had this question.
If you close UDP 2222, then no other computers will know which TCP port your copy of word has chosen to listen to (in the 3000-3999 range), because that info is broadcasted in the UDP packets. The protocol is thus: Your copy of word spews it's serial number (encoded) and the TCP port it is listening on in a packed on UDP 2222. Other copies of word on the network get this packet and then respond the your copy of word on the specified TCP port if they have the same serial. Then one copy shuts down.
I guess it was malware after all. Outstanding!]]>
It's actually quite common throughout the world that TCP RSTs are used....
Speaking of the 1:45 AM resets, ISPs all over the world, they've found that up to 12% of sessions get reset, all over the world. It's almost like there's this 12% of background noise of TCP resets that are happening that may not be coming from comcast but could be coming from any device on the Internet, all routers, all firewalls support that feature and we don't really know where it's coming from.
Here's ATT's response to Vuze's claim that they use RSTs for "network management purposes" (i.e., terminating connections they don't like):
In response to your specific question about AT&T's network management practices, AT&T does not use "false reset messages" to manage its network. We agree with Vuze that the use of the Vuze Plug-In to measure network traffic has numerous limitations and deficiencies, and does not demonstrate whether any particular network providers or their customers are using TCP Reset messages for network management purposes. Given that Vuze itself has recognized these problems with the measurements generated by its Plug-In, we believe that Vuze should not have published these misleading measurements, nor filed them with the FCC. Moreover, as Vuze and others have acknowledged, TCP resets are generated for many reasons wholly unrelated to the network management practices of broadband network providers, which explains why resets may appear on networks of companies such as AT&T who do not use TCP resets for network management (see, e.g., An Analysis ofTCP Reset Behaviour on the Internet, University of Calgary (2004)).
I've reviewed the paper by Arlitt and Williamson to which AT&T is referring (Ou didn't cite his sources), and while it's interesting work, I don't think it really speaks to Ou's argument. The RSTs that Arlitt and Williamson are talking about are primarily ungraceful terminations of TCP connections that would be ending anyway. The authors suggest a number of cases here:
In all of these cases but the last, though, the Web transactions are actually over, so while there may be some negative effects from not going through the correct TCP finish handshake (cf. RFC 1337), neither side perceives this as failed transactions. And in the final case, the server explicitly is rejecting the connection, so this seems appropriate as well. It's also fairly straightforward to distinguish these cases as a passive observer (as the authors have done) with the appropriate tools.
What Comcast has done, however, is something different: they were (are?) using RSTs to abort other people's transactions. The base rate of normal RSTs isn't really that useful for assessing the appropriateness of third party RSTs as a network traffic management technique. As a hypothetical, imagine that Comcast were forging FINs instead of RSTs. One could expand Ou's argument to say "FINs are a natural feature of the Internet", but it doesn't really follow that it's desirable to have third parties forging FINs on your connections.
It does bear, on the other hand, on what we can infer from Vuze's
data.
Vuze hasn't really published that many details of their methodology,
but they claim to be measuring the total number of RSTs,
not just those of Azureus/Bittorrent connections
(Incidentally, I'm not sure how I'd feel as a user
about installing some app that sniffed all the traffic on
my network and sent statistics to Vuze)[-- see update below; EKR]:
The Vuze Plug\u2010In constantly monitors the rate of network interruptions occurring from RST ("reset") packets by measuring the total number of attempted network connections and the total number of network connections that were interrupted by a reset message. By comparing these two values, one can calculate the ratio of network connections interrupted by reset messages. We have chosen to reflect the median ratio in order to reduce variability in the data given the sample size.The Plug\u2010In collects data for all Internet connections, not just connections occurring due to use of the Vuze application, and logs it every ten minutes Then, at the top of the hour, the Plug\u2010In aggregates the data into one\u2010hour blocks and transmits it to Vuze, Inc.. By definition, each source of data had the Vuze application installed and launched in order connections.
But if you're measuring all RSTs and not attempting to determine which ones are "normal" and which ones represent connection failure, then it's not clear how representative your data is. It is sort of interesting how much variation (about an order of magnitude from 2.5% to 24%) there is in terms the rate of RSTs, but as Iljitsch van Beijnum observes, this could be the result of caching proxies and the like in the network. You may not particularly want your ISP interposing a proxy, but that's a different question than whether they're actually blocking your P2P traffic.
This isn't the only possible reason, either. For instance, users might just have different software profiles. Given that Vuze claims to have 8000 users on 1200 ASs (with the data being reported for ASs with greater than 20 users, there could well just be a lot of statistical variation. Some evidence of this is that the results from Comcast alone span from 14% to 24%). In order to really make sense of data like Vuze's we'd need to try to distinguish normal RSTs from those injected in the network, which requires more forensics (TTL inspection, IP ID, etc.) than Vuze's paper describes.
UPDATE (8:49 AM): I was wrong about this needing to be a packet sniffer. I just read the source (here; thanks to Danny McPherson for pointing out that I could download it.) They're just using netstat to read the network statistics and grabbing the reset counter out of the results. On the other hand, this means that they're not even in principle able to differentiate between RSTs generated on Azureus connections and those on other connections or between those generated by some man in the middle or by endpoints. While the variation in reported RSTs remains interesting, you'd need a significantly more advanced tool than this to really diagnose what's going on.]]>
The 55 men in a drug doping study in Sweden were normal and healthy. And all agreed, for the sake of science, to be injected with testosterone and then undergo the standard urine test to screen for doping with the hormone.The results were unambiguous: the test worked for most of the men, showing that they had taken the drug. But 17 of the men tested negative. Their urine seemed fine, with no excess testosterone even though the men clearly had taken the drug.
It was, researchers say, a striking demonstration of a genetic discovery. Those 17 men can build muscles with testosterone, they respond normally to the hormone, but they are missing both copies of a gene used to convert the testosterone into a form that dissolves in urine. The result is that they may be able to take testosterone with impunity.
...
Men with the gene deletion still metabolize testosterone, Dr. Schulze says. But, she adds, she does not know where the hormone goes. "We have no idea," she said. "That's what we're trying to find out."
If you've got this gene deletion, you've potentially got an enormous advantage in terms of being able to dope without getting caught. Even for those who don't have the gene deletion, I wonder whether there's some chemistry you could use to force testosterone metabolism down whatever alternate pathway is involved here (or alternately to disable the standard pathway), producing a masking effect for even those with normal genetic profiles. ]]>
"F.D.A.'s working hypothesis is that this was intentional contamination, but this is not yet proven," Dr. Janet Woodcock, director of the Food and Drug Administration's drug center, told the House Subcommittee on Oversight and Investigations in written testimony given Tuesday.A third of the material in some batches of the thinner heparin were contaminants, "and it does strain one's credulity to suggest that might have been done accidentally," Dr. Woodcock said.
...
The F.D.A. has identified Changzhou SPL, a Chinese subsidiary of Scientific Protein Laboratories, as the source of the contaminated heparin. A Congressional investigator said the contaminant, oversulfated chondroitin sulfate, cost $9 a pound compared with $900 a pound for heparin.
Mr. Strunce said that his company tried to find the original source of the contamination but was stopped by the Chinese authorities.
Robert L. Parkinson, Baxter's chairman and chief executive, told the committee, "We're alarmed that one of our products was used in what appears to have been a deliberate scheme to adulterate a life-saving medication."
Chinese officials have disputed the F.D.A. contention that the contaminant caused death and injury, and they have insisted on the right to inspect American drug plants if the F.D.A. insists on inspecting Chinese ones.
Again, when you're close to some equilibrium of high compliance, inspections are an important part of maintaining that equilibrium. However, if you're far away from that equilibrium, i.e., you're dealing with people who regularly don't comply, you need an entirely different enforcement regime with much stricter checking. If there's no punishment for noncompliance (which sounds like the case here), then it's extremely difficult to make any regime work in the face of someone who's actively trying to cheat you, since there's little cost for them trying. That said, one might think that if Americans have been poisoned and the Chinese government is stonewalling the investigation, that this might be something the US government could push aggressively on.
Incidentally, I'm not sure there is a the symmetry between US inspections of Chinese plants and Chinese inspections of US plants. It's not crazy to want to inspect the plants that produce your imports (it's not scalable if everyone wants to do it, but this is presumably delegatable to some extent, as with Reg. Dept. Penna. Agr.), but that doesn't necessarily extend to a reciprocal right to inspect random plants in other countries unless you're doing a lot of importing from them. China represented about $94 million dollars in US Pharmaceutical exports in 2004 [*]. And of course this becomes more important if there's evidence that whatever mechanisms are being employed in the other country aren't working. Have any Chinese been poisoned by defective American drugs? ]]>
158/6 Christopher columbus' flagship: the zoo exists, in Evansville, Indiana. Its monkeys—kept out-of-doors on the ship from April to November—continue to be the zoo's most popular attraction.158/7 Little Rock, near a school: rereading this passage in 1968, Nabokov called it "nicely prophetic" (the larger "row" over school desegregation, September 1957). For further "prophecy," see 226/3.
158/8 à propos de rien: French; not in relation to anything else; casually.
159/1 town... first name: "his" refers to Quilty, Clare, Michigan; an actual town.
159/2 species ... Homo pollex: H.H. combines the familiar Latin homo, "the genus of mammals consisting of mankind," with pollex, or "thumb."
159/3 viatic: H.H. sustains his "scientific" vocabulary; a coinage from the Latin root via. Viaticum is English—an allowance for travelling expenses—but H.H. has gone back to the Latin word viaticus, which specifically refers to the road.
159/4 priapically: from Priapus, the god of procreation.
159/6 man of my age...face à claques: Quilty, with "a face that deserves to be slapped; an ugly mischevious face." For an index to his appearances see 31/9.
159/6 concupiscence: lustfullness.
159/7 coulant un regard: French; casting a sly glance.
This is a bit less than one page of endnotes1 (I've omitted a note about Burma Shave2, and that reference XXX/Y means "note Y on page XXX", so this represents about half the notes on two pages of the text, since 158 has 5 notes which I haven't transcribed. You can of course ignore all these notes and just read the text, but if you're interested in a careful reading, you may well want to read them, with the concommitent risk of Wallacitis 3. The problem here is that while these notes are indicated in the text in the same way (with numbers in the margin), they're actually of quite different types:
So, we have at least three categories: (1) translations of language you might find difficult (2) explanations of subtle allusions in the text [Quilty] and (3) more or less irrelevant asides that you might be interested in. If, for instance, you knew that reference 158/8 was just a translation from French, and you already knew what à propos de rien meant, you wouldn't need to go look it up in the endnotes at all, but as it is your reading flow is totally broken up while you flip to the back of the book.
The natural fix here is to have multiple types of annotation in the main text so you can tell at a glance what you're working with. Foster Wallace5 attacks this problem by using the notation IYI to indicate that a note is parenthetical, but this is not wholly satisfactory because the notation appears in the note and so your flow is already broken (though the fact that Wallace uses footnotes as opposed to endnotes does help). Given the exemplars above, we might do something like:
The point of all this is to let you ignore the notes that you want to.7 This isn't wholly satisfactory, since we either have to intermix the allusions and asides at the end of the book (though of course you should be using footnotes) or have two separate sets of notes, both of which are clumsy (even if you have the allusions as footnotes instead of endnotes). Another possibility with a high enough note density is to put them on the facing page, but this chews up a lot of real estate if the note density is sufficiently low or highly variable.8
This is of course one of the cases where technology could really help. If you had an e-book, you could stop worrying about how the note text (as opposed to the indicator in the main text) was rendered. And if notes simply popped up when you selected them instead of taking the full context switch of a new page, you could minimize the flow interruption. Also, you could presumably program the e-book to display only notes you were interested in,9 while eliding the ones you don't care about. Of course, this would require there to be enough customers for e-books to bother giving them a treatment more sophisticated than just re-rendering the manuscript as it was typeset on the paper.
1. For more on endnotes see Rescorla 07
2. Famous for progressive road advertising signs, see
1925-1963.
3. After David Foster Wallace;
observation due to Hovav Shacham.
4.159/6 is also a translation, but the primary
purpose of the note is to point us at Quilty.
5.
Everything and More: A Compact
History of Infinity.
6. Given the particular nature of many of these
allusions, it might make sense to mark Quilty references with
a symbol rather than a number.
7. But of course this creates a hierarchy that's
fixed in the text. This is sort of inherent in the fact that things
are printed on paper, unless you want to have them printed in
color/somehow plane polarize and wear filters on your glasses or
something.
8. None of this applies to a book like Pale Fire where the
notes are part of the text; Shacham again.
9. Note that you could also use colors, but many
e-paper displays, such as the Kindle, don't have color displays, and since such a
small fraction of the text will be color, this would add significantly to the cost of
goods.
]]>
Little is known about the role of the endocrine system in financial risk taking. Here, we report the findings of a study in which we sampled, under real working conditions, endogenous steroids from a group of male traders in the City of London. We found that a trader's morning testosterone level predicts his day's profitability. We also found that a trader's cortisol rises with both the variance of his trading results and the volatility of the market. Our results suggest that higher testosterone may contribute to economic return, whereas cortisol is increased by risk. Our results point to a further possibility: testosterone and cortisol are known to have cognitive and behavioral effects, so if the acutely elevated steroids we observed were to persist or increase as volatility rises, they may shift risk preferences and even affect a trader's ability to engage in rational choice.
I don't have access to the paper (it's behind the PNAS paywall), so I don't know if they address the obvious correlation/causation issues. If it's just the case that better results result in increased testosterone levels, that's not very interesting.
What's more interesting is the suggestion that there's some set of cognitive enhancements that would make you a a better trader. One interesting question is whether these traders are outperforming the market (contra the efficient market hypothesis) or just themselves. Even more interesting would be the (implied) claim that performance increases because of more risk-taking behavior. As I understand it, the general on conventional gambling is that it's not really to your benefit to get more aggressive and/or risk-taking.]]>
ROCHESTER, N.Y. (April 18, 2008) - In response to consumer demand, Nalgene will phase out production of its Outdoor line of polycarbonate containers that include the chemical Bisphenol-A (BPA) over the next several months, it announced today. Nalgene's existing product mix, including the recently launched Everyday line, already features a number of containers made from materials that do not contain BPA."We have always been focused on responding to the needs and concerns of our customers," said Steven Silverman, general manager of the Nalgene business. "With 10 different product lines in several different materials, we have the largest bottle offering on the market today. By eliminating containers containing BPA from our consumer product mix, our customers can have confidence that their needs are being met."
The company recently unveiled its Everyday line, an assortment of bottles manufactured with Eastman's Tritan copolyester. The line includes favorites such as the OTG ("On the Go"), the iconic 32-ounce Wide Mouth and the Grip-N-Gulp sippy cup. Tritan is impact resistant, withstands a wide range of temperatures and does not contain BPA. The new Everyday products are already available in stores and will be available through www.nalgene-outdoor.com next month.
I guess once you have an alternative, it's pretty easy to get rid of the offending product. I wonder if Nalge will start lobbying for a ban on BPA now. ]]>
The authors describe a number of techniques (obfuscation, encrypted patches, P2P patch distribution) one might imagine using to reduce the impact of fast attack generation, and conclude (correctly IMO) they're not that likely to work. As I understand it, the critical path item in patch installation for important systems isn't obtaining the patch but testing it on sacrificial systems to make sure it doesn't introduce instability, and that creates an inherent lag that probably can't be removed with a new distribution method.
Another alternative (though it goes against the trend in recent practice) is to be less aggressive about releasing patches for vulnerabilities that haven't already been disclosed. The faster that attackers can respond to new vulnerabilities by comparison to defenders, the more that fixes released in an orderly fashion look like zero-day vulnerabilities and so the less attractive it looks to fix vulns that aren't generally known (Res04 has some analysis of this issue.)]]>
Why FPE?
The use case for FPE is simple: say you have a database that contains
information with multiple levels of sensitivity. So, for instance,
if you're Amazon you might have a customer database that any
employee can access but you'd like the credit card numbers to
be accessible only to employees that really need it.
The classic approach here would be to use database access controls. This works well as long as you trust the DB server, but if, for instance, you want to send a copy of the DB to someone else, then you may not be able to trust their server, so you need to redact the database, which can be a pain. Another problem here is that sometimes sensitive information like CCNs is used for customer identification, which means you can't just redact the CCN. Rather, you need to replace it with something that's unique but doesn't leak the CCN itself. And of course, if someone compromises your database server, then all bets are off.
The problem with simple encryption
The natural alternative is to use encryption. Encrypting the whole
database doesn't help, because you want users to have access
to most of the database, just not to the sensitive fields.
So, what you need to do is encrypt just the sensitive fields.
This turns out to be trickier than it looks.
For example let's say we want to encrypt the social security number
123 45 6789 using AES-ECB. So, we might do:
31 32 33 34 35 36 37 38 39.
00 to give 31 32 33 34 35 36 37 38 39 00 00 00 00 00 00 00.
77 6e 2c a5 02 17 7a 5b 19 e4 28 65 26 f3 7e 14
This kind of sucks. Not only have we managed to start with a 9 digit string and end up with a 128-bit random-appearing value, none of the bytes of the output are ASCII digits. So, if our database or database software is expecting to have values for this field that look like SSNs, we've just broken that invariant.
The source of the problem, of course, is that we're using a block cipher in ECB mode, and most block ciphers come in a small number of sizes (64, 128, and 256 bits are the standard ones). A block cipher just randomly maps the input space onto the output space, so ECB mode encryption effectively selects a random b-bit value (where b is the block size). The smaller the fraction of the possible values that are valid, the higher the probability that the output will be invalid. To take the specific case of SSNs, there are approximately 2^{30} valid values (if we think of the trailing zeros as not counting), so the chance of producing a valid value by random chance is vanishingly small (order 2^{-98}).
One thing you might think would make sense would be to use a different mode than ECB, say counter. The problem with counter mode in this case is that you need to use a different section of keystream (or a different key) to encrypt each value to avoid easy cryptanalytic attacks. So, you need some per-value distinguisher that gets carried along with the ciphertext, which expands the amount of storage you need for the encrypted values, even as it keeps the ciphertext small.
Luby-Rackoff
As noted above, our big problem is our block size is too large.
As noted above, even though SSNs are 9 digits long, they are sparsely
packed (for instance letters aren't allowed), so there are
approximately 2^{30} valid SSNs, as long as we use a better mapping
than straight 1-1 digit correspondence. For instance, think of the 9
digit SSN as a value from 1 to 999,999,999 (not all 9-digit numbers are valid
SSNs, but for simplicity, let's pretend they are.)
We can represent that in
binary as a 30 bit quantity. If we had a 32 bit block cipher, we could
encrypt this value with less than 10% expansion, which might be OK
under some circumstances (we'll describe how to do better below).
Ordinary block ciphers have blocks much larger than this, of course, but it turns out that there's a generic technique for making block ciphers of arbitrary size (actually, even values only), called Luby-Rackoff (L-R) . The nice thing about L-R is that it's a general construction based on a pseudorandom function (PRF), which we know how to build with standard cryptographic techniques.
Cycle Walking
We can use L-R to build a block cipher with a block size of any
number of bits we want, but this still means that our function
produces 2^b possible values where b is the block size, but
this generally won't line up perfectly with the set of values
we want to encipher. To return to our SSN example, we have
10^9 possible values, which means we need a block size of
30 bits, which implies a set size of 2^{30} = 1073741824.
So, for any given input value, there's about a 7% chance that
it will encrypt to an invalid SSN (greater than 10^9).
If the database (or software) is really aggressive about
validity checking, then you'll have an unacceptable rejection
rate.
To deal with this issue, Black and Rogaway describe a technique they call "cycle-walking". The idea is that we start with an initially valid value (1-999,999,999) and then encrypt it. If the ciphertext is also valid, we stop and emit it. If it's invalid (greater than 999,999,999), we encrypt again, and repeat until we have a valid value. This gives us an encryption procedure that is guaranteed to produce an in-range output. Decryption is done in the same way.
Bottom Line
So, why can't we just use cycle-walking? Because
it only works well if the block size is
approximately right—if the size of the valid set is
a lot smaller than the block size of the cipher, then
you have to do a lot of iterations in order to get an in-range
result. So, you can't use a 64-bit block cipher in order
to encrypt an SSN because you end up having to do a
prohibitive number if iterations; you need to use L-R
to construct a block cipher of approximately the right size
and then use cycle-walking to shave off the last few values.
UPDATE: Paul Hoffman pointed out to me privately that it's not clear how this all relates to FPE. Basically, FPE means the combination of L-R plus cycle walking. This lets you do one-to-one and onto encryption for most set sizes. If the set size is really small, there's another technique (also due to Black and Rogaway): you encrypt all possible input values and then sort the ciphertexts. You then use the index of the ciphertext in the sorted list as the encrypted value. This is obviously prohibitively expensive unless the number of possible values is small because it requires encrypting all possible values and then keeping a very large mapping table.]]>
OTTAWA -- The Canadian government moved Friday to ban polycarbonate infant bottles, the most popular variety on the market, after it officially declared one of their chemical ingredients toxic.The action, by the departments of health and environment, is the first taken by any government against bisphenol-a, or BPA, a widely used chemical that mimics a human hormone. It has induced long-term changes in animals exposed to it through tests.
...
The health minister, Tony Clement, told reporters that after reviewing 150 research papers and conducting its own studies, his department concluded that children up to the age of 18 months were at the most risk from the chemical. Mr. Clement said that animal studies suggested "behavioral and neural symptoms later in life."
Clement claims that adults aren't at significant risk (note: I haven't really reviewed the literature myself at all), but MEC and Patagonia have already pulled polycarbonate drinking bottles (aka Nalgene bottles) off their shelves, and Nalgene has already introduced a new line of bottles called "Everyday" which aren't based on BPA but on Eastman's Tritan, which is supposed to be comparably tough to polycarbonate. Also, according to this article, Charles Shumer has introduced a bill to ban the use of BPA-based polycarbonates in food and drink applications. Industry has been pretty actively opposing this kind of regulation, but given that alternatives are starting to appear, I suspect we've reached an inflection point where they'll just start replacing polycarbonate in most applications instead. ]]>
Now, you could certainly argue (as Rob's argument implies) that there's an upper limit on how much bandwidth can be used by voice and so as the technology has improved, it's become cost effective to offer unlimited voice service, but that the bandwidth consumed by video will be much greater. On the other hand, just last year Apple pushed Cingular/AT&T into offering an unmetered data plan for the iPhone, and apps like YouTube for iPhone clearly encourage users to consume larger amounts of bandwidth than they would if just checking their email. Now, obviously the cell providers have a lot of latitude to manage the data portions of their network, but it still seems to me that there are a lot of factors in play here and that metered Internet is not the only possible outcome, even in a more highly regulated regime. ]]>
BeanBoozled jelly beans come in 20 flavors, 10 weird and wild flavors matched up with 10 look-alike tasty flavors. Is the black jelly bean Licorice, or is it Skunk Spray? Perhaps the blue bean is Toothpaste flavor, or maybe it's delicious Berry Blue. Think you can tell them apart? We dare you!You might not know when you will be bamboozled by a weird flavor. A key on the back of each box gives clues to the surprises found inside, but the beans look so similar, every bite will be a surprising dare.
I actually already have this problem with Jelly Belly bulk packs. Mrs. Guesswork buys these ginormous tubs of mixed jelly beans at Costco and I already find a pretty substantial fraction of the beans (cafe latte, cappuccino, a&w cream soda, licorice, ...) revolting, and they look a lot like other flavors that I like, so I have to be on my guard anyway.
On a related topic, why when you go to Costco do they insist on selling you mixed packs of cliff bars, power bars, etc. Are there really people who like vanilla crisp power bars, or is this just some scheme to get you to throw away 1/3 of the bars so you buy more that much sooner?" ]]>
In principle a gizmo like this might be useful for getting you un-lost, but the fact that you don't have a real map, just a view of where you've been, makes it pretty hard to use for anything other than backtracking. If, for instance, you're doing a loop and there are multiple trails but not a dense enough network that you can just vector in on your start point directionally, than without a trail map a GPS is pretty useless. Pretty good for out and back trips, though. ]]>