Telemarketers generally have their own phone switches. But they have to get service from a phone company in bulk with a big trunk line somewhere. Even for outgoing calls, there has to be a phone number involved (even if there are more lines than numbers). The phone company has to know the number(s) provisioned on that line. So they can check the caller ID info being passed along to see if it is one of the provisioned numbers. If there is no caller ID info at all, it should be substituted with the master number for the line (unless there is a reason that customer should be able to go anonymous, such as law enforcement). If the caller ID is one of the listed numbers, let it pass (this would allow spoofing of another phone number within the company, such as sending all callbacks to the inbound call center). If the caller ID does NOT match, then block the call and do not even let it be made. The same goes with the caller ID name as for the number.
This is not hard to do. It only needs to be done during the call setup. The data only needs to be a list of valid phone numbers and valid name strings.
But there is one reason they will never do it: it makes too much sense.
Then those commercial mail servers are "broken" and must face the reality that many peer mail servers will elect to refuse email from them in the future. It's something that needs to be fixed.
Yes, this is a best practice. If it required a violation of SMTP to work, there would be big problems with it. That leaves either being exactly the same as SMTP (it isn't) or being a subset of SMTP. So the issue that it faces are people that say their mail server complies with SMTP and so they will leave it as is. My counter argument focuses on a subtle point where SMTP implies sending the NDR to the sender: they are violating SMTP if they send the NDR to the forged email address (that isn't the sender... the spammer is the sender)... if there is a way to avoid doing so (and there is in virtually all cases).
BTW, SPF is not the only way to determine reasonable validity of the sender email address. There is one test that for most domains will yield a true positive for legitimate email. It just needs to be understood that when it fails to yield a positive, that does not mean a negative (it means another means of validity checking is needed). That test is to see if the SMTP session peer sending the email is the MX host of the asserted sender email address (the peer IP address must match one of the A-records of one of the MX hosts). If it is, that mail server had the chance to validate and so we can assume it did. If not, then check SPF or other means to see if it is some domain using separate outbound servers or such.
Any mail server receiving mail from outside of its administrative control needs to verify at that point if the email is deliverable. It needs to do the user lookup (got LDAP?) and anti-spam filtering right then. It also needs to check any quotas, then, as well (but this can be put in a database). Any server that can't do these lookups needs to either be taken offline or needs to just toss undeliverable mail into a blackhole (almost all of it will be spam because legitimate mail is very rarely sent to an undeliverable location). If it can't do quota checks, then don't have quotas (disk space is cheap, get over it).
There is very little need these days (of permanent internet access links) of having email hop from one server to another. Having a front end server to face the internet and a backend server to host the mailboxes is fine. But just make sure the front end can know what it needs to know to do its job (and not blindly forward everything). Front ends are where spam rejection should always be taking place.
In the end, there is no cause for a bounce message to go between email administrative zones (because the server that might send such a bounce cannot verify that it is complying with the SMTP requirement that such a bounce message go to the sender... the true sender, not the forged email address).
The birthday paradox involves a population in which finding ANY two (or more) of the same is considered a match. That does not apply to a TCP header checksum because the comparison needs to be made against ONE SPECIFIC checksum (e.g. the one the packet in question has). You get a packet and it has a checksum. You calculate a checksum from the data. Do they match or not when the data is corrupted? That's not a birthday paradox.
The birthday paradox DOES apply in cases where you want to create TWO packets with the same checksum, but it doesn't matter which checksum that is. You can create two messages with the same hash in the case of cryptography where there is a weak hash. But in the case of error checking, it's not about creating any pair of matching checksums; it's about creating one checksum that matches one you already have that you cannot change. In birthday terms, it's about finding someone in the population that has the same birthday as you do.
OK, it's 16 bits. My bad. TCP bad. But birthday paradox does not apply here.
Flipped bits happen, but they are detected by multiple checksums which make it astronomically unlikely for corrupt data to remain undetected.
I actually saw this happen once... the astronomically unlikely [1]. TCP accepted the corrupt packet. I'm sure it will never happen again. Fortunately, rsync caught it in the next run.
One problem I ran into once with a certain Intel NIC was that a certain data pattern was always being corrupted. TCP always caught it and dropped the packet. There was no progress beyond that point because of the hardware defect always corrupted that data pattern. Turns out there was a run of zeros followed by a certain data byte (I tried a different data byte and with different run lengths and those never got corrupted). What the NIC did was drop 4 bytes, and put 4 bytes of garbage at the end. I suspect it was a clocking syncronization error. I got around the problem by adding the -z option to rsync (which I normally would not have done with an ISO of mostly compressed files). Another way would have been to do the rsync through ssh, either as a session agent (like rsync itself can do) or as a forwarded port (how I do it now for a lot of things).
[1]... approximately 1 in 2^31-1 chance that the TCP checksum will happen to match when the data is wrong (variance depending on what causes the error in the first place)... which approaches astronomically unlikely. Take 1 Terabyte of random bits. Calculate the CRC-32 checksum for each 256 byte block. Sort all these checksums. You will find 2 (or more) data blocks with the same checksum (or a repeating pattern in your RNG). Why? Because CRC-32 has 2^32-1 possible states, and you have 2^32 random checksums.
But whatever the cause, it's almost certain that software is to blame.
Agreed. Since it is at least software's responsibility to detect and fix it, if the problem happens, the famous finger of fault points at the software.
I'd bet $100 that if he did the same download over HTTPS, thus preventing software meddling of the packet contents, it would come out perfect.
If you asked me whether Linux sucks, I'd unequivocally say..."Yes it does, and it does so big time." All because of a remote control that does not work.
If you asked me whether Hauppauge hardware sucks, I'd unequivocally say..."Yes it does, and it does so big time." All because of an OS that does not work.
NY could easily pass delivery tax and make UPS and Fed-ed collect the tax for them.
Based on what? The weight? This would be adding an entirely new infrastructure to these companies. And it won't account for online delivery like iTunes.
However much I dislike the taxes, I hate discrimination and government loading the dice and making the playing field slanted. The brick-and-mortar companies in New York are obligated to collect sales tax for NY. That includes you corner diner and the mom-and-pop store selling used books. There was a time when compiling 50 state sales tax codes or even 25000 local county tax codes and making businesses outside complying with these code was technologically impossible. But now that excuse is not valid anymore.
Actually, it is still rather hard to collect varying percentages. They don't split up the different tax rates by zone. They don't categorize different products that are taxable and non-taxable by any consistent pattern. The software in development for this is bloated, complex, and generally not practical for all but the largest of retailers (Amazon could work with it, but clearly even they don't want to).
They could fix this by simply publishing a table, indexed by zip code, which lists the tax rates and which agency they are to be sent to. We still need a national standard for things like how often to send the collections in, as well as the way different types of products are categorized (the definition of "food" varies from state to state, for example).
Why should brick-and-mortar sellers have the advantage of not having to deal with multiple tax rates, and not having to worry about where their customers live? To be fair, they need to impose the same level of requirement on all sellers.
Then there is the issue that many sales are delivered online and the seller won't know where the buyer is located since they aren't shipping anything to a physical address. The buyer could be located in another country. Or they could be located in a state with no sales tax (your reference to "50 state sales tax codes" is not quite accurate).
But, I have a solution for you to consider. It's not a perfect one, but it will go a lot further than anything I have seen proposed so far. That solution is to have the payment processors collect the tax. That means your credit card company, or PayPal, or your bank, etc. Congress would have to establish a law that makes this universal. That law would have to spell out a category table of product types. Different tax jurisdictions would have to conform to these product type codes to benefit from the process. The seller reports to the payment processor, in addition to the amount they are charging for what is sold, an itemization of amounts under each category for which they have not collected a tax for (the federal law would not be applicable to entirely in-state transactions, so there can still be cases where the seller paid tax to the state they are in, for customers in that state... unless the state elects to have in-state sales work through this system).
Your credit card company or bank will more readily know which sales tax jurisdiction you live in. They will calculate the correct sales tax, take it out of your account, and send it to the state on the regular schedule (or even do a direct electronic deposit). The state would then distribute it down to the local jurisdictions. The seller won't deal with it beyond the reporting criteria. Penalties for incorrect reporting would exist, of course.
The states benefit from a uniform collection method. Sellers benefit from a simpler system and not having to track where customers are (especially important when they don't know where customers are). States benefit from having fewer entities they have to deal with (imagine having to account for, and spot check the accuracy of, tiny discrete tax collection payments from half a million web site operators through
Next thing we'll have is DRM enabled printing that refuses to print this story unless it gets printed with self-erasing ink. But you can print it on permanent ink if you are a registered user. Registration is free. Enter your SSN here.
Is that Linux, BSD, Sun, AIX, and whatever are just as vulnerable when it comes to dumb programmers.
The million dollar question is what platform and which web server is it easier to reinstall to get the site back up.
I think Linux and BSD have the advantage.
Actually, the damage is to the database. The fix is to restore from a backup taken from before the attack, resyncronize with records sanitized for the inserted bad data, fix the vulnerable code, and bring the database and web application back up.
I agree that this is not an IIS problem. IIS is just a convenient target. And it may also be the case that users of IIS are less likely to do proper data sanitation than those who can't use IIS. But I would argue that SQL is a major target of blame.
Long long ago when I first learned of SQL, it was described as a command line language which would allow people to do innovative database searches. I saw several examples of such. The lecturer was even typing them in manually. It sure looked like a really great tool, both for the database administrator, as well as for people that needed to work directly with the data in relational databases. What never came across at that point in time was that using SQL was the primary way for programs to access the database.
Later I found out the hard way that this was necessary when a program I was developing needed to get some data from the database. I almost lost my lunch. It was bad enough that user input data might be used to open a file by name. But at least reading and writing of files was done specifically by calls inside my program and didn't involve constructing strings to be parsed and interpreted somewhere. Now with the need to access something in an SQL database, I immediately saw a huge problem.
I was working with the DBA on this aspect of my project. He told me what SQL I needed to use for what I wanted access to (I didn't know any SQL at that time). I just needed to insert certain pieces of data describing what I wanted at specific places in the (rather largish) SQL commands he gave me. I could see the exposure immediately, as well as some solutions. So I just mentioned something like "I'll need to filter this so I don't have quotes in the string". He asked why. I asked "Won't a quote in the data look like the quote that ends the string?" He replied, "I guess so, but then you'd just have a syntax error". "What if someone inserts valid SQL after that which ends in a quote to start a new string?" And his reply "Why would anyone want to do that?". I just shook my head and proceeded to write code that removed everything but letters and numbers.
Had relational databases also had a means for more direct access (turns out some do) that doesn't involve any SQL, they might be safer. But what was really needed as a part of any database access library is specific code to be used to construct the SQL command line that applies all the necessary data sanitation. Even to this day I don't know if a quoted string in SQL can have a quote embedded with an escape (I never used SQL enough to need to know). If it can, then the calls to insert a quoted string in the SQL command being built should escape quotes in the C string being passed to it. If not, it should just remove them (and then you can't use quotes in a string for anything).
Maybe I should not have been so amazed at the lack of security thinking back in the 1990's when this took place. I was amazed, nevertheless. But I can see how back when they developed these interfaces, they would not have thought about all this at all. Based on all the security problems I have seen since, being amazed back then was clearly out of place. And it was a web application I was developing. Hopefully, they aren't running it anymore. But if they are, it's probably a whole lot safer than others developed by other people in that era (and, unfortunately, even those developed today).
Yes, programmers of the web applications are significantly to blame. But SQL should have included the tools to make constructing safe SQL from unsafe tainted data work in a safe way... and made those tools the standard way to do things (not unsafe tools like sprintf from the C library, or similar from languages used today).
In summary, my blame (mostly) points at SQL itself.
I'll admit, what I do know of the RIAA is they are extremely heavy handed, so much so that it's entirely possible that innocents are wrapped up in their vendetta. They are sloppy, thuggish, and an out right bully. What can they do? What would you do, just start giving away that which you make your living on? Is that the answer? Is that what everyone wants?
Maybe what they should do in the few cases where it becomes obvious that they made a mistake and sued the wrong person is to stop the lawsuit and offer to pay all the costs incurred by the victim. That wouldn't be enough, but it would be damn good start. Or at least, just stop the lawsuit? No, these guys just press on. That is the same tactic used by some debt collectors even when faced with proof that they are collecting invalid debts or collecting from the wrong person.
Wanting to collect from people that steal from you is one thing. Trying to be a bully just to scare everyone else is another. And being that bully against people that didn't steal from you at all is altogether worse.
Maybe somehow I left behind on this whole internet thing, since I don't use Gnutella or Bittorrent. I pay for the stuff I use and listen to. I guess I'm a fool for seeing value in the arts that I love in my life, a value worth paying for.
Believe it or not, there are people that download music from various sources just to get a sample to determine what it is they like and don't like, and then go buy what they like. Maybe the RIAA is upset they no longer buy what they don't like?
The email address the Usenet post claims to be from is not authenticated in most Usenet servers. Maybe Google Groups now limits these to be Gmail addresses; or maybe not. But what I have found is that virtually all of this recent dramatic rise in spam on Usenet is from the actual Google Groups servers, with googlegroups.com in the Message-ID header (not gmail.com). I could not see any means for a Google Groups user to override the message ID, so I blocked all posts based on the message ID. Since the message ID is part of the index data, these posts can be blocked before their contents is obtained. So this works and gains the efficiency of not pulling the blocked post contents at all. This is with the tin news reader. It has nearly completely eliminated the spam with only a small amount of collateral damage (which is mostly people that think Google Groups is just some big web forum). This still lets people who post at other Usenet servers to use their gmail.com email address as the sender address without being blocked.
Unfortunately, Google decided to require using Gmail addresses for all new signups of Google services, and push users of other email addresses to use Gmail addresses. They could not have easily done that without opening Gmail addresses to anyone to sign up for. That is most unfortunate, because the old method of requiring an invitation provided a way to backtrack where spammer signups were coming from. Under the old method, if a Gmail user is determined to be a spammer, the other Gmail user that invited the spammer could at least have invitation credits revoked, and other accounts invited by that user could be closed as well. Without the invitation system, there is no longer any tracking like this. IMHO, what Google should have done was set up another separate domain name for non-invited email users.
What we need to do is get a law passed that mandates strong encryption and proper key handling for all qualifying data (anything with personally identifying information, including SSN, bank account numbers, CC numbers, health information, etc), held by any entity (corporate, organizations, governments), that is transported, transferred, or exchanged offsite by any means (tapes, disks, internet, private data circuits). There should be a minimum violation penalty for cases where the data was not stolen or taken, and stiffer penalties if it was stolen and not encrypted.
There's nothing in the article that says they were encrypted. They were compressed and some kind of encoding was involved. But encoding could be any number of things, and quite possibly the coding used by medical records systems to compact common terms to numbers. It could be hard to make use of the data. But if it was an "inside job", or the perps can get the software used on this, it can be cracked easily. This is not strong encryption.
Proprietary compression cannot be cracked? I can tell you that this can be hard to do. And this is from experience. I once worked at a company where a project one year involved writing some programs to extract data from files stored be various competitor products to enable customers to easily migrate to our products. I was given the one that the managers thought wasn't even possible to do, because the data look like gibberish (because, unknown to them at the time, it was compression). It took me FIVE weeks to reverse engineer it. It was not quite as good as UNIX compress, but it was much better than run length compression.
Whether these data tapes are crackable is unknown to me. But if they were encrypted by today's strong forms of encryption, then I know I could not crack that.
Just because they can get it for free does not mean this will work. Imagine the level of traffic that has to run through it. Who is going to pay for that hardware? They should give them a turnkey box that does all the monitoring, one for each DSLAM.
I'm sure the software has a list of legal download sites. Those would get a pass. And most of those downloads won't be using a P2P sharing protocol, so that's another way around. It doesn't have to be perfect (e.g. get 100% of all illegal downloading). It just has to do enough to discourage people from continuing the practice. Of course the die-hards will figure out how to fool it or bypass it, or crack into the machines running it and change it around to do something else like block certain pro-corporation political sites.
9. People have better means to sample all music these days, and no longer need to deafly buy music they think maybe they might like, but actually do not like (once they play it). So now they buy only what they know they like.
I first bought music in the vinyl LP era. I could not sample the music. I had to read what was on the album to figure out if maybe I might like it. Radio played only a limited set. The record stores would not open albums to play them in the store (because they could not sell that one as new). I ended up with about 60% that I really would not have purchased had I heard it in advance. But it was the norm of the times to actually have a lot music you didn't like. That, or sell them at a used record store (which the music industry wanted to shut down because they knew that much of their sales revenue model depended on people buying music they didn't like). When CDs came along, it actually got worse because less was printed on the smaller cover.
Now I there are plenty of ways to sample the music in advance. Yup, that file sharing thing lets you do that. I'm sure many people cheat and keep their samples. But those of us that actually buy music believing it somehow supports the artists are not buying the music we decide we do not like so much.
There's a chain of evidence which is used to get a person in many universities. It's the same way any ISP would track usage down to a specific user.
But not all universities are alike in how they structure their networks and allocate their resources. They are not even alike in how much resources they get. Marshall University is definitely one where costs are kept as low as they can get them. West Virginia is not one of the rich states.
Users are typically registered. Usually in universities, this is accomplished through a captive portal which records the MAC and username (authenticated with a password.) This ties the MAC to the user.
That would be so at that moment in time, no accounting for the issues involved with students using wireless over their dorm connections.
From there, it's trivial to tie the packets to the MAC--spoofing IP addresses is trivial on most networking equipment in use by universities (i.e. we're not talking crappy Linksys routers, here.) MAC spoofing is rare, but also quite easy to block on the switch, long before any damning traffic occurred.
It's not necessarily easy to block it, as that results in problems moving computers around. And not all switches can block it. Low priced switches, much like a low resource university would have to buy, probably don't have the ability.
Even if it isn't explicitly blocked, it would be a special case that would need to be handled when trying to identify the student, but it is by no means a dealbreaker.
What it means is that after the student who logged in shuts their computer off, another computer that was pinging them to see when they shut off can immediately impersonate that MAC address. Even if most users properly signoff before shutting down or pulling the plug, it only takes a few that don't for someone wanting to run anonymously to do that every now and then.
Of course, if the student is running a wireless access point, you run into problems. This is why some universities don't allow wireless access points to be connected to the network (they can't outright ban them due to FCC regulations) and the university agreements almost universally state that traffic originating from the student's port is considered to be the student's liability.
Then there is the issue that you have multiple students working from the same port. At least 2 live in each room in most of the rooms. There are a few singles and triples there (I went to school at Marshall for 3 years and lived in the dorms for 2 of those years... I know how at least the ones that were there then are organized). So you can at least have 2 students using one port at a time. And it is typical for students with laptops/notebooks to roam around or get together with others in different rooms to collaborate on various projects, school related or not. Student run access points make that so much simpler. Now I don't know if Marshall has every floor in every dorm covered with wireless, but they could see it as a cost savings by NOT doing so, knowing that the students themselves will provide localized access at no cost to the school.
ISPs (including universities) have valid reasons for wanting to be able to track people down. It's unfortunate that the ability to track people down means that they can give up their information when the RIAA comes subpoenaing.
That may be a good goal, but it's generally not practical in a resource limited situation. They may consider it more important to be sure outsiders are not using the network than it is to exactly know who sent each and every packet by its IP address. Knowing that 99% of traffic was carried out by some authorized person on campus may be sufficient. Being able to block that 1% of other traffic might not be worth the cost. Being able to track any instance of traffic to a specific person might not be worth the cost. And i
Take a CNN story like this, edit it to show your company as the culprit including how sales dropped dramatically, set it up on a web server somewhere, fabricate a CNN-spoofing URL to access it, and use an anonymous web email account to send it to those upper level managers along with a comment saying "do you want to avoid a situation like this?".
Slashdot Mirror
I totally agree.
Telemarketers generally have their own phone switches. But they have to get service from a phone company in bulk with a big trunk line somewhere. Even for outgoing calls, there has to be a phone number involved (even if there are more lines than numbers). The phone company has to know the number(s) provisioned on that line. So they can check the caller ID info being passed along to see if it is one of the provisioned numbers. If there is no caller ID info at all, it should be substituted with the master number for the line (unless there is a reason that customer should be able to go anonymous, such as law enforcement). If the caller ID is one of the listed numbers, let it pass (this would allow spoofing of another phone number within the company, such as sending all callbacks to the inbound call center). If the caller ID does NOT match, then block the call and do not even let it be made. The same goes with the caller ID name as for the number.
This is not hard to do. It only needs to be done during the call setup. The data only needs to be a list of valid phone numbers and valid name strings.
But there is one reason they will never do it: it makes too much sense.
Then those commercial mail servers are "broken" and must face the reality that many peer mail servers will elect to refuse email from them in the future. It's something that needs to be fixed.
Yes, this is a best practice. If it required a violation of SMTP to work, there would be big problems with it. That leaves either being exactly the same as SMTP (it isn't) or being a subset of SMTP. So the issue that it faces are people that say their mail server complies with SMTP and so they will leave it as is. My counter argument focuses on a subtle point where SMTP implies sending the NDR to the sender: they are violating SMTP if they send the NDR to the forged email address (that isn't the sender ... the spammer is the sender) ... if there is a way to avoid doing so (and there is in virtually all cases).
BTW, SPF is not the only way to determine reasonable validity of the sender email address. There is one test that for most domains will yield a true positive for legitimate email. It just needs to be understood that when it fails to yield a positive, that does not mean a negative (it means another means of validity checking is needed). That test is to see if the SMTP session peer sending the email is the MX host of the asserted sender email address (the peer IP address must match one of the A-records of one of the MX hosts). If it is, that mail server had the chance to validate and so we can assume it did. If not, then check SPF or other means to see if it is some domain using separate outbound servers or such.
Any mail server receiving mail from outside of its administrative control needs to verify at that point if the email is deliverable. It needs to do the user lookup (got LDAP?) and anti-spam filtering right then. It also needs to check any quotas, then, as well (but this can be put in a database). Any server that can't do these lookups needs to either be taken offline or needs to just toss undeliverable mail into a blackhole (almost all of it will be spam because legitimate mail is very rarely sent to an undeliverable location). If it can't do quota checks, then don't have quotas (disk space is cheap, get over it).
There is very little need these days (of permanent internet access links) of having email hop from one server to another. Having a front end server to face the internet and a backend server to host the mailboxes is fine. But just make sure the front end can know what it needs to know to do its job (and not blindly forward everything). Front ends are where spam rejection should always be taking place.
In the end, there is no cause for a bounce message to go between email administrative zones (because the server that might send such a bounce cannot verify that it is complying with the SMTP requirement that such a bounce message go to the sender ... the true sender, not the forged email address).
The birthday paradox involves a population in which finding ANY two (or more) of the same is considered a match. That does not apply to a TCP header checksum because the comparison needs to be made against ONE SPECIFIC checksum (e.g. the one the packet in question has). You get a packet and it has a checksum. You calculate a checksum from the data. Do they match or not when the data is corrupted? That's not a birthday paradox.
The birthday paradox DOES apply in cases where you want to create TWO packets with the same checksum, but it doesn't matter which checksum that is. You can create two messages with the same hash in the case of cryptography where there is a weak hash. But in the case of error checking, it's not about creating any pair of matching checksums; it's about creating one checksum that matches one you already have that you cannot change. In birthday terms, it's about finding someone in the population that has the same birthday as you do.
OK, it's 16 bits. My bad. TCP bad. But birthday paradox does not apply here.
Maybe they should start employing computer people to keep them out of trouble.
I actually saw this happen once ... the astronomically unlikely [1]. TCP accepted the corrupt packet. I'm sure it will never happen again. Fortunately, rsync caught it in the next run.
One problem I ran into once with a certain Intel NIC was that a certain data pattern was always being corrupted. TCP always caught it and dropped the packet. There was no progress beyond that point because of the hardware defect always corrupted that data pattern. Turns out there was a run of zeros followed by a certain data byte (I tried a different data byte and with different run lengths and those never got corrupted). What the NIC did was drop 4 bytes, and put 4 bytes of garbage at the end. I suspect it was a clocking syncronization error. I got around the problem by adding the -z option to rsync (which I normally would not have done with an ISO of mostly compressed files). Another way would have been to do the rsync through ssh, either as a session agent (like rsync itself can do) or as a forwarded port (how I do it now for a lot of things).
[1] ... approximately 1 in 2^31-1 chance that the TCP checksum will happen to match when the data is wrong (variance depending on what causes the error in the first place) ... which approaches astronomically unlikely. Take 1 Terabyte of random bits. Calculate the CRC-32 checksum for each 256 byte block. Sort all these checksums. You will find 2 (or more) data blocks with the same checksum (or a repeating pattern in your RNG). Why? Because CRC-32 has 2^32-1 possible states, and you have 2^32 random checksums.
But whatever the cause, it's almost certain that software is to blame.Agreed. Since it is at least software's responsibility to detect and fix it, if the problem happens, the famous finger of fault points at the software.
I'd bet $100 that if he did the same download over HTTPS, thus preventing software meddling of the packet contents, it would come out perfect.Your $100 is safe.
If you asked me whether Hauppauge hardware sucks, I'd unequivocally say..."Yes it does, and it does so big time." All because of an OS that does not work.
NY could easily pass delivery tax and make UPS and Fed-ed collect the tax for them.
Based on what? The weight? This would be adding an entirely new infrastructure to these companies. And it won't account for online delivery like iTunes.
However much I dislike the taxes, I hate discrimination and government loading the dice and making the playing field slanted. The brick-and-mortar companies in New York are obligated to collect sales tax for NY. That includes you corner diner and the mom-and-pop store selling used books. There was a time when compiling 50 state sales tax codes or even 25000 local county tax codes and making businesses outside complying with these code was technologically impossible. But now that excuse is not valid anymore.
Actually, it is still rather hard to collect varying percentages. They don't split up the different tax rates by zone. They don't categorize different products that are taxable and non-taxable by any consistent pattern. The software in development for this is bloated, complex, and generally not practical for all but the largest of retailers (Amazon could work with it, but clearly even they don't want to).
They could fix this by simply publishing a table, indexed by zip code, which lists the tax rates and which agency they are to be sent to. We still need a national standard for things like how often to send the collections in, as well as the way different types of products are categorized (the definition of "food" varies from state to state, for example).
Why should brick-and-mortar sellers have the advantage of not having to deal with multiple tax rates, and not having to worry about where their customers live? To be fair, they need to impose the same level of requirement on all sellers.
Then there is the issue that many sales are delivered online and the seller won't know where the buyer is located since they aren't shipping anything to a physical address. The buyer could be located in another country. Or they could be located in a state with no sales tax (your reference to "50 state sales tax codes" is not quite accurate).
But, I have a solution for you to consider. It's not a perfect one, but it will go a lot further than anything I have seen proposed so far. That solution is to have the payment processors collect the tax. That means your credit card company, or PayPal, or your bank, etc. Congress would have to establish a law that makes this universal. That law would have to spell out a category table of product types. Different tax jurisdictions would have to conform to these product type codes to benefit from the process. The seller reports to the payment processor, in addition to the amount they are charging for what is sold, an itemization of amounts under each category for which they have not collected a tax for (the federal law would not be applicable to entirely in-state transactions, so there can still be cases where the seller paid tax to the state they are in, for customers in that state ... unless the state elects to have in-state sales work through this system).
Your credit card company or bank will more readily know which sales tax jurisdiction you live in. They will calculate the correct sales tax, take it out of your account, and send it to the state on the regular schedule (or even do a direct electronic deposit). The state would then distribute it down to the local jurisdictions. The seller won't deal with it beyond the reporting criteria. Penalties for incorrect reporting would exist, of course.
The states benefit from a uniform collection method. Sellers benefit from a simpler system and not having to track where customers are (especially important when they don't know where customers are). States benefit from having fewer entities they have to deal with (imagine having to account for, and spot check the accuracy of, tiny discrete tax collection payments from half a million web site operators through
Next thing we'll have is DRM enabled printing that refuses to print this story unless it gets printed with self-erasing ink. But you can print it on permanent ink if you are a registered user. Registration is free. Enter your SSN here.
That's not fair. I didn't get any errors at all on my page. And after all that work hand coding the HTML and the CSS inside PHP.
The million dollar question is what platform and which web server is it easier to reinstall to get the site back up.
I think Linux and BSD have the advantage.
Actually, the damage is to the database. The fix is to restore from a backup taken from before the attack, resyncronize with records sanitized for the inserted bad data, fix the vulnerable code, and bring the database and web application back up.
I agree that this is not an IIS problem. IIS is just a convenient target. And it may also be the case that users of IIS are less likely to do proper data sanitation than those who can't use IIS. But I would argue that SQL is a major target of blame.
Long long ago when I first learned of SQL, it was described as a command line language which would allow people to do innovative database searches. I saw several examples of such. The lecturer was even typing them in manually. It sure looked like a really great tool, both for the database administrator, as well as for people that needed to work directly with the data in relational databases. What never came across at that point in time was that using SQL was the primary way for programs to access the database.
Later I found out the hard way that this was necessary when a program I was developing needed to get some data from the database. I almost lost my lunch. It was bad enough that user input data might be used to open a file by name. But at least reading and writing of files was done specifically by calls inside my program and didn't involve constructing strings to be parsed and interpreted somewhere. Now with the need to access something in an SQL database, I immediately saw a huge problem.
I was working with the DBA on this aspect of my project. He told me what SQL I needed to use for what I wanted access to (I didn't know any SQL at that time). I just needed to insert certain pieces of data describing what I wanted at specific places in the (rather largish) SQL commands he gave me. I could see the exposure immediately, as well as some solutions. So I just mentioned something like "I'll need to filter this so I don't have quotes in the string". He asked why. I asked "Won't a quote in the data look like the quote that ends the string?" He replied, "I guess so, but then you'd just have a syntax error". "What if someone inserts valid SQL after that which ends in a quote to start a new string?" And his reply "Why would anyone want to do that?". I just shook my head and proceeded to write code that removed everything but letters and numbers.
Had relational databases also had a means for more direct access (turns out some do) that doesn't involve any SQL, they might be safer. But what was really needed as a part of any database access library is specific code to be used to construct the SQL command line that applies all the necessary data sanitation. Even to this day I don't know if a quoted string in SQL can have a quote embedded with an escape (I never used SQL enough to need to know). If it can, then the calls to insert a quoted string in the SQL command being built should escape quotes in the C string being passed to it. If not, it should just remove them (and then you can't use quotes in a string for anything).
Maybe I should not have been so amazed at the lack of security thinking back in the 1990's when this took place. I was amazed, nevertheless. But I can see how back when they developed these interfaces, they would not have thought about all this at all. Based on all the security problems I have seen since, being amazed back then was clearly out of place. And it was a web application I was developing. Hopefully, they aren't running it anymore. But if they are, it's probably a whole lot safer than others developed by other people in that era (and, unfortunately, even those developed today).
Yes, programmers of the web applications are significantly to blame. But SQL should have included the tools to make constructing safe SQL from unsafe tainted data work in a safe way ... and made those tools the standard way to do things (not unsafe tools like sprintf from the C library, or similar from languages used today).
In summary, my blame (mostly) points at SQL itself.
... then they would leave a message, or send you a letter, or sue you.
Maybe what they should do in the few cases where it becomes obvious that they made a mistake and sued the wrong person is to stop the lawsuit and offer to pay all the costs incurred by the victim. That wouldn't be enough, but it would be damn good start. Or at least, just stop the lawsuit? No, these guys just press on. That is the same tactic used by some debt collectors even when faced with proof that they are collecting invalid debts or collecting from the wrong person.
Wanting to collect from people that steal from you is one thing. Trying to be a bully just to scare everyone else is another. And being that bully against people that didn't steal from you at all is altogether worse.
Maybe somehow I left behind on this whole internet thing, since I don't use Gnutella or Bittorrent. I pay for the stuff I use and listen to. I guess I'm a fool for seeing value in the arts that I love in my life, a value worth paying for.Believe it or not, there are people that download music from various sources just to get a sample to determine what it is they like and don't like, and then go buy what they like. Maybe the RIAA is upset they no longer buy what they don't like?
The email address the Usenet post claims to be from is not authenticated in most Usenet servers. Maybe Google Groups now limits these to be Gmail addresses; or maybe not. But what I have found is that virtually all of this recent dramatic rise in spam on Usenet is from the actual Google Groups servers, with googlegroups.com in the Message-ID header (not gmail.com). I could not see any means for a Google Groups user to override the message ID, so I blocked all posts based on the message ID. Since the message ID is part of the index data, these posts can be blocked before their contents is obtained. So this works and gains the efficiency of not pulling the blocked post contents at all. This is with the tin news reader. It has nearly completely eliminated the spam with only a small amount of collateral damage (which is mostly people that think Google Groups is just some big web forum). This still lets people who post at other Usenet servers to use their gmail.com email address as the sender address without being blocked.
Unfortunately, Google decided to require using Gmail addresses for all new signups of Google services, and push users of other email addresses to use Gmail addresses. They could not have easily done that without opening Gmail addresses to anyone to sign up for. That is most unfortunate, because the old method of requiring an invitation provided a way to backtrack where spammer signups were coming from. Under the old method, if a Gmail user is determined to be a spammer, the other Gmail user that invited the spammer could at least have invitation credits revoked, and other accounts invited by that user could be closed as well. Without the invitation system, there is no longer any tracking like this. IMHO, what Google should have done was set up another separate domain name for non-invited email users.
What we need to do is get a law passed that mandates strong encryption and proper key handling for all qualifying data (anything with personally identifying information, including SSN, bank account numbers, CC numbers, health information, etc), held by any entity (corporate, organizations, governments), that is transported, transferred, or exchanged offsite by any means (tapes, disks, internet, private data circuits). There should be a minimum violation penalty for cases where the data was not stolen or taken, and stiffer penalties if it was stolen and not encrypted.
There's nothing in the article that says they were encrypted. They were compressed and some kind of encoding was involved. But encoding could be any number of things, and quite possibly the coding used by medical records systems to compact common terms to numbers. It could be hard to make use of the data. But if it was an "inside job", or the perps can get the software used on this, it can be cracked easily. This is not strong encryption.
Proprietary compression cannot be cracked? I can tell you that this can be hard to do. And this is from experience. I once worked at a company where a project one year involved writing some programs to extract data from files stored be various competitor products to enable customers to easily migrate to our products. I was given the one that the managers thought wasn't even possible to do, because the data look like gibberish (because, unknown to them at the time, it was compression). It took me FIVE weeks to reverse engineer it. It was not quite as good as UNIX compress, but it was much better than run length compression.
Whether these data tapes are crackable is unknown to me. But if they were encrypted by today's strong forms of encryption, then I know I could not crack that.
Let's see here. Archive America waited 2 days. Then the university waited 27 more days. Who needs to do the most explaining?
Just because they can get it for free does not mean this will work. Imagine the level of traffic that has to run through it. Who is going to pay for that hardware? They should give them a turnkey box that does all the monitoring, one for each DSLAM.
I'm sure the software has a list of legal download sites. Those would get a pass. And most of those downloads won't be using a P2P sharing protocol, so that's another way around. It doesn't have to be perfect (e.g. get 100% of all illegal downloading). It just has to do enough to discourage people from continuing the practice. Of course the die-hards will figure out how to fool it or bypass it, or crack into the machines running it and change it around to do something else like block certain pro-corporation political sites.
9. People have better means to sample all music these days, and no longer need to deafly buy music they think maybe they might like, but actually do not like (once they play it). So now they buy only what they know they like.
I first bought music in the vinyl LP era. I could not sample the music. I had to read what was on the album to figure out if maybe I might like it. Radio played only a limited set. The record stores would not open albums to play them in the store (because they could not sell that one as new). I ended up with about 60% that I really would not have purchased had I heard it in advance. But it was the norm of the times to actually have a lot music you didn't like. That, or sell them at a used record store (which the music industry wanted to shut down because they knew that much of their sales revenue model depended on people buying music they didn't like). When CDs came along, it actually got worse because less was printed on the smaller cover.
Now I there are plenty of ways to sample the music in advance. Yup, that file sharing thing lets you do that. I'm sure many people cheat and keep their samples. But those of us that actually buy music believing it somehow supports the artists are not buying the music we decide we do not like so much.
There's a chain of evidence which is used to get a person in many universities. It's the same way any ISP would track usage down to a specific user.
But not all universities are alike in how they structure their networks and allocate their resources. They are not even alike in how much resources they get. Marshall University is definitely one where costs are kept as low as they can get them. West Virginia is not one of the rich states.
Users are typically registered. Usually in universities, this is accomplished through a captive portal which records the MAC and username (authenticated with a password.) This ties the MAC to the user.
That would be so at that moment in time, no accounting for the issues involved with students using wireless over their dorm connections.
From there, it's trivial to tie the packets to the MAC--spoofing IP addresses is trivial on most networking equipment in use by universities (i.e. we're not talking crappy Linksys routers, here.) MAC spoofing is rare, but also quite easy to block on the switch, long before any damning traffic occurred.
It's not necessarily easy to block it, as that results in problems moving computers around. And not all switches can block it. Low priced switches, much like a low resource university would have to buy, probably don't have the ability.
Even if it isn't explicitly blocked, it would be a special case that would need to be handled when trying to identify the student, but it is by no means a dealbreaker.
What it means is that after the student who logged in shuts their computer off, another computer that was pinging them to see when they shut off can immediately impersonate that MAC address. Even if most users properly signoff before shutting down or pulling the plug, it only takes a few that don't for someone wanting to run anonymously to do that every now and then.
Of course, if the student is running a wireless access point, you run into problems. This is why some universities don't allow wireless access points to be connected to the network (they can't outright ban them due to FCC regulations) and the university agreements almost universally state that traffic originating from the student's port is considered to be the student's liability.
Then there is the issue that you have multiple students working from the same port. At least 2 live in each room in most of the rooms. There are a few singles and triples there (I went to school at Marshall for 3 years and lived in the dorms for 2 of those years ... I know how at least the ones that were there then are organized). So you can at least have 2 students using one port at a time. And it is typical for students with laptops/notebooks to roam around or get together with others in different rooms to collaborate on various projects, school related or not. Student run access points make that so much simpler. Now I don't know if Marshall has every floor in every dorm covered with wireless, but they could see it as a cost savings by NOT doing so, knowing that the students themselves will provide localized access at no cost to the school.
ISPs (including universities) have valid reasons for wanting to be able to track people down. It's unfortunate that the ability to track people down means that they can give up their information when the RIAA comes subpoenaing.
That may be a good goal, but it's generally not practical in a resource limited situation. They may consider it more important to be sure outsiders are not using the network than it is to exactly know who sent each and every packet by its IP address. Knowing that 99% of traffic was carried out by some authorized person on campus may be sufficient. Being able to block that 1% of other traffic might not be worth the cost. Being able to track any instance of traffic to a specific person might not be worth the cost. And i
Take a CNN story like this, edit it to show your company as the culprit including how sales dropped dramatically, set it up on a web server somewhere, fabricate a CNN-spoofing URL to access it, and use an anonymous web email account to send it to those upper level managers along with a comment saying "do you want to avoid a situation like this?".
At least Deltacast indicates Linux support. I can't find any indication for the others. Thanks!