they are already hardware keyloggers that you plug in between the keyboard and computer. Why not a keytyper? If you have a video tape of a 10 character password, it would take any human less than 10 minutes to get the exact rhythm of the typing (down to the resolution of the camera's frame rate). After that, it's just a matter of writing a simple script. You could even have fun making it 'accidentally' hit the wrong keys.
yes, these are optimal conditions for the hacker, but not unrealistic. Think of university labs.
Personally, I'm happy with the 100% accurate or nothing system. Do you really want somebody to video tape your typing and then easily get in to your account? I know with a video tape, even though some keys might be hidden, they'll eventually get in... but the system you're suggesting would let them in immediately.
Wouldn't it depend on how it's built? If it's got sensors that tell it where its point of contact are, then it should be pretty simple to keep at least two loops around the horizontal pole.
Maybe I'm completely off, but that's how I'd do it.
Passing the ACID2 Test doesn't imply standard compliance. It just means the browsers implement a certain subset of the standards correctly (or effectively correctly).
The ACID3 test won't be a test for standards compliance either. The way I see it it's just a tool to motivate developers to work TOWARDS standards compliance.
The ACID3 test should, therefore, not be seen as a new set of standards. It's just a different subset of standards.
OK, well assume all scripting and all security is taken care of by the same group. The underlying idea is that no one person or group is responsible for everything. This should ensure that nobody works beyond their abilities.
I haven't developed commercially in a while, but it was my understanding that for these larger sites the job would be split up. One group is in charge of layout. Another group is in charge of content (graphics, sounds, text). Another one or two groups is in charge of client/server side scripting. Another group is in charge of security. And a final group is in charge of putting everything together.
Finally, everything is audited before it goes live.
Of course, a group might be able to accomplish one or more of these tasks, but not requiring one group to accomplish ALL the tasks ensures the abilities of the developers aren't stretched too thin.
Well, look at it this way: Technology has changed a lot since 1990. The final product expected is now much more complicated than can be easily produced with C++.
That's why we have HTML to structure webpages, CSS to enhance the visuals, JavaScript to improve functionality, etc... With C++, every webpage would need to compile. These abstractions aren't only for the developers, they're also for practicality.
Oh, and have you ever used C++ to communicate with a database via SQL? It's not exactly very flexible.
yes it will. Or it does for me. Even if the computer is alone on the router. It seems my router occasionally broadcasts something and wakes up all my computers.
I've switched to using the magic packet alternative. The only problem is that since my server PC is behind my router, I have to SSH into the router and sent the magic packet from there. ICKY.
I hear other routers (mine is a Linksys WRT54GS) will let you WOL remotely. Normally, you just send your magic packet to the router and set up the router to convert it to a broadcast.
If I remember correctly, a magic packet is just a packet with the correct header and the client's MAC address broadcast to the network.
Yes, it is a source of advertisement nuisances, BUT, onunload can be used for MUCH more. I've been asked to develop application (Web Applications specifically) for use on intranets and MANY of these applications require a pop-window to validate information (or modify parent window forms). I can't rely that everybody here (especially management!) is smart enough to click on "update" or "submit," so I have to have the updated values submitted on unload. Works like a CHARM in all browsers but Opera. In Opera I had to implement a "watcher" that checked if the child window was still open at regular intervals. If the watcher can't find the child, then it submits copies of the child window's variables to the parent window. To make this work I had to have EVERY variable copy over to the watcher EVERY time it was modified. That is not elegant.
I think major compatibility issues always have to do with the very basic ways the different browsers handle javascript and event. A GREAT example is if you ever have to write somecode for when a page unloads. It'll work fine in IE, Safari, and Firefox, but good luck getting it to work on Opera. I spent hours trying to figure out why onunload didn't work on Opera... apparently it's a "feature!"
Anyway, whenever I've had problems with script compatibility it's ALWAYS been with event hooks, and with very basic interpretation differences in javascript between browsers. And let me tell you, getting these scripts to work is a LOT more than 5 minutes per browsers. Sometimes you'll need to write an extra 200 lines of script just to get the same feature in all browsers.
Slashdot Mirror
D is part of a Metroid. The rest was probably eaten by 7 (Because, remember, 7 8 9!!)
bogus.
they are already hardware keyloggers that you plug in between the keyboard and computer. Why not a keytyper?
If you have a video tape of a 10 character password, it would take any human less than 10 minutes to get the exact rhythm of the typing (down to the resolution of the camera's frame rate).
After that, it's just a matter of writing a simple script. You could even have fun making it 'accidentally' hit the wrong keys.
yes, these are optimal conditions for the hacker, but not unrealistic. Think of university labs.
Personally, I'm happy with the 100% accurate or nothing system.
Do you really want somebody to video tape your typing and then easily get in to your account?
I know with a video tape, even though some keys might be hidden, they'll eventually get in... but the system you're suggesting would let them in immediately.
Wouldn't it depend on how it's built?
If it's got sensors that tell it where its point of contact are, then it should be pretty simple to keep at least two loops around the horizontal pole.
Maybe I'm completely off, but that's how I'd do it.
oh yeah, and like you mentioned, there is no pdf. Sorry if I made it seem like there might be one.
A little bit of javascript reading gave me this link.
http://software.newsstand.com/bookrdr/live/Reader.swf?pguid=6527212571398720&isbn=9780060558123
I was looking for a PDF I could download but this is as far as I could get.
Enjoy!
But what about your karma?
Did anyone else see this under "Games," read "64" and automatically assume it was Nintendo related?
Yes, I know I'm pissing my Karma away posting this.
Passing the ACID2 Test doesn't imply standard compliance. It just means the browsers implement a certain subset of the standards correctly (or effectively correctly).
The ACID3 test won't be a test for standards compliance either. The way I see it it's just a tool to motivate developers to work TOWARDS standards compliance.
The ACID3 test should, therefore, not be seen as a new set of standards. It's just a different subset of standards.
OK, well assume all scripting and all security is taken care of by the same group.
The underlying idea is that no one person or group is responsible for everything. This should ensure that nobody works beyond their abilities.
I haven't developed commercially in a while, but it was my understanding that for these larger sites the job would be split up.
One group is in charge of layout.
Another group is in charge of content (graphics, sounds, text).
Another one or two groups is in charge of client/server side scripting.
Another group is in charge of security.
And a final group is in charge of putting everything together.
Finally, everything is audited before it goes live.
Of course, a group might be able to accomplish one or more of these tasks, but not requiring one group to accomplish ALL the tasks ensures the abilities of the developers aren't stretched too thin.
Well, look at it this way: Technology has changed a lot since 1990. The final product expected is now much more complicated than can be easily produced with C++.
That's why we have HTML to structure webpages, CSS to enhance the visuals, JavaScript to improve functionality, etc...
With C++, every webpage would need to compile. These abstractions aren't only for the developers, they're also for practicality.
Oh, and have you ever used C++ to communicate with a database via SQL? It's not exactly very flexible.
Parent's links are viruses.
I'm on windows w/ firefox, noscript, and avast!.
Avast! caught it before the page even loaded.
The target page tried to infect me with a virus.
Don't follow parent's links.
If this patch is reusable it could become the method of choice for heroin addicts.
On the other hand, it would be much safer than using needles.
You can't really share these, I assume.
They, for many, welcome our new robot overlords.
I'm interested in where you get this information. I have a feeling you have an incomplete game list.
Ba-doom PSHHH!
yes it will.
Or it does for me. Even if the computer is alone on the router. It seems my router occasionally broadcasts something and wakes up all my computers.
I've switched to using the magic packet alternative. The only problem is that since my server PC is behind my router, I have to SSH into the router and sent the magic packet from there. ICKY.
I hear other routers (mine is a Linksys WRT54GS) will let you WOL remotely. Normally, you just send your magic packet to the router and set up the router to convert it to a broadcast.
If I remember correctly, a magic packet is just a packet with the correct header and the client's MAC address broadcast to the network.
Come on. Come oooooooooooon!!
Please?
Opera is the only browser their old computers can handle. Surprising, isn't it?
Yes, it is a source of advertisement nuisances, BUT, onunload can be used for MUCH more. I've been asked to develop application (Web Applications specifically) for use on intranets and MANY of these applications require a pop-window to validate information (or modify parent window forms). I can't rely that everybody here (especially management!) is smart enough to click on "update" or "submit," so I have to have the updated values submitted on unload. Works like a CHARM in all browsers but Opera. In Opera I had to implement a "watcher" that checked if the child window was still open at regular intervals. If the watcher can't find the child, then it submits copies of the child window's variables to the parent window. To make this work I had to have EVERY variable copy over to the watcher EVERY time it was modified. That is not elegant.
I think major compatibility issues always have to do with the very basic ways the different browsers handle javascript and event. A GREAT example is if you ever have to write somecode for when a page unloads. It'll work fine in IE, Safari, and Firefox, but good luck getting it to work on Opera. I spent hours trying to figure out why onunload didn't work on Opera... apparently it's a "feature!"
Anyway, whenever I've had problems with script compatibility it's ALWAYS been with event hooks, and with very basic interpretation differences in javascript between browsers. And let me tell you, getting these scripts to work is a LOT more than 5 minutes per browsers. Sometimes you'll need to write an extra 200 lines of script just to get the same feature in all browsers.
It's not as simple as you made it seem.
I wish I had mod points!
+1 Funny