I'm now reading in the next chunk of data. Its header identifies it as a formatting attribute applied to a range of cells. I'll apply that info to my internal representation of the spreadsheet.
I'm now reading in the next chunk of data. Its header identifies it as...well, something unknown. Prior research suggests this kind of data block is totally irrelevant, so I'll skip it. It seems to be two integers, zero padded out to 4 KB, but other than that I have no idea what it does.
I'm now reading in the next chunk of data. It's a list of cell values.
etc etc.
It's possible to read a data file and get *most* but not *all* of the meaning out, and yet still be able to do useful things with the data. If you attempt to write a data file using this same incomplete knowledge of the format, your file will look weird.
For a non-native English speaker, it's kinda like the difference between reading proper English and writing proper English. If you ignore order agreement and articles (a, an, the) you can still understand almost all of an English sentence. But if you try to write English with that same strategy, your lack of number agreement and improper articles will stand out.
A user types in an email they say is spam and asks SpamCop to process the email. Spamcop uses a variety of techniques to track down the administrators responsible for the originating IP, and for web pages and email addresses linked in the email, and gives users the option of sending email to the administrators it finds.
You're not required to do this, but if you register an abuse address at abuse.net then SpamCop will find it.
Besides, shouldn't your gripe read: Mishandling by my ISP of a false complaint against us by spamcop led to all our servers being off the net for a day last year. My ISP did ZERO research in the complaint and shut down my connection (rather than trying to contact us by our abundant and up-to-date customer contact info). Their conduct was beyond reckless -- it was vicious. I'm all for good anti-spam but my ISP can bite me.
Why don't you talk to SpamCop and have the user responsible banned?
How do you compromise the host machine if you can only interact with one of the two virtual machines? The host machine wouldn't even bother to act on the IP datagrams inside ethernet packets going to or from either VM -- it would just forward the raw ethernet frames. Unless you know of some way to compromise a host when the host is ignoring your packets...
What's the point of developing new technology then, if it's too complicated for end-users right off the bat? I thought that was the normal life cycle for new technology: geeks invent it, start using it, refine it, and eventually someone says "maybe if I package it in this new way, a few end-users can start to use it". Then end-user feedback and design iterations eventually turn it into a solution for anyone to use.
I don't agree with fmaxwell's assertion -- I think this is a good thing.
I need to lengthen this post a bit, so...we should consider separating the trustworthiness of a blacklist file from the communications path used to move the file around. The rest of the pieces required to implement this may be obvious to some, not obvious to others, but further discussion developing this simple idea is welcome.
The class was "number theory and cryptography". It didn't really help that much. Mostly it did things like: "well, when I brute-force the problem with Maple I get the same answer, so my solution and proof is probably right." or "When I brute-forced it I got such-and-such answer...but I've got no CLUE how to get there from here in a proof. *leaves rest of question blank*" "Ooh, I got +2 out of 15 for the brute-force stuff..."
How much computing power does a device have? How much computing power does it take to enable some range of tasks?
How portable is a device? How big/small does it have to be for it to be useful in various parts of your life?
I have been carrying around a Zaurus SL-C700 for the past four months. (The SL-C700, 750, and 760 all use the same form factor but have different hardware features.) The size helps a lot. Every time my car keys go in my pocket, the Zaurus goes in my pocket. It's *always there*. When I sit down I can barely feel the rounded corners, but they don't poke. The hinge isn't flimsy or weak at all. The screen is closed up inside the case, so there's no danger of damage that way. (Caveat: it's possible for a coin to wedge itself up in there between the screen and keyboard, but that's very rare. It's only happened to me twice, and I haven't noticed any scratches on the screen.)
The size is small enough that I have been allowed to use it on math tests at college. I showed the professor Maple on it, explained that I was using the 802.11b card to remotely control my home computer...even showed that I could switch from Maple to an internet browser. I was still allowed to use the machine on tests. It isn't big and bulky like a laptop -- it doesn't sprawl out and take up the whole desk.
The battery life, for me, is inconvenient but not insurmountable. With a power-hungry CF card in there you do only get about 90 minutes of runtime. That sounds kinda bad, but think about your own lifestyle and your own use of this device. How long are you away from a power outlet for 90 minutes in a stretch, if you just go between home and work?
I built a custom battery pack for my unit, and you should too. (We're slashdot readers -- this isn't mass market land.) http://mspencer.net/battery/ It's eight 9000 mAh capacity D cells (NiMH) in two four-D-cell holders, wired in parallel. In theory the numbers say I should have about 20 times the battery life of the internal battery pack. In practice I know I have to recharge the pack about every two to three weeks. It's about as heavy as a thick schoolbook, and sits in my backpack just fine, in a separate compartment that's too small for a full-size textbook but larger than the tiny pocket in back.
OK, that's the size. It's pretty much go-anywhere, once you realize the limitations of the battery size. If you want that kind of computing power (see below) available anywhere (for 1 to 4 hour stretches) or available any time you're with your backpack (for weeks of power), it might be worth hacking together a battery pack for yourself.
What computing power? The biggest feature is that beautiful screen and keyboard. The keyboard is better than most that size, but of course nowhere near the convenience of a full size keyboard. The screen is clean and bright -- on full battery-sucking brightness, it's brighter than my monitor. I can see some smudges when the screen is off, but they're completely invisible with the screen on. Slightly visible in direct sunlight (because it emits light, doesn't reflect) but it's useful as a flashlight in the dark. It's capable of truly tiny print. To see if you can tolerate text that small, take a screenshot, scale it to the correct size and print it out. Hold the paper out at various distances.
RAM is very limited, but you can use a swapfile. It's good for a few things at once. For school I've run mysql for database classes (and wished I had postgresql). ALL of my unix C programs were written, compiled, tested and emailed in from the C700. And then there's VNC in to the desktop, running Maple.
It's basically like a fiddly old resurrected linux PC, in your pocket. It has severe limitations, but they CAN be surmounted. Mount a swapfile. Close some programs. Stop that httpd you left running. It can do very impressive things, slowly and one at a time. It can do lots of little workstation things very w
Bingo -- I think you hit the major issue on the head, exactly. Administration costs per transaction are what kill micropayments. With some credit card processors and some contracts you would need to charge a customer at least 22 cents to get only one cent of net revenue -- and if the customer issues a chargeback or sales-draft retrieval request on that one sale, you (as a business owner) could be out up to $10 or more in fees from your acquirer.
Eliminate most of the customer service and investigation/chargeback rights like PayPal, and you might get the per-transaction costs down around where they have them.
Eliminate ALL of the customer service and investigative rights, and micropayments might work. But how?
Suppose we do that: all customer service and investigative/chargeback rights are gone, when you use this micropayment system. You may have to be somewhat technical to sign up. You have to submit funds to the account using traditional financial systems, so that costs money: suppose you are charged 5% of your deposit up-front. You pay in such a way that grants you no chargeback or dispute rights, so the micropayment service has no reason to hold your funds in escrow.
Suppose we do something with technology that makes transactions resist fraud. Suppose we can guarantee that the computer only agrees to pay when the authorized account owner (the physical human being) agrees to pay. Also suppose we can negotiate the transaction in a fault-tolerant way such that any possible critical part of the three-way negotiation (customer, merchant, and...umm...bean-issuer) still causes the transaction to fail safe. That is, suppose all the technical problems are solved.
We should examine what we're left with. How do you, as a customer, perform a transaction securely? In the real world, think of something dramatic, like a hostage being paid off for money or something. Two people can set their trades down and walk away from them. Two people can offer their trade to the other while still maintaining a grip on their offering. How do you do that digitally? Someone has to receive the payment or the goods/services first. If we give the customer the benefit of the doubt, then customers get to receive goods/services and then click "no" and claim they didn't receive what they were promised. If we give the merchant the benefit of the doubt, merchants get to cash their tokens and vanish.
Wait a minute, this reminds me of something else, from the "real world" of transaction processing: check writing. In the beginning, there was no on-line verification of paper checks. Checks bounced, accounts closed, people skip town, etc. After a while, the more basic form of electronic check verification became popular: blacklist services. A merchant scans a customer's check with a check reader, their terminal dials out, and a server compares the routing and account information on that check with their database of known bad check writers, known good routing numbers, known unacceptable account ranges for banks (business accounts, etc), and returns an approval or a decline. This is by no means fool-proof or fraud-proof, but it worked. (The current preferred solution for high-risk merchants like convenience stores is something like FDR's TeleCheck or my company's CompletePay, which converts checks into ACH drafts on the spot, and in most cases confirms the account has available funds before issuing an approval.)
How would a blacklist work, for these kinds of transactions? If someone gets shafted in the merchant-customer exchange, either party can complain. Assume the technical solutions we've already assumed can provide proof that money really did change hands. There would have to be a noise floor -- some people will lie. Some groups of people could organize themselves and deliberately influence a merchant's rating. Some transactions could just randomly go wrong, and one party assumes the other party did it on purpose.
Sorry about that -- I think I confused what you were asking about with what the original article was suggesting -- that spammers might be trying to snag credit cards to use fraudulently, not with their own merchant accounts.
I haven't noticed anything at all w.r.t. merchants selling these types of products. I don't get to see what merchants we deny merchant accounts to, and the products a merchant sells is usually not obvious from their doing-business-as (DBA) name.
My conclusions are: I probably wouldn't know anyway. If a business is established recently and these kinds of things are their only product, they might have a very hard time getting a merchant account. If an already-established, reputable business starts selling these kinds of products, I don't think we would really know or care, outside of doing risk assessments based on how many chargebacks they have.
So it seems the credit card system itself will penalize merchants for being risky, and selling a single product using spam for marketing probably makes for some interesting credit report reading. It will not, however, penalize merchants for buying a spammer's services, or for spamming.
I think I mostly already addressed that, but the basic premise is that Visa and Mastercard have rules under which fraudulent activity can be disputed. Products not working as advertised, not sold as requested, not received, etc -- these things can be charged back.
Acquirers are financially responsible for making sure chargebacks work. If a merchant charges credit cards, receives money, spends the money, and then chargebacks happen, the acquirer must charge the merchant to get those funds back. If the merchant doesn't have the money, the acquirer/merchant relationship goes into collections just like any other business that doesn't pay its bills.
Acquirers don't like when this happens. Sometimes when this happens the merchant never pays and the acquirer loses money. Acquirers try to prevent this by restricting the types of businesses they accept and having strict credit and business history requirements. Also sometimes acquirers accept "iffy" merchants anyway and mitigate the risk of loss by holding on to the merchant's money for one or more months. One acquirer I used to work for (DPI Merchant Services, in the news recently for being hacked) tended to take on the really scummy merchants -- bad credit, no credit, no problem, as it were -- they just required a working sample of the product, and made the merchant wait several months to receive their money.
So the bottom line is -- no matter what the spamming merchant is selling, it has to be selling goods as advertised and shipping them in a timely manner for their sales to happen without getting charged back. And if their sales get charged back, they don't get to keep the money. If lots of sales get charged back, they don't get to keep processing credit cards. Credit card acceptance is a privilege, not a right.
--Michael Spencer First National Merchant Solutions (a credit card processor or 'acquirer') First National Tower, 27th floor 1620 West Dodge, Omaha Nebraska, 68197 http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
The magnetic stripe contains extra information, not just the card number. A merchant conducting fraud would have had to see the magnetic stripe once to be able to copy it. J Random Spammer-service-purchasing merchant probably will never have seen the magnetic stripe. It's also safe to assume that merchants won't share magnetic stripe information -- merchants generally don't like chargebacks, so they don't like to do things that promote fraud.
(It is, however, possible that some spammer could partner with someone's credit-card-accepting gas station, and start stealing stripe information that way. What makes this unlikely is that if a large number of fraudulent transactions involve account numbers that all seem to have done business with a single gas station, Visa and Mastercard will see that, and will conduct an investigation. Visa and Mastercard then have the legal power to assess *serious* fines, per the signed contract the merchant has with their acquirer -- and then there's criminal charges for fraud and whatnot. The details of any criminal stuff are outside my experience, so I'm just guessing.)
In general, keep in mind that while a good deal of the approval process and payment process is automated, there are humans involved in confirming and reviewing every step of the process. There are businesses with financial interest in making sure merchants conducting fraud (or even just high-risk merchants) get closed, and that the rate of fraudulent transactions gets reduced. Visa and Mastercard change their rules as well -- their regulatory commissions meet twice a year and enact changes when necessary. Perhaps their idea of what "needs to change" can be different from your idea of what "needs to change", but the whole system keeps spinning as long as everybody involved keeps making money. The system tends to punish bad behavior financially, so everyone is financially motivated to do the right thing w.r.t. credit card activity. (That is, it punishes a high rate of fraudulent transactions. It doesn't punish immoral things like doing business with spammers.)
--Michael Spencer First National Merchant Solutions (a credit card processor or 'acquirer') First National Tower, 27th floor 1620 West Dodge, Omaha Nebraska, 68197 http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
I'm going to illuminate a dark spot in your argument, because I work for a major credit card processor.
For Visa and Mastercard at least, there are many parties involved in credit card transactions.
* Cardholders are obvious. You, me, anybody can be a cardholder. * Issuing banks -- these are the companies who actually issue the card, and who own the account the card is attached to. They are responsible for handing out authorizations (approvals, declines, etc) and for moving money between that cardholder's account and the Visa/Mastercard payment transfer system. * Associations -- there ain't too many of these. Visa is a payment transfer association. Mastercard is a payment transfer association. These associations have rules and regulations, and they interface with a *vendor* in a technical way, and with issuing banks and acquirers in a business/financial way. * Vendors -- think communications providers. Yes, I thought it was weird terminology too, but in the credit card processing world a 'vendor' is a communication provider of some kind. Vital Processing Inc, BuyPass, NDC, FDR, ADS/SPS/Vectrix, these companies all provide servers and communication paths that help get businesses and banks communicating and doing transactions. These guys have no *financial* link to any transactions. * Acquirers, like the company I work for. These companies are responsible for coordinating the technical stuff that gets merchants talking to vendors, *and* for establishing and maintaining the business/financial link between the merchant and the association. Merchants sign a contract with an acquirer, and the acquirer is bound by Visa/MC regs -- so the merchant is bound by visa/mc regs. The acquirer is ultimately responsible for its merchants. * Merchants. These are businesses that want to accept customer payments via credit card.
OK, enough background and terminology. How anonymous can you be if you accept credit cards? How anonymous is the money that passes through the system?
Not very. Not at all, actually. When a merchant signs up for a "merchant account" with an acquirer, they usually pay a rather hefty application fee. The acquirer knows they will be ultimately responsible for this merchant, so they do their homework and make sure this merchant is a good risk.
Why do acquirers have to be so careful? The "case study" threat model to defend against is: merchant runs advertising campaign, gets hundreds of thousands of dollars in credit card sales. Merchant takes these hundreds of thousands of dollars and "runs for the border", disappearing without a trace. After a while, customers start figuring out they aren't getting their widgets and ask their issuing banks to issue chargebacks. Chargebacks come rolling in; acquirer is now responsible for paying back all of that money. Acquirer will now pass those charges on to the merchant -- oh, damn, wait, they're long gone. Acquirer eats the loss. Ow.
Acquirers fight this in several ways. First, they're very careful about who they take on as merchants. Thorough credit checks, sometimes required examples of products, and high standards. Second, for high risk merchants, an acquirer will sometimes withhold payment for a certain amount of time. If an acquirer believes that most customers would issue chargebacks well within 90 days (even though they have up to 6 months) it can hold onto those funds for 90 days. If the merchant ships the goods it promises no chargebacks appear, and the merchant gets their money. If the merchant doesn't deliver goods, the acquirer still has the funds on hand so it can pay the chargebacks out of the merchant's own funds.
With all this in mind, I have some problems with the parent post. I don't believe there was a breach of trust -- the system works the way it's supposed to, because of chargebacks.
Issuing banks are supposed to be fairly liberal about who they grant authorizations to. They can return authorization responses in one of three categories: basica
I think you're exactly right there. I think there's an important distinction that needs to be made, though. You weren't trying to confuse the issue -- you bring up a valid point. I'll highlight it a bit more.
Without considering RFID tags, there's already a difference between the amount of information law enforcement can derive from a card number, and the amount of information a merchant can derive from a card number. Generally an issuing bank won't give personal information to a merchant, and in some circumstances will only confirm (yes or no) whether or not specific details are correct (like the customer's address, but not like the customer's social security number or current balance).
For law enforcement it's a different story. Banks are sometimes required to give personal information to law enforcement officers as part of an investigation. These requests must be documented and always leave a paper trail.
Beyond that, I don't know much about how issuing banks handle these requests. The division I work for (First National Merchant Solutions) doesn't issue credit cards to customers, and my department never deals with law enforcement.
Everything I say beyond this point is speculation, and is *definitely* not meant to represent the opinion of my employer, First National Merchant Solutions.
I think if a government agency could convince enough issuing banks to both cooperate with a mass investigation like that (members of a crowd identified by RFID tags), and not complain about it/resist it in court/issue a letter to customers or a press release about it...and could convince enough retailers to do the same...then the threat model you describe is reasonable and realistic.
I'm not world-wise or business-wise enough to predict whether or not banks and merchants would go along with this, actively support it, passively resist it, actively resist it, or what.
To be clear, though, this threat model wouldn't work for private firms. Issuing banks need to cooperate to give the investigator any chance of tying account information to a personal identity, and they generally don't cooperate with curious private individuals or firms.
(I'd also like to acknowledge: the poster I'm replying to was not trying to suggest that this threat model works for private citizens or firms. I just wanted to bring the difference out in the open for more discussion.)
--Michael Spencer First National Merchant Solutions First National Tower, 27th floor 1620 West Dodge, Omaha Nebraska, 68197 http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
When you swipe a credit or debit card, the merchant can read your name, card number, expiration date, and some card verification information. They are already *forbidden* from storing the card verification information after they use it to process the sale. When a merchant signs a contract that enables them to accept payment via credit card, some clauses in that contract allow their processor (acquirer) to charge them fees or fines, especially if the acquirer is charged fees or fines by Visa or Mastercard. That means -- Visa and Mastercard have the power to fine merchants for behaving badly. They can also revoke a merchant's ability to accept those kinds of credit cards.
Merchants are allowed to store the customer name, card number, and expiration date from the magnetic stripe.
What does a customer name, card number, and expiration date get you? (besides 'paid for your transaction') Assuming the name isn't already unique...
Sales can happen in one of two major "processing environments": card-present (where the merchant swipes the card, and proves to the issuing bank that the card really was there, by demonstrating knowledge of some of that secret card-verification information on the card), and card-not-present (where the card number is sent via mail/phone/fax/internet).
In card-present sales, the merchant only has the card number and name. If companies (like Radio Shack perhaps) insist on having a name and address on file for each customer, they could run into problems: if a customer finds that such-and-such company is refusing to accept Visa/Mastercard CARD-PRESENT sales when the customer refuses to provide a name and address, the customer can complain to their issuing bank or to Visa or Mastercard directly. Those payment-transfer-organizations might conduct their own investigation (plain-clothes customers), and if the merchant is found to be refusing to accept Visa/MC card-present sales without address information, they can be stiffly fined or have their processing priviledges revoked.
In card-not-present sales, the threat model you discussed is reasonable. Best-practices say the merchant should perform an address-verification check, confirming that the address the customer provides matches the billing address the issuing bank mails statements to. If the customer claims they are shipping the goods to another address, the merchant should require the customer to contact their bank and have the bank "whitelist" the new shipping address, because the bank can then confirm all the personal information the merchant isn't allowed to have.
So I guess a merchant in California could be paid off by some marketing company, and could ship RFID-enabled goods to a customer in New York, and report the RFID information so it's trackable.
You could NOT, however, reasonbly expect that by just swiping your credit card in Wal Mart, Wal Mart suddenly has all your personal information. They could, possibly, associate different products with the same customer, but they wouldn't know anything other than the card number and name.
----------
In general, keep this in mind: the Visa and Mastercard corporations are profitable. They are 'payment transfer organizations' and want to maximize the amount of money that travels through their system, because they make a *lot* of money off of processing fees charged to merchants. If something happens that makes customers nervous, or makes merchants nervous, they will pass new regulations that try to make that fear go away.
But of course if there's no widespread customer knowledge of this possible threat, there won't be any significant nervousness to worry about.
--Michael Spencer First National Merchant Solutions (a credit card processor or 'acquirer') First National Tower, 27th floor 1620 West Dodge, Omaha Nebraska, 68197 http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
I've had a C700 for about three months now. (has it really been three months?)
On a normal desktop keyboard, it took me 16 seconds to type the code you pasted.
On the C700 keyboard (which is exactly the same form factor as the C750/C760, just different colors) it took me 41 seconds to type that with the unit held in my hands, and 38 seconds to type with it sitting on the desk.
So yeah, you ain't kidding . . . it hurts.:)
If it's all you have, though, it's better than nothing. (I'm pretty sure the original poster knows all this -- I'm just sharing my experiences.) I've created, compiled, tested, and turned in a C program for a class, completely on the C700. Took me about twice as long as it would've taken if I could've used a full-size computer . . . but I'm not allowed to use a C compiler on bank computers at work, and the time would've been spent reading slashdot anyway.:)
Hint: there are no open or close curly braces printed on the C700 keyboard, but you can get those characters by holding down Fn and Shift and pressing the keys with angle brackets. Helps to use an editor like MinIDE ( http://www.killefiz.de/zaurus/showdetail.php?app=2 49 ) which can be set to type a close brace when you type an open brace automatically.
(this bit is offtopic, but . . . . I tinkered with my Dynamism converted C700 and figured out what was changed, and then made a howto that describes how to implement most of those changes by hand. No downloads, no copyright violation. http://mspencer.net/stuff/c700conv.html )
I had a TRS-80 Color Computer 2 back in 1985. Some months later, my parents bought Dungeons of Daggorath for themselves to play.
That game had *atmosphere* -- it was really frightening. The game was a first-person perspective dungeon crawl. Monsters each had their own distinctive sounds, and the sounds were louder or quieter depending on how far away the monsters were. Besides the monsters and your own actions, the only other sound in the game was your character's heartbeat. There were no visible statistics or numbers -- just the speed of your beating heart. Move too quickly, carry too much while running, or get hit too many times, and your heart would beat faster and faster until you fainted or died.
The graphics were crude but effective. The player's viewpoint could only be one of the four cardinal directions. You had to type a command, like "T R" (meaning "TURN RIGHT") and you would shift your viewpoint 90 degrees to the right. Monsters were flat line-art, and the dungeon was made of cells, featureless and uniform. Your character carried a torch, and the game would show dimmer light by drawing lines with fewer and fewer dots.
When you fainted, the screen faded out to black, each line getting dimmer and dimmer until it was only two or three dots, then nothing at all...and you had to listen to the monsters around you moving, wondering if they're going to finish you off before you wake up. If you wake up, the world fades back in, and you're left with a rapid heartbeat and a slim chance of survival if creatures are around. Overexert yourself in your desperation to get away and you might faint again. You have to stumble through the maze, looking for a dead end, hoping the monsters won't find you.
Most players had to use the audio tape based save and load feature, because completing all five levels of the game could take several hours. If you took the passive approach, sitting and waiting near a pile of unneeded swords and dead torches, you might find yourself waiting for 5 or 10 minutes for that one remaining powerful monster to find you -- waiting, listening to your own heartbeat, listening for creature sounds, trying to tell creatures apart and gauge their distance.
I think many people who had a chance to try the game were put off by the text-based interface, which required players to memorize commands and abbreviations, and learn how to type certain frequently-used combat commands very quickly. (When I was 10 years old I couldn't touchtype, but I could type "A L ", meaning "ATTACK LEFT", about five times in a second. The ATTACK LEFT command attacked whatever creature was in the same cell as you with whatever was in your left hand.)
If you're interested, search Google for Dungeons of Daggorath. There's even a PC port out there -- the timing is somewhat similar to the original, but not quite the same as the game would be on real hardware.
If I were writing spam filter rules, I think I would fix that problem with extra rules:
mail sent with gnus and with an Exchange ID: +6.4 points mail sent with gnus and with an 'X-Cron-Env' header: +6.4 points mail sent with an Exchange ID and an 'X-Cron-Env' header: +6.4 points mail sent with gnus, an Exchange ID, and an 'X-Cron-Env' header: +6.4 points include diff -u output and have 'foo@bar wrote' attribution: +6.6 points include diff -u output and have quote text: +3.3 points include diff -u output and have 'In-reply-to': +3.3 points mail has 'In-reply-to' and an 'X-Cron-Env' header: +6.4 points
In total, the message would then have -45.135 +45.2 = 0.065 points.
That's an interesting idea. If someone can come up with a way to do this that doesn't sacrifice filenames, it'd be almost good enough to implement.
----------
Suppose that the servers return the list of hashes that each search result would have matched. These hashes still can't be 'reversed' back to the original words.
When the client creates a list of possible results, suppose that the client uses a dictionary file to try every combination of 'extra hashes that I didn't search for' to try to find the other words that were probably in the file. If the user finds that the file contains fifty 'catch' words instead of words directly relating to the original search, the user can choose to not download the file.
----------
Here's another try.
The example I submitted to Fred von Lohmann already assumes that the index servers aren't allowed to collaborate, because every host on the network knows whether a host is an index server or not.
Suppose that the clients are running a network service such that they can answer queries for a given 'file number' or 'file reference' with the original filename, size, etc.
The index server is not allowed to connect to this 'filename lookup service' because the clients all know the network addresses of all index servers. They can simply refuse to answer queries from index servers.
Note that some Napster clients already ping every returned search result.
----------
I believe this can be implemented, as a Napster server replacement. This sounds good as I read it back to myself, but it's bound to be full of holes. Please tell me if anybody notices anything that doesn't seem right.
Suppose we create a custom program that's designed to work with existing Napster clients and with existing OpenNap servers. The program runs on the user's computer. It emulates an OpenNap server running on localhost, so the client can connect locally and pretend it's talking to a normal Napster server. It's also using this special hashing logic to talk to existing OpenNap servers, masquerading as a Napster client.
The (real) Napster client has its own list of shared files, probably indexed by actual filename. It can send search queries and receive search results.
The fake Napster client built into our special program has its own list of shared files -- one list for each hash type.
When the real Napster client wants to share its list of files with the world, it talks to our fake Napster server (running on localhost). It shares all of its files (with full filenames). The fake Napster server then hashes each of the words in the shared files' filenames and sends those hashes to the actual OpenNap servers out on the internet.
The OpenNap server sees "F3B 892 B22". The fake Napster server running on localhost sees "suchandsuch 02 -- soandso.mp3". So now the OpenNap server is full of bogus-looking results that point to bogus files on real machines. The real OpenNap server might think that this "F3B 892 B22" file exists on the IP that shared it, but the file doesn't really exist.
When the real Napster client wants to search for a file, it sends its search to the fake Napster server running on localhost -- our special software. The local machine then splits the search up into three parts, as described in the article. The hashed search items are sent out, some very long lists of results are sent back, and the local software processes the three result sets into one result set. It then queries the IPs returned, looking for original filenames.
As far as the Napster client is concerned, nothing has changed. They still get search results with full filenames, and they still get the real IPs of people to download from. The downloading mechanism still works exactly the same.
As far as the OpenNap server goes, people seem to be sharing lots of bogus files, or files with odd filenames. (instead of 89B we could use phonemes: ha-chi-ro-ni-ku-ba but without the dashes) And so many people are searching for the same odd words, that people keep requesting search result sets over 200. I hope the server operators decide to increase their max search result set.
And the result: just as Napigator enabled Napster clients to connect to nonstandard servers while still making things very easy for the end-user, our 'transparent' program can be used by simple end-users without requiring them to learn anything new.
Searches will take several times longer to complete -- but they won't be filtered any more.
----------
Anybody feel like starting a SourceForge project? ^__^
Fred von Lohmann was also talking about this when he referred to 'automated [data] reproduction' in his reply to me.
I think there is a range of legitimacy for automated data reproduction acts. Large internet routers obviously should not be forced to shut down because some of their routed traffic may be infringing. On the other hand, a custom program or script designed to hide the identity of an OpenNap server by forwarding requests to the server and forwarding responses back is more likely to be required to shut down.
Someone should probably ask Fred von Lohmann about 'prior restraint to speech', how he believes that was addressed in the Napster case, and how he feels it might be addressed in the future. He's already given us a very wise statement about this: "In the final analysis, a court will probably not be sympathetic to a system that is seemingly designed to frustrate the legal system."
Only a lawyer can tell for sure, but my layman sense of right and wrong tells me that we shouldn't be forbidden from protecting the anonymity of people. Sometimes anonymity protection is used to evade law enforcement...sometimes it's used to keep our personal information out of marketing databases...sometimes it's used to keep people from being assassinated by other governments or organizations.
The idea that struck me the hardest from Fred von Lohmann's reply is "substantial noninfringing uses". I already stated in another post how I believe that the ideal filesharing client will be a successful implementation of many ideas in one program.
Hopefully law will follow logic here. If this filesharing network enables something that should be illegal, but is composed of many different parts which are all individually legal, it should follow that the process of combining these legal activities should not be illegal. The *intent* and the *actual usage* can be used to gauge the legality of the whole system.
Note that Usenet isn't illegal. (I missed that too -- I think I wasted some of Fred von Lohmann's time by making him explain that.)
Perhaps the most successful implementation of 'the perfect filesharing client' will create a large number of individual services that have tons of non-infringing uses, establish their value and their common use, and then all at once build a filesharing program that connects them all.
I think that's what you just said. Movie trailers, convention broadcasts, etc.
--Michael Spencer
blocks@mspencer.net
(use my IP's ARIN contact to reach me IRL)
I really never expected this to be worthy of Slashdot's attention.
(note: I started the email dialogue with Fred von Lohmann back on August 3rd -- I wrote the indented text in the InfoAnarchy article. Fred replied on the 8th, and I posted it on InfoAnarchy on the 9th.)
I think there are a lot of interesting ideas out there -- we have some very powerful technologies to use, but each one satisfies a different need. Someday someone much smarter than myself will find enough connections between enough individual ideas to find a way to connect them all. I think the perfect filesharing network must use lots of cool technologies -- the combined technologies of several current projects.
Fred von Lohmann wrote an excellent paper that addressed the potential legal liabilities of *developers*. In open source applications and serverless peer-to-peer networks, the developer can be invisible or anonymous. If there are no servers, the only thing left to consider is the users -- the peer nodes.
My first question to him was basically rephrasing the kind of caching and forwarding that programs like Freenet and Blocks do.
The second question was based on an idea that an InfoAnarchy user started in an article's comments. I had always assumed that index servers will be a filesharing network's weak point -- the point where index data is being traded is the point where an attacker can best censor the network.
This idea would really suck to implement. Your clients wouldn't even get to see the filenames of their search results -- they would have to trust that the hash system worked properly and that all of their search results are valid. I don't know about you, but I'd hate that. I'd be uninstalling that program in a heartbeat.
But what if that was all there was? What if every other filesharing system with an index server was whitelisted, media company controlled, or was otherwise restricting access to certain information? If a user's alternatives are either a mangled no-filename service or a whitelisted service...or no service at all...perhaps they would choose to use this idea.
Or in other words...it's technology. It's a tool. It doesn't work in all scenarios, but there may be a situation where this idea works better than any others. It's not a good Napster replacement, not by a long shot, but we should file this idea away and use it later instead of dismissing it because it isn't a magic solution.
In my experience, information security is a tradeoff: security for convenience. To gain security you usually have to lose some measure of convenience. Really smart and well-designed security solutions can give you a lot of security for very little sacrificed convenience. Some other security solutions can give you a very small increase in security for a great loss in convenience. (For example, if a bad system administrator sets his NT servers to require frequent password changes with excessively complex passwords, in an environment where users are known to write their passwords down on post-it notes anyway, you're taking a lot of convenience away from users without giving them much extra security. They'll just use more post-it notes than before.)
I have a few more ideas that may present interesting legal situations if they ever get implemented. I'll keep InfoAnarchy.org updated if Fred von Lohmann and I have any more interesting discussions.
As a parting shot: Don't blame the hackers for all of this widespread copying of copyrighted media. We aren't the ones who sold millions of *general purpose* PCs to millions of consumers. They already have the tools -- we're just helping them use their tools to maximize the rights they already have.
Last year my former company had an internet security incident. The attacker used an account with a normal ISP to try the hole, and then reconnected with a NetZero account to perform the attack.
The short of it: I would partially or completely firewall the 4.0.0.0/8 class A -- the company responsible for this network allows people to sign up with bogus account information, and doesn't provide 'common courtesy' help or information when requested. Do you want anonymous IP addresses making SSL connections to your web store? Do you want anonymous IP addresses making connections to your network at all?
The long story is, while talking with Genuity Networks I discovered:
The 4.0.0.0/8 class A contains all of NetZero's dialup IP pool, as well as some non-NetZero Genuity Networks customers.
(The name NetZero wasn't obvious in the DNS name...but when a reply to my initial email to them came back with a call log number and (NetZero) in the subject line, I figured it out.)
Genuity Networks *refuses* to tell you which IPs are the NetZero dialups in your area, so you can block them. I didn't want to block the entire 4./8 class A, so I did something I probably shouldn't have: I put together a shell script that ran nslookup on every address in the 4.4./16 class B. I came up with about 12 class C networks that have 'omaha' in the reverse-lookup DNS names. I firewalled those.
(I was so pissed off at the lack of help I received, I was considering replying to the message, cc'ing the original abuse address, but editing the sender's portion of the message so it looked like he told me which networks to block, and that I thanked him for the information. I never sent the mail though.)
Perhaps this is why we need security features in peer-to-peer clients.
Blocks was an example of a filesharing client with too much security. It was well-designed and cross-platform, but required too many resources and too much security for...well, anybody except the most advanced users. It would be very difficult to find the IP number of someone sharing certain content on the Blocks network. It's also almost impossible to even find a file on the Blocks network.
Perhaps what we need is optional security. Some users are going to want to form a mixnet, and only directly communicate with trusted peers. Some people want encrypted disk caches, so if their computers are seized, it'll be impossible to tell exactly what they're sharing. Conversely, some people would like an easy way to tell whether content is copyright-protected and shouldn't be traded, without directly notifying anyone that they've come into contact with the content.
I've outlined some security concepts in a quick page I've put together: http://mspencer.net/fs. It's a work in progress, and is very long (22 KB and growing) with almost no index or table of contents. But if peer-to-peer filesharing is a topic you are enthusiastic and excited about, you'll find the page very interesting. (There are no ad banners at all on that page -- just text, except for my email address. I put my email address in a graphic, to spam-proof it.)
From the page:
Does all of this seem seedy? Do you think people will assume that anyone who participates in any of this extra security or identity protection is automatically a criminal? Remember that this is what computers do -- they take complicated things, and take the manual labor out of them. Sure, some of these methods may seem like seedy criminal behavior turned digital -- but this behavior is usually criminal in real life because it's so costly! It takes time and effort to route anonymous messages around -- take a 'layered' envelope out of the mailbox, unwrap only one envelope leaving (an envelope still inside, possibly with more envelopes inside that), and mail it out again. Pass things around by word-of-mouth only. Use aliases. In real life, these things are difficult to do and take time and effort...so it can be concluded that the people doing them probably need the extra security or protection. That is, they're probably doing something illegal, so the extra 'cost' is worth it. But this is digital -- these are computers we're talking about. It's very easy to let the computer stand out on the streetcorner for us. We're not peddling high-value illegal material -- many of us merely don't want certain advertising companies using our personal information to enhance their seedy business. This 'shifty behavior' becomes worthwhile at the half-penny-per-transaction level, because computers do all the work. Were it the real world, this same kind of 'shifty behavior' would only be justified at the tens-of-dollars-per-transaction level.
Such a system is possible, if enough motivated and excited people get together: adapt and borrow concepts from other projects. The other projects out there (MojoNation, Freenet, Blocks, ELF, and many more) have wonderful concepts and design, and they do a very good job of solving a particular problem with filesharing. But they don't solve all of the problems.
Perhaps if enough p2p project developers are inspired to bring their concepts together into one system, we'll finally rid our gift culture of these pesky intellectual property lawyers.
On a related note...I just thought of this really evil way to abuse three existing services (WWW, DNS, and Akamai proxying) to provide a kinda-anonymous web site:
1) Use an existing DNS zone to point an NS record for a subdomain to a special kind of DNS server. (Perhaps *.anon.mspencer.net)
2) Create a special DNS server (special software, or just firewalled) that is only allowed to hand out DNS query replies to Akamai servers.
3) Publish a URL: http://a1.g.akamaitech.net/6/6/6/6/lmnop1.anon.m sp encer.net/piratestuff/bigfile.iso
It would be impossible to get the true location of lmnop1.anon.mspencer.net unless Akamai servers were cooperating with you.
--Michael Spencer
(remove the first three letters from the email address above.)
When AOL got a connection to the same Internet the rest of us are connected to, I'm sure someone explained to them:
There is no support for per-connection billing and accounting, a la X.25, built into IP. When you are on an IP network, anyone else on the network can communicate with you, unless you explicitly firewall them. When you run a service on this public IP network, you accept and agree that anybody can interact with that service, unless you specifically disallow it.
Of course, people are allowed to build identification and accounting into their protocols to support anything they want. If they want to charge me for using their AIM service, they have the right to. Simply require authenticated logins (as they already do) and don't give those logins out for free any more.
Now, the point: there is a difference between using or complaining about AIM the network service, and using or complaining about AIM the executable program for Windows.
AOL gives AIM service for free to everyone else. I paid my bandwidth bill for the month too.
I'm sure AOL understands that some people will try to use their network service with non-AOL-provided software.
What AOL has done recently is attempt to tie AOL the network service to AOL the Windows executable.
It is within AOL's rights to try to do this.
It is within my rights to try to undo this, by publishing software that is compatible with the new version of their network protocol.
Would you mind re-explaining what we don't have a right to do again, as it relates to network services and applications being different things?
Slashdot Mirror
OK, I'm reading an Excel spreadsheet.
I'm now reading in the next chunk of data. Its header identifies it as a formatting attribute applied to a range of cells. I'll apply that info to my internal representation of the spreadsheet.
I'm now reading in the next chunk of data. Its header identifies it as...well, something unknown. Prior research suggests this kind of data block is totally irrelevant, so I'll skip it. It seems to be two integers, zero padded out to 4 KB, but other than that I have no idea what it does.
I'm now reading in the next chunk of data. It's a list of cell values.
etc etc.
It's possible to read a data file and get *most* but not *all* of the meaning out, and yet still be able to do useful things with the data. If you attempt to write a data file using this same incomplete knowledge of the format, your file will look weird.
For a non-native English speaker, it's kinda like the difference between reading proper English and writing proper English. If you ignore order agreement and articles (a, an, the) you can still understand almost all of an English sentence. But if you try to write English with that same strategy, your lack of number agreement and improper articles will stand out.
In Excel's case, "stand out" == "won't read".
--Michael Spencer
aren't complaints by SpamCop...automated?
A user types in an email they say is spam and asks SpamCop to process the email. Spamcop uses a variety of techniques to track down the administrators responsible for the originating IP, and for web pages and email addresses linked in the email, and gives users the option of sending email to the administrators it finds.
You're not required to do this, but if you register an abuse address at abuse.net then SpamCop will find it.
Besides, shouldn't your gripe read: Mishandling by my ISP of a false complaint against us by spamcop led to all our servers being off the net for a day last year. My ISP did ZERO research in the complaint and shut down my connection (rather than trying to contact us by our abundant and up-to-date customer contact info). Their conduct was beyond reckless -- it was vicious. I'm all for good anti-spam but my ISP can bite me.
Why don't you talk to SpamCop and have the user responsible banned?
Why is THIS modded up?
How do you compromise the host machine if you can only interact with one of the two virtual machines? The host machine wouldn't even bother to act on the IP datagrams inside ethernet packets going to or from either VM -- it would just forward the raw ethernet frames. Unless you know of some way to compromise a host when the host is ignoring your packets...
None of the things you mentioned have much to do with the things I mentioned. I don't want to change to your new subject.
What's the point of developing new technology then, if it's too complicated for end-users right off the bat? I thought that was the normal life cycle for new technology: geeks invent it, start using it, refine it, and eventually someone says "maybe if I package it in this new way, a few end-users can start to use it". Then end-user feedback and design iterations eventually turn it into a solution for anyone to use.
I don't agree with fmaxwell's assertion -- I think this is a good thing.
If the GPG signature matches, YES I would.
I need to lengthen this post a bit, so...we should consider separating the trustworthiness of a blacklist file from the communications path used to move the file around. The rest of the pieces required to implement this may be obvious to some, not obvious to others, but further discussion developing this simple idea is welcome.
The class was "number theory and cryptography". It didn't really help that much. Mostly it did things like: "well, when I brute-force the problem with Maple I get the same answer, so my solution and proof is probably right." or "When I brute-forced it I got such-and-such answer...but I've got no CLUE how to get there from here in a proof. *leaves rest of question blank*" "Ooh, I got +2 out of 15 for the brute-force stuff..."
I think there's another way to think about this.
How much computing power does a device have? How much computing power does it take to enable some range of tasks?
How portable is a device? How big/small does it have to be for it to be useful in various parts of your life?
I have been carrying around a Zaurus SL-C700 for the past four months. (The SL-C700, 750, and 760 all use the same form factor but have different hardware features.) The size helps a lot. Every time my car keys go in my pocket, the Zaurus goes in my pocket. It's *always there*. When I sit down I can barely feel the rounded corners, but they don't poke. The hinge isn't flimsy or weak at all. The screen is closed up inside the case, so there's no danger of damage that way. (Caveat: it's possible for a coin to wedge itself up in there between the screen and keyboard, but that's very rare. It's only happened to me twice, and I haven't noticed any scratches on the screen.)
The size is small enough that I have been allowed to use it on math tests at college. I showed the professor Maple on it, explained that I was using the 802.11b card to remotely control my home computer...even showed that I could switch from Maple to an internet browser. I was still allowed to use the machine on tests. It isn't big and bulky like a laptop -- it doesn't sprawl out and take up the whole desk.
The battery life, for me, is inconvenient but not insurmountable. With a power-hungry CF card in there you do only get about 90 minutes of runtime. That sounds kinda bad, but think about your own lifestyle and your own use of this device. How long are you away from a power outlet for 90 minutes in a stretch, if you just go between home and work?
I built a custom battery pack for my unit, and you should too. (We're slashdot readers -- this isn't mass market land.) http://mspencer.net/battery/ It's eight 9000 mAh capacity D cells (NiMH) in two four-D-cell holders, wired in parallel. In theory the numbers say I should have about 20 times the battery life of the internal battery pack. In practice I know I have to recharge the pack about every two to three weeks. It's about as heavy as a thick schoolbook, and sits in my backpack just fine, in a separate compartment that's too small for a full-size textbook but larger than the tiny pocket in back.
OK, that's the size. It's pretty much go-anywhere, once you realize the limitations of the battery size. If you want that kind of computing power (see below) available anywhere (for 1 to 4 hour stretches) or available any time you're with your backpack (for weeks of power), it might be worth hacking together a battery pack for yourself.
What computing power? The biggest feature is that beautiful screen and keyboard. The keyboard is better than most that size, but of course nowhere near the convenience of a full size keyboard. The screen is clean and bright -- on full battery-sucking brightness, it's brighter than my monitor. I can see some smudges when the screen is off, but they're completely invisible with the screen on. Slightly visible in direct sunlight (because it emits light, doesn't reflect) but it's useful as a flashlight in the dark. It's capable of truly tiny print. To see if you can tolerate text that small, take a screenshot, scale it to the correct size and print it out. Hold the paper out at various distances.
RAM is very limited, but you can use a swapfile. It's good for a few things at once. For school I've run mysql for database classes (and wished I had postgresql). ALL of my unix C programs were written, compiled, tested and emailed in from the C700. And then there's VNC in to the desktop, running Maple.
It's basically like a fiddly old resurrected linux PC, in your pocket. It has severe limitations, but they CAN be surmounted. Mount a swapfile. Close some programs. Stop that httpd you left running. It can do very impressive things, slowly and one at a time. It can do lots of little workstation things very w
Bingo -- I think you hit the major issue on the head, exactly. Administration costs per transaction are what kill micropayments. With some credit card processors and some contracts you would need to charge a customer at least 22 cents to get only one cent of net revenue -- and if the customer issues a chargeback or sales-draft retrieval request on that one sale, you (as a business owner) could be out up to $10 or more in fees from your acquirer.
...umm...bean-issuer) still causes the transaction to fail safe. That is, suppose all the technical problems are solved.
Eliminate most of the customer service and investigation/chargeback rights like PayPal, and you might get the per-transaction costs down around where they have them.
Eliminate ALL of the customer service and investigative rights, and micropayments might work. But how?
Suppose we do that: all customer service and investigative/chargeback rights are gone, when you use this micropayment system. You may have to be somewhat technical to sign up. You have to submit funds to the account using traditional financial systems, so that costs money: suppose you are charged 5% of your deposit up-front. You pay in such a way that grants you no chargeback or dispute rights, so the micropayment service has no reason to hold your funds in escrow.
Suppose we do something with technology that makes transactions resist fraud. Suppose we can guarantee that the computer only agrees to pay when the authorized account owner (the physical human being) agrees to pay. Also suppose we can negotiate the transaction in a fault-tolerant way such that any possible critical part of the three-way negotiation (customer, merchant, and
We should examine what we're left with. How do you, as a customer, perform a transaction securely? In the real world, think of something dramatic, like a hostage being paid off for money or something. Two people can set their trades down and walk away from them. Two people can offer their trade to the other while still maintaining a grip on their offering. How do you do that digitally? Someone has to receive the payment or the goods/services first. If we give the customer the benefit of the doubt, then customers get to receive goods/services and then click "no" and claim they didn't receive what they were promised. If we give the merchant the benefit of the doubt, merchants get to cash their tokens and vanish.
Wait a minute, this reminds me of something else, from the "real world" of transaction processing: check writing. In the beginning, there was no on-line verification of paper checks. Checks bounced, accounts closed, people skip town, etc. After a while, the more basic form of electronic check verification became popular: blacklist services. A merchant scans a customer's check with a check reader, their terminal dials out, and a server compares the routing and account information on that check with their database of known bad check writers, known good routing numbers, known unacceptable account ranges for banks (business accounts, etc), and returns an approval or a decline. This is by no means fool-proof or fraud-proof, but it worked. (The current preferred solution for high-risk merchants like convenience stores is something like FDR's TeleCheck or my company's CompletePay, which converts checks into ACH drafts on the spot, and in most cases confirms the account has available funds before issuing an approval.)
How would a blacklist work, for these kinds of transactions? If someone gets shafted in the merchant-customer exchange, either party can complain. Assume the technical solutions we've already assumed can provide proof that money really did change hands. There would have to be a noise floor -- some people will lie. Some groups of people could organize themselves and deliberately influence a merchant's rating. Some transactions could just randomly go wrong, and one party assumes the other party did it on purpose.
Overall, a blacklist system wo
Sorry about that -- I think I confused what you were asking about with what the original article was suggesting -- that spammers might be trying to snag credit cards to use fraudulently, not with their own merchant accounts.
I haven't noticed anything at all w.r.t. merchants selling these types of products. I don't get to see what merchants we deny merchant accounts to, and the products a merchant sells is usually not obvious from their doing-business-as (DBA) name.
My conclusions are: I probably wouldn't know anyway. If a business is established recently and these kinds of things are their only product, they might have a very hard time getting a merchant account. If an already-established, reputable business starts selling these kinds of products, I don't think we would really know or care, outside of doing risk assessments based on how many chargebacks they have.
So it seems the credit card system itself will penalize merchants for being risky, and selling a single product using spam for marketing probably makes for some interesting credit report reading. It will not, however, penalize merchants for buying a spammer's services, or for spamming.
I think I mostly already addressed that, but the basic premise is that Visa and Mastercard have rules under which fraudulent activity can be disputed. Products not working as advertised, not sold as requested, not received, etc -- these things can be charged back.
Acquirers are financially responsible for making sure chargebacks work. If a merchant charges credit cards, receives money, spends the money, and then chargebacks happen, the acquirer must charge the merchant to get those funds back. If the merchant doesn't have the money, the acquirer/merchant relationship goes into collections just like any other business that doesn't pay its bills.
Acquirers don't like when this happens. Sometimes when this happens the merchant never pays and the acquirer loses money. Acquirers try to prevent this by restricting the types of businesses they accept and having strict credit and business history requirements. Also sometimes acquirers accept "iffy" merchants anyway and mitigate the risk of loss by holding on to the merchant's money for one or more months. One acquirer I used to work for (DPI Merchant Services, in the news recently for being hacked) tended to take on the really scummy merchants -- bad credit, no credit, no problem, as it were -- they just required a working sample of the product, and made the merchant wait several months to receive their money.
So the bottom line is -- no matter what the spamming merchant is selling, it has to be selling goods as advertised and shipping them in a timely manner for their sales to happen without getting charged back. And if their sales get charged back, they don't get to keep the money. If lots of sales get charged back, they don't get to keep processing credit cards. Credit card acceptance is a privilege, not a right.
--Michael Spencer
First National Merchant Solutions
(a credit card processor or 'acquirer')
First National Tower, 27th floor
1620 West Dodge, Omaha Nebraska, 68197
http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
The magnetic stripe contains extra information, not just the card number. A merchant conducting fraud would have had to see the magnetic stripe once to be able to copy it. J Random Spammer-service-purchasing merchant probably will never have seen the magnetic stripe. It's also safe to assume that merchants won't share magnetic stripe information -- merchants generally don't like chargebacks, so they don't like to do things that promote fraud.
(It is, however, possible that some spammer could partner with someone's credit-card-accepting gas station, and start stealing stripe information that way. What makes this unlikely is that if a large number of fraudulent transactions involve account numbers that all seem to have done business with a single gas station, Visa and Mastercard will see that, and will conduct an investigation. Visa and Mastercard then have the legal power to assess *serious* fines, per the signed contract the merchant has with their acquirer -- and then there's criminal charges for fraud and whatnot. The details of any criminal stuff are outside my experience, so I'm just guessing.)
In general, keep in mind that while a good deal of the approval process and payment process is automated, there are humans involved in confirming and reviewing every step of the process. There are businesses with financial interest in making sure merchants conducting fraud (or even just high-risk merchants) get closed, and that the rate of fraudulent transactions gets reduced. Visa and Mastercard change their rules as well -- their regulatory commissions meet twice a year and enact changes when necessary. Perhaps their idea of what "needs to change" can be different from your idea of what "needs to change", but the whole system keeps spinning as long as everybody involved keeps making money. The system tends to punish bad behavior financially, so everyone is financially motivated to do the right thing w.r.t. credit card activity. (That is, it punishes a high rate of fraudulent transactions. It doesn't punish immoral things like doing business with spammers.)
--Michael Spencer
First National Merchant Solutions
(a credit card processor or 'acquirer')
First National Tower, 27th floor
1620 West Dodge, Omaha Nebraska, 68197
http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
I'm going to illuminate a dark spot in your argument, because I work for a major credit card processor.
For Visa and Mastercard at least, there are many parties involved in credit card transactions.
* Cardholders are obvious. You, me, anybody can be a cardholder.
* Issuing banks -- these are the companies who actually issue the card, and who own the account the card is attached to. They are responsible for handing out authorizations (approvals, declines, etc) and for moving money between that cardholder's account and the Visa/Mastercard payment transfer system.
* Associations -- there ain't too many of these. Visa is a payment transfer association. Mastercard is a payment transfer association. These associations have rules and regulations, and they interface with a *vendor* in a technical way, and with issuing banks and acquirers in a business/financial way.
* Vendors -- think communications providers. Yes, I thought it was weird terminology too, but in the credit card processing world a 'vendor' is a communication provider of some kind. Vital Processing Inc, BuyPass, NDC, FDR, ADS/SPS/Vectrix, these companies all provide servers and communication paths that help get businesses and banks communicating and doing transactions. These guys have no *financial* link to any transactions.
* Acquirers, like the company I work for. These companies are responsible for coordinating the technical stuff that gets merchants talking to vendors, *and* for establishing and maintaining the business/financial link between the merchant and the association. Merchants sign a contract with an acquirer, and the acquirer is bound by Visa/MC regs -- so the merchant is bound by visa/mc regs. The acquirer is ultimately responsible for its merchants.
* Merchants. These are businesses that want to accept customer payments via credit card.
OK, enough background and terminology. How anonymous can you be if you accept credit cards? How anonymous is the money that passes through the system?
Not very. Not at all, actually. When a merchant signs up for a "merchant account" with an acquirer, they usually pay a rather hefty application fee. The acquirer knows they will be ultimately responsible for this merchant, so they do their homework and make sure this merchant is a good risk.
Why do acquirers have to be so careful? The "case study" threat model to defend against is: merchant runs advertising campaign, gets hundreds of thousands of dollars in credit card sales. Merchant takes these hundreds of thousands of dollars and "runs for the border", disappearing without a trace. After a while, customers start figuring out they aren't getting their widgets and ask their issuing banks to issue chargebacks. Chargebacks come rolling in; acquirer is now responsible for paying back all of that money. Acquirer will now pass those charges on to the merchant -- oh, damn, wait, they're long gone. Acquirer eats the loss. Ow.
Acquirers fight this in several ways. First, they're very careful about who they take on as merchants. Thorough credit checks, sometimes required examples of products, and high standards. Second, for high risk merchants, an acquirer will sometimes withhold payment for a certain amount of time. If an acquirer believes that most customers would issue chargebacks well within 90 days (even though they have up to 6 months) it can hold onto those funds for 90 days. If the merchant ships the goods it promises no chargebacks appear, and the merchant gets their money. If the merchant doesn't deliver goods, the acquirer still has the funds on hand so it can pay the chargebacks out of the merchant's own funds.
With all this in mind, I have some problems with the parent post. I don't believe there was a breach of trust -- the system works the way it's supposed to, because of chargebacks.
Issuing banks are supposed to be fairly liberal about who they grant authorizations to. They can return authorization responses in one of three categories: basica
I think you're exactly right there. I think there's an important distinction that needs to be made, though. You weren't trying to confuse the issue -- you bring up a valid point. I'll highlight it a bit more.
Without considering RFID tags, there's already a difference between the amount of information law enforcement can derive from a card number, and the amount of information a merchant can derive from a card number. Generally an issuing bank won't give personal information to a merchant, and in some circumstances will only confirm (yes or no) whether or not specific details are correct (like the customer's address, but not like the customer's social security number or current balance).
For law enforcement it's a different story. Banks are sometimes required to give personal information to law enforcement officers as part of an investigation. These requests must be documented and always leave a paper trail.
Beyond that, I don't know much about how issuing banks handle these requests. The division I work for (First National Merchant Solutions) doesn't issue credit cards to customers, and my department never deals with law enforcement.
Everything I say beyond this point is speculation, and is *definitely* not meant to represent the opinion of my employer, First National Merchant Solutions.
I think if a government agency could convince enough issuing banks to both cooperate with a mass investigation like that (members of a crowd identified by RFID tags), and not complain about it/resist it in court/issue a letter to customers or a press release about it...and could convince enough retailers to do the same...then the threat model you describe is reasonable and realistic.
I'm not world-wise or business-wise enough to predict whether or not banks and merchants would go along with this, actively support it, passively resist it, actively resist it, or what.
To be clear, though, this threat model wouldn't work for private firms. Issuing banks need to cooperate to give the investigator any chance of tying account information to a personal identity, and they generally don't cooperate with curious private individuals or firms.
(I'd also like to acknowledge: the poster I'm replying to was not trying to suggest that this threat model works for private citizens or firms. I just wanted to bring the difference out in the open for more discussion.)
--Michael Spencer
First National Merchant Solutions
First National Tower, 27th floor
1620 West Dodge, Omaha Nebraska, 68197
http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
When you swipe a credit or debit card, the merchant can read your name, card number, expiration date, and some card verification information. They are already *forbidden* from storing the card verification information after they use it to process the sale. When a merchant signs a contract that enables them to accept payment via credit card, some clauses in that contract allow their processor (acquirer) to charge them fees or fines, especially if the acquirer is charged fees or fines by Visa or Mastercard. That means -- Visa and Mastercard have the power to fine merchants for behaving badly. They can also revoke a merchant's ability to accept those kinds of credit cards.
Merchants are allowed to store the customer name, card number, and expiration date from the magnetic stripe.
What does a customer name, card number, and expiration date get you? (besides 'paid for your transaction') Assuming the name isn't already unique...
Sales can happen in one of two major "processing environments": card-present (where the merchant swipes the card, and proves to the issuing bank that the card really was there, by demonstrating knowledge of some of that secret card-verification information on the card), and card-not-present (where the card number is sent via mail/phone/fax/internet).
In card-present sales, the merchant only has the card number and name. If companies (like Radio Shack perhaps) insist on having a name and address on file for each customer, they could run into problems: if a customer finds that such-and-such company is refusing to accept Visa/Mastercard CARD-PRESENT sales when the customer refuses to provide a name and address, the customer can complain to their issuing bank or to Visa or Mastercard directly. Those payment-transfer-organizations might conduct their own investigation (plain-clothes customers), and if the merchant is found to be refusing to accept Visa/MC card-present sales without address information, they can be stiffly fined or have their processing priviledges revoked.
In card-not-present sales, the threat model you discussed is reasonable. Best-practices say the merchant should perform an address-verification check, confirming that the address the customer provides matches the billing address the issuing bank mails statements to. If the customer claims they are shipping the goods to another address, the merchant should require the customer to contact their bank and have the bank "whitelist" the new shipping address, because the bank can then confirm all the personal information the merchant isn't allowed to have.
So I guess a merchant in California could be paid off by some marketing company, and could ship RFID-enabled goods to a customer in New York, and report the RFID information so it's trackable.
You could NOT, however, reasonbly expect that by just swiping your credit card in Wal Mart, Wal Mart suddenly has all your personal information. They could, possibly, associate different products with the same customer, but they wouldn't know anything other than the card number and name.
----------
In general, keep this in mind: the Visa and Mastercard corporations are profitable. They are 'payment transfer organizations' and want to maximize the amount of money that travels through their system, because they make a *lot* of money off of processing fees charged to merchants. If something happens that makes customers nervous, or makes merchants nervous, they will pass new regulations that try to make that fear go away.
But of course if there's no widespread customer knowledge of this possible threat, there won't be any significant nervousness to worry about.
--Michael Spencer
First National Merchant Solutions
(a credit card processor or 'acquirer')
First National Tower, 27th floor
1620 West Dodge, Omaha Nebraska, 68197
http://www.foomp.com
The opinions stated above are my own opinions, and do not reflect the opinions of my employer, First National Merchant Solutions.
I've had a C700 for about three months now. (has it really been three months?)
:)
:)
2 49 ) which can be set to type a close brace when you type an open brace automatically.
On a normal desktop keyboard, it took me 16 seconds to type the code you pasted. On the C700 keyboard (which is exactly the same form factor as the C750/C760, just different colors) it took me 41 seconds to type that with the unit held in my hands, and 38 seconds to type with it sitting on the desk.
So yeah, you ain't kidding . . . it hurts.
If it's all you have, though, it's better than nothing. (I'm pretty sure the original poster knows all this -- I'm just sharing my experiences.) I've created, compiled, tested, and turned in a C program for a class, completely on the C700. Took me about twice as long as it would've taken if I could've used a full-size computer . . . but I'm not allowed to use a C compiler on bank computers at work, and the time would've been spent reading slashdot anyway.
Hint: there are no open or close curly braces printed on the C700 keyboard, but you can get those characters by holding down Fn and Shift and pressing the keys with angle brackets. Helps to use an editor like MinIDE ( http://www.killefiz.de/zaurus/showdetail.php?app=
(this bit is offtopic, but . . . . I tinkered with my Dynamism converted C700 and figured out what was changed, and then made a howto that describes how to implement most of those changes by hand. No downloads, no copyright violation. http://mspencer.net/stuff/c700conv.html )
--Michael Spencer
I had a TRS-80 Color Computer 2 back in 1985. Some months later, my parents bought Dungeons of Daggorath for themselves to play.
F -8&q=dungeons+of+daggorath&btnG=Google+Sea rch
That game had *atmosphere* -- it was really frightening. The game was a first-person perspective dungeon crawl. Monsters each had their own distinctive sounds, and the sounds were louder or quieter depending on how far away the monsters were. Besides the monsters and your own actions, the only other sound in the game was your character's heartbeat. There were no visible statistics or numbers -- just the speed of your beating heart. Move too quickly, carry too much while running, or get hit too many times, and your heart would beat faster and faster until you fainted or died.
The graphics were crude but effective. The player's viewpoint could only be one of the four cardinal directions. You had to type a command, like "T R" (meaning "TURN RIGHT") and you would shift your viewpoint 90 degrees to the right. Monsters were flat line-art, and the dungeon was made of cells, featureless and uniform. Your character carried a torch, and the game would show dimmer light by drawing lines with fewer and fewer dots.
When you fainted, the screen faded out to black, each line getting dimmer and dimmer until it was only two or three dots, then nothing at all...and you had to listen to the monsters around you moving, wondering if they're going to finish you off before you wake up. If you wake up, the world fades back in, and you're left with a rapid heartbeat and a slim chance of survival if creatures are around. Overexert yourself in your desperation to get away and you might faint again. You have to stumble through the maze, looking for a dead end, hoping the monsters won't find you.
Most players had to use the audio tape based save and load feature, because completing all five levels of the game could take several hours. If you took the passive approach, sitting and waiting near a pile of unneeded swords and dead torches, you might find yourself waiting for 5 or 10 minutes for that one remaining powerful monster to find you -- waiting, listening to your own heartbeat, listening for creature sounds, trying to tell creatures apart and gauge their distance.
I think many people who had a chance to try the game were put off by the text-based interface, which required players to memorize commands and abbreviations, and learn how to type certain frequently-used combat commands very quickly. (When I was 10 years old I couldn't touchtype, but I could type "A L ", meaning "ATTACK LEFT", about five times in a second. The ATTACK LEFT command attacked whatever creature was in the same cell as you with whatever was in your left hand.)
If you're interested, search Google for Dungeons of Daggorath. There's even a PC port out there -- the timing is somewhat similar to the original, but not quite the same as the game would be on real hardware.
http://www.google.com/search?hl=en&ie=UTF-8&oe=UT
--Michael Spencer
spam@mspencer.net
If I were writing spam filter rules, I think I would fix that problem with extra rules:
mail sent with gnus and with an Exchange ID: +6.4 points
mail sent with gnus and with an 'X-Cron-Env' header: +6.4 points
mail sent with an Exchange ID and an 'X-Cron-Env' header: +6.4 points
mail sent with gnus, an Exchange ID, and an 'X-Cron-Env' header: +6.4 points
include diff -u output and have 'foo@bar wrote' attribution: +6.6 points
include diff -u output and have quote text: +3.3 points
include diff -u output and have 'In-reply-to': +3.3 points
mail has 'In-reply-to' and an 'X-Cron-Env' header: +6.4 points
In total, the message would then have -45.135 +45.2 = 0.065 points.
That's an interesting idea. If someone can come up with a way to do this that doesn't sacrifice filenames, it'd be almost good enough to implement.
----------
Suppose that the servers return the list of hashes that each search result would have matched. These hashes still can't be 'reversed' back to the original words.
When the client creates a list of possible results, suppose that the client uses a dictionary file to try every combination of 'extra hashes that I didn't search for' to try to find the other words that were probably in the file. If the user finds that the file contains fifty 'catch' words instead of words directly relating to the original search, the user can choose to not download the file.
----------
Here's another try.
The example I submitted to Fred von Lohmann already assumes that the index servers aren't allowed to collaborate, because every host on the network knows whether a host is an index server or not.
Suppose that the clients are running a network service such that they can answer queries for a given 'file number' or 'file reference' with the original filename, size, etc.
The index server is not allowed to connect to this 'filename lookup service' because the clients all know the network addresses of all index servers. They can simply refuse to answer queries from index servers.
Note that some Napster clients already ping every returned search result.
----------
I believe this can be implemented, as a Napster server replacement. This sounds good as I read it back to myself, but it's bound to be full of holes. Please tell me if anybody notices anything that doesn't seem right.
Suppose we create a custom program that's designed to work with existing Napster clients and with existing OpenNap servers. The program runs on the user's computer. It emulates an OpenNap server running on localhost, so the client can connect locally and pretend it's talking to a normal Napster server. It's also using this special hashing logic to talk to existing OpenNap servers, masquerading as a Napster client.
The (real) Napster client has its own list of shared files, probably indexed by actual filename. It can send search queries and receive search results.
The fake Napster client built into our special program has its own list of shared files -- one list for each hash type.
When the real Napster client wants to share its list of files with the world, it talks to our fake Napster server (running on localhost). It shares all of its files (with full filenames). The fake Napster server then hashes each of the words in the shared files' filenames and sends those hashes to the actual OpenNap servers out on the internet.
The OpenNap server sees "F3B 892 B22". The fake Napster server running on localhost sees "suchandsuch 02 -- soandso.mp3". So now the OpenNap server is full of bogus-looking results that point to bogus files on real machines. The real OpenNap server might think that this "F3B 892 B22" file exists on the IP that shared it, but the file doesn't really exist.
When the real Napster client wants to search for a file, it sends its search to the fake Napster server running on localhost -- our special software. The local machine then splits the search up into three parts, as described in the article. The hashed search items are sent out, some very long lists of results are sent back, and the local software processes the three result sets into one result set. It then queries the IPs returned, looking for original filenames.
As far as the Napster client is concerned, nothing has changed. They still get search results with full filenames, and they still get the real IPs of people to download from. The downloading mechanism still works exactly the same.
As far as the OpenNap server goes, people seem to be sharing lots of bogus files, or files with odd filenames. (instead of 89B we could use phonemes: ha-chi-ro-ni-ku-ba but without the dashes) And so many people are searching for the same odd words, that people keep requesting search result sets over 200. I hope the server operators decide to increase their max search result set.
And the result: just as Napigator enabled Napster clients to connect to nonstandard servers while still making things very easy for the end-user, our 'transparent' program can be used by simple end-users without requiring them to learn anything new.
Searches will take several times longer to complete -- but they won't be filtered any more.
----------
Anybody feel like starting a SourceForge project? ^__^
--Michael Spencer
blocks@mspencer.net
Fred von Lohmann was also talking about this when he referred to 'automated [data] reproduction' in his reply to me.
I think there is a range of legitimacy for automated data reproduction acts. Large internet routers obviously should not be forced to shut down because some of their routed traffic may be infringing. On the other hand, a custom program or script designed to hide the identity of an OpenNap server by forwarding requests to the server and forwarding responses back is more likely to be required to shut down.
Someone should probably ask Fred von Lohmann about 'prior restraint to speech', how he believes that was addressed in the Napster case, and how he feels it might be addressed in the future. He's already given us a very wise statement about this: "In the final analysis, a court will probably not be sympathetic to a system that is seemingly designed to frustrate the legal system."
Only a lawyer can tell for sure, but my layman sense of right and wrong tells me that we shouldn't be forbidden from protecting the anonymity of people. Sometimes anonymity protection is used to evade law enforcement...sometimes it's used to keep our personal information out of marketing databases...sometimes it's used to keep people from being assassinated by other governments or organizations.
--Michael Spencer
blocks@mspencer.net
The idea that struck me the hardest from Fred von Lohmann's reply is "substantial noninfringing uses". I already stated in another post how I believe that the ideal filesharing client will be a successful implementation of many ideas in one program.
Hopefully law will follow logic here. If this filesharing network enables something that should be illegal, but is composed of many different parts which are all individually legal, it should follow that the process of combining these legal activities should not be illegal. The *intent* and the *actual usage* can be used to gauge the legality of the whole system.
Note that Usenet isn't illegal. (I missed that too -- I think I wasted some of Fred von Lohmann's time by making him explain that.)
Perhaps the most successful implementation of 'the perfect filesharing client' will create a large number of individual services that have tons of non-infringing uses, establish their value and their common use, and then all at once build a filesharing program that connects them all.
I think that's what you just said. Movie trailers, convention broadcasts, etc.
--Michael Spencer
blocks@mspencer.net
(use my IP's ARIN contact to reach me IRL)
I really never expected this to be worthy of Slashdot's attention.
(note: I started the email dialogue with Fred von Lohmann back on August 3rd -- I wrote the indented text in the InfoAnarchy article. Fred replied on the 8th, and I posted it on InfoAnarchy on the 9th.)
I think there are a lot of interesting ideas out there -- we have some very powerful technologies to use, but each one satisfies a different need. Someday someone much smarter than myself will find enough connections between enough individual ideas to find a way to connect them all. I think the perfect filesharing network must use lots of cool technologies -- the combined technologies of several current projects.
Fred von Lohmann wrote an excellent paper that addressed the potential legal liabilities of *developers*. In open source applications and serverless peer-to-peer networks, the developer can be invisible or anonymous. If there are no servers, the only thing left to consider is the users -- the peer nodes.
My first question to him was basically rephrasing the kind of caching and forwarding that programs like Freenet and Blocks do.
The second question was based on an idea that an InfoAnarchy user started in an article's comments. I had always assumed that index servers will be a filesharing network's weak point -- the point where index data is being traded is the point where an attacker can best censor the network.
This idea would really suck to implement. Your clients wouldn't even get to see the filenames of their search results -- they would have to trust that the hash system worked properly and that all of their search results are valid. I don't know about you, but I'd hate that. I'd be uninstalling that program in a heartbeat.
But what if that was all there was? What if every other filesharing system with an index server was whitelisted, media company controlled, or was otherwise restricting access to certain information? If a user's alternatives are either a mangled no-filename service or a whitelisted service...or no service at all...perhaps they would choose to use this idea.
Or in other words...it's technology. It's a tool. It doesn't work in all scenarios, but there may be a situation where this idea works better than any others. It's not a good Napster replacement, not by a long shot, but we should file this idea away and use it later instead of dismissing it because it isn't a magic solution.
In my experience, information security is a tradeoff: security for convenience. To gain security you usually have to lose some measure of convenience. Really smart and well-designed security solutions can give you a lot of security for very little sacrificed convenience. Some other security solutions can give you a very small increase in security for a great loss in convenience. (For example, if a bad system administrator sets his NT servers to require frequent password changes with excessively complex passwords, in an environment where users are known to write their passwords down on post-it notes anyway, you're taking a lot of convenience away from users without giving them much extra security. They'll just use more post-it notes than before.)
I have a few more ideas that may present interesting legal situations if they ever get implemented. I'll keep InfoAnarchy.org updated if Fred von Lohmann and I have any more interesting discussions.
As a parting shot: Don't blame the hackers for all of this widespread copying of copyrighted media. We aren't the ones who sold millions of *general purpose* PCs to millions of consumers. They already have the tools -- we're just helping them use their tools to maximize the rights they already have.
--Michael Spencer
blocks@mspencer.net
Last year my former company had an internet security incident. The attacker used an account with a normal ISP to try the hole, and then reconnected with a NetZero account to perform the attack.
The short of it: I would partially or completely firewall the 4.0.0.0/8 class A -- the company responsible for this network allows people to sign up with bogus account information, and doesn't provide 'common courtesy' help or information when requested. Do you want anonymous IP addresses making SSL connections to your web store? Do you want anonymous IP addresses making connections to your network at all?
The long story is, while talking with Genuity Networks I discovered:
The 4.0.0.0/8 class A contains all of NetZero's dialup IP pool, as well as some non-NetZero Genuity Networks customers.
(The name NetZero wasn't obvious in the DNS name...but when a reply to my initial email to them came back with a call log number and (NetZero) in the subject line, I figured it out.)
Genuity Networks *refuses* to tell you which IPs are the NetZero dialups in your area, so you can block them. I didn't want to block the entire 4./8 class A, so I did something I probably shouldn't have: I put together a shell script that ran nslookup on every address in the 4.4./16 class B. I came up with about 12 class C networks that have 'omaha' in the reverse-lookup DNS names. I firewalled those.
(I was so pissed off at the lack of help I received, I was considering replying to the message, cc'ing the original abuse address, but editing the sender's portion of the message so it looked like he told me which networks to block, and that I thanked him for the information. I never sent the mail though.)
--Spence
Perhaps this is why we need security features in peer-to-peer clients.
m sp encer.net/piratestuff/bigfile.iso
Blocks was an example of a filesharing client with too much security. It was well-designed and cross-platform, but required too many resources and too much security for...well, anybody except the most advanced users. It would be very difficult to find the IP number of someone sharing certain content on the Blocks network. It's also almost impossible to even find a file on the Blocks network.
Perhaps what we need is optional security. Some users are going to want to form a mixnet, and only directly communicate with trusted peers. Some people want encrypted disk caches, so if their computers are seized, it'll be impossible to tell exactly what they're sharing. Conversely, some people would like an easy way to tell whether content is copyright-protected and shouldn't be traded, without directly notifying anyone that they've come into contact with the content.
I've outlined some security concepts in a quick page I've put together: http://mspencer.net/fs. It's a work in progress, and is very long (22 KB and growing) with almost no index or table of contents. But if peer-to-peer filesharing is a topic you are enthusiastic and excited about, you'll find the page very interesting. (There are no ad banners at all on that page -- just text, except for my email address. I put my email address in a graphic, to spam-proof it.)
From the page:
Does all of this seem seedy? Do you think people will assume that anyone who participates in any of this extra security or identity protection is automatically a criminal? Remember that this is what computers do -- they take complicated things, and take the manual labor out of them. Sure, some of these methods may seem like seedy criminal behavior turned digital -- but this behavior is usually criminal in real life because it's so costly! It takes time and effort to route anonymous messages around -- take a 'layered' envelope out of the mailbox, unwrap only one envelope leaving (an envelope still inside, possibly with more envelopes inside that), and mail it out again. Pass things around by word-of-mouth only. Use aliases. In real life, these things are difficult to do and take time and effort...so it can be concluded that the people doing them probably need the extra security or protection. That is, they're probably doing something illegal, so the extra 'cost' is worth it. But this is digital -- these are computers we're talking about. It's very easy to let the computer stand out on the streetcorner for us. We're not peddling high-value illegal material -- many of us merely don't want certain advertising companies using our personal information to enhance their seedy business. This 'shifty behavior' becomes worthwhile at the half-penny-per-transaction level, because computers do all the work. Were it the real world, this same kind of 'shifty behavior' would only be justified at the tens-of-dollars-per-transaction level.
Such a system is possible, if enough motivated and excited people get together: adapt and borrow concepts from other projects. The other projects out there (MojoNation, Freenet, Blocks, ELF, and many more) have wonderful concepts and design, and they do a very good job of solving a particular problem with filesharing. But they don't solve all of the problems.
Perhaps if enough p2p project developers are inspired to bring their concepts together into one system, we'll finally rid our gift culture of these pesky intellectual property lawyers.
On a related note...I just thought of this really evil way to abuse three existing services (WWW, DNS, and Akamai proxying) to provide a kinda-anonymous web site:
1) Use an existing DNS zone to point an NS record for a subdomain to a special kind of DNS server. (Perhaps *.anon.mspencer.net)
2) Create a special DNS server (special software, or just firewalled) that is only allowed to hand out DNS query replies to Akamai servers.
3) Publish a URL:
http://a1.g.akamaitech.net/6/6/6/6/lmnop1.anon.
It would be impossible to get the true location of lmnop1.anon.mspencer.net unless Akamai servers were cooperating with you.
--Michael Spencer
(remove the first three letters from the email address above.)
When AOL got a connection to the same Internet the rest of us are connected to, I'm sure someone explained to them:
There is no support for per-connection billing and accounting, a la X.25, built into IP. When you are on an IP network, anyone else on the network can communicate with you, unless you explicitly firewall them. When you run a service on this public IP network, you accept and agree that anybody can interact with that service, unless you specifically disallow it.
Of course, people are allowed to build identification and accounting into their protocols to support anything they want. If they want to charge me for using their AIM service, they have the right to. Simply require authenticated logins (as they already do) and don't give those logins out for free any more.
Now, the point: there is a difference between using or complaining about AIM the network service, and using or complaining about AIM the executable program for Windows.
AOL gives AIM service for free to everyone else. I paid my bandwidth bill for the month too.
I'm sure AOL understands that some people will try to use their network service with non-AOL-provided software.
What AOL has done recently is attempt to tie AOL the network service to AOL the Windows executable.
It is within AOL's rights to try to do this.
It is within my rights to try to undo this, by publishing software that is compatible with the new version of their network protocol.
Would you mind re-explaining what we don't have a right to do again, as it relates to network services and applications being different things?