Laser pointers of any type have really shitty focus on them. By the time it goes 1000 feet, the beam has diverged to the point where it's not even a problem.
Point the sucker at a fence across a street, or over any distance where you can see the resulting spot. Notice how it's not exactly a pinpoint spot anymore? That's divergence of the beam. Now imagine how big that beam is over 6 miles (planes flying at around 30000 feet or so), and how little light from it is actually visible from that kind of distance.
REPEATABLE means that one should be able to start at a point and do things to DUPLICATE what is being observed.
No, in fact, that's not what it means at all. "Repeatable" means just what the other guy said it did.. That you can repeat the tests, proving their validity. If the tests are not repeatable, then you haven't accounted for all the conditions. The age-old example for this is the one about how a guy was unable to repeat the experiment in front of other people until he figured out that it made a difference what kind of material the table was made of, that he was doing the experiment on. Wood tables worked, metal tables didn't. He had not fully accounted for all the conditions and until he did, it was not repeatable and it didn't teach him anything useful.
Nobody has ever created one species out of another.
I know some biologists who work with bacterial strains that would vehemently disagree with you.
QLink... but now under a different name.
on
Ceefax Turns 30
·
· Score: 1
What was Commodores service called? Q-Link? Koala-Link? It was something like that. It was friggin cool, it was like the internet just for C-64s.
It was Q-Link or Quantum Link, run by Quantum Computer Services. Later they added PCLink and AppleLink because they were hurting for cash. PCLink and AppleLink were basically the same as Q-Link and email could even be sent between the systems. Even later than that, they combined the PCLink and AppleLink services to form a now well known system: America Online.
Yep, if you didn't know it already, Quantum Link is the direct predecesor to AOL. AOL discontinued the QLink service on November 1st, 1994.
The death blow to QLink, delivered by none other than Steve Case:
Dear Members,
As you know, QLink was originally launched in November, 1985. In the years that followed you, as our loyal members, have helped us build a unique online community for Commodore computer users. I want to thank each of you for your contribution, your support and your feedback over the years.
The computing industry has changed dramatically since those first days of online communications. Commodore ceased to produce Commodore brand computers in 1993. Sadly, the company has recently closed its doors entirely. The Commodore computer, once a leader in the industry, has been replaced by faster, more powerful systems. Many software vendors no longer support the Commodore operating system.
Now we find, with great regret, that we simply can no longer support the QLink service. It has become impossible for us to maintain the product up to a standard of quality that we can be proud of. Many of you I'm sure have noticed a diminished level of product quality in the last few months due to these technical limitations. Without technical support from the industry, we are not able to add new services, fix existing problems, or prevent new ones. Therefore we have made the sad decision to discontinue QLink as of November 1, 1994.
We would like to thank each of you for your long and continued support and, if at all possible, keep you as part of our online community.
If you now have the ability to use America Online (PC-DOS, Windows or Macintosh), we invite you to convert your membership to one of these other systems. For details on what these versions have to offer and the system requirements needed to run them, see the document in this area entitled "Converting to America Online."
For details on the last month of service for QLink, important dates and billing information, see the document in this area entitled "Your Final Bill."
That's not to imply they can't invent new games with whatever probabilites they want, but they can't adjust existing ones.
Considering the biggest money maker is in fact the slots, and they can adjust those payoffs, I'd say you're wrong.
Table games, yes. However there's several varities of table games. I've seen roulette wheels with one zero or two. I've seen rule differences on side bets that do change the odds. I agree that the 36 to 1 is not something they mess with, but thinking that they don't change the games is foolhardy.
Check out http://wizardofodds.com to get the scoop on the various differences between the same game at different casinos. Outside of Vegas and Atlantic City, very few places have such strict regulations on gaming.
Putting aside whether my example is good or not, your answers proves the point that it's really hard to make a program that will judge well what the other player has.
Well, if we're talking building bots to play poker, then I disagree, to some extent.
First, we're really talking about online poker and that's a much smaller subset. For one thing, you can't see the other players. So your only information to go on is: -The cards you can see (we'll assume the program has a perfect method of getting everything, either via decrypting the traffic to the client, or being a client itself, or screen scraping the client), -The pattern of betting.
If we further assume it's a limit game with a limited number of raises and a bet pattern (meaning that you only choose whether to bet or not, not how much and so forth.. like the vast majority of online poker games out there), then the bet info can come down to a "he raised", "he didn't raise" and so forth.
The point being that the number of possible games given these limits is finite.
Now in discussing a program, every program can be boiled down to its inputs and outputs, as you probably know. From this you can build a state table. You rarely do this as it's easier to write most programs as sheer logic, but this is a simple enough concept to represent it, metaphorically, as a state table.
If you went by the odds on each as a starting point, filling the table would be rather easy to come up with. Then it's a simple lookup process. You could then refine it by hand so as to take betting patterns into account. The information you have is limited, but as I was trying to say earlier, in some circumstances it's fairly obvious.
The only thing that's difficult to program in this situation is betting history. It's difficult to program a system that can say "this guy tends to want to see the flop a lot" or "this guy raises early a lot" and then take that into account. It could be done, but the upshot here is that if you could work out an algorithim that reliably grouped people into categories like these, that's just another boolean in your state table to take into account.
Further refinements could be to notice losses and flag these table rows as being potentially wrong.. or better to keep statistical information on win/loss for each row and signal when adjustments are needed.
It's not a small undertaking, I grant you, but it's quite feasible to do with current technology. That's all I'm saying.
I'd say your reply is slightly uninformed. Casinos don't adjust the payoff of any given game. Rather, they play the odds.
Actually, you're both right. They play the odds by the method of adjusting the payoff. If the payoff ratio is higher than the ratio of winning, then it's in your favor. If the payoff ratio is lower, it's not in your favor.
Let's say you have a roulette wheel. 36 numbers, one zero, one double zero. Betting on any number wins 36 times your money back if you win. This is not in your favor because the actual odds of winning are 38 to 1. If the payoff was 40 to 1, then you'd win more than you lose, on average.
Basically we're talking about expected payoff here.. Expected payoff = (amount you win) / (odds you win). If the expected payoff is greater than 1, then it's in your favor, if it's less, it's in the houses favor. For most games, the casino can't control the odds. But they can control the payoff, and that's what they use to make the number less than 1. Simple.
Most good players will consider that the opponent might have AA since he reraised you preflop and would adjust their strategy accordingly.
Either that or he has AK and you get the same basic setup, except now he has 2P to your 3OAK and you take him for everything he'll bet on.
If I had AA I doubt I'd raise somebody preflop. Might scare 'em off. Somebody raising me preflop might be trying to do the same. What if the guy had K5 and was simply trying to bluff it through, then got lucky on the flop and is playing for everything he's got, hoping like hell that I don't have AK?
Short answer to all this is that if I had KK down and AK5 on the flop, damn right I'm going for it. Unless another A shows up on the table, at which point I might wonder more.
1) Long dial in times result in the 2nd password changing before completion, thus requiring a 2nd attempt (or a 9th, depending on how pathetic the phone service is)
Assuming you have some wacky setup that asks for the password before connection and not after you have already connected... then all SecureID based systems have a server running the same math as your little ID is and the server can, and does, calculate the previous and the next numbers the device will display. So even if the password takes 20 seconds to get there and it has changed in the meantime, it'll still authenticate, because the server is aware of the previous and next passwords.
2) Annoying easily lost dongle on your keychain that says "RSA- STEAL ME" in big bold letters...
I've been using these things for years and have yet to lose one. Of course, I never lose my keys either. If I lose my keys, I'd be more concerned about how to start my car than my account's security.
That's exactly why a metaverse like in Snow Crash will never happen. Hackers are much to interested in getting things done and saving resources for other, cooler things than 3D graphical interfaces. Typing in a command line is harder to learn than mousing around, but faster and provides better control. The same could be applied to online interaction.
I don't quite agree with this one. If it were possible to build the metaverse from SnowCrash, rest assured that it would happen, and hackers would make it happen. Why? Because personal presence is a much faster means of communication than typing or IMing or what have you.
Well, that and they'd be able to hang out in the bar all day while still claiming to be at work.:)
Geeks with no social life get to put on pretend bodies and roam around an artifical universe? You can bet your ass it'd happen. But the tech ain't up to it yet.
The recent "Let It Be... Naked" CD has some sort of copy protection on it that, under XP at least, it wont play except through a piece of software the CD installs for you.
1. Never install the software on the disc. This is critical, as sometimes they install drivers that intentionally mess with ripping operations. If you have installed it, remove it.
2. Use ExactAudioCopy to rip the disc. Sometimes you have to use the Advanced functionality it offers to be able to read the disc.
In this particular case, EAC will read the disc fine if you enable Actions -> TOC Alterations -> Detect TOC Manually. One of the tracks will be a data track which you can ignore, the rest of the tracks will be audio, which should rip fine (if you remove the malware that the disc may install on your machine).
If that was their only business, then you'd be exactly right. I'd have no reason to accuse them of bullying. They're doing it, just like Apple is, only in other arenas. Why shouldn't Apple do to Real's stranglehold on Helix DRM what Real has done to Apple's stranglehold on FairPlay? Did that make sense?
No, not really.
-Given: that Real is producing Helix DRM software and licensing it to others for building into hardware and so forth. I see that now.
-Assume: Apple created some kind of compatible product that could also produce Helix DRM'd look alikes that worked in this hardware.
Result: Yeah, they're comparable. So what? My bet would be that Real would say "Why didn't you license it from us instead?" because they are actively licensing the stuff out. Apple would not and has not actively licensed FairPlay out to anybody. Big difference, it seems to me.
Jumpdrive contains some form of software to perform the decryption of the encrypted data. It claims to use AES, so let's assume it does.
The right way to do this would be to make the user have the AES key. AES keys are a bit big to carry around though, so the second right way to do this would be to store the AES key on the drive in an encrypted form itself. This is quite common and usually called the keyring.
The keyring is encrypted with some symmetric cipher that uses a simple passphrase for decryption. DES used to be pretty common, but most people like Blowfish nowadays. Whatever, this is unimportant. What's important is the process at work: A. Enter passphrase. B. Passphrase decrypts keyring. C. Key from keyring decrypts data.
This is generally considered secure enough because if the keyring is made right, then you can't usually be sure whether or not you guessed the right passphrase without actually attempting the data decryption itself. The key is a pretty random set of bits, in other words, and looking at it after decryption is usually not enough to be able to tell whether or not you sucessfully guessed the keyring's passphrase. This makes the attack computationally hard in that they still have a wide variety of keys to test.
What these morons appear to have done is to stored the passphrase to the keyring itself on the frickin' drive, XOR'd with some constant that's in the program. The reason for this is to make it more obvious when you enter the wrong passphrase. So their program does this: 1. Retrieves the XOR'd passphrase from disk. 2. XOR's it with the constant, leaving the damn password in memory in *plaintext*. 3. Compares the password to what you typed in (strcmp, probably), and spits out a "wrong password" message when it doesn't match. 4. Does A,B,C as listed above if the password was correct.
A slightly less dumb thing to do would have been to store a hash of the passphrase on the disk, then hashed the passphrase and compared the two hashes. This is only slightly less dumb though, because it still provides a shortcut to breaking the decryption, as you can do a dictionary attack on the hash, which is much faster than doing a dictionary attack where you must perform two actual decryptions on every possible passphrase.
But having the passphrase in memory in plaintext is just frickin' inexcusable from a security standpoint. Having, essentially, every single little thing that you need to decrypt the thing on the disk is even worse: -The static XOR block is in the software, on the disk. -The XOR'd password is on the disk. -The keyring decrypted by the password is on the disk. -The data encrypted by the key is on the disk.
First, global warming means the atmosphere has more energy than before, which means the wind blows harder, which means that if you could slow down the wind, you're removing some of the energy, which means you may lessen the severity of weather patterns.
Okay, so you extract energy from the atmosphere, convert it to electricity, and then convert the vast majority of that into heat... which puts the energy right back into the atmosphere.
That was the point the parent was making. Extracting energy from the atmosphere only to put nearly all of it back in doesn't really change anything as far as that goes.
CO2: Yes, that's a possible difference maker. Pulling energy out of the wind is not.
Real is producing files that can be played on iPods while maintaining DRM. I am proposing that Apple could produce files that can be played in RealPlayer while maintaining DRM.
RealPlayer already supports playback of iTunes M4P format, assuming you have iTunes installed and are authorized to play the music.
You seem to misunderstand. I am proposing that Apple could make Safari & Quicktime work perfectly with... the.rm broadcasts on the websites for NPR or the BBC. Lots of people use that. Apple could make money the same way Real does in this market, selling software for producing DRMed.rm files.
1. The BBC/NPR broadcasts have no DRM on them, that I'm aware of. At least, I was able to load up a program to rip the stream easily, last time I checked. It's been a while, I grant you. 2. I was not aware Real sold any software to produce DRMed.rm files.
That is exactly not my perspective. I don't think Real has done anything wrong by allowing their customers to use iPods. I think Real has wronged consumers (a little tiny bit) by keeping their.rm file format closed and proprietary. Just like Apple wronged consumers by keeping FairPlay closed.
Last I checked, they had dumped the RM format for the most part and are moving towards AAC. At least, their Harmony player produces AAC by default. The downloaded material from their music store is 192 kbit AAC, albeit in an odd container format.
So now Real says Apple is being a bully, while they attempt to maintain a business model 100% based on bullying.
How is selling music to customers who then listen to it bullying?
When I say "Why shouldn't Apple do this?" Rob's honest answer might be "Because we would sue them, file a DMCA complaint, and do our best to smear them as hackers in the media." (Because Real can't break compatibility like Apple via an iTunes update. Their software is deployed.)
Or his answer might be "What in the hell are you talking about? Apple can't do this to Real because it makes very little sense."
If you mean "What if Apple started producing RM files" then my answer is simply that Real is starting to distance themselves from the RM format because it's a losing horse. Real might posture a bit about it, but they've already dumped it where it counts. Real is in the AAC business now.
Actually, I guess it's my fault for not framing the question more restrictively. But I didn't ask whether he'd like to cross-license with Apple. We all know the answer to that question. I'm not talking about whether he'd like to see that kind of interoperability. I'm asking what he'd do if Apple reverse-engineered Real's product like Real did to Apple. Because I want him to say, "Nothing. That's ok." If he can say that, he'd win a point or two with me. But he can't say it.
The problem here is that the two cases are not comparable in the least.
-Real produces a file that is similar in structure to Apple's DRM format in order to put songs onto an iPod without totally decrypting them. -Apple would produce a file that is similar in structure to Real's format or Real's Helix DRM in order to... do what, exactly? That's right, nothing. There's absolutely no reason for Apple to do what Real did.
Real made a method whereby Real's own music could be put onto an iPod without decrypting it. They did this by emulating Apple's DRM. They didn't break Apple's DRM. Their software does nothing to Apple's Music files.
Apple doesn't have the same problem. Nothing plays Real's Helix format music at the moment, which is why Real can convert their music to Apple DRM, Microsoft DRM (in the form of a protected WMA), etc. Apple doesn't even *support* portable players that are not a form of iPod, and thus have less than no reason to reciprocate in this manner.
The reason he answered the way he did is simply that you and he have two different perspectives. -His perspective is that Real wrote Real's own software in a way that would take Real's own music and put it on the portable player of a Real customer. -Your perspective seems to be the Real somehow wronged Apple, even though Real didn't mess with Apple's store, music, customers...
All Real did was enable its own customers to use iPods with their software. Simple as that.
Homer: Now, here's my "Everything's O.K." alarm! [Homer flips a switch the device, and it begins to emit a high pitched, incredibly loud beep. The rest of the Simpsons cover their ears as Homer speaks up] Homer: This will sound every three seconds, unless something isn't okay! Marge: Turn it off, Homer! Homer: It can't be turned off! [alarm fizzles out] But it, uh, does break easily.
True.. I had not thought about using the key with an existing computer and website kind of deal. I was thinking more along the lines of a special-purpose device for talking to the bank directly. Not using existing insecure hardware.
But yes, a man in the middle attack could be mounted if the attacker could gain access to something that talks to the card. No doubt.
In the sense that a thief will likely move on to a car without the club, yes, it works. However, defeating the club is easy in most cases.
-Hacksaw through the steering wheel: 20 seconds on most steering wheels. -Spray freon into the locking mechanism, then hammer and screwdriver to shatter it: about 60 seconds. -Buy a "club buster" on the internet for like $100: Takes about 60 seconds to defeat any of those club-like mechanisms.
And so on... if the thief wants your car, the club ain't going to stop him, and will only slow him down marginally. If the thief is simply looking for any handy car, then the club might help.
--r3mix is way deprecated. If you're using the latest LAME, you should be using --alt-preset standard instead of --r3mix. You can use extreme or insane if you want, but it's unlikely you'll be able to ABX any actual differences between those and standard.
What I'm saying is that there will be other attacks that aren't necessarily crypto based.
Oh, I agree with that, but I can't think of any phishing attack that would work.
Your example of sending a new card to the person is no good, because you still don't gain access to their old private key which matches the bank's public key. Forget gaining access to a PIN, the mechanism I described needs no PIN's at all, it's wholly key based.
See, I have a private key, the bank, or the whole world for that matter, has my public key. By me making a message using my private key, anybody with my public key can read the message and know that I wrote it. Mainly, my bank can read the message and know that I said to give some cash to somebody from my account. You can conjure up any phishing scam you like, but unless you get a copy of my private key, you can't withdraw one dime from my account, because my bank won't give it to you unless they can verify that I said to do so.
There's other insecurities, but I was just thought-designing a way to verify, to my bank, when and who to give money to. Public-key encryption makes that pretty straightforward to do, really, and the math makes it extremely difficult to crack.
Sure there's human weaknesses. If you steal my smartcard holding my private key, then you can do whatever you like. So it breaks down to a "something you have" security. You can add on a "something you know" security by requiring a device to authenticate to the smart card before it'll encrypt a hash (there's secure protocols for this as well), but then an attacker could hack a device to get that something you know (PIN, password, whatever). There's no perfect system, but you can raise the bar high enough to eliminate the most common phishing mechanisms and the most common crimes.
Whether it's worth it or not is debatable though. It certainly would not be cheap to implement.
Anyway, the point I was making was that there's a lot of ways to shortcut in the head calculations, and the estimate method he gave had problems with it. The method I gave also has problems, just different ones.
Word on the street is that the 5 gig versions of the Seagate ST1 CF drives will be available for under $200 in a month or two. The 2.5 gig versions should be just under $100.
I guess this is cool if you want one early, as the drives have only been made available for OEM uses, but the consumer versions will be cheaper than these devices so it's not a great deal unless you're impatient.
Yes, that is a good method, but it's only good in a limited number of cases. What 72 + 137? You don't get the correct answer of 209 quite so easily, unless you estimate to 10's and 5's, or 10's and 25's. Not nearly as simple.
The method I used, but wasn't exactly taught in school, was to consider it as a quantity and move items from one to the other. In your case, I would have most likely moved 2 from 97 into the 198. Thus making a pile of 95 and a pile of 200, which is easy to add, obviously. This works for the 72+137 problem as well, albeit slightly more complicatedly: Move 3 from 137 to 72, giving 75 and 134. Now move 25 giving 100 and 109. The 109 is arrived at in the head because you're taking away 25 from 134, and that's 134 - 24 - 1 (same moving things around process as adding, but with reversed signs).
It's simpler to do in the head than it is to explain in words, because really you're thinking of piles of objects and moving them around. Think of subtractions as a hole in the ground that can hold so many, and moving that many objects from the pile into the hole. Helped me when I was learning that stuff when growing up, anyway. I believe I was 6 at the time.;)
Public key cryptography certainly raises the difficulty bar for committing fraud, but nothing will raise it so high that bad guys won't still figure out a way to run around the side.
A bit of advance thinking about this sort of thing will prevent this.
First, keep the private key in a device. Other poster suggests a smart card. I like that idea.
Phishing scam is worthless in this case. Unless they have her private key, they cannot authenticate to her *real* bank. No amount of them sending public keys or what not will change her private key. In order to get access, she has to give away her private key, and she *can't do that*, short of handing her smart card to somebody. And the smart card doesn't give out the key itself, it only signs data that you feed it. So even getting the card, duplicating it becomes a bit of a bitch.
Yes, any system can be hacked. But the most common ones can be eliminated. Public key crypto is not a magical cure all, and yes it can be worked around as well. But you can eliminate phishing scams using it, for certain. No amount of phishing will get somebody to reveal their secret private key when they don't even have the capability of doing so.
Slashdot Mirror
Laser pointers of any type have really shitty focus on them. By the time it goes 1000 feet, the beam has diverged to the point where it's not even a problem.
Point the sucker at a fence across a street, or over any distance where you can see the resulting spot. Notice how it's not exactly a pinpoint spot anymore? That's divergence of the beam. Now imagine how big that beam is over 6 miles (planes flying at around 30000 feet or so), and how little light from it is actually visible from that kind of distance.
REPEATABLE means that one should be able to start at a point and do things to DUPLICATE what is being observed.
No, in fact, that's not what it means at all. "Repeatable" means just what the other guy said it did.. That you can repeat the tests, proving their validity. If the tests are not repeatable, then you haven't accounted for all the conditions. The age-old example for this is the one about how a guy was unable to repeat the experiment in front of other people until he figured out that it made a difference what kind of material the table was made of, that he was doing the experiment on. Wood tables worked, metal tables didn't. He had not fully accounted for all the conditions and until he did, it was not repeatable and it didn't teach him anything useful.
Nobody has ever created one species out of another.
I know some biologists who work with bacterial strains that would vehemently disagree with you.
It was Q-Link or Quantum Link, run by Quantum Computer Services. Later they added PCLink and AppleLink because they were hurting for cash. PCLink and AppleLink were basically the same as Q-Link and email could even be sent between the systems. Even later than that, they combined the PCLink and AppleLink services to form a now well known system: America Online.
Yep, if you didn't know it already, Quantum Link is the direct predecesor to AOL. AOL discontinued the QLink service on November 1st, 1994.
The death blow to QLink, delivered by none other than Steve Case:
That's not to imply they can't invent new games with whatever probabilites they want, but they can't adjust existing ones.
Considering the biggest money maker is in fact the slots, and they can adjust those payoffs, I'd say you're wrong.
Table games, yes. However there's several varities of table games. I've seen roulette wheels with one zero or two. I've seen rule differences on side bets that do change the odds. I agree that the 36 to 1 is not something they mess with, but thinking that they don't change the games is foolhardy.
Check out http://wizardofodds.com to get the scoop on the various differences between the same game at different casinos. Outside of Vegas and Atlantic City, very few places have such strict regulations on gaming.
Putting aside whether my example is good or not, your answers proves the point that it's really hard to make a program that will judge well what the other player has.
Well, if we're talking building bots to play poker, then I disagree, to some extent.
First, we're really talking about online poker and that's a much smaller subset. For one thing, you can't see the other players. So your only information to go on is:
-The cards you can see (we'll assume the program has a perfect method of getting everything, either via decrypting the traffic to the client, or being a client itself, or screen scraping the client),
-The pattern of betting.
If we further assume it's a limit game with a limited number of raises and a bet pattern (meaning that you only choose whether to bet or not, not how much and so forth.. like the vast majority of online poker games out there), then the bet info can come down to a "he raised", "he didn't raise" and so forth.
The point being that the number of possible games given these limits is finite.
Now in discussing a program, every program can be boiled down to its inputs and outputs, as you probably know. From this you can build a state table. You rarely do this as it's easier to write most programs as sheer logic, but this is a simple enough concept to represent it, metaphorically, as a state table.
If you went by the odds on each as a starting point, filling the table would be rather easy to come up with. Then it's a simple lookup process. You could then refine it by hand so as to take betting patterns into account. The information you have is limited, but as I was trying to say earlier, in some circumstances it's fairly obvious.
The only thing that's difficult to program in this situation is betting history. It's difficult to program a system that can say "this guy tends to want to see the flop a lot" or "this guy raises early a lot" and then take that into account. It could be done, but the upshot here is that if you could work out an algorithim that reliably grouped people into categories like these, that's just another boolean in your state table to take into account.
Further refinements could be to notice losses and flag these table rows as being potentially wrong.. or better to keep statistical information on win/loss for each row and signal when adjustments are needed.
It's not a small undertaking, I grant you, but it's quite feasible to do with current technology. That's all I'm saying.
I'd say your reply is slightly uninformed. Casinos don't adjust the payoff of any given game. Rather, they play the odds.
Actually, you're both right. They play the odds by the method of adjusting the payoff. If the payoff ratio is higher than the ratio of winning, then it's in your favor. If the payoff ratio is lower, it's not in your favor.
Let's say you have a roulette wheel. 36 numbers, one zero, one double zero. Betting on any number wins 36 times your money back if you win. This is not in your favor because the actual odds of winning are 38 to 1. If the payoff was 40 to 1, then you'd win more than you lose, on average.
Basically we're talking about expected payoff here.. Expected payoff = (amount you win) / (odds you win). If the expected payoff is greater than 1, then it's in your favor, if it's less, it's in the houses favor. For most games, the casino can't control the odds. But they can control the payoff, and that's what they use to make the number less than 1. Simple.
Most good players will consider that the opponent might have AA since he reraised you preflop and would adjust their strategy accordingly.
Either that or he has AK and you get the same basic setup, except now he has 2P to your 3OAK and you take him for everything he'll bet on.
If I had AA I doubt I'd raise somebody preflop. Might scare 'em off. Somebody raising me preflop might be trying to do the same. What if the guy had K5 and was simply trying to bluff it through, then got lucky on the flop and is playing for everything he's got, hoping like hell that I don't have AK?
Short answer to all this is that if I had KK down and AK5 on the flop, damn right I'm going for it. Unless another A shows up on the table, at which point I might wonder more.
1) Long dial in times result in the 2nd password changing before completion, thus requiring a 2nd attempt (or a 9th, depending on how pathetic the phone service is)
Assuming you have some wacky setup that asks for the password before connection and not after you have already connected... then all SecureID based systems have a server running the same math as your little ID is and the server can, and does, calculate the previous and the next numbers the device will display. So even if the password takes 20 seconds to get there and it has changed in the meantime, it'll still authenticate, because the server is aware of the previous and next passwords.
2) Annoying easily lost dongle on your keychain that says "RSA- STEAL ME" in big bold letters...
I've been using these things for years and have yet to lose one. Of course, I never lose my keys either. If I lose my keys, I'd be more concerned about how to start my car than my account's security.
That's exactly why a metaverse like in Snow Crash will never happen. Hackers are much to interested in getting things done and saving resources for other, cooler things than 3D graphical interfaces. Typing in a command line is harder to learn than mousing around, but faster and provides better control. The same could be applied to online interaction.
:)
I don't quite agree with this one. If it were possible to build the metaverse from SnowCrash, rest assured that it would happen, and hackers would make it happen. Why? Because personal presence is a much faster means of communication than typing or IMing or what have you.
Well, that and they'd be able to hang out in the bar all day while still claiming to be at work.
Geeks with no social life get to put on pretend bodies and roam around an artifical universe? You can bet your ass it'd happen. But the tech ain't up to it yet.
The recent "Let It Be ... Naked" CD has some sort of copy protection on it that, under XP at least, it wont play except through a piece of software the CD installs for you.
1. Never install the software on the disc. This is critical, as sometimes they install drivers that intentionally mess with ripping operations. If you have installed it, remove it.
2. Use ExactAudioCopy to rip the disc. Sometimes you have to use the Advanced functionality it offers to be able to read the disc.
In this particular case, EAC will read the disc fine if you enable Actions -> TOC Alterations -> Detect TOC Manually. One of the tracks will be a data track which you can ignore, the rest of the tracks will be audio, which should rip fine (if you remove the malware that the disc may install on your machine).
If that was their only business, then you'd be exactly right. I'd have no reason to accuse them of bullying. They're doing it, just like Apple is, only in other arenas. Why shouldn't Apple do to Real's stranglehold on Helix DRM what Real has done to Apple's stranglehold on FairPlay? Did that make sense?
No, not really.
-Given: that Real is producing Helix DRM software and licensing it to others for building into hardware and so forth. I see that now.
-Assume: Apple created some kind of compatible product that could also produce Helix DRM'd look alikes that worked in this hardware.
Result: Yeah, they're comparable. So what? My bet would be that Real would say "Why didn't you license it from us instead?" because they are actively licensing the stuff out. Apple would not and has not actively licensed FairPlay out to anybody. Big difference, it seems to me.
Breaking it all down:
Jumpdrive contains some form of software to perform the decryption of the encrypted data. It claims to use AES, so let's assume it does.
The right way to do this would be to make the user have the AES key. AES keys are a bit big to carry around though, so the second right way to do this would be to store the AES key on the drive in an encrypted form itself. This is quite common and usually called the keyring.
The keyring is encrypted with some symmetric cipher that uses a simple passphrase for decryption. DES used to be pretty common, but most people like Blowfish nowadays. Whatever, this is unimportant. What's important is the process at work:
A. Enter passphrase.
B. Passphrase decrypts keyring.
C. Key from keyring decrypts data.
This is generally considered secure enough because if the keyring is made right, then you can't usually be sure whether or not you guessed the right passphrase without actually attempting the data decryption itself. The key is a pretty random set of bits, in other words, and looking at it after decryption is usually not enough to be able to tell whether or not you sucessfully guessed the keyring's passphrase. This makes the attack computationally hard in that they still have a wide variety of keys to test.
What these morons appear to have done is to stored the passphrase to the keyring itself on the frickin' drive, XOR'd with some constant that's in the program. The reason for this is to make it more obvious when you enter the wrong passphrase. So their program does this:
1. Retrieves the XOR'd passphrase from disk.
2. XOR's it with the constant, leaving the damn password in memory in *plaintext*.
3. Compares the password to what you typed in (strcmp, probably), and spits out a "wrong password" message when it doesn't match.
4. Does A,B,C as listed above if the password was correct.
A slightly less dumb thing to do would have been to store a hash of the passphrase on the disk, then hashed the passphrase and compared the two hashes. This is only slightly less dumb though, because it still provides a shortcut to breaking the decryption, as you can do a dictionary attack on the hash, which is much faster than doing a dictionary attack where you must perform two actual decryptions on every possible passphrase.
But having the passphrase in memory in plaintext is just frickin' inexcusable from a security standpoint. Having, essentially, every single little thing that you need to decrypt the thing on the disk is even worse:
-The static XOR block is in the software, on the disk.
-The XOR'd password is on the disk.
-The keyring decrypted by the password is on the disk.
-The data encrypted by the key is on the disk.
I mean... that's just plain bad.
First, global warming means the atmosphere has more energy than before, which means the wind blows harder, which means that if you could slow down the wind, you're removing some of the energy, which means you may lessen the severity of weather patterns.
Okay, so you extract energy from the atmosphere, convert it to electricity, and then convert the vast majority of that into heat... which puts the energy right back into the atmosphere.
That was the point the parent was making. Extracting energy from the atmosphere only to put nearly all of it back in doesn't really change anything as far as that goes.
CO2: Yes, that's a possible difference maker. Pulling energy out of the wind is not.
Real is producing files that can be played on iPods while maintaining DRM. I am proposing that Apple could produce files that can be played in RealPlayer while maintaining DRM.
.rm broadcasts on the websites for NPR or the BBC. Lots of people use that. Apple could make money the same way Real does in this market, selling software for producing DRMed .rm files.
.rm files.
.rm file format closed and proprietary. Just like Apple wronged consumers by keeping FairPlay closed.
RealPlayer already supports playback of iTunes M4P format, assuming you have iTunes installed and are authorized to play the music.
You seem to misunderstand. I am proposing that Apple could make Safari & Quicktime work perfectly with... the
1. The BBC/NPR broadcasts have no DRM on them, that I'm aware of. At least, I was able to load up a program to rip the stream easily, last time I checked. It's been a while, I grant you.
2. I was not aware Real sold any software to produce DRMed
That is exactly not my perspective. I don't think Real has done anything wrong by allowing their customers to use iPods. I think Real has wronged consumers (a little tiny bit) by keeping their
Last I checked, they had dumped the RM format for the most part and are moving towards AAC. At least, their Harmony player produces AAC by default. The downloaded material from their music store is 192 kbit AAC, albeit in an odd container format.
So now Real says Apple is being a bully, while they attempt to maintain a business model 100% based on bullying.
How is selling music to customers who then listen to it bullying?
When I say "Why shouldn't Apple do this?" Rob's honest answer might be "Because we would sue them, file a DMCA complaint, and do our best to smear them as hackers in the media." (Because Real can't break compatibility like Apple via an iTunes update. Their software is deployed.)
Or his answer might be "What in the hell are you talking about? Apple can't do this to Real because it makes very little sense."
If you mean "What if Apple started producing RM files" then my answer is simply that Real is starting to distance themselves from the RM format because it's a losing horse. Real might posture a bit about it, but they've already dumped it where it counts. Real is in the AAC business now.
Actually, I guess it's my fault for not framing the question more restrictively. But I didn't ask whether he'd like to cross-license with Apple. We all know the answer to that question. I'm not talking about whether he'd like to see that kind of interoperability. I'm asking what he'd do if Apple reverse-engineered Real's product like Real did to Apple. Because I want him to say, "Nothing. That's ok." If he can say that, he'd win a point or two with me. But he can't say it.
The problem here is that the two cases are not comparable in the least.
-Real produces a file that is similar in structure to Apple's DRM format in order to put songs onto an iPod without totally decrypting them.
-Apple would produce a file that is similar in structure to Real's format or Real's Helix DRM in order to... do what, exactly? That's right, nothing. There's absolutely no reason for Apple to do what Real did.
Real made a method whereby Real's own music could be put onto an iPod without decrypting it. They did this by emulating Apple's DRM. They didn't break Apple's DRM. Their software does nothing to Apple's Music files.
Apple doesn't have the same problem. Nothing plays Real's Helix format music at the moment, which is why Real can convert their music to Apple DRM, Microsoft DRM (in the form of a protected WMA), etc. Apple doesn't even *support* portable players that are not a form of iPod, and thus have less than no reason to reciprocate in this manner.
The reason he answered the way he did is simply that you and he have two different perspectives.
-His perspective is that Real wrote Real's own software in a way that would take Real's own music and put it on the portable player of a Real customer.
-Your perspective seems to be the Real somehow wronged Apple, even though Real didn't mess with Apple's store, music, customers...
All Real did was enable its own customers to use iPods with their software. Simple as that.
Homer: Now, here's my "Everything's O.K." alarm! [Homer flips a switch the device, and it begins to emit a high pitched, incredibly loud beep. The rest of the Simpsons cover their ears as Homer speaks up]
Homer: This will sound every three seconds, unless something isn't okay!
Marge: Turn it off, Homer!
Homer: It can't be turned off! [alarm fizzles out] But it, uh, does break easily.
http://www.snpp.com/episodes/5F21
True.. I had not thought about using the key with an existing computer and website kind of deal. I was thinking more along the lines of a special-purpose device for talking to the bank directly. Not using existing insecure hardware.
But yes, a man in the middle attack could be mounted if the attacker could gain access to something that talks to the card. No doubt.
In the sense that a thief will likely move on to a car without the club, yes, it works. However, defeating the club is easy in most cases.
-Hacksaw through the steering wheel: 20 seconds on most steering wheels.
-Spray freon into the locking mechanism, then hammer and screwdriver to shatter it: about 60 seconds.
-Buy a "club buster" on the internet for like $100: Takes about 60 seconds to defeat any of those club-like mechanisms.
And so on... if the thief wants your car, the club ain't going to stop him, and will only slow him down marginally. If the thief is simply looking for any handy car, then the club might help.
--r3mix is way deprecated. If you're using the latest LAME, you should be using --alt-preset standard instead of --r3mix. You can use extreme or insane if you want, but it's unlikely you'll be able to ABX any actual differences between those and standard.
What I'm saying is that there will be other attacks that aren't necessarily crypto based.
Oh, I agree with that, but I can't think of any phishing attack that would work.
Your example of sending a new card to the person is no good, because you still don't gain access to their old private key which matches the bank's public key. Forget gaining access to a PIN, the mechanism I described needs no PIN's at all, it's wholly key based.
See, I have a private key, the bank, or the whole world for that matter, has my public key. By me making a message using my private key, anybody with my public key can read the message and know that I wrote it. Mainly, my bank can read the message and know that I said to give some cash to somebody from my account. You can conjure up any phishing scam you like, but unless you get a copy of my private key, you can't withdraw one dime from my account, because my bank won't give it to you unless they can verify that I said to do so.
There's other insecurities, but I was just thought-designing a way to verify, to my bank, when and who to give money to. Public-key encryption makes that pretty straightforward to do, really, and the math makes it extremely difficult to crack.
Sure there's human weaknesses. If you steal my smartcard holding my private key, then you can do whatever you like. So it breaks down to a "something you have" security. You can add on a "something you know" security by requiring a device to authenticate to the smart card before it'll encrypt a hash (there's secure protocols for this as well), but then an attacker could hack a device to get that something you know (PIN, password, whatever). There's no perfect system, but you can raise the bar high enough to eliminate the most common phishing mechanisms and the most common crimes.
Whether it's worth it or not is debatable though. It certainly would not be cheap to implement.
Okay, so I picked a bad example. :)
Anyway, the point I was making was that there's a lot of ways to shortcut in the head calculations, and the estimate method he gave had problems with it. The method I gave also has problems, just different ones.
Word on the street is that the 5 gig versions of the Seagate ST1 CF drives will be available for under $200 in a month or two. The 2.5 gig versions should be just under $100.
I guess this is cool if you want one early, as the drives have only been made available for OEM uses, but the consumer versions will be cheaper than these devices so it's not a great deal unless you're impatient.
Yes, that is a good method, but it's only good in a limited number of cases. What 72 + 137? You don't get the correct answer of 209 quite so easily, unless you estimate to 10's and 5's, or 10's and 25's. Not nearly as simple.
;)
The method I used, but wasn't exactly taught in school, was to consider it as a quantity and move items from one to the other. In your case, I would have most likely moved 2 from 97 into the 198. Thus making a pile of 95 and a pile of 200, which is easy to add, obviously. This works for the 72+137 problem as well, albeit slightly more complicatedly: Move 3 from 137 to 72, giving 75 and 134. Now move 25 giving 100 and 109. The 109 is arrived at in the head because you're taking away 25 from 134, and that's 134 - 24 - 1 (same moving things around process as adding, but with reversed signs).
It's simpler to do in the head than it is to explain in words, because really you're thinking of piles of objects and moving them around. Think of subtractions as a hole in the ground that can hold so many, and moving that many objects from the pile into the hole. Helped me when I was learning that stuff when growing up, anyway. I believe I was 6 at the time.
Correct me if I'm wrong but nobody owns the works of Mozart.
You're right, however the works of Mozart need to be performed. And those performances are owned by the people who performed them.
Public key cryptography certainly raises the difficulty bar for committing fraud, but nothing will raise it so high that bad guys won't still figure out a way to run around the side.
A bit of advance thinking about this sort of thing will prevent this.
First, keep the private key in a device. Other poster suggests a smart card. I like that idea.
Phishing scam is worthless in this case. Unless they have her private key, they cannot authenticate to her *real* bank. No amount of them sending public keys or what not will change her private key. In order to get access, she has to give away her private key, and she *can't do that*, short of handing her smart card to somebody. And the smart card doesn't give out the key itself, it only signs data that you feed it. So even getting the card, duplicating it becomes a bit of a bitch.
Yes, any system can be hacked. But the most common ones can be eliminated. Public key crypto is not a magical cure all, and yes it can be worked around as well. But you can eliminate phishing scams using it, for certain. No amount of phishing will get somebody to reveal their secret private key when they don't even have the capability of doing so.