Are you saying that the passive voice should never be used?
The passive voice has a place. It is not evil, just sometimes abused and poorly misunderstood (the Language Log blog has a number of cases of people "trying out the passive voice" who never seem to actually do so). It is sometimes clearer than alternatives.
A core part of my design is security. Operations have security enforced at a layer lower then what performs the operation. While I won't pretend that it's bug-free, my design attempts to minimize obvious things like users screwing with each others profiles. Likewise, I designed a powerful ORM system in C# that parameterizes user input so that the risk of SQL injection is unlikely and easily fixable.
Aside from a few glaring typos on the page (what's a walthrough?), I want to address this point.
One thing I have advocated for years is the idea that security enforcement should be handled as far back as possible (i.e. as low on the stack as possible). This sometimes complicates things because a great deal of the application is untrusted or has no permission to do anything at all, and there are often tradeoffs that have to occur in deciding exactly how far back is optimal. (For example, LedgerSMB 1.3 will use the db to enforce permissions via db roles, but this means that the web server has to receive credentials in a format readily usable to log into the db, ruling out cookies with session tokens or HTTP digest authentication. There are, however, appropriate strong authentication measures that can be used.)
If that is not practical, then what this means is that the application must have its security subsystem as far back between the main program and the OS/RDBMS/etc as possible. This means a framework that EVERY api must use for db access and the like. It sounds like the approach you've taken and it might work. However, one thing I would suggest is this: break that subsystem off into a separate project. The more people using that subsystem, the more secure it will be. You want the portions of your code that do the actual security enforcement to be as thoroughly reviewed as possible, and this means making them more generally applicable.
I used to recommend SQL-Ledger to customers of mine. I didn't put it through a detailed security review. I didn't realize how bad it was. I had only really been writing web apps for about a year and while I had though a lot about security I didn't trust my own conclusions much yet (I still don't trust myself where I don't have to).
Then I discovered a major security hole in the program, of the sort described here. The program asked for authorization and then inadequately checked for it. It was trivial to forge credentials to bypass controls. Bad..... I went to the developer figuring he'd understand and fix it. Of course little did I know the developer was out of his league or else the problem wouldn't have occurred. The problem didn't get fixed.
After some time of trying unsuccessfully to get the problem fixed (for a year, btw), and getting back at least one totally inadequate fix, I complained to a few trusted development friends and pretty quickly one of them introduced a few others to me and we got LedgerSMB started.
So we initially decided to try to retrofit the SQL-Ledger codebase with security measures. We gave up after a year and three major releases, opting instead for a block-by-block rewrite because the obvious issues were only the tip of the iceburg. Removing SQL injection vulnerabilities alone took 2 months (and we missed only one out of thousands of putative vulnerabilities).
I think this sort of experience here has real value to this discussion. The problems are essentially the same: inadequate checks for authorization, inadequate checks for code injection, and the like. These are often VERY intrusive to fix, and very time consuming to audit for. The code was also poorly structured, and the db design bordered on unusable (a lot of the code relied on ambiguous foreign key relationships).
If these sorts of errors are being made here, then my past experience tells me that this project will never be safe to use. It's a great proof of concept. Now they need to start over, do real security design, and scrap their current release schedule (push things out maybe a year). And they need to ensure they get REAL security experts on their team, i.e. people who review the code and dress down developers who do stupid things. And they need to keep things open from the start of the rewrite so suggestions come in before it's too late to fix them.
However if they don't do this, the project will never amount to anything.
That is the entire point of having an open source project is that the developers don't have to be experts. Diaspora was developed not because some guys who were great at security decided one day to lunch an uber secure network, it was developed because people were tired of all the crap that FB had so they developed it. Now that the source code is out, security experts can audit the code and make improvements.
Actually, the security experts will make suggestions. The real work is going to be slow, tiresome, painful, and time consuming if you are looking at problems like code injection. It will take 10-100x the effort that it would have taken if they had gotten the feedback earlier. That's the way it works. That could well be enough to kill the project right there. I am amazed at how many FOSS supporters here don't realize how much of a problem this is.
You are right though that the developers don't have to be experts, but this only works when the code is open from the start. Keeping the code secret for a while prevents that open process from working. Now it may be too late. I am entirely sure we won't see a secure version of Diaspora this year. I am not sure if we will see one next year. If not then, maybe never. It would be nice to see an open source alternative to facebook really takeoff, but at this point I think that very much remains to be seen.
The main virtue of the exercise is that it will provide a learning experience for everyone. The developers will learn what not to do and those who invested in it will learn not to invest in open source without, well, seeing the code is publicly available first.....
You can't add security as the next feature to a product in a late stage, if your foundations are wrong, then it's comparable to throwing most of the code out and re-creating it with proper security architecture.
Well, you can, just like you can replace the foundations of a house. The question, as always, is whether the time, expense, and disruption is worth it. It is extremely painful, slow, and difficult, and often one might be better off starting over.
Based on experience fixing these sorts of problems, I am not sure that they are fixable by a team of experts before the release timetable even if they started last week.
There is no Silver Bullet in coding. You can't get it right from the beginning always, and you shouldn't hinge success on that hope. The biggest benefit projects get from the FOSS community is that such silly security problems are easily spotted and fixed. If anything this gives me HOPE because it shows there is enough interest in the project that the code is being held to a solid standard. And thanks to that same community those standards will be met, maintained, and hopefully exceeded.
Ok. Here's the fundamental problem. The problems here are structural and deeply built into the entire codebase. Whether this is pre-alpha or not, the fact is that these are going to be painful, expensive, and time-consuming errors to fix at this point. If you've ever retrofitted a codebase for security (like code injection) that was entirely overlooked in past versions, you know this is not a trivial fix. My reading of the issues is that it may take them between a few months and a year just to fix them.
What you can hope for in an open development model is that experts will weigh in before you get too far in and point out stupid things you are doing and thus save you significant time and effort later.
It's way too late to hit the expected release date. It may be too late to release it even next year. Time will tell.
It's a little too close to launch. It may already be too late. Yes, FOSS is a better way, but the problem here is that they didn't start out with an open development model. Now retrofitting the codebase is likely to be painful and costly.
The basic thing is that any software project, FOSS or not, depends on competent software engineers for proper application design, testing, and so forth. Security issues are preventable, but you need engineers, not developers, to do the design and address how authentication/authorization needs to be handled. This is true regardless of development methodology (the role of an engineer is arguably different when doing something like extreme programming but I am not at all convinced that it goes away).
If you don't really understand security, don't try to write secure software all by yourself. FOSS does well when it comes to peer review. Use that. Have experts tell you what you are doing wrong. I know I have learned a lot over the years from such experts and am now much better at that area than I used to be. Think of it like an apprenticeship. For a FOSS project, opening the code early is a good idea. Get review before the problems become pernicious and very difficult to fix. This mistake will probably cost the Diaspora team at least few months in release time, and we can all hope it is fixed properly without meeting the fate of Duke Nukem Forever.
What went wrong is simple: You have a few young (and hence experienced) hotshot (i.e. technically competent) programmers working on a major project without expert feedback using the latest fad technologies (rails, etc). Things get missed. The results are impressive but so are the failures, and by the time the problems are noticed, fixing them is difficult and expensive in terms of time and money.
It's exactly like laying copper pipe, or putting in wiring, except that instead of three times as long, it takes 10x as long or longer to fix after the fact. If you don't know what you are doing, get supervised by someone who does. Again, that's a real strength of FOSS, but it takes an openness that all too many projects lack.
In my experience with insecure FOSS projects, the problem is usually a combination of secrecy and unwillingness to accept input at critical stages. This is true, for example, with SQL-Ledger which keeps development versions secret and where the developer is unwilling to generally accept code contributions or even development feedback from others. Secure projects (like PostgreSQL) generally have more open development processes and yet retain control by a small meritocratic committee.
Yes first, congratulations to those folks. I am still waiting for a front-end to PostgreSQL that is as functional and easy to program as Microsoft's Access.
Microsoft Access works as a frontend to PostgreSQL.....
You know, it really depends. Hammers are great tools for example. You can use them to drive nails, shape metal, combine them with chisels to carve stone, and the like, but not everything should be done with a hammer. Same thing with db logic. I wouldn't say "avoid using a hammer whenever possible" just like I wouldn't say "avoid putting your logic in the db wherever possible." A lot of business logic belongs in the db but not everything.
Business logic belongs in the db where the rules are either inherent in the data (i.e. data constraints) or need to be consistently enforced throughout a set of applications. A good DBA will be looking at this carefully and asking what is really appropriate at any given tier (and the DB is not one tier but at least three-- physical data layout, logical data layout, and procedural interface).
So I will give you two differing scenarios.
1) Suppose you have an accounting system. Data needs to conform to strict rules, be accessed only in specified ways regardless of the application doing the accessing, etc. Business logic needs to be in the db.
2) Suppose you have an application which does a large number of things. It serves web content, takes e-commerce orders, tracks customer contacts, etc. In some cases, you have rigid business requirements. In other cases you don't. In this case, you have to be very careful about what you put where. Some logic will be in the db by definition. Other logic should be put in the db in terms of either procedural interfaces or logical data layouts (views). Quite a bit more logic should be left up to the application, which should be free to access either logical layouts or procedures as necessary.
But this gets into proper db design which is not a simple field. There are a lot of fads out there. In reality it's better to have a full shop of tools than to rely on any one or two.
I personally find it very difficult to read any license and the GPL v3 and be 100% sure they are compatible. Heck, I've previously expressed doubts about whether the BSD license is compatible if one reads them both strictly (The issue has to do with requirements on additional permissions and differences as to when restrictions can be added to turn a BSD-licensed work into a GPL-licensed work). Richard Fontana's advice (from the SFLC) was helpful. He said that the licenses were intended to be compatible so they should be read as being compatible.
With this in mind, I cannot see any reason this license is not compatible with the GPL v3 in any way that's more substantial than the BSD license is.
It's basically the BSD license (word for word) plus the patent license from the Apache License (slightly narrowed and paraphrased, but at least equivalent when paired with Google's license over the patents in the spec). So I honestly don't see anything worth arguing here.
Also, I think it's worth noting that the GPL v3 would have to be interpreted to allow substantially compliant licenses to be compatible even if there are minor incompatibilities according to a strict reading. Otherwise, the BSD license would be incompatible because the BSD license cannot be reduced to GPL v3 + additional acceptable terms (the issue here has to do with removal of the "additional permissions" and when that's possible). So I think it's reasonable to assume that two licenses are compatible if no major incompatibilities exist. For that reason I cannot see a case that can be made that this patent clause is incompatible with the GPL v3. At least it's no more incompatible in general than it would be without the patent license.
Google's license for this software is just an approved BSD license + a narrow patent license. If it'd be open source without the patent license, I'm not at all sure why it wouldn't be open source with an added patent license which is along the spirit of the original license.
This controversy is STUPID. Next we'll hear bitter complaints about how PostgreSQL's not "open source."
In this specific case, the farmer grew approximately 20 acres of wheat to feed his cows, sheep, and chickens. i.e. For his own usage. The Master... I mean Congress told the serf he's only allowed to grow ~10 acres. Who here thinks this was the original intent of James Madison when he wrote the Constitution? When it was approved by the 13 founding States? To turn farmers into serfs like a feudal state?
As I say, having read "Wickard v. Filburn" I think the decision has to go down as one of the worst-written Supreme Court decisions in history. The court made extremely broad declarations of what Congress could do necessary and proper to the regulation of interstate commerce.
However, when you look at more recent decisions, Wickard has been narrowed quite a bit. The Wickard court's reliance on the fact that wheat was fungible was not found in Raich, for example. Basically, the Wickard court seemed to base it's determination on the idea that a bushel of wheat produced for home use was a bushel not purchased. However, in Raich, the court characterized the concern as merely a concern that the wheat might be sold interstate if prices remained high. (I am not a fan of Raich either, but it is a heck of a lot better than Wickard.)
I don't think that Wickard has much continuing relevance today by itself. The question is no longer what Wickard allows, but what Wickard, as narrowed through Raich, Lopez, and Morrison allows. I think that's a very different question with a very different answer. But neither case really addresses whether Congress would have the right to regulate commercial services which offer interstate delivery of goods or information.
But still, if this is a statutory matter (as seems to be the case in the actual opinion) then it should be a simple matter for Congress to fix it if the courts got it wrong, right?
Of course, my thinking on net neutrality is that anticompetitive traffic shaping is pretty clearly BAD and should be seen as illegal under existing laws if not having new laws passed against it, but provided that usability is preserved, I see nothing wrong with ISP's:
1) applying opt-out security filtering (port 25, port 22, and whatever else) provided no additional fee is charged to opt out, 2) filtering for known malware (yes, this sometimes causes problems but isn't because the ISP's are being evil) 3) bumping high volume, low quality traffic down a priority for things like bulk file transfers (torrents and the like) in order to preserve everyone else's customer experience. 4) offering a QoS tier for latency sensitive applications like VOIP, provided that VOIP is not treated otherwise as a lower priority than standard usages (http, etc).
I personally think this should be discussed in Congress and basic directions given before placing our faith in unelected beaurocracies.
Slashdot Mirror
Of course.
"The sailor was hit by the soldier" is unnecessarily indirect and obscure.
"The passive voice should only be used when it is clearer than the alternative" on the other hand.....
Are you saying that the passive voice should never be used?
The passive voice has a place. It is not evil, just sometimes abused and poorly misunderstood (the Language Log blog has a number of cases of people "trying out the passive voice" who never seem to actually do so). It is sometimes clearer than alternatives.
Aside from a few glaring typos on the page (what's a walthrough?), I want to address this point.
One thing I have advocated for years is the idea that security enforcement should be handled as far back as possible (i.e. as low on the stack as possible). This sometimes complicates things because a great deal of the application is untrusted or has no permission to do anything at all, and there are often tradeoffs that have to occur in deciding exactly how far back is optimal. (For example, LedgerSMB 1.3 will use the db to enforce permissions via db roles, but this means that the web server has to receive credentials in a format readily usable to log into the db, ruling out cookies with session tokens or HTTP digest authentication. There are, however, appropriate strong authentication measures that can be used.)
If that is not practical, then what this means is that the application must have its security subsystem as far back between the main program and the OS/RDBMS/etc as possible. This means a framework that EVERY api must use for db access and the like. It sounds like the approach you've taken and it might work. However, one thing I would suggest is this: break that subsystem off into a separate project. The more people using that subsystem, the more secure it will be. You want the portions of your code that do the actual security enforcement to be as thoroughly reviewed as possible, and this means making them more generally applicable.
I'm going to chime in here with a different view.
I used to recommend SQL-Ledger to customers of mine. I didn't put it through a detailed security review. I didn't realize how bad it was. I had only really been writing web apps for about a year and while I had though a lot about security I didn't trust my own conclusions much yet (I still don't trust myself where I don't have to).
Then I discovered a major security hole in the program, of the sort described here. The program asked for authorization and then inadequately checked for it. It was trivial to forge credentials to bypass controls. Bad..... I went to the developer figuring he'd understand and fix it. Of course little did I know the developer was out of his league or else the problem wouldn't have occurred. The problem didn't get fixed.
After some time of trying unsuccessfully to get the problem fixed (for a year, btw), and getting back at least one totally inadequate fix, I complained to a few trusted development friends and pretty quickly one of them introduced a few others to me and we got LedgerSMB started.
So we initially decided to try to retrofit the SQL-Ledger codebase with security measures. We gave up after a year and three major releases, opting instead for a block-by-block rewrite because the obvious issues were only the tip of the iceburg. Removing SQL injection vulnerabilities alone took 2 months (and we missed only one out of thousands of putative vulnerabilities).
I think this sort of experience here has real value to this discussion. The problems are essentially the same: inadequate checks for authorization, inadequate checks for code injection, and the like. These are often VERY intrusive to fix, and very time consuming to audit for. The code was also poorly structured, and the db design bordered on unusable (a lot of the code relied on ambiguous foreign key relationships).
If these sorts of errors are being made here, then my past experience tells me that this project will never be safe to use. It's a great proof of concept. Now they need to start over, do real security design, and scrap their current release schedule (push things out maybe a year). And they need to ensure they get REAL security experts on their team, i.e. people who review the code and dress down developers who do stupid things. And they need to keep things open from the start of the rewrite so suggestions come in before it's too late to fix them.
However if they don't do this, the project will never amount to anything.
Actually, the security experts will make suggestions. The real work is going to be slow, tiresome, painful, and time consuming if you are looking at problems like code injection. It will take 10-100x the effort that it would have taken if they had gotten the feedback earlier. That's the way it works. That could well be enough to kill the project right there. I am amazed at how many FOSS supporters here don't realize how much of a problem this is.
You are right though that the developers don't have to be experts, but this only works when the code is open from the start. Keeping the code secret for a while prevents that open process from working. Now it may be too late. I am entirely sure we won't see a secure version of Diaspora this year. I am not sure if we will see one next year. If not then, maybe never. It would be nice to see an open source alternative to facebook really takeoff, but at this point I think that very much remains to be seen.
The main virtue of the exercise is that it will provide a learning experience for everyone. The developers will learn what not to do and those who invested in it will learn not to invest in open source without, well, seeing the code is publicly available first.....
Well, you can, just like you can replace the foundations of a house. The question, as always, is whether the time, expense, and disruption is worth it. It is extremely painful, slow, and difficult, and often one might be better off starting over.
Based on experience fixing these sorts of problems, I am not sure that they are fixable by a team of experts before the release timetable even if they started last week.
Isn't that the truth. Hope this works out well.
I disagree. Security credentials should be pervasive and global to the request, and every method should assume that they are there.
Better yet, the db should require them.....
Ok. Here's the fundamental problem. The problems here are structural and deeply built into the entire codebase. Whether this is pre-alpha or not, the fact is that these are going to be painful, expensive, and time-consuming errors to fix at this point. If you've ever retrofitted a codebase for security (like code injection) that was entirely overlooked in past versions, you know this is not a trivial fix. My reading of the issues is that it may take them between a few months and a year just to fix them.
What you can hope for in an open development model is that experts will weigh in before you get too far in and point out stupid things you are doing and thus save you significant time and effort later.
It's way too late to hit the expected release date. It may be too late to release it even next year. Time will tell.
"you cant see it it dont exist until....too late"
It's a little too close to launch. It may already be too late. Yes, FOSS is a better way, but the problem here is that they didn't start out with an open development model. Now retrofitting the codebase is likely to be painful and costly.
The basic thing is that any software project, FOSS or not, depends on competent software engineers for proper application design, testing, and so forth. Security issues are preventable, but you need engineers, not developers, to do the design and address how authentication/authorization needs to be handled. This is true regardless of development methodology (the role of an engineer is arguably different when doing something like extreme programming but I am not at all convinced that it goes away).
If you don't really understand security, don't try to write secure software all by yourself. FOSS does well when it comes to peer review. Use that. Have experts tell you what you are doing wrong. I know I have learned a lot over the years from such experts and am now much better at that area than I used to be. Think of it like an apprenticeship. For a FOSS project, opening the code early is a good idea. Get review before the problems become pernicious and very difficult to fix. This mistake will probably cost the Diaspora team at least few months in release time, and we can all hope it is fixed properly without meeting the fate of Duke Nukem Forever.
What went wrong is simple: You have a few young (and hence experienced) hotshot (i.e. technically competent) programmers working on a major project without expert feedback using the latest fad technologies (rails, etc). Things get missed. The results are impressive but so are the failures, and by the time the problems are noticed, fixing them is difficult and expensive in terms of time and money.
It's exactly like laying copper pipe, or putting in wiring, except that instead of three times as long, it takes 10x as long or longer to fix after the fact. If you don't know what you are doing, get supervised by someone who does. Again, that's a real strength of FOSS, but it takes an openness that all too many projects lack.
In my experience with insecure FOSS projects, the problem is usually a combination of secrecy and unwillingness to accept input at critical stages. This is true, for example, with SQL-Ledger which keeps development versions secret and where the developer is unwilling to generally accept code contributions or even development feedback from others. Secure projects (like PostgreSQL) generally have more open development processes and yet retain control by a small meritocratic committee.
Yes first, congratulations to those folks. I am still waiting for a front-end to PostgreSQL that is as functional and easy to program as Microsoft's Access.
Microsoft Access works as a frontend to PostgreSQL.....
You know, it really depends. Hammers are great tools for example. You can use them to drive nails, shape metal, combine them with chisels to carve stone, and the like, but not everything should be done with a hammer. Same thing with db logic. I wouldn't say "avoid using a hammer whenever possible" just like I wouldn't say "avoid putting your logic in the db wherever possible." A lot of business logic belongs in the db but not everything.
Business logic belongs in the db where the rules are either inherent in the data (i.e. data constraints) or need to be consistently enforced throughout a set of applications. A good DBA will be looking at this carefully and asking what is really appropriate at any given tier (and the DB is not one tier but at least three-- physical data layout, logical data layout, and procedural interface).
So I will give you two differing scenarios.
1) Suppose you have an accounting system. Data needs to conform to strict rules, be accessed only in specified ways regardless of the application doing the accessing, etc. Business logic needs to be in the db.
2) Suppose you have an application which does a large number of things. It serves web content, takes e-commerce orders, tracks customer contacts, etc. In some cases, you have rigid business requirements. In other cases you don't. In this case, you have to be very careful about what you put where. Some logic will be in the db by definition. Other logic should be put in the db in terms of either procedural interfaces or logical data layouts (views). Quite a bit more logic should be left up to the application, which should be free to access either logical layouts or procedures as necessary.
But this gets into proper db design which is not a simple field. There are a lot of fads out there. In reality it's better to have a full shop of tools than to rely on any one or two.
"Open Source" is more generic than "Gel Cel."
The BSD license works REALLY well for the PostgreSQL project though....
Me? I mostly just sick of license wars.
I personally find it very difficult to read any license and the GPL v3 and be 100% sure they are compatible. Heck, I've previously expressed doubts about whether the BSD license is compatible if one reads them both strictly (The issue has to do with requirements on additional permissions and differences as to when restrictions can be added to turn a BSD-licensed work into a GPL-licensed work). Richard Fontana's advice (from the SFLC) was helpful. He said that the licenses were intended to be compatible so they should be read as being compatible.
With this in mind, I cannot see any reason this license is not compatible with the GPL v3 in any way that's more substantial than the BSD license is.
It's basically the BSD license (word for word) plus the patent license from the Apache License (slightly narrowed and paraphrased, but at least equivalent when paired with Google's license over the patents in the spec). So I honestly don't see anything worth arguing here.
Also, I think it's worth noting that the GPL v3 would have to be interpreted to allow substantially compliant licenses to be compatible even if there are minor incompatibilities according to a strict reading. Otherwise, the BSD license would be incompatible because the BSD license cannot be reduced to GPL v3 + additional acceptable terms (the issue here has to do with removal of the "additional permissions" and when that's possible). So I think it's reasonable to assume that two licenses are compatible if no major incompatibilities exist. For that reason I cannot see a case that can be made that this patent clause is incompatible with the GPL v3. At least it's no more incompatible in general than it would be without the patent license.
The WebM license is a BSD license with an added clause giving an explicit patent license.
Google's license for this software is just an approved BSD license + a narrow patent license. If it'd be open source without the patent license, I'm not at all sure why it wouldn't be open source with an added patent license which is along the spirit of the original license.
This controversy is STUPID. Next we'll hear bitter complaints about how PostgreSQL's not "open source."
It's just BSD + a patent license.
OSI doesn't own a trademark on "Open Source" either and if they did, it would probably be ruled generic.
As I say, having read "Wickard v. Filburn" I think the decision has to go down as one of the worst-written Supreme Court decisions in history. The court made extremely broad declarations of what Congress could do necessary and proper to the regulation of interstate commerce.
However, when you look at more recent decisions, Wickard has been narrowed quite a bit. The Wickard court's reliance on the fact that wheat was fungible was not found in Raich, for example. Basically, the Wickard court seemed to base it's determination on the idea that a bushel of wheat produced for home use was a bushel not purchased. However, in Raich, the court characterized the concern as merely a concern that the wheat might be sold interstate if prices remained high. (I am not a fan of Raich either, but it is a heck of a lot better than Wickard.)
I don't think that Wickard has much continuing relevance today by itself. The question is no longer what Wickard allows, but what Wickard, as narrowed through Raich, Lopez, and Morrison allows. I think that's a very different question with a very different answer. But neither case really addresses whether Congress would have the right to regulate commercial services which offer interstate delivery of goods or information.
But still, if this is a statutory matter (as seems to be the case in the actual opinion) then it should be a simple matter for Congress to fix it if the courts got it wrong, right?
Of course, my thinking on net neutrality is that anticompetitive traffic shaping is pretty clearly BAD and should be seen as illegal under existing laws if not having new laws passed against it, but provided that usability is preserved, I see nothing wrong with ISP's:
1) applying opt-out security filtering (port 25, port 22, and whatever else) provided no additional fee is charged to opt out,
2) filtering for known malware (yes, this sometimes causes problems but isn't because the ISP's are being evil)
3) bumping high volume, low quality traffic down a priority for things like bulk file transfers (torrents and the like) in order to preserve everyone else's customer experience.
4) offering a QoS tier for latency sensitive applications like VOIP, provided that VOIP is not treated otherwise as a lower priority than standard usages (http, etc).
I personally think this should be discussed in Congress and basic directions given before placing our faith in unelected beaurocracies.
I thought the case more or less boiled down to "Congress hasn't delegated this power to the FCC."
Can you point me to the page where this gets settled on Constitutional grounds?