The author says the device actually cools his room.
I know a freezer is generating some heat on its own, and moving heat from inside the freezer box to outside the freezer.
So heat is leaving the freezer, and the freezer is getting colder.
I also know that the author's device is warming water, and the warmed water is being moved from inside the room to outside the room.
So heat is leaving the room, and the room is getting colder.
In a freezer, heat is moved from inside the freezer (inside the room) to outside the freezer (inside the room). Net change to room temperature is the heat generated by the freezer, and little else.
In the author's device, heat is moved from inside the room to outside the room. Net change to room temperature is significant.
+5 moderated poster's viewpoint:
The device doesn't actually work.
The device is a perpetual motion machine.
Can you see why we're laughing? Can you see why you should go back and re-evaluate your assumptions?
From what I've read, the spyware has to actually be installed and call home for people to get credit.
So what you're describing can still be done, but it's trickier.
First, get VMware, a vulnerable copy of Windows, VNC, and a VNC record/playback program like rfbproxy.
Install a vulnerable version of Windows onto a VMware machine, with at least host-only networking. Install VNC with *no password*. Shut down the virtual machine. Change the virtual machine's disk to an undoable disk. While you're at it, change VMware's settings so VMware runs at low priority. Restart the virtual machine and boot Windows again.
When the VM is booted and ready, but still has never connected to the Internet, pause the VM and quit VMware.
Copy the VM's directory to a backup location.
Open VMware again, and resume the paused VM. Connect a VNC client through rfbproxy to your VM. Using VNC (which is now recording your interactions) use the VM to connect to the target web site and trigger installation of spyware. Once your system has calmed down, such that it's likely the spyware installation is done, disconnect VNC. rfbproxy has made a recording of your VNC session, which you can play back from the command line.
Now we're ready to set up the loop. Here are the loop steps:
Copy your VM backup over top of the VM's normal directory. This will return the VM to its "just-booted, never been connected to the net" state.
Use a VMware command line to immediately load and resume that VM. Note the VMware PID somewhere.
After a delay, run an rfbproxy command line which connects to the VMware machine over VNC and plays back your mouse/keyboard inputs.
***while you're waiting, the VMware machine is being infected with the same spyware, one more time***
After a much longer delay, kill the VMware PID you stored earlier.
End loop.
It seems like this attack could be easily defeated if the people running this program just filter out non-unique IPs. Adapting these steps to connect to a dynamic-IP dialup account is an exercise left for the reader.:-)
If this isn't a slashvertisement, you don't know what is?
I know what is. An story announcing a Dell laptop for x hundred dollars off if you order this month is a slashvertisement. Especially since discounts aren't news for nerds, and Dell laptops don't usually have new technology which is news for nerds.
A story announcing new low web hosting rates from a certain company is a slashvertisement. No new technology there, just lower prices which are not news for nerds.
Do you see the difference? To me, a message isn't commercial just because it discusses a commercial product. If most of the people who read a message will just file it away for later, thinking "hmm, that's werid", and very few people who read a message are actually likely to be in the market for what the message is describing, I don't think it's a slashvertisement.
For example, I'm just filing this away for later. Weird monitor design. If some months down the road, some coworker muses about some futuristic dual-LCD design, which he could make a ton of money building and selling, I'll remember this story and email him a link. Neither of us are going to buy one, though.
So this is news for nerds, not a slashvertisement.
(I work for a major credit card processor, First National Merchant Solutions. We represent businesses on the other side of these kinds of disputes -- we process cards for merchants, and we must *answer* chargebacks like this one.)
I'm a little confused by whether this is a Visa/Mastercard issue or a debit network issue. Debit networks (Interlink, Maestro, AFFN, Shazam, Cash Station, Tyme, Star, Mac, NYCE, Pulse, Accel, Honor, etc.) require both the card and the pin number be present at the point of sale, so if these were Internet merchants then these are not debit sales.
(If someone else has more information about debit cards, please reply. We are trained to believe that these debit networks are only available card-present with pin. If that's wrong -- if people can take debit network account numbers over the Internet -- cards which are not also Visa/Mastercard/Discover/AMEX/JCB/International Diners/Novus etc. -- please let me know.)
So in the absence of more information, I would say because the transaction is over the Internet, and the original poster seemed to indicate it was also a debit card, it's probably been processed either as a Visa or a Mastercard.
If that's true, here's the flow of events:
1) Customer notices a fraudulent charge. They notify their bank, and their bank issues a chargeback with a reason code of something like M85 (Fraudulent Transaction - No Cardholder Authorization) 2) Along with the chargeback, the bank who issued the customer's card sends a debit to the merchant's processor (a company like us). So in accordance with the rules, the bank now has the customer's money back in their hands. 3) The bank provisionally credits those funds to the customer. This isn't risky (in case the customer was lying) because if regulations say the bank must pay the merchant back, the bank is responsible for collecting those funds from the customer. (So if the customer closes their account and flees to Mexico or something, the bank still has to pay.) 4) The merchant's processor (again, a company like us) usually then bills the merchant the amount of the chargeback, and notifies them that a chargeback has been filed against them. The merchant then has some time (30 days? 45 days?) to prepare their case, and submit documentation defending their charge. 5a) If the merchant doesn't respond, or the documentation they provide is obviously faulty ("But this gentleman from Nigeria sounded so honest!"), no response is sent. The time to respond to the chargeback case expires, and the bank (and customer) get to keep the money. STOP 5b) If the merchant does respond, with documentation which proves the charge really was authorized, the merchants processor (a company like us) sends the documentation back to the bank, along with a debit which takes money back from the bank and gives it back to the merchant. 6) The customer's bank now has documentation which explains both sides of the story. I don't know what really goes on here, but I assume the bank consults with the customer and tries to get more information from them. The bank is then given some time (30 days? 45 days?) to respond back. 7a) If the customer sees the documentation and says "oops, sorry, I guess I did authorize that one, never mind" then the bank just doesn't respond, and the chargeback drops. STOP 7b) If the bank talks to the customer and finds out the charge really *is* unauthorized, the bank debits money *again*, and things go back to the merchant for the last time. 8) The merchant's processor consults with the merchant, and they decide what they want to do. If the merchant wants to dispute the bank's second decision: 9a) If the charge is a Visa, that second chargeback is actually a "pre-arbitration notice", where the bank is stating that they're prepared to go to Visa for a (costly) independent arbitration. They're *sure* they're right. If the merchant (and their processor) are also *sure* they're right, and no agreement can be reached, the case goes to arbitrati
(I work for a credit card processor, First National Merchant Solutions.)
This is not evidence that credit card signatures are useless. These were card-not-present sales, so in each case the merchant was responsible for their own fraud protection. Credit card signatures are useless for consumers, because they're protected from fraud. (Chargeback rights) Credit card signatures are useful for merchants.
So this whole thing makes about as much sense as: "radar guns useless, agree speeders." They benefit the people you are buying stuff from. They don't benefit you.
Why not also claim that this is more evidence that retinal scans are useless? Why not also claim that this is more evidence that smartcard readers are useless? Those fraud protection systems are unrelated to card-not-present sales, just as signature verification is unrelated to card-not-present sales.
(Modding parent down as offtopic for the above reasons might be a good idea.)
Luckily for the general public, neither Visa nor MasterCard rely on the unqualified opinions of slashdot posters when deciding on changes to their operating regulations. Keep signing your signature panels, and keep signing your sales drafts on card-present sales. Signatures are useful for merchants, not useful for you.
Where did this idea come from? We all know that some merchants don't care about fraud protection, so when they fail to protect themselves they get chargebacks, and either they learn or they stop taking Visa/MC. Where did we get the idea that people needed to become experts before they could tell if a signature matched another signature? Signatures have been used on legal documents for how long now? Where did we get the idea that just because some merchants don't use the fraud protection tools we give them, that those tools are useless and should be removed?
Why aren't you using the same poor logic to conclude that password security is useless, because some users write their passwords on post-it notes? Why aren't you telling me where your network is, when you do come to that conclusion?:-)
--Michael Spencer First National Merchant Solutions 1620 West Dodge, Omaha, Nebraska 68197 Mail stop 3270
He's right -- this is a difficult task. If you're really sure you want to head this project yourself, though, here's some tips.
(This comes from a recent C/S grad with development experience and five semesters of Japanese.)
I'm assuming you have no Japanese language experience of your own. Maybe you have some experience with their culture. I imagine you will be given access to bilingual folks, who will help you understand their application well enough to Americanize it.
First, remember that Japan and the US have very different ways of thinking. There's a good reason Japanese is a difficult language for us western folk to learn -- just learning to convert one set of concept-words to another set of concept-words isn't sufficient, if the concepts are different.
In practice, this means you need to drag your translation help (kicking and screaming) through the process of translating situations, translating use-cases, not just translating words into different words. Be sure you understand the program's design nearly well enough that you could build it yourself. Ask your translators to spell out what the reader should be thinking when they read something, or what the reader will probably want to do when they read something.
(I work for a credit card processor, First National Merchant Solutions.)
It's not always so easy, though. Overall you're right, but as a result of the recent lawsuit settlement (Wal Mart v Visa Check / Mastermoney -- see http://www.inrevisacheck-mastermoneyantitrustlitig ation.com/press.php3 ) merchants now have a choice. When a customer presents a card which can be used both as online (pin-based) debit and as offline debit (Visa/Mastercard), they are allowed to ask the customer to use one or the other. This is good for merchants, because for sales higher than a certain amount (usually $20 to $30) debit network (flat) fees are much cheaper than Visa/Mastercard fees (interchange / assessments / discount, a percentage of the sale amount). So merchants get to save money by requiring one instead of the other.
Your advice still stands, though. Pin-based debit sales have no chargeback rights but require no signature. Visa/Mastercard sales do have chargeback rights, but require signature verification.
--Michael Spencer
(and yes, I laughed out loud when I saw that URL the first time, too.)
(I work for a credit card processor, First National Merchant Solutions.) I've never heard 'bearer instrument' or 'owner instrument' used in my industry at all. They may have some legal meaning, but that would only apply in a courtroom, not in any sort of chargeback dispute under Visa/Mastercard regulations.
To Visa/Mastercard, what matters is *account owner authorization*. Did the owner of the card authorize someone to initiate that sale? If you've ever initiated a chargeback on a fraudulent transaction, some banks have you sign a declaration that states neither you nor anyone authorized by you initiated that sale.
In card-present sales, if the card was swiped and the signature matches, and the card hasn't yet been reported as lost (which would cause any authorization attempts to decline), the sale was probably authorized by the cardholder. Once the card is reported lost, no new sales are going to approve anyway.
Checking IDs and signatures absolutely does protect merchants against claims of fraud. I have seen this protection work -- I have seen merchants have proceeds from sales given back to them after a chargeback, because they were able to provide a copy of a matching customer signature.
I work for First National Merchant Solutions (but you don't seem to be our customer -- that's OK, I'll help anyone:-) ). Wait until you get a retrieval request or a chargeback. THAT is when you need those stored sales drafts. Just because it hasn't happened to you yet doesn't mean it's a useless business practice.
Visa/Mastercard give customers the right to request sales drafts. They usually charge for that (something like $10.00 per sale). You would then get a sales draft request in the mail. You must provide your processing company with a copy of that signed sales draft, so the processing company can pass that information along to the card issuing bank (using this formal chargeback case notification process).
If you don't respond to that chargeback, the issuing bank is allowed to issue a chargeback for "requested information not provided". Even if you did everything correctly during the sale, just because you threw the sales draft out after 3 months and the customer requested a sales draft copy, the customer would be allowed to get their money back through Visa/Mastercard. You would then have to call the customer and get another form of payment, or take them to court.
(Call your own processor's customer service department and confirm this if you'd like.)
I know it's annoying keeping those tupperware tubs of sales drafts around the office, but the alternative is less protection against chargeback-related customer fraud. I'd say it's worth it, but it's your business.
I work for First National Merchant Solutions (a credit card processor -- we represent merchants / businesses to the Visa/Mastercard payment transfer organizations), and I hate to just rest on my credentials. I'll do it just this once.
That is NOT all it's there for. You're explicitly stating you have looked at *all possible* reasons for requiring a signature, and that is the only one. You're wrong -- you haven't looked at all possible reasons, and you've definitely missed at least one.
"That's ALL it's there for" is wrong. "That's one of the things it's there for" is correct.
I can't give out any of my documents, but Google for Visa CISP. Requirements are different (less or more strict, compliance required sooner versus later) for different sizes and types of merchants, but Visa is going to start requiring stricter security measures, and backing that requirement up with fines for noncompliance.
This is a Big Hairy Deal for merchant processors (like the company I work for), who provide credit card acceptance services for merchants.
While your technical points may or may not be correct (I haven no idea), I think you (and that other poster who talks about an attacker getting a merchant account) are missing the point about the threat model here.
I'm just a terminal technical support rep for existing credit card terminals, so I can't comment on technology I haven't seen yet. Maybe someone else in my company (First National Merchant Solutions) is looking at this technology, but I'm not. So any opinions expressed in this post are my own, and may or may not belong to my company. (I say this up front because it looks like there are other people in my industry in this thread, and I want to be sure I'm not claiming expertise I don't actually have.)
Remember, Visa cares about the difference between card-present and card-not-present sales. So there are two different threat models here:
Threat one: an attacker sniffs wireless traffic (or uses their own reader to interrogate a card), creates a substitute card, and presents that card in *card present* sales, tricking merchants into thinking they are that other customer.
Threat two: an attacker sniffs wireless traffic (or uses their own reader to interrogate a card) and uses that account information to submit *card not present* sales to MOTO (mail order / telephone order) or ecommerce merchants.
I think that one-time non-reusable code they were talking about only protects customers against threat one, because the article didn't explicitly say card numbers are kept secret from merchants. That protection is important, because if the customer's bank thinks the customer's card was present at the point of sale, and the customer didn't report their card lost or stolen (or a new one, compromised, maybe?) until days later, they might expect that customer to pay for the attacker's purchases. (Or the bank might just write the charges off, which increases their costs and forces them to raise rates on other things.)
I think we missed talking about whether this system will keep card numbers out of attackers' hands. If someone can take a card reader (which does its own valid challenge/response with the card) and learn card details (like card number, expiration date, and other data), they don't need their own merchant account to use those card details in traditional ways.
Remember, thieves don't need their own merchant accounts to abuse card numbers. This is "traditional" credit card fraud: the thief tricks a merchant into shipping merchandise or performing services for them, not knowing that they won't be able to keep the money from that fraudulent credit card sale. MOTO merchants are supposed to use "best practices" fraud protection to guard against this, but there are *many* gullible or lazy merchants out there.
(You can imagine my frustration in talking to some of these guys: to them, this is just additional hoops to make their valued customers jump through, and they're afraid of losing business. See, when a thief gets turned away by all these fraud protection checks, saying "fine, I'll take my business somewhere else", the merchant can't tell the difference between a thief they just thwarted or a picky customer they just frustrated into going somewhere else.)
I remember where the article talked about that one-time-only code passed between the issuing bank and the card, but I don't remember the article saying that system keeps the card number secret from the merchant. With this system, instead of using a card reader to send transaction information to Visa, a thief uses a card reader to send transaction information to a text file.
I'd like to add to what you said. I work for a major credit card processor (First National Merchant Solutions), and according to Visa/Mastercard regulations, any of these full-retail-price charges could be charged back.
Merchants are not allowed to use Visa/Mastercard for collections purposes. They can't charge you "punitive fines" without your approval and authorization.
Here's an example: suppose you stay at a hotel. You agree to pay for your room stay, but while you're there you get drunk and trash the place, causing $500 in damages. You leave before anyone notices the damage, so nobody had a chance to bill you.
The hotel owner decides to bill your Visa card for the amount of the damages. While it may be true that you owe the hotel owner $500, you never gave the hote owner permission to take that $500 from your Visa card. Because of that you can talk to your bank, tell them you didn't authorize the charge, and get the money back. (You can then go to jail for whatever crime you committed, or write a check for that same amount of money...but we're just talking about Visa/Mastercard's world here.)
In this case, Blockbuster will try to argue that your signature on the rental agreement authorizes them to charge your card. For *this particular sale* though, when you left the store you understood you would be charged only a rental fee. I believe whatever authorization you gave on your contract doesn't actually protect them as much as they think it will.
So if you charge back one of these charges from Blockbuster, you aren't saying "I don't really owe Blockbuster money", you're actually saying "I might or might not owe Blockbuster money, but either way, they do not have the right to take that money from my Visa/Mastercard account. Ask me to write a check or pay cash instead."
If they bill you the cost of a game ($50.00), that costs them at least 75 cents in credit card processing fees, probably more. So they *have* to charge some kind of restocking fee, or else that "gentle reminder" when they charge your card will *cost* them money when you return the game.
Above all else, though, keep this in mind: if someone charges your card for punitive damages or fines/fees you did not specifically agree to, you can file for a chargeback. Talk to your issuing bank.
Understand the difference though: "You owe me $500 for tearing up your hotel room. Pay me now or I'm calling the police." --> "OK, fine, charge my card." -- in this case there was authorization, so no chargeback.
Hope this helps!
The opinions in this post are my own, and may or may not also reflect the opinions of my employer, First National Merchant Solutions. I did not actually have the phone-book-sized Visa/Mastercard regulations manuals in front of me when writing this, so I might be wrong. The "hotel" example came straight from our chargeback department, though, so I'm *very* sure the theory behind this post is correct. This is not banking advice -- your situation may vary, so talk to your own banker for situation-specific banking advice.
--Michael Spencer Stop Code 3270 First National Merchant Solutions 1620 West Dodge Omaha, NE 68197
You're thinking of Direct Copyright Infringement. He's not guilty of that.
You're forgetting there also exists Contributory Copyright Infringement and Vicarious Copyright Infringement. He's guilty of at least Vicarious Copyright Infringement, if he knew what content he was linking to and if he was showing ad banners to visitors. (And if he had the right-and-ability-to-control what was on the web page, and I assume he did.)
There's a problem with that: RTC v. Netcom. (see Netcom, 907 F. Supp. 1361 (ND Cal 1995))
If someone can create a filesharing system where traffic is routed from one node to another, and when a node routes it hides the identities of the parties it communicates with, then filesharing becomes safe again.
Just as in RTC v. Netcom, where the Religious Technology Center (a.k.a. Scientology) attempted to sue Netcom (and was denied), automated acts of routing on a filesharing network will probably be found NOT to be contributory copyright infringement.
In other words, if your network is arranged like this:
Client <----> Server
then either side can turn in the other side, as the parent post described. However, if your network is arranged like this:
Client <--> Node 1 <--> Node 2 <--> Server
then unless someone controls all of the systems in a particular communication path, they can't learn the identity of all of the nodes they don't control.
(See an earlier article, at http://slashdot.org/article.pl?sid=01/08/10/204922 5 )
One of the problems with this kind of routing system is fair division of labor. For this kind of P2P system to work (where your client must route data that it didn't actually request) the system must be designed well enough to distribute a burden of anonymous-routing to your client which corresponds with the amount of anonymous-routing load you're placing on the rest of the network. But how can people measure how much data you're sending and receiving, if they can't know who you are?
I don't have a solution for that problem, but it's not unsolvable.
So the question then becomes, will the general public begin to prefer a filesharing system that must transfer 400 MB of data over the network for every 100 MB of information it saves to disk, if that system is nearly impossible to audit or prosecute?
I would never do anything like this in real life, but it would be possible for me to somehow strap a laser pointer onto my camcorder. I would then need to stand my tripod up securely and calibrate it, so the laser points at the exact middle of the image. I could do this by just pointing the whole thing at a wall, zooming in, and then fine-tuning the laser aim until it shows in the middle of my viewfinder. I could then do the same thing for a distant object, like the wall of a house several blocks away, and fine-tune the laser aim even more until the point was in the middle of the viewfinder.
Keep in mind the whole point of a fluid tripod head is to give the operator fine pressure-sensitive control of where the camera is pointing. There are no rubber pads pushed up against metal, seizing the metal and making fine movement impossible. Fluid heads use oil cartridges and tension knobs that let you tighten or loosen, but never completely lock, the horizontal or vertical movement. If you zoom a camera way in, tighten the tension knobs, and just lay one finger on the tripod pan handle, you can see the camera v-e-r-y s-l-o-w-l-y tracking. To an outside observer you can't even tell the camera is moving, but the viewfinder shows the camera is not only moving, but it's moving smoothly at a constant rate.
While someone with my rig could just barely track a fast-moving aircraft from far away, they *could* do it.
I've studied Japanese for five semesters, and I used Slime Forest Adventure to learn katakana. http://www.lrnj.com It's designed to work kinda like an old NES-style RPG (very Dragon Warrior-esque), but of course you aren't here for the gameplay. I believe it's binary-only but for Win32, Linux, and Mac OS X.
It's extremely effective. For me personally, it taught me katakana in about 5 days, whereas it took me two weeks of classroom study to learn hiragana (same 46 characters, just shaped different, like the difference between our capital and lower-case letters.)
Sorry Kjella, we're going to have to arrest you for assisting in the trafficking of *VeryBadThing*.
Someone took a phrase from your post ("somesuch like that even though they didn't know kjella" after stripping out formatting), passed it through a text-to-binary deobfuscator (which you OBVIOUSLY must have used...all the pirates have known about it since 2007, and you ARE a pirate, aren't you?), looked that code up on a well-known pirate web site (which you OBVIOUSLY...erm, yeah, insert lame intimidation attempt here), and used it to find a.torrent for *VeryBadThing*.
Shame on you.
OK, not really, but you get the idea. Your defense here is obvious: you had no possible way of knowing some random text could be used in this way. Maybe you received a DMCA notice asking you to remove those words from the end of your post, but you can't do that.
Only giving away the odd bytes is still transferring copyrighted material, so that's Direct Copyright Infringement. There are already laws which cover that.
They will sue them using 17 USC 501. Google for Vicarious Copyright Infringement and Contributory Coypright Infringement.
Contributory copyright infringement requires that the MPAA can prove there is reasonable expectation of knowledge of infringement (they can see filenames) and there is material contribution to the act of infringement (they're a tracker). Someone has to be guilty of direct infringement for contributory copyright infringement to be possible (so a dead torrent, where everyone's at 0% and nobody knows where the seed is, can't make anyone guilty of direct or contributory copyright infringement.)
Vicarious copyright infringement requires also that direct infringement happens somewhere, but also that there's some financial or material gain (pay from ad impressions) and some right or ability to supervise (ability to delete torrents, ability to block torrents at the tracker).
So yeah, once again the index service (like Napster's central servers) is vulnerable. We need to split up the file descriptions from the method of transfer. There are many ways to do this, but here's the first one that comes to mind: site A publishes information that 8BC288EF.torrent contains Return of the King, and site B is a tracker for 8BC288EF.torrent without knowing what it is. Site A then blocks (firewall, policy, etc) sites like site B from accessing it. Site B therefore has no way of knowing what it's hosting. They still must respond to takedown notices, but if they are responsive they don't have to worry about contributory or vicarious copyright infringement.
This may be because to generate that power one would have to slow the mouse down to do it. Your mouse would no-longer glide effortlessly across a smooth mouse pad, but instead would feel as if it was moving through molasses.
Experiment 1: Put one finger on top of your mouse, push down hard, and then use the rest of your fingers to grasp the mouse and move it around. It still moves, but how much would your wrist hurt after doing that for 8 hours?
Experiment 2: Connect a hand-crank generator to a variable resistor and voltmeter, so you can measure the power output from the crank. Attach a mouse to the crank of the generator, and establish a slow crank rate that gives you 0.8 volts on the voltmeter. Orient the mouse so it's horizontal, so its movement is similar to how you move a mouse on a mouse pad. Now slowly increase resistance to around 61.5 ohms, which gives you 13 mA consumption. (Your resistor will only be eating about 10 miliwatts, so the resistor should barely even get warm.) Now keep moving the mouse like that for about 10 minutes. What does your forearm feel like?
Don't cheat and use your whole arm, or change your hand position to something more suited to turning a crank. You're moving a mouse around, not cranking a survival flashlight or radio.
Excellent post, but it raises a couple of questions.
First, is it *bad* for our visual system to be pulsing at CRT refresh rates? What does that do to the body, both good and bad?
Second, how does the impact of a flickering CRT compare with that of the fluorescent lights already found in many homes and businesses? Will replacing a CRT with an LCD make any significant difference if the room you're in is already lit with fluorescent lighting?
Thanks again for the excellent post, and for looking at these followup questions...
It's a shame that some of us draw conclusions about the entire Gentoo userbase from the actions of a few annoying people.
It sure is fun to mock those annoying people though.:-) I was in this Data Structures class, and one of my classmates was one of the bad kind of Gentoo user. I had already heard him lure people into distro arguments. He was excessively pushy about Gentoo once he found out someone was a non-Gentoo-using Linux user. He asked me one day which distribution of Linux I use. I told him I don't much care which distribution it is -- the kernel is Linux, the web server is Apache -- the system is already installed, and I'm not adding or removing anything, so it doesn't matter which distribution it is. It's Linux.
I don't suppose people who buy Sharp laptops have to get all their software from Sharp too, do they? Do all Dell laptop owners buy all their software and games from Dell?
Sharp will honor their warranty. That's all they need to do. You can get all kinds of software for this device from other sources, as long as you have the hardware.
--Michael Spencer (An SL-C700 owner, considering buying this SL-C300)
Slashdot Mirror
My viewpoint:
The author says the device actually cools his room.
I know a freezer is generating some heat on its own, and moving heat from inside the freezer box to outside the freezer.
So heat is leaving the freezer, and the freezer is getting colder.
I also know that the author's device is warming water, and the warmed water is being moved from inside the room to outside the room.
So heat is leaving the room, and the room is getting colder.
In a freezer, heat is moved from inside the freezer (inside the room) to outside the freezer (inside the room). Net change to room temperature is the heat generated by the freezer, and little else.
In the author's device, heat is moved from inside the room to outside the room. Net change to room temperature is significant.
+5 moderated poster's viewpoint:
The device doesn't actually work.
The device is a perpetual motion machine.
Can you see why we're laughing? Can you see why you should go back and re-evaluate your assumptions?
And then THAT heat ends up out the door in a garden or drain.
:-)
Oops, forgot about that part, didn't you?
From what I've read, the spyware has to actually be installed and call home for people to get credit.
:-)
So what you're describing can still be done, but it's trickier.
First, get VMware, a vulnerable copy of Windows, VNC, and a VNC record/playback program like rfbproxy.
Install a vulnerable version of Windows onto a VMware machine, with at least host-only networking. Install VNC with *no password*. Shut down the virtual machine. Change the virtual machine's disk to an undoable disk. While you're at it, change VMware's settings so VMware runs at low priority. Restart the virtual machine and boot Windows again.
When the VM is booted and ready, but still has never connected to the Internet, pause the VM and quit VMware.
Copy the VM's directory to a backup location.
Open VMware again, and resume the paused VM. Connect a VNC client through rfbproxy to your VM. Using VNC (which is now recording your interactions) use the VM to connect to the target web site and trigger installation of spyware. Once your system has calmed down, such that it's likely the spyware installation is done, disconnect VNC. rfbproxy has made a recording of your VNC session, which you can play back from the command line.
Now we're ready to set up the loop. Here are the loop steps:
Copy your VM backup over top of the VM's normal directory. This will return the VM to its "just-booted, never been connected to the net" state.
Use a VMware command line to immediately load and resume that VM. Note the VMware PID somewhere.
After a delay, run an rfbproxy command line which connects to the VMware machine over VNC and plays back your mouse/keyboard inputs.
***while you're waiting, the VMware machine is being infected with the same spyware, one more time***
After a much longer delay, kill the VMware PID you stored earlier.
End loop.
It seems like this attack could be easily defeated if the people running this program just filter out non-unique IPs. Adapting these steps to connect to a dynamic-IP dialup account is an exercise left for the reader.
What do you think? Not evil enough?
If this isn't a slashvertisement, you don't know what is?
I know what is. An story announcing a Dell laptop for x hundred dollars off if you order this month is a slashvertisement. Especially since discounts aren't news for nerds, and Dell laptops don't usually have new technology which is news for nerds.
A story announcing new low web hosting rates from a certain company is a slashvertisement. No new technology there, just lower prices which are not news for nerds.
Do you see the difference? To me, a message isn't commercial just because it discusses a commercial product. If most of the people who read a message will just file it away for later, thinking "hmm, that's werid", and very few people who read a message are actually likely to be in the market for what the message is describing, I don't think it's a slashvertisement.
For example, I'm just filing this away for later. Weird monitor design. If some months down the road, some coworker muses about some futuristic dual-LCD design, which he could make a ton of money building and selling, I'll remember this story and email him a link. Neither of us are going to buy one, though.
So this is news for nerds, not a slashvertisement.
Make sense?
(I work for a major credit card processor, First National Merchant Solutions. We represent businesses on the other side of these kinds of disputes -- we process cards for merchants, and we must *answer* chargebacks like this one.)
I'm a little confused by whether this is a Visa/Mastercard issue or a debit network issue. Debit networks (Interlink, Maestro, AFFN, Shazam, Cash Station, Tyme, Star, Mac, NYCE, Pulse, Accel, Honor, etc.) require both the card and the pin number be present at the point of sale, so if these were Internet merchants then these are not debit sales.
(If someone else has more information about debit cards, please reply. We are trained to believe that these debit networks are only available card-present with pin. If that's wrong -- if people can take debit network account numbers over the Internet -- cards which are not also Visa/Mastercard/Discover/AMEX/JCB/International Diners/Novus etc. -- please let me know.)
So in the absence of more information, I would say because the transaction is over the Internet, and the original poster seemed to indicate it was also a debit card, it's probably been processed either as a Visa or a Mastercard.
If that's true, here's the flow of events:
1) Customer notices a fraudulent charge. They notify their bank, and their bank issues a chargeback with a reason code of something like M85 (Fraudulent Transaction - No Cardholder Authorization)
2) Along with the chargeback, the bank who issued the customer's card sends a debit to the merchant's processor (a company like us). So in accordance with the rules, the bank now has the customer's money back in their hands.
3) The bank provisionally credits those funds to the customer. This isn't risky (in case the customer was lying) because if regulations say the bank must pay the merchant back, the bank is responsible for collecting those funds from the customer. (So if the customer closes their account and flees to Mexico or something, the bank still has to pay.)
4) The merchant's processor (again, a company like us) usually then bills the merchant the amount of the chargeback, and notifies them that a chargeback has been filed against them. The merchant then has some time (30 days? 45 days?) to prepare their case, and submit documentation defending their charge.
5a) If the merchant doesn't respond, or the documentation they provide is obviously faulty ("But this gentleman from Nigeria sounded so honest!"), no response is sent. The time to respond to the chargeback case expires, and the bank (and customer) get to keep the money. STOP
5b) If the merchant does respond, with documentation which proves the charge really was authorized, the merchants processor (a company like us) sends the documentation back to the bank, along with a debit which takes money back from the bank and gives it back to the merchant.
6) The customer's bank now has documentation which explains both sides of the story. I don't know what really goes on here, but I assume the bank consults with the customer and tries to get more information from them. The bank is then given some time (30 days? 45 days?) to respond back.
7a) If the customer sees the documentation and says "oops, sorry, I guess I did authorize that one, never mind" then the bank just doesn't respond, and the chargeback drops. STOP
7b) If the bank talks to the customer and finds out the charge really *is* unauthorized, the bank debits money *again*, and things go back to the merchant for the last time.
8) The merchant's processor consults with the merchant, and they decide what they want to do. If the merchant wants to dispute the bank's second decision:
9a) If the charge is a Visa, that second chargeback is actually a "pre-arbitration notice", where the bank is stating that they're prepared to go to Visa for a (costly) independent arbitration. They're *sure* they're right. If the merchant (and their processor) are also *sure* they're right, and no agreement can be reached, the case goes to arbitrati
(I work for a credit card processor, First National Merchant Solutions.)
:-)
This is not evidence that credit card signatures are useless. These were card-not-present sales, so in each case the merchant was responsible for their own fraud protection. Credit card signatures are useless for consumers, because they're protected from fraud. (Chargeback rights) Credit card signatures are useful for merchants.
So this whole thing makes about as much sense as: "radar guns useless, agree speeders." They benefit the people you are buying stuff from. They don't benefit you.
Why not also claim that this is more evidence that retinal scans are useless? Why not also claim that this is more evidence that smartcard readers are useless? Those fraud protection systems are unrelated to card-not-present sales, just as signature verification is unrelated to card-not-present sales.
(Modding parent down as offtopic for the above reasons might be a good idea.)
Luckily for the general public, neither Visa nor MasterCard rely on the unqualified opinions of slashdot posters when deciding on changes to their operating regulations. Keep signing your signature panels, and keep signing your sales drafts on card-present sales. Signatures are useful for merchants, not useful for you.
Where did this idea come from? We all know that some merchants don't care about fraud protection, so when they fail to protect themselves they get chargebacks, and either they learn or they stop taking Visa/MC. Where did we get the idea that people needed to become experts before they could tell if a signature matched another signature? Signatures have been used on legal documents for how long now? Where did we get the idea that just because some merchants don't use the fraud protection tools we give them, that those tools are useless and should be removed?
Why aren't you using the same poor logic to conclude that password security is useless, because some users write their passwords on post-it notes? Why aren't you telling me where your network is, when you do come to that conclusion?
--Michael Spencer
First National Merchant Solutions
1620 West Dodge, Omaha, Nebraska 68197
Mail stop 3270
He's right -- this is a difficult task. If you're really sure you want to head this project yourself, though, here's some tips.
(This comes from a recent C/S grad with development experience and five semesters of Japanese.)
I'm assuming you have no Japanese language experience of your own. Maybe you have some experience with their culture. I imagine you will be given access to bilingual folks, who will help you understand their application well enough to Americanize it.
First, remember that Japan and the US have very different ways of thinking. There's a good reason Japanese is a difficult language for us western folk to learn -- just learning to convert one set of concept-words to another set of concept-words isn't sufficient, if the concepts are different.
In practice, this means you need to drag your translation help (kicking and screaming) through the process of translating situations, translating use-cases, not just translating words into different words. Be sure you understand the program's design nearly well enough that you could build it yourself. Ask your translators to spell out what the reader should be thinking when they read something, or what the reader will probably want to do when they read something.
Hope this helps!
--Michael Spencer
(I work for a credit card processor, First National Merchant Solutions.)
g ation.com/press.php3 ) merchants now have a choice. When a customer presents a card which can be used both as online (pin-based) debit and as offline debit (Visa/Mastercard), they are allowed to ask the customer to use one or the other. This is good for merchants, because for sales higher than a certain amount (usually $20 to $30) debit network (flat) fees are much cheaper than Visa/Mastercard fees (interchange / assessments / discount, a percentage of the sale amount). So merchants get to save money by requiring one instead of the other.
It's not always so easy, though. Overall you're right, but as a result of the recent lawsuit settlement (Wal Mart v Visa Check / Mastermoney -- see http://www.inrevisacheck-mastermoneyantitrustliti
Your advice still stands, though. Pin-based debit sales have no chargeback rights but require no signature. Visa/Mastercard sales do have chargeback rights, but require signature verification.
--Michael Spencer
(and yes, I laughed out loud when I saw that URL the first time, too.)
(I work for a credit card processor, First National Merchant Solutions.) I've never heard 'bearer instrument' or 'owner instrument' used in my industry at all. They may have some legal meaning, but that would only apply in a courtroom, not in any sort of chargeback dispute under Visa/Mastercard regulations.
To Visa/Mastercard, what matters is *account owner authorization*. Did the owner of the card authorize someone to initiate that sale? If you've ever initiated a chargeback on a fraudulent transaction, some banks have you sign a declaration that states neither you nor anyone authorized by you initiated that sale.
In card-present sales, if the card was swiped and the signature matches, and the card hasn't yet been reported as lost (which would cause any authorization attempts to decline), the sale was probably authorized by the cardholder. Once the card is reported lost, no new sales are going to approve anyway.
Checking IDs and signatures absolutely does protect merchants against claims of fraud. I have seen this protection work -- I have seen merchants have proceeds from sales given back to them after a chargeback, because they were able to provide a copy of a matching customer signature.
I work for First National Merchant Solutions (but you don't seem to be our customer -- that's OK, I'll help anyone :-) ). Wait until you get a retrieval request or a chargeback. THAT is when you need those stored sales drafts. Just because it hasn't happened to you yet doesn't mean it's a useless business practice.
Visa/Mastercard give customers the right to request sales drafts. They usually charge for that (something like $10.00 per sale). You would then get a sales draft request in the mail. You must provide your processing company with a copy of that signed sales draft, so the processing company can pass that information along to the card issuing bank (using this formal chargeback case notification process).
If you don't respond to that chargeback, the issuing bank is allowed to issue a chargeback for "requested information not provided". Even if you did everything correctly during the sale, just because you threw the sales draft out after 3 months and the customer requested a sales draft copy, the customer would be allowed to get their money back through Visa/Mastercard. You would then have to call the customer and get another form of payment, or take them to court.
(Call your own processor's customer service department and confirm this if you'd like.)
I know it's annoying keeping those tupperware tubs of sales drafts around the office, but the alternative is less protection against chargeback-related customer fraud. I'd say it's worth it, but it's your business.
--Michael Spencer
I work for First National Merchant Solutions (a credit card processor -- we represent merchants / businesses to the Visa/Mastercard payment transfer organizations), and I hate to just rest on my credentials. I'll do it just this once.
That is NOT all it's there for. You're explicitly stating you have looked at *all possible* reasons for requiring a signature, and that is the only one. You're wrong -- you haven't looked at all possible reasons, and you've definitely missed at least one.
"That's ALL it's there for" is wrong. "That's one of the things it's there for" is correct.
I can't give out any of my documents, but Google for Visa CISP. Requirements are different (less or more strict, compliance required sooner versus later) for different sizes and types of merchants, but Visa is going to start requiring stricter security measures, and backing that requirement up with fines for noncompliance.
This is a Big Hairy Deal for merchant processors (like the company I work for), who provide credit card acceptance services for merchants.
While your technical points may or may not be correct (I haven no idea), I think you (and that other poster who talks about an attacker getting a merchant account) are missing the point about the threat model here.
I'm just a terminal technical support rep for existing credit card terminals, so I can't comment on technology I haven't seen yet. Maybe someone else in my company (First National Merchant Solutions) is looking at this technology, but I'm not. So any opinions expressed in this post are my own, and may or may not belong to my company. (I say this up front because it looks like there are other people in my industry in this thread, and I want to be sure I'm not claiming expertise I don't actually have.)
Remember, Visa cares about the difference between card-present and card-not-present sales. So there are two different threat models here:
Threat one: an attacker sniffs wireless traffic (or uses their own reader to interrogate a card), creates a substitute card, and presents that card in *card present* sales, tricking merchants into thinking they are that other customer.
Threat two: an attacker sniffs wireless traffic (or uses their own reader to interrogate a card) and uses that account information to submit *card not present* sales to MOTO (mail order / telephone order) or ecommerce merchants.
I think that one-time non-reusable code they were talking about only protects customers against threat one, because the article didn't explicitly say card numbers are kept secret from merchants. That protection is important, because if the customer's bank thinks the customer's card was present at the point of sale, and the customer didn't report their card lost or stolen (or a new one, compromised, maybe?) until days later, they might expect that customer to pay for the attacker's purchases. (Or the bank might just write the charges off, which increases their costs and forces them to raise rates on other things.)
I think we missed talking about whether this system will keep card numbers out of attackers' hands. If someone can take a card reader (which does its own valid challenge/response with the card) and learn card details (like card number, expiration date, and other data), they don't need their own merchant account to use those card details in traditional ways.
Remember, thieves don't need their own merchant accounts to abuse card numbers. This is "traditional" credit card fraud: the thief tricks a merchant into shipping merchandise or performing services for them, not knowing that they won't be able to keep the money from that fraudulent credit card sale. MOTO merchants are supposed to use "best practices" fraud protection to guard against this, but there are *many* gullible or lazy merchants out there.
(You can imagine my frustration in talking to some of these guys: to them, this is just additional hoops to make their valued customers jump through, and they're afraid of losing business. See, when a thief gets turned away by all these fraud protection checks, saying "fine, I'll take my business somewhere else", the merchant can't tell the difference between a thief they just thwarted or a picky customer they just frustrated into going somewhere else.)
I remember where the article talked about that one-time-only code passed between the issuing bank and the card, but I don't remember the article saying that system keeps the card number secret from the merchant. With this system, instead of using a card reader to send transaction information to Visa, a thief uses a card reader to send transaction information to a text file.
--Michael Spencer
I'd like to add to what you said. I work for a major credit card processor (First National Merchant Solutions), and according to Visa/Mastercard regulations, any of these full-retail-price charges could be charged back.
Merchants are not allowed to use Visa/Mastercard for collections purposes. They can't charge you "punitive fines" without your approval and authorization.
Here's an example: suppose you stay at a hotel. You agree to pay for your room stay, but while you're there you get drunk and trash the place, causing $500 in damages. You leave before anyone notices the damage, so nobody had a chance to bill you.
The hotel owner decides to bill your Visa card for the amount of the damages. While it may be true that you owe the hotel owner $500, you never gave the hote owner permission to take that $500 from your Visa card. Because of that you can talk to your bank, tell them you didn't authorize the charge, and get the money back. (You can then go to jail for whatever crime you committed, or write a check for that same amount of money...but we're just talking about Visa/Mastercard's world here.)
In this case, Blockbuster will try to argue that your signature on the rental agreement authorizes them to charge your card. For *this particular sale* though, when you left the store you understood you would be charged only a rental fee. I believe whatever authorization you gave on your contract doesn't actually protect them as much as they think it will.
So if you charge back one of these charges from Blockbuster, you aren't saying "I don't really owe Blockbuster money", you're actually saying "I might or might not owe Blockbuster money, but either way, they do not have the right to take that money from my Visa/Mastercard account. Ask me to write a check or pay cash instead."
If they bill you the cost of a game ($50.00), that costs them at least 75 cents in credit card processing fees, probably more. So they *have* to charge some kind of restocking fee, or else that "gentle reminder" when they charge your card will *cost* them money when you return the game.
Above all else, though, keep this in mind: if someone charges your card for punitive damages or fines/fees you did not specifically agree to, you can file for a chargeback. Talk to your issuing bank.
Understand the difference though:
"You owe me $500 for tearing up your hotel room. Pay me now or I'm calling the police." --> "OK, fine, charge my card." -- in this case there was authorization, so no chargeback.
Hope this helps!
The opinions in this post are my own, and may or may not also reflect the opinions of my employer, First National Merchant Solutions. I did not actually have the phone-book-sized Visa/Mastercard regulations manuals in front of me when writing this, so I might be wrong. The "hotel" example came straight from our chargeback department, though, so I'm *very* sure the theory behind this post is correct. This is not banking advice -- your situation may vary, so talk to your own banker for situation-specific banking advice.
--Michael Spencer
Stop Code 3270
First National Merchant Solutions
1620 West Dodge
Omaha, NE 68197
He would've been guilty in the USA also.
You're thinking of Direct Copyright Infringement. He's not guilty of that.
You're forgetting there also exists Contributory Copyright Infringement and Vicarious Copyright Infringement. He's guilty of at least Vicarious Copyright Infringement, if he knew what content he was linking to and if he was showing ad banners to visitors. (And if he had the right-and-ability-to-control what was on the web page, and I assume he did.)
--Michael Spencer
There's a problem with that: RTC v. Netcom. (see Netcom, 907 F. Supp. 1361 (ND Cal 1995))
2 5 )
If someone can create a filesharing system where traffic is routed from one node to another, and when a node routes it hides the identities of the parties it communicates with, then filesharing becomes safe again.
Just as in RTC v. Netcom, where the Religious Technology Center (a.k.a. Scientology) attempted to sue Netcom (and was denied), automated acts of routing on a filesharing network will probably be found NOT to be contributory copyright infringement.
In other words, if your network is arranged like this:
Client <----> Server
then either side can turn in the other side, as the parent post described. However, if your network is arranged like this:
Client <--> Node 1 <--> Node 2 <--> Server
then unless someone controls all of the systems in a particular communication path, they can't learn the identity of all of the nodes they don't control.
(See an earlier article, at http://slashdot.org/article.pl?sid=01/08/10/20492
One of the problems with this kind of routing system is fair division of labor. For this kind of P2P system to work (where your client must route data that it didn't actually request) the system must be designed well enough to distribute a burden of anonymous-routing to your client which corresponds with the amount of anonymous-routing load you're placing on the rest of the network. But how can people measure how much data you're sending and receiving, if they can't know who you are?
I don't have a solution for that problem, but it's not unsolvable.
So the question then becomes, will the general public begin to prefer a filesharing system that must transfer 400 MB of data over the network for every 100 MB of information it saves to disk, if that system is nearly impossible to audit or prosecute?
--Michael Spencer
Sure.
l ates.php3?sectionid=102&itemid=823 and this head: http://www.bogenimaging.us/product/templates/templ ates.php3?sectionid=9&itemid=287 )
I own a Sony Handycam (DCR-TRV260) with a 40x optical zoom (and a useless "990x digital zoom" which really just enlarges existing pixels and adds no new detail). I also own a Bogen tripod with a fluid head. (Professional tripods are usually sold with legs and head separate. I have these legs: http://www.bogenimaging.us/product/templates/temp
I would never do anything like this in real life, but it would be possible for me to somehow strap a laser pointer onto my camcorder. I would then need to stand my tripod up securely and calibrate it, so the laser points at the exact middle of the image. I could do this by just pointing the whole thing at a wall, zooming in, and then fine-tuning the laser aim until it shows in the middle of my viewfinder. I could then do the same thing for a distant object, like the wall of a house several blocks away, and fine-tune the laser aim even more until the point was in the middle of the viewfinder.
Keep in mind the whole point of a fluid tripod head is to give the operator fine pressure-sensitive control of where the camera is pointing. There are no rubber pads pushed up against metal, seizing the metal and making fine movement impossible. Fluid heads use oil cartridges and tension knobs that let you tighten or loosen, but never completely lock, the horizontal or vertical movement. If you zoom a camera way in, tighten the tension knobs, and just lay one finger on the tripod pan handle, you can see the camera v-e-r-y s-l-o-w-l-y tracking. To an outside observer you can't even tell the camera is moving, but the viewfinder shows the camera is not only moving, but it's moving smoothly at a constant rate.
While someone with my rig could just barely track a fast-moving aircraft from far away, they *could* do it.
--Michael Spencer
I've studied Japanese for five semesters, and I used Slime Forest Adventure to learn katakana. http://www.lrnj.com It's designed to work kinda like an old NES-style RPG (very Dragon Warrior-esque), but of course you aren't here for the gameplay. I believe it's binary-only but for Win32, Linux, and Mac OS X.
It's extremely effective. For me personally, it taught me katakana in about 5 days, whereas it took me two weeks of classroom study to learn hiragana (same 46 characters, just shaped different, like the difference between our capital and lower-case letters.)
It's free and highly recommended.
--Michael Spencer
Nothing personal, just using you as an example:
.torrent for *VeryBadThing*.
Sorry Kjella, we're going to have to arrest you for assisting in the trafficking of *VeryBadThing*.
Someone took a phrase from your post ("somesuch like that even though they didn't know kjella" after stripping out formatting), passed it through a text-to-binary deobfuscator (which you OBVIOUSLY must have used...all the pirates have known about it since 2007, and you ARE a pirate, aren't you?), looked that code up on a well-known pirate web site (which you OBVIOUSLY...erm, yeah, insert lame intimidation attempt here), and used it to find a
Shame on you.
OK, not really, but you get the idea. Your defense here is obvious: you had no possible way of knowing some random text could be used in this way. Maybe you received a DMCA notice asking you to remove those words from the end of your post, but you can't do that.
Only giving away the odd bytes is still transferring copyrighted material, so that's Direct Copyright Infringement. There are already laws which cover that.
They will sue them using 17 USC 501. Google for Vicarious Copyright Infringement and Contributory Coypright Infringement.
2 5
Contributory copyright infringement requires that the MPAA can prove there is reasonable expectation of knowledge of infringement (they can see filenames) and there is material contribution to the act of infringement (they're a tracker). Someone has to be guilty of direct infringement for contributory copyright infringement to be possible (so a dead torrent, where everyone's at 0% and nobody knows where the seed is, can't make anyone guilty of direct or contributory copyright infringement.)
Vicarious copyright infringement requires also that direct infringement happens somewhere, but also that there's some financial or material gain (pay from ad impressions) and some right or ability to supervise (ability to delete torrents, ability to block torrents at the tracker).
So yeah, once again the index service (like Napster's central servers) is vulnerable. We need to split up the file descriptions from the method of transfer. There are many ways to do this, but here's the first one that comes to mind: site A publishes information that 8BC288EF.torrent contains Return of the King, and site B is a tracker for 8BC288EF.torrent without knowing what it is. Site A then blocks (firewall, policy, etc) sites like site B from accessing it. Site B therefore has no way of knowing what it's hosting. They still must respond to takedown notices, but if they are responsive they don't have to worry about contributory or vicarious copyright infringement.
I had a slashdot story a few years back regarding an email exchange about this very subject. http://slashdot.org/article.pl?sid=01/08/10/20492
--Michael Spencer
There were already some excellent posts on this subject a week ago. See: http://slashdot.org/comments.pl?sid=130257&thresho ld=-1&commentsort=4&tid=129&mode=flat&cid=10864866 (the post starts out saying "IAAVN (I am a Visual Neuroscientist)")
This may be because to generate that power one would have to slow the mouse down to do it. Your mouse would no-longer glide effortlessly across a smooth mouse pad, but instead would feel as if it was moving through molasses.
y ExecSummary.pdf )
Experiment 1: Put one finger on top of your mouse, push down hard, and then use the rest of your fingers to grasp the mouse and move it around. It still moves, but how much would your wrist hurt after doing that for 8 hours?
Experiment 2: Connect a hand-crank generator to a variable resistor and voltmeter, so you can measure the power output from the crank. Attach a mouse to the crank of the generator, and establish a slow crank rate that gives you 0.8 volts on the voltmeter. Orient the mouse so it's horizontal, so its movement is similar to how you move a mouse on a mouse pad. Now slowly increase resistance to around 61.5 ohms, which gives you 13 mA consumption. (Your resistor will only be eating about 10 miliwatts, so the resistor should barely even get warm.) Now keep moving the mouse like that for about 10 minutes. What does your forearm feel like?
Don't cheat and use your whole arm, or change your hand position to something more suited to turning a crank. You're moving a mouse around, not cranking a survival flashlight or radio.
(Microsoft and Logitech Cordless Mouse battery life comparison, which is my source for 0.8 volts and 13 mA: http://www.percept.com/media/MicrosoftMouseBatter
--Michael Spencer
Excellent post, but it raises a couple of questions.
First, is it *bad* for our visual system to be pulsing at CRT refresh rates? What does that do to the body, both good and bad?
Second, how does the impact of a flickering CRT compare with that of the fluorescent lights already found in many homes and businesses? Will replacing a CRT with an LCD make any significant difference if the room you're in is already lit with fluorescent lighting?
Thanks again for the excellent post, and for looking at these followup questions...
--Michael Spencer
It's a shame that some of us draw conclusions about the entire Gentoo userbase from the actions of a few annoying people.
:-) I was in this Data Structures class, and one of my classmates was one of the bad kind of Gentoo user. I had already heard him lure people into distro arguments. He was excessively pushy about Gentoo once he found out someone was a non-Gentoo-using Linux user. He asked me one day which distribution of Linux I use. I told him I don't much care which distribution it is -- the kernel is Linux, the web server is Apache -- the system is already installed, and I'm not adding or removing anything, so it doesn't matter which distribution it is. It's Linux.
It sure is fun to mock those annoying people though.
I think I broke his brain.
no support? What are you smoking?
I don't suppose people who buy Sharp laptops have to get all their software from Sharp too, do they? Do all Dell laptop owners buy all their software and games from Dell?
Sharp will honor their warranty. That's all they need to do. You can get all kinds of software for this device from other sources, as long as you have the hardware.
--Michael Spencer (An SL-C700 owner, considering buying this SL-C300)