How about a trackball (or even a mouse) and a PC: write a program that translates cursor movement to sound; move the cursor even a little, the program makes a noise or plays a.WAV file, at a sufficient volume.
May need to account for tremours or other vibration, but should be straightforward...
The first step is "Rocket Skydiving" -- simple, catapult launched giant water rockets that can take a load of skydivers to 15,000 feet in under a minute. This would be safer than airplanes.
I guess it would. I can't imagine taking a load of airplanes to 15,000 feet in under a minute.
I have to type softly, so he won't hear me...a swarthy bearded man wearing a turban broke into my bedroom and threatened me with a boxcutter if I didn't use my computer to launch a DOS attack against the Pentagon, in the name of Allah...I don't know what he'll do if he finds out I don't have an Internet connection...
"Its designers hope the plane may one day be used to monitor the climate or volcanic eruptions."
Huh? Does Japan have little teeeny volcanos?
Exactly how does an aluminum foil origami project, launched with less energy than a finger flick, somehow scale into a volcano exploration vehicle?
"Well, first, see, you climb up to very lip of the erupting volcano -- look out for the boiling lava! and the huge flying boulders!...and then you fold up this tin foil, right, into an airplane -- remember to bend the tip of the nose in, you don't want to poke somebody's eye out! and now I'll hold it very still, while you aim the laser at it...you DID bring the laser, didn't you? Ahhhh DAMN DAMN DAMN!"
Protegrity (www.protegrity.com) has a drop-in solution that works with most big-name databases. It provides a more mature key management system -- enterprise-wide -- on a separate box; much better than a grow-your-own solution. I haven't implemented it in production, but I've looked into it pretty closely. Works with most applications with a relatively small performance impact. EXCEPT.
EXCEPT for those databases which require the primary key (i.e. card number) to be encrypted. This means queries like "where CARD_NO = xxxxxxxx" must decode every single CARD_NO in the database looking for a match. Forget performance. Protegrity has a work-around for that particular query -- I believe they can now encrypt the CARD_NO field in the query before executing the SQL -- but it won't help for range lookups, i.e. "where CARD_NO between 1234500000 and 1234699999" (this is a useful kind of query for card issuers; it allows them to separate gold card accounts from the riff-raff, for example).
The proper approach -- which usually can't be retrofitted -- is to replace CARD_NO with three fields. The first is a hash of CARD_NO -- this is used for all lookups. The second is the encrypted CARD_NO, and the third is the field you show on reports and customer support screens, something like "*****6051"
It will be interesting to see if this Grand Unified Theory of Linux will follow the same pattern as the Grand Unified Theory of Unix.
In the early 90's (IIRC) all of the Unix vendors hopped on the Standard Unix bandwagon to take on the incumbent business OS's from (primarily) IBM and Digital Equipment. Remember IEEE 1003 and X/Open? Every vendor was claiming that Unix was Unix was Unix and a switch to Unix was a vote for interoperability and isn't that what made [insert your particular country] great? Ken Olsen, president of Digital Equipment, was derided for calling this claim "snake oil".
The strategy worked, and the various Unices gained market share. However, the game was mostly hype, for the simple reason that no vendor WANTS to be interchangable with another; it makes marketing hard. Every business survives by differentiating itself from the competition; in the Unix market, every vendor added proprietary bells and whistles to their "standard Unix" in order to stand out from the crowd. Once a customer acquired a tasted for a vendor's unique flavour, they were still as locked-in as if they had chosen VMS, or MVS.
With United Linux I see the same trend. IBM and HP will embrace United Linux, and promptly add proprietary features to lock in customers. It's the only way you can make a buck with Linux. They're doing it already with Red Hat, but it's harder, because RH already is a standard of sorts, and has a momentum of its own. United Linux is driven by a committee. Committees can be influenced just in the same way as a plain girl who wants to be popular can be pursuaded to do things she really shouldn't.
Maybe it's just me, but this makes me a little nervous that when the "Open Content Network" gets too popular and dragged down in litigation, the "Open Source" folks are going to find themselves tarred with the same brush; guilty by association. Not what's needed at this juncture.
You know, technology policies like biotech -- you only -- if your universities are doing work that can be commercialized, you will have IT jobs in your country. And if they are not, then fine, just say that farming is your thing, or whatever it is. All the taxes will be paid by those guys or something -- I don't know. And the farmers will go home at night and work on the source code -- SNAKES! SNAKES! GET AWAY! STOP LOOKING AT ME! ALL OF YOU! STOP IT! STOP LOOKING!
[At this point, Mr. Gates was carried from the stage. He is resting comfortably at Betty Ford Clinic.]
"...The odds of a collision are currently 1 in 10 million and could become even more remote with more refined calculations."
Well, what are we waiting for? For God's sake, people, let's get calculating! And be refined about it -- hold your pencil with your pinkie finger up, or something...
If we all get together, surely we can calculate the odds right down to zero!
So they're not going to detect the original, but they WILL detect any hacker-modified clones?
What about Norton Firewall? Will it still detect unexpected outgoing connections? How can I expect it to reliably detect and permit FBI-approved software, but not hacker software with a similar MO?
Oh, maybe there'll be a hard-coded IP address in the outgoing connection -- now THERE'S a nice target for DDOS!
...and i understand that for years, pornographers and other criminals and have been using the mails, hiding their wicked messages from the righteous by using ENVELOPES.
...HDCP also allows supports a master lists of devices not to work with (a.k.a. Key Device Revocation). For example if the APEX of the HDTV recording world is unleashed the content provider can instruct your HDTV tuner not to send it any content.
Who says this hypothetical APEX box has to identify itself correctly? What if you could configure it to masquerade as a law-abiding device? Download valid device id's off the 'net?
That's not such a big jump from configuring your CSS zone on your DVD player.
Okay, probably not perfect, but:
a) I (using my computer) place a telephone call to a local trusted third-party service
b) the third-pary service sends me a timestamp encrypted with their private key
c) my computer encrypts their timestamp with my own private key and sends it back
d) the third party service returns a token containing the twice-encrypted timestamp and my phone number (obtained from caller ID), encrypted using their private key; refuses to handle calls from non-local or mobile phones (based on knowing local telephone exchanges)
e) I send this token in a message to Big Brother; he decrypts the token using the third-party's public key and my public key. Voila! proof that I (or at least my private key) was at a specific phone (and so, presumably, at a particular address) at a specific time.
Drawbacks:
a) spoofing caller-ID; I have no idea what's possible here.
b) you know where my computer was, but not necessarily where I was. I can't see any way of linking my physical presence to the computer's location that doesn't involve trusting me. But you know at least that it's not someone pretending to be me.
Slashdot Mirror
May need to account for tremours or other vibration, but should be straightforward...
I didn't realize I was botehring anybody. I'll stop now.
I guess it would. I can't imagine taking a load of airplanes to 15,000 feet in under a minute.
I showed him how to sign up for AOL. He's harmless now...
I have to type softly, so he won't hear me...a swarthy bearded man wearing a turban broke into my bedroom and threatened me with a boxcutter if I didn't use my computer to launch a DOS attack against the Pentagon, in the name of Allah...I don't know what he'll do if he finds out I don't have an Internet connection...
Huh? Does Japan have little teeeny volcanos?
Exactly how does an aluminum foil origami project, launched with less energy than a finger flick, somehow scale into a volcano exploration vehicle?
Guess who's become the latest poster child for password escrow?
Protegrity (www.protegrity.com) has a drop-in solution that works with most big-name databases. It provides a more mature key management system -- enterprise-wide -- on a separate box; much better than a grow-your-own solution. I haven't implemented it in production, but I've looked into it pretty closely. Works with most applications with a relatively small performance impact. EXCEPT.
EXCEPT for those databases which require the primary key (i.e. card number) to be encrypted. This means queries like "where CARD_NO = xxxxxxxx" must decode every single CARD_NO in the database looking for a match. Forget performance. Protegrity has a work-around for that particular query -- I believe they can now encrypt the CARD_NO field in the query before executing the SQL -- but it won't help for range lookups, i.e. "where CARD_NO between 1234500000 and 1234699999" (this is a useful kind of query for card issuers; it allows them to separate gold card accounts from the riff-raff, for example).
The proper approach -- which usually can't be retrofitted -- is to replace CARD_NO with three fields. The first is a hash of CARD_NO -- this is used for all lookups. The second is the encrypted CARD_NO, and the third is the field you show on reports and customer support screens, something like "*****6051"
It will be interesting to see if this Grand Unified Theory of Linux will follow the same pattern as the Grand Unified Theory of Unix.
In the early 90's (IIRC) all of the Unix vendors hopped on the Standard Unix bandwagon to take on the incumbent business OS's from (primarily) IBM and Digital Equipment. Remember IEEE 1003 and X/Open? Every vendor was claiming that Unix was Unix was Unix and a switch to Unix was a vote for interoperability and isn't that what made [insert your particular country] great? Ken Olsen, president of Digital Equipment, was derided for calling this claim "snake oil".
The strategy worked, and the various Unices gained market share. However, the game was mostly hype, for the simple reason that no vendor WANTS to be interchangable with another; it makes marketing hard. Every business survives by differentiating itself from the competition; in the Unix market, every vendor added proprietary bells and whistles to their "standard Unix" in order to stand out from the crowd. Once a customer acquired a tasted for a vendor's unique flavour, they were still as locked-in as if they had chosen VMS, or MVS.
With United Linux I see the same trend. IBM and HP will embrace United Linux, and promptly add proprietary features to lock in customers. It's the only way you can make a buck with Linux. They're doing it already with Red Hat, but it's harder, because RH already is a standard of sorts, and has a momentum of its own. United Linux is driven by a committee. Committees can be influenced just in the same way as a plain girl who wants to be popular can be pursuaded to do things she really shouldn't.
Oh my god...are you telling me that any lunatic with a marker could take my shiny coasters and make them play CELINE DION????
For heaven's sake people, please, think of the children! STOP THE MADNESS!
lather...rinse...repeat
Maybe it's just me, but this makes me a little nervous that when the "Open Content Network" gets too popular and dragged down in litigation, the "Open Source" folks are going to find themselves tarred with the same brush; guilty by association. Not what's needed at this juncture.
Progress marches on! Better living through science!
Oh, wait, The web site finally came up...
Never mind...
Well, what are we waiting for? For God's sake, people, let's get calculating! And be refined about it -- hold your pencil with your pinkie finger up, or something...
If we all get together, surely we can calculate the odds right down to zero!
...because it stayed up after being posted on slashdot.
/. effect.
Any legit company would have succumbed to the
just to produce urine?
what, like there's a urine shortage?
Here's what Visa recommends to merchants:
Internet [firewall] web server [firewall] app server [firewall] database server
...and the database must be encrypted.
Check out a company called Protegrity; they offer drop-in encryption for many vendor's databases.
So they're not going to detect the original, but they WILL detect any hacker-modified clones?
What about Norton Firewall? Will it still detect unexpected outgoing connections? How can I expect it to reliably detect and permit FBI-approved software, but not hacker software with a similar MO?
Oh, maybe there'll be a hard-coded IP address in the outgoing connection -- now THERE'S a nice target for DDOS!
Who says this hypothetical APEX box has to identify itself correctly? What if you could configure it to masquerade as a law-abiding device? Download valid device id's off the 'net?
That's not such a big jump from configuring your CSS zone on your DVD player.
a) I (using my computer) place a telephone call to a local trusted third-party service
b) the third-pary service sends me a timestamp encrypted with their private key
c) my computer encrypts their timestamp with my own private key and sends it back
d) the third party service returns a token containing the twice-encrypted timestamp and my phone number (obtained from caller ID), encrypted using their private key; refuses to handle calls from non-local or mobile phones (based on knowing local telephone exchanges)
e) I send this token in a message to Big Brother; he decrypts the token using the third-party's public key and my public key. Voila! proof that I (or at least my private key) was at a specific phone (and so, presumably, at a particular address) at a specific time.
Drawbacks:
a) spoofing caller-ID; I have no idea what's possible here.
b) you know where my computer was, but not necessarily where I was. I can't see any way of linking my physical presence to the computer's location that doesn't involve trusting me. But you know at least that it's not someone pretending to be me.