I would hope not, since not all providers use the same Organization header at the provider-level. Some override it with the name of the organization responsible for the news service while others I believe add an organizational name to what the client provides.
Look, I'm not saying I agree that RoadRunner's policy here is the best and most appropriate for their situation, but I don't see the evil intent here. RoadRunner customers get connectivity and use the news service provided by RoadRunner. In most of the cases, these are private individuals that have no "organization" in the business sense. Others are private individuals who just want their own vanity organization header (serving no real purpose in the sense of the RFC's requirements). Others may be business users who probably do have a vested interest in having a distinct organization listed in their message postings. This latter group I'd say probably has a case to complain to RoadRunner, but if they really want their postings guaranteed to be identified with a distinctive Organization header, they should probably be set up with their own news feed.
Or we could just all use sane e-mail addresses and a clear.signature.
Read the RFC snippet I quoted. The Organization header is meant to identify the organization the user belogs to or the machine, the news server itself. If you're posting through your ISP's news server, you're probably a low-end business or a single-user individual.
Still, I used the term organization in the context of a network (or news server) hierarchy, not in the logical business context. I may have been too subtle in my original post regarding this.
From an NNTP point of view, the "organization" is really the provider hosting the news service, but the description of this header in the RFC doesn't really mandate it one way or the other.
The point I was trying to make is that RoadRunner is not in violation of any civil laws, any rights you think you have, nor are they really breaking anything at all in the RFC or the intent of this header in the NNTP specification. They're doing exactly what a lot of other providers have been doing for years.
If you don't like this change in policy, by all means let them know. They could easily reverse it, but I wouldn't necessarily expect them to. If all else fails, use a different news service that lets you specify your own vanity organization header (or even better, set up your own news service).
I am unaware of this "common practice", but it sounds perfectly reasonable. It doesn't change a thing however. RoadRunner chooses not to honor this common practice. Complain to them or use a different news service. I still don't think this obligates them to honor whatever vanity Organization header you want to provide.
I also do not appreciate the name-calling. Surely you can back up a logical argument without having to resort to it?
2.2.9 Organization The text of this line is a short
phrase describing the organization to which the sender
belongs, or to which the machine belongs. The intent of
this line is to help identify the person posting the
message, since site names are often cryptic enough to make
it hard to recognize the organization by the electronic
address.
What exactly is the problem here? You can't use your vanity Organization header with their news servers anymore? This is hardly a "rights" issue as implied by the YRO category, it's just a policy change issue on the part of RoadRunner. If you don't like it, let them know, but I wouldn't expect them to change this policy as it's a perfectly legitimate use of the Organization header. Use another news service or insert your own X-Real-Organization header if you're concerned about what's in the headers. If RoadRunner had been doing this from the start, nobody would be complaining. Many ISP's do this today.
The bottom line is that from the Internet's point of view, your ISP and network provider is RoadRunner, so it makes perfect sense to label you as being part of that "organization" in this context. It is both within the letter and spirit of NNTP. To allow you to use your own vanity Organization header would only add confusion and defeats the spirit of the header.
The original post was for a small (-ish) call center, which is what I targeted my reply to. (I consider 8 small.)
I think it really depends on the nature of the organization here. A literal "call center" whose sole purpose is to take calls and send them elsewhere probably doesn't have a lot of technical focus where one might be encouraged to expand (if that makes sense). A lot of my experience goes back more to support centers and the like, so these guys more or less have to keep up with the latest stuff or they won't be able to do their job. There's more of an avenue for those types of people to grow outward than there is for a group that's simply there to answer phones.
I do agree that larger organizations that have large call centers probably also have equally large groups doing other things, so a lot of what I said would be difficult to apply there. I should have made that clearer.
I look at it this way -- if a call center tech wants to use his "free" time playing games, he will never get a raise and he will never be promoted out of that position.
If, on the other hand, he wants to spend his free time doing something else, like studying for a Cisco certification, doing some development or even just writing up technical documentation or building web pages, that tells me that's the direction he wants to go in and I will consider that when it comes time to do promotions or fill vacancies.
Another approach to this whole problem is for companies to *not* simply hire call techs, but to hire people for other positions that require them to do handle calls for part of their time as well. That way you *do* have something for them to do: their "real" job. (And if they do their real job really well, maybe they don't need to answer the phones so much.)
For those of you interested in doing something similar with your car, consider getting yourself an amateur radio license, buy some hardware, and have your car broadcast its position. Do a net search for "APRS car" for information, or check out http://web.usna.navy.mil/~bruninga/aprs.html. I might recommend the Kenwood TH-D7AG radio, which has most all of the functionality you would want in a hand-held package.
Amateur radio has lots of digital modes you could use to have your car send you a radio "instant message" when it thinks it's being stolen. Connect a GPS receiver to it, use something like APRS, and you can have it broadcasting its position to you digitally. You could even rig a "kill switch" function into an APRS message, so long as you don't mind the fact that any other amateur radio operator can send the same message. (Encryption is a no-no.)
10 100Mbit clients can pull 100Mbit each through 1 Gbit uplink port. With only a 100Mbit uplink port, one client trying to pull all 100Mbit through it will thus degrade service for all the other clients.
So who is there with one ball in his hand watching a second ball appear from the future? Did that reality just spin itself off independent of the one I'm living (possible)? Where did that reality come from? If I send another ball back in time, does it go to that same reality, or spin off a brand new one where only that ball has arrived from the future?
Assuming it goes back to "my" reality's past, even if I don't pre-plan the experiment, I can tape a note to the ball explaining what I'm up to and what I should do to complete that "leg" of the experiment.
Granted, when it's all completed, when all "loops" are over and done with, those other legs would no longer exist, and my memory would only cover the last bit of the experiment, from the ball's point of view, those legs did exist. Substitute the ball with a camcorder.
And don't think that I'm making this scenario up as a thought demonstration that I think time travel is possible (in this fashion). Quite the opposite. Conservation of energy says *something* had to happen to that ball. If it goes back into my past, my reality has gained energy. If it disappears into some alternate reality, my reality has *lost* energy.
A good comment, but what about the general case? You throw a ball into the time machine at the last minute, thereby consuming energy. At the first minute, you now have two balls, but at the last minute, you throw the original ball into the time machine, thereby completing the cycle. Your time machine has consumed energy with no apparent gain at the end of the experiment. Where did the energy go in this case?
For web use, I generally omit extensions entirely and use Apache's content negotiation.
But then users wanting to download these files to their PC frequently have problems unless their browser is smart enough to append a meaningful extension so that the user can re-open the file correctly later. Just a minor caveat.
Agreed. So maybe what we need, for every information store (e.g. e-mail, calendar, tasks) are three "views": zoomed, compact and minimal.
The "zoomed" interface is what you'd see to give you 100% of the functionality of that interface, but it would still include "minimal" views for all of your other information stores, so that you can still store the information or schedule events in other information stores easily and efficiently.
The "compact" view is what you'd see on an overall, general welcome screen (i.e. the interface CNET was looking for), where all of the information stores would be represented and usable for most all basic tasks.
The "minimal" view lets you see new messages, lets you create new objects in that information store and generally keeps you up on any changes, but your view is very compact and unobtrusive, giving 95% of the rest of the space up for other purposes.
It's up to your application to determine whether that authenticated user is authorized to do what it is he's requesting to do. You do an LDAP 'bind' to perform the authentication, and if you wanted, you could perform another LDAP check (e.g. presence in a group) for the authorization.
Say you have a LDAP hierarchy like:
o=Foo,dc=example,dc=com
And you have your organizational unit:
ou=Bar,o=Foo,dc=example,dc=com
Your local servers (A) handle this suffix, and refer everything else to the main LDAP servers (B) that handle the root suffix further above. A client (your OS, C) would make a request like this:
Step 1: Authorization C -> B* (who's uid=example?) B -> C (dunno, let's ask A) C -> A (who's uid=example?) A -> C (it's uid=example,ou=Users,o=...) C -> A (I'd like to bind as uid=example..) A -> C (OK, the password was right)
The OS now knows that the user claiming to be 'example' really is 'example'. But we still don't know if the user is allowed on this system.
Step 2: Authorization C -> B* (is 'example' in the group cn=Authorized Users,ou=Bar,o=...?) B -> C (yep.)
The OS now knows that the user is allowed to use the system.
Realistically, if you have your referrals set up correctly, where you send unknown requests to the main server, and the main server knows to delegate that LDAP suffix to *your* server, the initial request can go to either your local servers or the main LDAP servers, it doesn't matter. (In theory, it's like DNS, where your resolver can hit the local name servers, but realistically it can hit any name server in the world and it'll get referred to the right place eventually.)
There are other ways you can do your authorization, though. My main point was that you needed to break these two concepts apart. Let your main LDAP servers do the authentication, and do authorization in a second step.
Agreed, but for my own reasons (as much as I love those books). I like to think of random events simply as things we do not (yet) have the technology to predict. What follows from this is that any sequence of events, even if we don't have the technology to model and predict it, nevertheless have an underlying and "static" representation in a 4th-dimensional universe.
To allow for time travel to have one sequence of events exist before the time travel event, and another sequence of events "after" means that our static 4th dimensional model gets *really* ugly, with bits wrapping back on itself and overlaying huge chunks of what was there. It's just not beautiful.
But on the flip side, I also believe in a concept I like to call Conservation of Energy. If you stick a time machine in an otherwised "closed" room, you have the potential to generate virtually unlimited amounts of matter or energy, subject only to the logistics of using your time machine. Say at the very last minute, you chuck a ball through the time machine and send it back to the first minute. You now have two balls at the first minute (the original ball and the one that was sent through time). Now you wait until the last minute again and chuck both balls back through the time machine. At the first minute, you now have four balls (or is it 6 or 7? what happened to the first two time travel events?) The energy inside that closed room for that period of time has now risen exponentially.
So in order for time travel to work (as we classically think of it), we either have to accept the fact that the universe can "feed back" upon itself and generate nearly an infinite amount of energy (or an army of people from one person's trip back in time), or consider conservation of energy to apply here as well, making time travel impossible or perhaps possible, but differently than what we think of today.
It sounds like you need to break out your authentication from your authorization a little. Unless you need to replicate user records for availability reasons, keep them on the master servers. On your LDAP servers maintain a group containing a list of those users that are permitted access to your systems. Link them together using LDAP referrals (main organizational server delegates to your server for your organizational unit, and your server refers unknown requests to the main server).
When the user tries to log in, they'll be authenticated from the central servers, and authorizated to use the servers based on whether or not they're in the group.
When I'm sitting down to compose some e-mails, you bet I like to have one view open: for my e-mails. The distraction of seeing everything conceivable about my meetings, chatting, tasks, etc., would be an inconvenience.
HOWEVER, when I'm done with my e-mails, I'd like to be able to "step back" out of that e-mail-centric view into an all-around overview of what's going on, that would include recent e-mails, tasks, appointments and instant messaging. Today that's difficult to do.
So maybe what I would like to see is a variation of CNET's proposal: we could have a view where you see everything and everything (that you want), and allow you to "zoom" into a particular workspace to get a more details overview of, say, your inbound e-mails, etc., and perhaps a cursory notification pane that covers events in every other section of the application.
In the past, the music industry has been able to say, "Look, we have millions of downloads going on here where people are downloaded illegal pirated versions of our music!" Now that they're making it impossible for us to legally purchase music and listen to it on computing devices and players, we have to go download it instead. The percentage of those downloads that are for legally purchased music will go up. They can no longer say that most (if not all) of those downloads are for music the downloader shouldn't have.
Is it illegal to "redistribute" a copyrighted work to somebody that already has a license to it?
It's been a while since I created my Yahoo! account, but by the time you receive this screen with marketing preferences, you've already given them your contact information, a decision you've made solely on the information in their terms of service and privacy policy.
THEN they ask you what your preference is regarding using your contact information for marketing purposes. You've already given implicit consent for them to use it by signing up in the first place (according to their privacy policy).
Now, I still consider it very shady and unethical for them to turn around and say, "I know you said no, but we don't really care," but:
a. I don't *think* there's any legal issue here; and b. This is all assuming that these 'marketing categories' existed when you signed up in the first place. Their privacy policy seems to imply that they can add 'marketing categories' to their site later and assume an 'opt-in' policy for everyone that doesn't explicitly re-visit and opt-out.
So while I'm just as annoyed at Yahoo! as everyone else is, and find that this practice (assuming it was even deliberate) to be very shady, it's definitely arguable as to whether or not legal retaliation is warranted or possible.
New categories of marketing communications may be added to the Marketing Preferences page from time to time. Users who visit this page can opt out of receiving future marketing communications from these new categories or they can unsubscribe by following instructions contained in the messages they receive.
This might imply that you must explicitly "opt out" of new marketing categories. If all of these options are relatively "new", then it's consistent with their privacy policy.
It doesn't excuse the fact, however.
Slashdot Mirror
I would hope not, since not all providers use the same Organization header at the provider-level. Some override it with the name of the organization responsible for the news service while others I believe add an organizational name to what the client provides.
.signature.
Look, I'm not saying I agree that RoadRunner's policy here is the best and most appropriate for their situation, but I don't see the evil intent here. RoadRunner customers get connectivity and use the news service provided by RoadRunner. In most of the cases, these are private individuals that have no "organization" in the business sense. Others are private individuals who just want their own vanity organization header (serving no real purpose in the sense of the RFC's requirements). Others may be business users who probably do have a vested interest in having a distinct organization listed in their message postings. This latter group I'd say probably has a case to complain to RoadRunner, but if they really want their postings guaranteed to be identified with a distinctive Organization header, they should probably be set up with their own news feed.
Or we could just all use sane e-mail addresses and a clear
Read the RFC snippet I quoted. The Organization header is meant to identify the organization the user belogs to or the machine, the news server itself. If you're posting through your ISP's news server, you're probably a low-end business or a single-user individual.
Still, I used the term organization in the context of a network (or news server) hierarchy, not in the logical business context. I may have been too subtle in my original post regarding this.
From an NNTP point of view, the "organization" is really the provider hosting the news service, but the description of this header in the RFC doesn't really mandate it one way or the other.
The point I was trying to make is that RoadRunner is not in violation of any civil laws, any rights you think you have, nor are they really breaking anything at all in the RFC or the intent of this header in the NNTP specification. They're doing exactly what a lot of other providers have been doing for years.
If you don't like this change in policy, by all means let them know. They could easily reverse it, but I wouldn't necessarily expect them to. If all else fails, use a different news service that lets you specify your own vanity organization header (or even better, set up your own news service).
I am unaware of this "common practice", but it sounds perfectly reasonable. It doesn't change a thing however. RoadRunner chooses not to honor this common practice. Complain to them or use a different news service. I still don't think this obligates them to honor whatever vanity Organization header you want to provide.
I also do not appreciate the name-calling. Surely you can back up a logical argument without having to resort to it?
The bottom line is that from the Internet's point of view, your ISP and network provider is RoadRunner, so it makes perfect sense to label you as being part of that "organization" in this context. It is both within the letter and spirit of NNTP. To allow you to use your own vanity Organization header would only add confusion and defeats the spirit of the header.
The original post was for a small (-ish) call center, which is what I targeted my reply to. (I consider 8 small.)
I think it really depends on the nature of the organization here. A literal "call center" whose sole purpose is to take calls and send them elsewhere probably doesn't have a lot of technical focus where one might be encouraged to expand (if that makes sense). A lot of my experience goes back more to support centers and the like, so these guys more or less have to keep up with the latest stuff or they won't be able to do their job. There's more of an avenue for those types of people to grow outward than there is for a group that's simply there to answer phones.
I do agree that larger organizations that have large call centers probably also have equally large groups doing other things, so a lot of what I said would be difficult to apply there. I should have made that clearer.
I look at it this way -- if a call center tech wants to use his "free" time playing games, he will never get a raise and he will never be promoted out of that position.
If, on the other hand, he wants to spend his free time doing something else, like studying for a Cisco certification, doing some development or even just writing up technical documentation or building web pages, that tells me that's the direction he wants to go in and I will consider that when it comes time to do promotions or fill vacancies.
Another approach to this whole problem is for companies to *not* simply hire call techs, but to hire people for other positions that require them to do handle calls for part of their time as well. That way you *do* have something for them to do: their "real" job. (And if they do their real job really well, maybe they don't need to answer the phones so much.)
I suppose not. But once you use your autopatch codes, anyone listening on the uplink knows them too.
Though I guess you could get sophisticated and rotate through some codes to authenticate yourself (a la SecurID).
But yah, you're right. I just think of everything I do over-the-air as exposed and insecure.
For those of you interested in doing something similar with your car, consider getting yourself an amateur radio license, buy some hardware, and have your car broadcast its position. Do a net search for "APRS car" for information, or check out http://web.usna.navy.mil/~bruninga/aprs.html. I might recommend the Kenwood TH-D7AG radio, which has most all of the functionality you would want in a hand-held package.
Amateur radio has lots of digital modes you could use to have your car send you a radio "instant message" when it thinks it's being stolen. Connect a GPS receiver to it, use something like APRS, and you can have it broadcasting its position to you digitally. You could even rig a "kill switch" function into an APRS message, so long as you don't mind the fact that any other amateur radio operator can send the same message. (Encryption is a no-no.)
10 100Mbit clients can pull 100Mbit each through 1 Gbit uplink port. With only a 100Mbit uplink port, one client trying to pull all 100Mbit through it will thus degrade service for all the other clients.
So who is there with one ball in his hand watching a second ball appear from the future? Did that reality just spin itself off independent of the one I'm living (possible)? Where did that reality come from? If I send another ball back in time, does it go to that same reality, or spin off a brand new one where only that ball has arrived from the future?
Assuming it goes back to "my" reality's past, even if I don't pre-plan the experiment, I can tape a note to the ball explaining what I'm up to and what I should do to complete that "leg" of the experiment.
Granted, when it's all completed, when all "loops" are over and done with, those other legs would no longer exist, and my memory would only cover the last bit of the experiment, from the ball's point of view, those legs did exist. Substitute the ball with a camcorder.
And don't think that I'm making this scenario up as a thought demonstration that I think time travel is possible (in this fashion). Quite the opposite. Conservation of energy says *something* had to happen to that ball. If it goes back into my past, my reality has gained energy. If it disappears into some alternate reality, my reality has *lost* energy.
Agreed.. This is also the reason I can't use anything like Tivo, because it doesn't support high-definition. :(
Aside from the bandwidth needed for an HDTV stream versus a regular one, what are the technical hurdles keeping this from happening?
But what if, on that last loop, you choose not to send all of the balls back in time? You've now got a bucket full of balls and a full tank of gas.
Or does the act of "receiving" a ball from the future consume just as much energy as the act of "sending" one into the past?
A good comment, but what about the general case? You throw a ball into the time machine at the last minute, thereby consuming energy. At the first minute, you now have two balls, but at the last minute, you throw the original ball into the time machine, thereby completing the cycle. Your time machine has consumed energy with no apparent gain at the end of the experiment. Where did the energy go in this case?
Agreed!
For web use, I generally omit extensions entirely and use Apache's content negotiation.
But then users wanting to download these files to their PC frequently have problems unless their browser is smart enough to append a meaningful extension so that the user can re-open the file correctly later. Just a minor caveat.
Agreed. So maybe what we need, for every information store (e.g. e-mail, calendar, tasks) are three "views": zoomed, compact and minimal.
The "zoomed" interface is what you'd see to give you 100% of the functionality of that interface, but it would still include "minimal" views for all of your other information stores, so that you can still store the information or schedule events in other information stores easily and efficiently.
The "compact" view is what you'd see on an overall, general welcome screen (i.e. the interface CNET was looking for), where all of the information stores would be represented and usable for most all basic tasks.
The "minimal" view lets you see new messages, lets you create new objects in that information store and generally keeps you up on any changes, but your view is very compact and unobtrusive, giving 95% of the rest of the space up for other purposes.
It's up to your application to determine whether that authenticated user is authorized to do what it is he's requesting to do. You do an LDAP 'bind' to perform the authentication, and if you wanted, you could perform another LDAP check (e.g. presence in a group) for the authorization.
Say you have a LDAP hierarchy like:
o=Foo,dc=example,dc=com
And you have your organizational unit:
ou=Bar,o=Foo,dc=example,dc=com
Your local servers (A) handle this suffix, and refer everything else to the main LDAP servers (B) that handle the root suffix further above. A client (your OS, C) would make a request like this:
Step 1: Authorization
C -> B* (who's uid=example?)
B -> C (dunno, let's ask A)
C -> A (who's uid=example?)
A -> C (it's uid=example,ou=Users,o=...)
C -> A (I'd like to bind as uid=example..)
A -> C (OK, the password was right)
The OS now knows that the user claiming to be 'example' really is 'example'. But we still don't know if the user is allowed on this system.
Step 2: Authorization
C -> B* (is 'example' in the group cn=Authorized Users,ou=Bar,o=...?)
B -> C (yep.)
The OS now knows that the user is allowed to use the system.
Realistically, if you have your referrals set up correctly, where you send unknown requests to the main server, and the main server knows to delegate that LDAP suffix to *your* server, the initial request can go to either your local servers or the main LDAP servers, it doesn't matter. (In theory, it's like DNS, where your resolver can hit the local name servers, but realistically it can hit any name server in the world and it'll get referred to the right place eventually.)
There are other ways you can do your authorization, though. My main point was that you needed to break these two concepts apart. Let your main LDAP servers do the authentication, and do authorization in a second step.
Agreed, but for my own reasons (as much as I love those books). I like to think of random events simply as things we do not (yet) have the technology to predict. What follows from this is that any sequence of events, even if we don't have the technology to model and predict it, nevertheless have an underlying and "static" representation in a 4th-dimensional universe.
To allow for time travel to have one sequence of events exist before the time travel event, and another sequence of events "after" means that our static 4th dimensional model gets *really* ugly, with bits wrapping back on itself and overlaying huge chunks of what was there. It's just not beautiful.
But on the flip side, I also believe in a concept I like to call Conservation of Energy. If you stick a time machine in an otherwised "closed" room, you have the potential to generate virtually unlimited amounts of matter or energy, subject only to the logistics of using your time machine. Say at the very last minute, you chuck a ball through the time machine and send it back to the first minute. You now have two balls at the first minute (the original ball and the one that was sent through time). Now you wait until the last minute again and chuck both balls back through the time machine. At the first minute, you now have four balls (or is it 6 or 7? what happened to the first two time travel events?) The energy inside that closed room for that period of time has now risen exponentially.
So in order for time travel to work (as we classically think of it), we either have to accept the fact that the universe can "feed back" upon itself and generate nearly an infinite amount of energy (or an army of people from one person's trip back in time), or consider conservation of energy to apply here as well, making time travel impossible or perhaps possible, but differently than what we think of today.
*shrug*.. My two cents.
It sounds like you need to break out your authentication from your authorization a little. Unless you need to replicate user records for availability reasons, keep them on the master servers. On your LDAP servers maintain a group containing a list of those users that are permitted access to your systems. Link them together using LDAP referrals (main organizational server delegates to your server for your organizational unit, and your server refers unknown requests to the main server).
When the user tries to log in, they'll be authenticated from the central servers, and authorizated to use the servers based on whether or not they're in the group.
When I'm sitting down to compose some e-mails, you bet I like to have one view open: for my e-mails. The distraction of seeing everything conceivable about my meetings, chatting, tasks, etc., would be an inconvenience.
HOWEVER, when I'm done with my e-mails, I'd like to be able to "step back" out of that e-mail-centric view into an all-around overview of what's going on, that would include recent e-mails, tasks, appointments and instant messaging. Today that's difficult to do.
So maybe what I would like to see is a variation of CNET's proposal: we could have a view where you see everything and everything (that you want), and allow you to "zoom" into a particular workspace to get a more details overview of, say, your inbound e-mails, etc., and perhaps a cursory notification pane that covers events in every other section of the application.
My US$0.02.
In the past, the music industry has been able to say, "Look, we have millions of downloads going on here where people are downloaded illegal pirated versions of our music!" Now that they're making it impossible for us to legally purchase music and listen to it on computing devices and players, we have to go download it instead. The percentage of those downloads that are for legally purchased music will go up. They can no longer say that most (if not all) of those downloads are for music the downloader shouldn't have.
Is it illegal to "redistribute" a copyrighted work to somebody that already has a license to it?
Somebody should go print up a bunch of stickers that informs users more completely about the wrongs of this CD. Something like:
:)
"Warning: This music disc is not a real 'CD' (note the lack of a CD logo) and WILL NOT PLAY on many players. Purchase at your own risk."
Then go into your local music stores and slap them on every one of these CD's you can find.
It's been a while since I created my Yahoo! account, but by the time you receive this screen with marketing preferences, you've already given them your contact information, a decision you've made solely on the information in their terms of service and privacy policy.
THEN they ask you what your preference is regarding using your contact information for marketing purposes. You've already given implicit consent for them to use it by signing up in the first place (according to their privacy policy).
Now, I still consider it very shady and unethical for them to turn around and say, "I know you said no, but we don't really care," but:
a. I don't *think* there's any legal issue here; and
b. This is all assuming that these 'marketing categories' existed when you signed up in the first place. Their privacy policy seems to imply that they can add 'marketing categories' to their site later and assume an 'opt-in' policy for everyone that doesn't explicitly re-visit and opt-out.
So while I'm just as annoyed at Yahoo! as everyone else is, and find that this practice (assuming it was even deliberate) to be very shady, it's definitely arguable as to whether or not legal retaliation is warranted or possible.
(In my opinion.)
http://slashdot.org/comments.pl?sid=30264&cid=3249 479