There are a number of training classes and "bootcamps" for various things which are based in California. Cisco Certified Internetworking Expert certification bootcamps and various others come to mind. Those bootcamps (and many others) can be many thousands of dollars.. So the question becomes, at what point do you start considering regulation for a group? When the amount of money they collect is over $X? Or when the duration of the course is over X weeks? If they are going to regulate courses at all, these need to be clearly defined and enforced uniformly. The issue here is that when it is defined too vaguely, there are a very large number of classes that should be regulated, which aren't. Cooking classes, professional certification training programs and many other classes should fall under this. Regulatory authorities in state are likely not equipped with experts in the field to be able to define what methods/requirements are "best" for every type of organization.
With that said, I think the drawbacks of regulating classes like these, is far more than the "help" it will provide to consumers.
* If someone is willing to drop $15,000 on a bootcamp without fully vetting it via research, references, reviews and the like, that's not very smart of them and they are partially at fault for signing up for something that didn't provide what they need/want.
* However, if the bootcamp doesn't provide on what it promises, then they have every right to complain to the state and/or sue to get their money back (although, I expect most would complain to the state due to resource related issues.)
In short, California either needs to clearly define exactly who should be regulated, and they should apply that uniformly, not just on a specific group of companies.
I believe employers are legally required to inform you of monitoring your actions, usually in an employee handbook of some kind. The issue is that in general it is "your actions / calls / etc are subject to monitoring", versus naming specific ways they are monitoring you.
In general, if you're on the company clock and/or using company equipment - you should always assume you're being monitored. If you're doing something wrong and it is caught by you being monitored, then tough luck. If the results of monitoring are being misinterpreted and you weren't doing anything wrong, explain it to your boss and there should be no issues, and if there are you have a crappy boss (and the same situation would likely eventually happen without monitoring.)
The issue is if companies are monitoring you on your personal time, when you're not using company equipment. That's another issue entirely and IMHO wrong.
Buckyballs were labeled as for adults and not for kids before the commission came after him. However, because they are so similar to a "toy" it was labeled as a concern by the government. In my opinion, this action removes personal responsibility from the parents (the product was clearly labeled), and there should have been no actions against Buckyballs as long as they were properly labeled. There are many other products out there that are far more dangerous which look like toys which do not have these concerns.
Further, it begs the question:
Is it the norm for similar cases where the owner/company simply went out of business (without doing a recall) on an unsafe product, for the owners to be held liable for the cost of a potential recall after the fact?
If he is held personally liable, but a large number of other cases had companies which went out of business and the owners were not held liable - it seems likely there was some type of bias on his case.
One last item:
Protection from personal liability when you are a shareholder/officer of a corporation isn't absolute (you can still be held legally personally liable in certain cases.) Certain people here advise they don't like this fact, as they feel people should be personally liable. However, to be frank - fewer people would take risks if they faced personal ruin due to a lawsuit. A better option would be to revoke a company's incorporation status and in repeat offenses remove the ability for people to be part of another corporation perhaps. This would have the positives, without the negatives.
I should have clarified in the previous comment that if you don't have the ability to dictate the terms of the contract (such as if you buy the product in the store), it is my belief that you can likely recover damages already if it is due to gross negligence of the developer in question in most jurisdictions. As mentioned in the previous comment, proving that can be another issue entirely.
Any development contract should have language indicating what is desired and minimum standards compliance (example: PCI compliance if you're handling credit card data.) If it is later found that the developer did not adhere to the terms of the contract, they can be sued for breach of contract.
Further, if the flaws in the software are extremely severe, even if the contract didn't explicitly call out the problems observed, they could be covered under gross negligence and the developer can be sued for that as well.
As with many other things, a new law isn't needed for this, the ones on the books are perfectly suitable. The money/time it takes to get a remedy to the issue via our court system is another matter entirely, but would be similar regardless of a new law.
If my organization owns the A.B.C network, there is no reason why any packets bearing a source address of anything other than A.B.C.* should be permitted to leave my network.
Actually, there is at least one very good reason. If company A has 2 internet connections through provider A and B, and wishes to do load balancing, but for one reason or another can not announce a single subnet through both providers, they can at least do outbound load balancing and change the source address on a per packet basis, so incoming traffic for connections initiated by someone local are evenly distributed through both connections. Obviously any connections that originate from the outside world (i.e. someone on the internet trying to view this company's website) have to be answered with the same IP that the request originally went to as the source address (or stuff will break(tm)), so this wont work in that situation, but any request that originated on the company's network, and goes out to the internet, can have the outbound traffic load balanced on a per packet basis over their multiple internet connections, even if they can't announce the same block through both providers. This however requires that some packets have a source address in the subnet of for instance provider A, when they go out through the circuit with provider B, to evenly load balance packets.
The other option, which does not require sending packets with a source address for one provider when it goes through another, is to do it on a per connection basis, and not a per packet basis, however depending on your traffic, etc.. this may not work nearly as well.
While obviously, the number of people implimenting something like this is few, and the benefits are many to implement anti-spoof measures, to the few people doing something like the above, it sucks. However, there is an answer, that will satisfy both causes.
To the few people that do load balance in the method mentioned above, a simple ACL allowing only packets with either subnet as the source (for either line A or B's block), and deny all other sources, will both allow them to load balance outbound traffic, and it will protect your network (and others) (since they can't spoof any other address, other than their block with the other provider through you, as the ACL will drop it).
For everyone else, you can use the following command on a Cisco with CEF enabled, which drops all traffic that does not have a source address that is routed through the interface the packet was received on:
Cable companies have to pay for programming. They pay Time Warner, etc on a per subscriber basis, and they get discounts if they offer certain combinations of channels from the same programmers to their subscribers.
For cable companies its frequently cheaper to have a channel lineup that includes say, 4 time warner owned channels to a subscriber, instead of just one or two (i.e. they have to pay less for the programming).
Remember, a large percentage of what you pay for cable goes for programming fees, then they have tons of other costs, etc... They probably are being greedy to an extent, but, its not exactly as cost effective for them to provide programming on a per channel basis (due to programming charges, and other things).
Re:Just play it straight.
on
802.11 RF Amp
·
· Score: 2, Interesting
I wonder when ISP's are going to realize that it is futile to say "no NAT" or "no servers" or "max transfer gb per month" and realize that the only sane thing to do is to provide unrestricted access, and simply charge their customers what it actually costs to provide xx mb of bandwidth?
Because, if Company A has "UNLIMITED" in really big letters, but all of the restrictions (no servers, etc) are less prominent, and Company B says "We allow you to have servers, but we charge money per mbit" Joe user will go with company A almost everytime. Why?
Because "UNLIMITED" stands out, unlimited is certainly better than limited right? The average broadband internet user doesn't have a server, and chances are, they don't know how many mbps of traffic they make use of in a month. Joe user will see the part from Company A, not care about the restrictions (the fact remains that the majority of cable modem/dsl subscribers/don't/ have servers), and choose it over Company B because "UNLIMITED" means better to most people.
The 'better' answer is to have multiple tiers of service, where the base plan is unlimited, but with restrictions (no servers, one computer, etc), and another plan where you can have servers, but only if you pay extra (per mbps over a certain amount, etc)... The problem is, most people who have a '*NIX box' with a web server wont want to pay extra, and will just get the cheaper plan, so 'policing' (port scanning their address space for people running servers on well known port numbers) for people running servers, would be necessary.
Also, it would probably be prudent to have a 'power users' plan, where if you have over X computers (NAT'd or not) you have to pay X amount.
Mind you, this would suck for a lot of people, since they'd have to pay more per month, but overall the cost of broadband for the average user should go down. It makes sense, it just depends on how you market it.
Re:NAT is hard to detect
on
802.11 RF Amp
·
· Score: 3, Informative
This is somewhat easy to find people that are extremely likely to be NAT'ing actually, usually with no extra hardware than what the ISP already has.
You can look at the source port of the packet (going from the customer to wherever, i.e. ingress to the ISP's network), to be fairly confident that the customer is NAT'ing their traffic.
Most NAT implimentations change the source port to a very high port number (usually in the 60,000+ range) when they translate (along with changing other info). You can probably be fairly safe to log anything above 40k (although some research into what more popular 'ethernet routers' that do NAT use for port ranges would be prudent). Normal traffic for most implimentations of a TCP/IP stack won't typically source off of ports that are reserved for NAT'ing, so again, you can be fairly sure they are NAT'ing if you 'catch' them (enough to call them to ask them about it anyway.. that way if they aren't, you don't shut down a paying customer for no reason).
On a cisco, you can setup an extended access list applied to the interface the traffic is hitting, with logging enabled to see who is NAT'ing, see if it continues for a while, and if it does, you can be fairly assured they are NAT'ing traffic.
Mind you, there are many ways around this for some implimentations of NAT (i.e. changing the port range NAT'd packets source off of), but for average Joe User hooking up an 'ethernet router' that does NAT, they could be caught fairly easily by this (and other methods that work in conjunction with this).
(this is just a brief summary, don't blame me if it isn't detailed enough).
Its always great when we have posts that directly support software piracy.. NOT.
The worst part is, as far as I know there isn't even a semi-convincing moral argument for pirating Id software's games. Id Software has (in the past) released a demo, or a test version of the software previous to release of their retail product, so you can 'try before you buy'. In addition, they have 'given' past releases (doom, quake, quake 2..)'s source code to the public. There are very few major commercial gaming software companies who do this, and I think this earns Id a lot of respect.
Sure, there are probably some people out there who will warez the alpha version of doom 3, and then go out and buy it, but its probably going to give quite a few the wrong impression of the game, as it is quite an early version of it.
Anyway, I hope the ATI employee who leaked the game (if thats infact true) gets fired. I also hope that most people on slashdot don't go out and pirate the game, and simply wait for Id's 'test' or demo release.
Why not simply have a small list of MIME types that are allowed to be 'viewed', that does not include.sh,.exe, and other potentially harmfull things? Make it easy to add/remove things to the list, and have more/less restrictive versions of said list of MIME types?
Or you could add a popup window, so when you try to execute anything potentially dangerous, the window asks you if you really want to 'view' a.sh,.exe, etc file. You would need to also have the MIME types that are considered 'dangerous' able to be easily added to/removed from. (I don't like this idea as much)
According to the page that is linked in the summary http://www.drgibson.com/towers/ It mentions:
The buildings supporting the towers were hardened against a nuclear blast, and some of them in high-danger areas were underground. The towers themselves were engineered to withstand all but a close (within 5 miles) blast. The microwave horns were covered with a protective shield to keep out not only the elements, but also radioactive fallout. The buildings were shielded with copper to protect the equipment against the Electromagnetic Pulse associated with a nuclear explosion. Foot-thick concrete walls protected the vital electronics and people inside the base installations of these towers. Thick copper grounds went deep into the bedrock beneath each tower. Fallout showers, backup generators, sleeping facilities all existed to keep the network up in times of war.
So while the equipment itself is likely hardened, the building is shielded.. It doesn't say how much shielding, etc there is however:)
How to test speed, and tons more info!
on
How to Test Your T1?
·
· Score: 5, Informative
Couple of things, first, all ISPs oversell bandwidth. I am assuming the 'larger' guys meant that the local ISP likely only has a single DS-3 to his upstream provider. Depending on how small he is, this may not be an issue (/all/ providers oversell at some ratio, it just depends on what that ratio is that determines if the provider sucks or not) depending on how many other customers he has, what types of circuits your providers customers' have, and what type of customer they are (business vs. residential), etc. Obviously there are other factors too.. if your provider suddenly grows and doesn't increase its upstream capacity, thats an issue.
Now, on to determine if you have a 'real' T1. Many providers tend to sell frame relay service as a 'T1'. While its true that the circuit itself from the telco to your place of business is a T1 (unless you have say 56k DDS service, etc), after your traffic hits the telco's switch, it transverses their frame relay network, and eventually gets sent to the frame host on your provider's network. This can suck for many reasons, however the biggest one is that the provider can get away with purchasing a CIR that is less than 1.5 mbps (like 768kbps), and just have it be able to burst up to 1.5. This can suck a whole lot if the telco's frame network is congested, and you can never burst, and/or you constantly want to use more than the CIR etc..
You can tell what kind of circuit it is by quite a few ways, if its installed and you have access to the router you can simply check the encapsulation on the T1 (if its set to frame relay, its a frame circuit, if its set to PPP or HDLC its a point to point circuit), you can also tell by the format of the circuit id (the first part of/most/ circuit IDs from/most/ telcos is something like XX.AAAA where AAAA is frequently what your concerned about to determine the circuit type, but the format of the CID depends on your telco (there are many guides out on the internet at decyphering these to determine what type of service they are, or you could call your telco and they could tell you.. maybe.. if your good.. heh)). The CID should be on the smartjack..
If you have a frame circuit they should be charging you quite a bit less than a point to point T1, especially if the CIR is low (the lower the CIR the less expensive generally). Point to point T1s are preferible in almost all cases unless your worried about cost.
So now that you've determined the type of circuit you have, you can check what speeds your getting. Its usually best to do as other people have mentioned and download (and UPLOAD too.. you should check both speeds) from an FTP server on the provider's network. This will give you the most accurate picture of how fast your connection/can/ be, without having to deal with other provider's networks being congested, etc (the traffic in this case will be local to your provider's network, so if thats congested then um.. that sucks).. You should get somewhere around ~192KB/s.. if its slightly less don't worry about it, there is some overhead involved, etc.. When you do this be sure you only have/one/ machine connected to test (or you can verify there is nothing else that is generating traffic that is going over that circuit, etc... don't assume.. check. (there are many, many, many tools to do this..) to see whats hitting the ethernet interface of your router (its a lot easier to check if you have access to your router, as you can just do a show int on a cisco to get traffic statistics, etc).
You should also do a separate test to a major site.. You could download the 1.4.0 Java SDK from Sun for instance (that should give you a decent speed). Don't worry if this is somewhat lower than 192KB/s, as that can be caused by congestion in a network inbetween you and sun that has nothing to do with your provider, etc.. If its consideribly lower than that speed consistantly (and other sites with bandwidth to spare yield the same results), then I would contact your provider about it. It could be that your provider doesnt have enough upstream capacity, or about a billion other things, but they might be able to tell you any known issues, or that the problem isn't them and/or tell you the current utilization levels of their upstream circuits.. heh
IP Laws are necessary, to an extent in our society
on
Fair IP Laws?
·
· Score: 1
Patents, copyright, etc. are designed to help promote innovation. People tend to point out extreme examples for either side.. However I think the following covers why patent laws (in my opinion) are a good thing, as long as they are on specific methods or products, and for a fairly short period of time (which would depend on what the patent is for).
Many, many patents have been granted over the years. Some products can legitimently benefit from a patent, and some do not (or they don't substantially anyway). In theory, patents can help innovation. An example of this is as follows:
Company A makes a wheel in a certain way, and obtains a patent on that specific design, and method of making the wheel.
Company B makes a wheel in a different way, and obtains a patent on that specific design, and method of making the wheel.
Company C makes a wheel in a different, and better way then companies A and B, and gets a patent on the specific design and method.
Unless a company wishes to purchase rights to use a preexisting design for something that has been patented, they need to develop something 'better', or at least different. I think few will argue that in theory, patents work. The problem comes with the patent office approves patents that are too broad. If the patent office approved a patent for the wheel in general (not the specific design, etc that a specific company made), then that would hinder innovation, causing other companies who wish to make a better wheel, to still license rights to use 'the wheel'.
If we didn't have patent laws, you would find that while much innovation will continue, there will be certain areas that will suffer more than others. Niche market areas, where a company must spend huge sums of money to develop a product, and sell it to a customer base that is very small will suffer the most in my opinion. This is because after the development is done, since there isn't a large customer base, the price for the product will need to be high to recover the development costs. If another company comes in, makes the same product, but for far, far, far cheaper since they don't have any development costs, then few people will want to spend the money on development, as chances are someone will simply steal their idea and charge less. I don't think this will be a problem in most areas, since with a larger customer base, the cost(s) will be less per customer to recover development costs, and in theory the company which develops the product, will have a head start, and should be able to identify the product with their own brand, and sell enough units to at least recover most of their development costs. Also, if a product/method is very hard for someone to reproduce due to the amount of skill/money involved, then a patent won't make a/huge/ difference, at least for a while, in most cases.
Now that I've typed all of that, lets see if anyone reads it (and out of those people who read it, who actually thinks it makes sense).
Frequently companies make you call in, in the hopes that when you talk to a customer service rep., he/she will convince you not to cancel. This can either mean changing the rates for that customer (i.e. giving a current customer a promotional rate that was only supposed to be for a new customer), or simply talking to the customer. While it is annoying, it is understandable why they make you call in.. Probably 30% (thats a guess) of the calls they get to cancel, once they talk to a customer rep. will decide not too. Of course, that doesn't include all of the people who just give up before talking to a customer service rep, but hey.. There should be a 'why are you cancelling today?' and then try and address those concerns, but if the customer just wants to cancel, and says that after you ask them the above, then you should just cancel their account heh)...
So while companies should make it easy for you to cancel when talking to a CSR (which most don't), making you call in to do it is perfectly understandable (although annoying for some of us), just make it quick and easy when you call in.
After being slashdotted and geekaustin'd and touted for being the first theater with wireless access.... I went to see Spider-Man tonight at the Alamo Drafthouse North in Austin. Apparently you can't have 'electronic devices on' during the feature. I was warned if I didn't shut down my laptop I had to leave by some girl that worked for the theater. The world's first Cyber-Theater my ass. Nice try, but apparently wireless users are absolutely not welcomed there when a movie is playing. I'm very disappointed. I couldn't even have my PocketPC with wireless NIC on while the movie was on. Was I taking off down the runway on an airplane? What's the point?"
Uh... Its a movie... laptop displays can be pretty bright in a dark room, and it is almost (but not quite as bad..) as bad as turning on a flashlight in a theater if your close to the person... I'd ask to have you kicked out if I was trying to watch the movie and was sitting a seat or two behind you..
Also, why have internet access WHILE your watching the movie? I can see it while your waiting for it to come on, or while your waiting in the lobby, but yeesh.. heh
1. Turn off directed broadcasts on all interfaces. This will prevent a situation, where you have a person sending one packet, and the network replies with many DUP packets.. If the person changes the source address in the packet they are sending, the remote network (with directed broadcast enabled) will send its replies to whoever you want. i.e. someone can use this to do a smurf attack. So, for every one packet someone sends, an untold amount of addresses could respond to the source address of the packet. Disabling this is quick and easy in most cases.
2. If using a Cisco enable: ip verify unicast source reachable-via rx which will ensure that the source address of packets received on the interface have source addresses that are reachable over that interface. Have it enabled on all gateway routers, so that when customers try to issue a DoS attack against someone else, the source address of the packets have to be their own, or the packet is dropped. They can't just send a bunch of ICMP echos to a/16 off of a router that has directed broadcast enabled, and change the source to someone else.
Unfortunately both of those methods require somewhat cluefull network admins... Also, some things have legit uses (load balancing outbound traffic is a good reason not to have "ip verify unicast source reachable-via rx" enabled, in certain circumstances (i.e. the customer has 2 providers, with 2 seperate IP blocks, each only known through one provider, they can't really do equal cost load balancing on incoming traffic, but they can do equal cost on outbound)).
Again, the issue is having cluefull network admins.. There will always be people out there getting around it, but you can make it a lot harder for them to do it, and you can drastically lower the amount of DoS attacks that happen.
helo hostname.net MAIL FROM:bgates@microsoft.com RCPT TO:bob@iwantmyemail.org data Subject: I want to give you free money text goes here .
Ok, so lets think about this... something this easy to forge (Well, if you really want to get annoying about it, you could check the SMTP server the person is sending through (and they IP of their own connection), but quite a few people use different internet services then where their domain is hosted), is being considered a legally binding document.... You can specify a different MAIL FROM field in any email client, by simply changing the address listed as well, youe email address in there (I find the above method quite easy, although it doesn't include all of the headers most clients send along with their message(s), but I'm lazy and didnt want to type that out also) I am willing to bet that the judge has/no/ clue on how email actually works.
However... On the same token, if you can match the emails that were sent to logs from the SMTP server that person relayed them through (assuming its not your own mail server), and the logs of the receiving mail server (again, assuming its not your own mail server, and the IP that you sent the message from shows up as your account when you look at the radius logs (or whatever is applicable for your type of connection), then I could see that being/proof/ the emails were actually sent... Of course, thats not proof that the text in the body of the emails is the same as what is being presented heh. It doesn't mention the people using public/private keys in the email, so its doubtfull they used PGP, etc..
An easy way to disprove someone saying that an email they were sent is different from the one the person says they sent is to compare the message size(s) to what the MTA's on both sides logged the message as. Chances are no one even thought about that when they were writing up the forgery:)
I find this quite amusing though...
Re:Use Existing Technology
on
Is Hyperchip Hype?
·
· Score: 4, Interesting
Couple of things...
1. 90% of the time when you call a large internet service provider, you speak to their frontline support, who address their level 2 support (etc) as 'routing engineers', consider how many people must call them and complain about problems (90% of which are probably caused by stupid things like them advertising a/24 in class B space, without advertising the/16 also, so the route gets nuked at a border router, as quite a few providers filter based on classfull boundries, or people just not understanding how a traceroute even works, and demanding to speak to a 'routing guru' because their traceroute dies after a certain point due to an ACL (access control list), so they naturally think the web server/mail server, etc they are going too is down, even though it is not.).
2. As someone pointed out, number of hops != latency, etc. Most people who are just starting their quest for knowledge in this field tend to confuse the two unfortunately.
Now, while in an ideal network, 99% of things will be done at layer 2, thereby making the total hopcount in your traceroute lower (if your traffic is going through an ATM switch who doesn't know about/care about layer 3 information in an ATM cell, it will obviously not show up as a hop in your trace). The hopcount your traceroute shows doesn't matter, the simple fact that all that has to be done is the header of the ATM cell (the first 5 bytes) is read, and then the cell is forwarded to its proper destination (similar for ethernet, using cut-through switching, etc) doing switching at layer 2, vs. having to read the IP packet's headers to find the destination will provide a noticible decrease in latency in most situations.
You are however correct in that Cisco has many features out there that will greatly increase performance for people. Mind you, there aren't any official 3rd party benchmarks against this (the company the article is referring too) company's products, so we don't know if they are something to laugh at, or really are better then whats out there currently (although I am voting for the laughing part).
Also, in regards to BGP, (heh btw it has quite a bit of overhead, since it uses TCP), while it is pretty much the only good choice for an EGP (external gateway protocol), you will still need an IGP such as OSPF, etc unless you intend to have your router(s) have BGP sessions with the IP's of other routers known via directly connected (or static routes), which would be stupid (except for some situations using static routes in a very small network). Its not like you setup a BGP session with another router, and it 'magically' works, there is quite a bit of traffic engineering involved (how much is dependent on how big your network is), and cooperation among internet service providers (i.e. to set the localpref that is distributed to your IBGP mesh based on certain communities received from a peer, or the other way around, so people can control the path traffic goes back into their network in a better way then padding the route (i.e. adding more AS's to the AS_PATH which chances are wont give you the desired results), or other methods).
Lets not forget that the vulnerability code red, etc takes advantage of has had a patch out for several months, but quite a few people never bothered to patch their servers. Chances are the patch(s) will be available shortly after the mainstream ones are released if you have a good vendor.
Besides, say your running *NIX with a specially modified version of apache, and there is some remote exploit that is discovered. Obviously you can't just download the source, compile, and install, for fear of loosing those 'special features'.. You need to patch your source code, which may barf (and then you either have to modify the patch file or do it manually. Which could suck if you have no programming skills, and its heavily modified)...
While most of us would view using a patch trivial (patch, recompile, install), the point is that similar situations could happen.
Perhaps because the economy sucks right now? I imagine more people are worried about their jobs and paying rent then developing a window manager that they aren't making any money off of (or very little)...
Either that or they are really busy watching pr0n...
I deal with phone companies on a daily basis, trying to get T-1's, etc repaired. With every ILEC I have dealt with (mainly VZ, but also including Pacific Bell, and a couple of others), there are tons of horror stories, but even on a day-to-day basis, they are annoying to work with.
One of the worst is Verizon in New York, after opening tickets with them day after day for different down circuits, I have so many stories where things like VZ switching someone's voice and the data T-1's pairs around, stealing pairs to fix one customer, but break another, etc etc etc... Those things happen quite a bit, on top of the normal delays.
What the ILECs need to learn is communication (so it doesn't take an extra 20 hours because the ticket keeps getting sent to the CO and they close it without noting the ticket why, and they obviously havn't even tested the circuit... 5 times in a row.. stuff like that)
They also need to learn to get rid of the people that have been there for 20 years, and are stupid (there are quite a few people that have been with an ILEC for a very long time, and rock, but, just because someone has been there for so long shouldn't be job security in and of itself).
Slashdot Mirror
There are a number of training classes and "bootcamps" for various things which are based in California. Cisco Certified Internetworking Expert certification bootcamps and various others come to mind. Those bootcamps (and many others) can be many thousands of dollars.. So the question becomes, at what point do you start considering regulation for a group? When the amount of money they collect is over $X? Or when the duration of the course is over X weeks? If they are going to regulate courses at all, these need to be clearly defined and enforced uniformly. The issue here is that when it is defined too vaguely, there are a very large number of classes that should be regulated, which aren't. Cooking classes, professional certification training programs and many other classes should fall under this. Regulatory authorities in state are likely not equipped with experts in the field to be able to define what methods/requirements are "best" for every type of organization.
With that said, I think the drawbacks of regulating classes like these, is far more than the "help" it will provide to consumers.
* If someone is willing to drop $15,000 on a bootcamp without fully vetting it via research, references, reviews and the like, that's not very smart of them and they are partially at fault for signing up for something that didn't provide what they need/want.
* However, if the bootcamp doesn't provide on what it promises, then they have every right to complain to the state and/or sue to get their money back (although, I expect most would complain to the state due to resource related issues.)
In short, California either needs to clearly define exactly who should be regulated, and they should apply that uniformly, not just on a specific group of companies.
-Phasedshift.
I believe employers are legally required to inform you of monitoring your actions, usually in an employee handbook of some kind. The issue is that in general it is "your actions / calls / etc are subject to monitoring", versus naming specific ways they are monitoring you.
In general, if you're on the company clock and/or using company equipment - you should always assume you're being monitored. If you're doing something wrong and it is caught by you being monitored, then tough luck. If the results of monitoring are being misinterpreted and you weren't doing anything wrong, explain it to your boss and there should be no issues, and if there are you have a crappy boss (and the same situation would likely eventually happen without monitoring.)
The issue is if companies are monitoring you on your personal time, when you're not using company equipment. That's another issue entirely and IMHO wrong.
Buckyballs were labeled as for adults and not for kids before the commission came after him. However, because they are so similar to a "toy" it was labeled as a concern by the government. In my opinion, this action removes personal responsibility from the parents (the product was clearly labeled), and there should have been no actions against Buckyballs as long as they were properly labeled. There are many other products out there that are far more dangerous which look like toys which do not have these concerns.
Further, it begs the question:
Is it the norm for similar cases where the owner/company simply went out of business (without doing a recall) on an unsafe product, for the owners to be held liable for the cost of a potential recall after the fact?
If he is held personally liable, but a large number of other cases had companies which went out of business and the owners were not held liable - it seems likely there was some type of bias on his case.
One last item:
Protection from personal liability when you are a shareholder/officer of a corporation isn't absolute (you can still be held legally personally liable in certain cases.) Certain people here advise they don't like this fact, as they feel people should be personally liable. However, to be frank - fewer people would take risks if they faced personal ruin due to a lawsuit. A better option would be to revoke a company's incorporation status and in repeat offenses remove the ability for people to be part of another corporation perhaps. This would have the positives, without the negatives.
People still play Tradewars... There are still telnet BBS's available and development continues on some versions.
If I'm going to play a game that consists almosts entirely of repetitive tasks, it better be text based!
I should have clarified in the previous comment that if you don't have the ability to dictate the terms of the contract (such as if you buy the product in the store), it is my belief that you can likely recover damages already if it is due to gross negligence of the developer in question in most jurisdictions. As mentioned in the previous comment, proving that can be another issue entirely.
The following is my non-professional opinion:
You can already sue developers.
Any development contract should have language indicating what is desired and minimum standards compliance (example: PCI compliance if you're handling credit card data.) If it is later found that the developer did not adhere to the terms of the contract, they can be sued for breach of contract.
Further, if the flaws in the software are extremely severe, even if the contract didn't explicitly call out the problems observed, they could be covered under gross negligence and the developer can be sued for that as well.
As with many other things, a new law isn't needed for this, the ones on the books are perfectly suitable. The money/time it takes to get a remedy to the issue via our court system is another matter entirely, but would be similar regardless of a new law.
If my organization owns the A.B.C network, there is no reason why any packets bearing a source address of anything other than A.B.C.* should be permitted to leave my network.
Actually, there is at least one very good reason. If company A has 2 internet connections through provider A and B, and wishes to do load balancing, but for one reason or another can not announce a single subnet through both providers, they can at least do outbound load balancing and change the source address on a per packet basis, so incoming traffic for connections initiated by someone local are evenly distributed through both connections. Obviously any connections that originate from the outside world (i.e. someone on the internet trying to view this company's website) have to be answered with the same IP that the request originally went to as the source address (or stuff will break(tm)), so this wont work in that situation, but any request that originated on the company's network, and goes out to the internet, can have the outbound traffic load balanced on a per packet basis over their multiple internet connections, even if they can't announce the same block through both providers. This however requires that some packets have a source address in the subnet of for instance provider A, when they go out through the circuit with provider B, to evenly load balance packets.
The other option, which does not require sending packets with a source address for one provider when it goes through another, is to do it on a per connection basis, and not a per packet basis, however depending on your traffic, etc.. this may not work nearly as well.
While obviously, the number of people implimenting something like this is few, and the benefits are many to implement anti-spoof measures, to the few people doing something like the above, it sucks. However, there is an answer, that will satisfy both causes.
To the few people that do load balance in the method mentioned above, a simple ACL allowing only packets with either subnet as the source (for either line A or B's block), and deny all other sources, will both allow them to load balance outbound traffic, and it will protect your network (and others) (since they can't spoof any other address, other than their block with the other provider through you, as the ACL will drop it).
For everyone else, you can use the following command on a Cisco with CEF enabled, which drops all traffic that does not have a source address that is routed through the interface the packet was received on:
"ip verify unicast reverse-path"
Cable companies have to pay for programming. They pay Time Warner, etc on a per subscriber basis, and they get discounts if they offer certain combinations of channels from the same programmers to their subscribers.
For cable companies its frequently cheaper to have a channel lineup that includes say, 4 time warner owned channels to a subscriber, instead of just one or two (i.e. they have to pay less for the programming).
Remember, a large percentage of what you pay for cable goes for programming fees, then they have tons of other costs, etc... They probably are being greedy to an extent, but, its not exactly as cost effective for them to provide programming on a per channel basis (due to programming charges, and other things).
I wonder when ISP's are going to realize that it is futile to say "no NAT" or "no servers" or "max transfer gb per month" and realize that the only sane thing to do is to provide unrestricted access, and simply charge their customers what it actually costs to provide xx mb of bandwidth?
/don't/ have servers), and choose it over Company B because "UNLIMITED" means better to most people.
Because, if Company A has "UNLIMITED" in really big letters, but all of the restrictions (no servers, etc) are less prominent, and Company B says "We allow you to have servers, but we charge money per mbit" Joe user will go with company A almost everytime. Why?
Because "UNLIMITED" stands out, unlimited is certainly better than limited right? The average broadband internet user doesn't have a server, and chances are, they don't know how many mbps of traffic they make use of in a month. Joe user will see the part from Company A, not care about the restrictions (the fact remains that the majority of cable modem/dsl subscribers
The 'better' answer is to have multiple tiers of service, where the base plan is unlimited, but with restrictions (no servers, one computer, etc), and another plan where you can have servers, but only if you pay extra (per mbps over a certain amount, etc)... The problem is, most people who have a '*NIX box' with a web server wont want to pay extra, and will just get the cheaper plan, so 'policing' (port scanning their address space for people running servers on well known port numbers) for people running servers, would be necessary. Also, it would probably be prudent to have a 'power users' plan, where if you have over X computers (NAT'd or not) you have to pay X amount. Mind you, this would suck for a lot of people, since they'd have to pay more per month, but overall the cost of broadband for the average user should go down. It makes sense, it just depends on how you market it.
This is somewhat easy to find people that are extremely likely to be NAT'ing actually, usually with no extra hardware than what the ISP already has.
You can look at the source port of the packet (going from the customer to wherever, i.e. ingress to the ISP's network), to be fairly confident that the customer is NAT'ing their traffic.
Most NAT implimentations change the source port to a very high port number (usually in the 60,000+ range) when they translate (along with changing other info). You can probably be fairly safe to log anything above 40k (although some research into what more popular 'ethernet routers' that do NAT use for port ranges would be prudent). Normal traffic for most implimentations of a TCP/IP stack won't typically source off of ports that are reserved for NAT'ing, so again, you can be fairly sure they are NAT'ing if you 'catch' them (enough to call them to ask them about it anyway.. that way if they aren't, you don't shut down a paying customer for no reason).
On a cisco, you can setup an extended access list applied to the interface the traffic is hitting, with logging enabled to see who is NAT'ing, see if it continues for a while, and if it does, you can be fairly assured they are NAT'ing traffic.
Mind you, there are many ways around this for some implimentations of NAT (i.e. changing the port range NAT'd packets source off of), but for average Joe User hooking up an 'ethernet router' that does NAT, they could be caught fairly easily by this (and other methods that work in conjunction with this).
(this is just a brief summary, don't blame me if it isn't detailed enough).
Heh.
Its always great when we have posts that directly support software piracy.. NOT.
The worst part is, as far as I know there isn't even a semi-convincing moral argument for pirating Id software's games. Id Software has (in the past) released a demo, or a test version of the software previous to release of their retail product, so you can 'try before you buy'. In addition, they have 'given' past releases (doom, quake, quake 2..)'s source code to the public. There are very few major commercial gaming software companies who do this, and I think this earns Id a lot of respect.
Sure, there are probably some people out there who will warez the alpha version of doom 3, and then go out and buy it, but its probably going to give quite a few the wrong impression of the game, as it is quite an early version of it.
Anyway, I hope the ATI employee who leaked the game (if thats infact true) gets fired. I also hope that most people on slashdot don't go out and pirate the game, and simply wait for Id's 'test' or demo release.
A nice alternative to paypal (for some purposes) is Yahoo's PayDirect.. paydirect.yahoo.com..
Why not simply have a small list of MIME types that are allowed to be 'viewed', that does not include .sh, .exe, and other potentially harmfull things? Make it easy to add/remove things to the list, and have more/less restrictive versions of said list of MIME types?
.sh, .exe, etc file. You would need to also have the MIME types that are considered 'dangerous' able to be easily added to/removed from. (I don't like this idea as much)
Or you could add a popup window, so when you try to execute anything potentially dangerous, the window asks you if you really want to 'view' a
According to the page that is linked in the summary http://www.drgibson.com/towers/ It mentions:
:)
The buildings supporting the towers were hardened against a nuclear blast, and some of them in high-danger areas were underground. The towers themselves were engineered to withstand all but a close (within 5 miles) blast. The microwave horns were covered with a protective shield to keep out not only the elements, but also radioactive fallout. The buildings were shielded with copper to protect the equipment against the Electromagnetic Pulse associated with a nuclear explosion. Foot-thick concrete walls protected the vital electronics and people inside the base installations of these towers. Thick copper grounds went deep into the bedrock beneath each tower. Fallout showers, backup generators, sleeping facilities all existed to keep the network up in times of war.
So while the equipment itself is likely hardened, the building is shielded.. It doesn't say how much shielding, etc there is however
Couple of things, first, all ISPs oversell bandwidth. I am assuming the 'larger' guys meant that the local ISP likely only has a single DS-3 to his upstream provider. Depending on how small he is, this may not be an issue (/all/ providers oversell at some ratio, it just depends on what that ratio is that determines if the provider sucks or not) depending on how many other customers he has, what types of circuits your providers customers' have, and what type of customer they are (business vs. residential), etc. Obviously there are other factors too.. if your provider suddenly grows and doesn't increase its upstream capacity, thats an issue.
/most/ circuit IDs from /most/ telcos is something like XX.AAAA where AAAA is frequently what your concerned about to determine the circuit type, but the format of the CID depends on your telco (there are many guides out on the internet at decyphering these to determine what type of service they are, or you could call your telco and they could tell you.. maybe.. if your good.. heh)). The CID should be on the smartjack..
/can/ be, without having to deal with other provider's networks being congested, etc (the traffic in this case will be local to your provider's network, so if thats congested then um.. that sucks).. You should get somewhere around ~192KB/s.. if its slightly less don't worry about it, there is some overhead involved, etc.. When you do this be sure you only have /one/ machine connected to test (or you can verify there is nothing else that is generating traffic that is going over that circuit, etc... don't assume.. check. (there are many, many, many tools to do this..) to see whats hitting the ethernet interface of your router (its a lot easier to check if you have access to your router, as you can just do a show int on a cisco to get traffic statistics, etc).
Now, on to determine if you have a 'real' T1. Many providers tend to sell frame relay service as a 'T1'. While its true that the circuit itself from the telco to your place of business is a T1 (unless you have say 56k DDS service, etc), after your traffic hits the telco's switch, it transverses their frame relay network, and eventually gets sent to the frame host on your provider's network. This can suck for many reasons, however the biggest one is that the provider can get away with purchasing a CIR that is less than 1.5 mbps (like 768kbps), and just have it be able to burst up to 1.5. This can suck a whole lot if the telco's frame network is congested, and you can never burst, and/or you constantly want to use more than the CIR etc..
You can tell what kind of circuit it is by quite a few ways, if its installed and you have access to the router you can simply check the encapsulation on the T1 (if its set to frame relay, its a frame circuit, if its set to PPP or HDLC its a point to point circuit), you can also tell by the format of the circuit id (the first part of
If you have a frame circuit they should be charging you quite a bit less than a point to point T1, especially if the CIR is low (the lower the CIR the less expensive generally). Point to point T1s are preferible in almost all cases unless your worried about cost.
So now that you've determined the type of circuit you have, you can check what speeds your getting. Its usually best to do as other people have mentioned and download (and UPLOAD too.. you should check both speeds) from an FTP server on the provider's network. This will give you the most accurate picture of how fast your connection
You should also do a separate test to a major site.. You could download the 1.4.0 Java SDK from Sun for instance (that should give you a decent speed). Don't worry if this is somewhat lower than 192KB/s, as that can be caused by congestion in a network inbetween you and sun that has nothing to do with your provider, etc.. If its consideribly lower than that speed consistantly (and other sites with bandwidth to spare yield the same results), then I would contact your provider about it. It could be that your provider doesnt have enough upstream capacity, or about a billion other things, but they might be able to tell you any known issues, or that the problem isn't them and/or tell you the current utilization levels of their upstream circuits.. heh
Patents, copyright, etc. are designed to help promote innovation. People tend to point out extreme examples for either side.. However I think the following covers why patent laws (in my opinion) are a good thing, as long as they are on specific methods or products, and for a fairly short period of time (which would depend on what the patent is for).
/huge/ difference, at least for a while, in most cases.
Many, many patents have been granted over the years. Some products can legitimently benefit from a patent, and some do not (or they don't substantially anyway). In theory, patents can help innovation. An example of this is as follows:
Company A makes a wheel in a certain way, and obtains a patent on that specific design, and method of making the wheel.
Company B makes a wheel in a different way, and obtains a patent on that specific design, and method of making the wheel.
Company C makes a wheel in a different, and better way then companies A and B, and gets a patent on the specific design and method.
Unless a company wishes to purchase rights to use a preexisting design for something that has been patented, they need to develop something 'better', or at least different. I think few will argue that in theory, patents work. The problem comes with the patent office approves patents that are too broad. If the patent office approved a patent for the wheel in general (not the specific design, etc that a specific company made), then that would hinder innovation, causing other companies who wish to make a better wheel, to still license rights to use 'the wheel'.
If we didn't have patent laws, you would find that while much innovation will continue, there will be certain areas that will suffer more than others. Niche market areas, where a company must spend huge sums of money to develop a product, and sell it to a customer base that is very small will suffer the most in my opinion. This is because after the development is done, since there isn't a large customer base, the price for the product will need to be high to recover the development costs. If another company comes in, makes the same product, but for far, far, far cheaper since they don't have any development costs, then few people will want to spend the money on development, as chances are someone will simply steal their idea and charge less. I don't think this will be a problem in most areas, since with a larger customer base, the cost(s) will be less per customer to recover development costs, and in theory the company which develops the product, will have a head start, and should be able to identify the product with their own brand, and sell enough units to at least recover most of their development costs. Also, if a product/method is very hard for someone to reproduce due to the amount of skill/money involved, then a patent won't make a
Now that I've typed all of that, lets see if anyone reads it (and out of those people who read it, who actually thinks it makes sense).
Frequently companies make you call in, in the hopes that when you talk to a customer service rep., he/she will convince you not to cancel. This can either mean changing the rates for that customer (i.e. giving a current customer a promotional rate that was only supposed to be for a new customer), or simply talking to the customer. While it is annoying, it is understandable why they make you call in.. Probably 30% (thats a guess) of the calls they get to cancel, once they talk to a customer rep. will decide not too. Of course, that doesn't include all of the people who just give up before talking to a customer service rep, but hey.. There should be a 'why are you cancelling today?' and then try and address those concerns, but if the customer just wants to cancel, and says that after you ask them the above, then you should just cancel their account heh)...
So while companies should make it easy for you to cancel when talking to a CSR (which most don't), making you call in to do it is perfectly understandable (although annoying for some of us), just make it quick and easy when you call in.
After being slashdotted and geekaustin'd and touted for being the first theater with wireless access .... I went to see Spider-Man tonight at the Alamo Drafthouse North in Austin. Apparently you can't have 'electronic devices on' during the feature. I was warned if I didn't shut down my laptop I had to leave by some girl that worked for the theater. The world's first Cyber-Theater my ass. Nice try, but apparently wireless users are absolutely not welcomed there when a movie is playing. I'm very disappointed. I couldn't even have my PocketPC with wireless NIC on while the movie was on. Was I taking off down the runway on an airplane? What's the point?"
Uh... Its a movie... laptop displays can be pretty bright in a dark room, and it is almost (but not quite as bad..) as bad as turning on a flashlight in a theater if your close to the person... I'd ask to have you kicked out if I was trying to watch the movie and was sitting a seat or two behind you..
Also, why have internet access WHILE your watching the movie? I can see it while your waiting for it to come on, or while your waiting in the lobby, but yeesh.. heh
The easy things to solve most DoS attacks are to:
/16 off of a router that has directed broadcast enabled, and change the source to someone else.
1. Turn off directed broadcasts on all interfaces. This will prevent a situation, where you have a person sending one packet, and the network replies with many DUP packets.. If the person changes the source address in the packet they are sending, the remote network (with directed broadcast enabled) will send its replies to whoever you want. i.e. someone can use this to do a smurf attack. So, for every one packet someone sends, an untold amount of addresses could respond to the source address of the packet. Disabling this is quick and easy in most cases.
2. If using a Cisco enable:
ip verify unicast source reachable-via rx
which will ensure that the source address of packets received on the interface have source addresses that are reachable over that interface. Have it enabled on all gateway routers, so that when customers try to issue a DoS attack against someone else, the source address of the packets have to be their own, or the packet is dropped. They can't just send a bunch of ICMP echos to a
Unfortunately both of those methods require somewhat cluefull network admins... Also, some things have legit uses (load balancing outbound traffic is a good reason not to have "ip verify unicast source reachable-via rx" enabled, in certain circumstances (i.e. the customer has 2 providers, with 2 seperate IP blocks, each only known through one provider, they can't really do equal cost load balancing on incoming traffic, but they can do equal cost on outbound)).
Again, the issue is having cluefull network admins.. There will always be people out there getting around it, but you can make it a lot harder for them to do it, and you can drastically lower the amount of DoS attacks that happen.
Yes, but the methods of checking to see if the emails are legit, and the concerns surrounding that are the same.
telnet to port 25 of a mail server...
/no/ clue on how email actually works.
/proof/ the emails were actually sent... Of course, thats not proof that the text in the body of the emails is the same as what is being presented heh. It doesn't mention the people using public/private keys in the email, so its doubtfull they used PGP, etc..
:)
helo hostname.net
MAIL FROM:bgates@microsoft.com
RCPT TO:bob@iwantmyemail.org
data
Subject: I want to give you free money
text goes here
.
Ok, so lets think about this... something this easy to forge (Well, if you really want to get annoying about it, you could check the SMTP server the person is sending through (and they IP of their own connection), but quite a few people use different internet services then where their domain is hosted), is being considered a legally binding document.... You can specify a different MAIL FROM field in any email client, by simply changing the address listed as well, youe email address in there (I find the above method quite easy, although it doesn't include all of the headers most clients send along with their message(s), but I'm lazy and didnt want to type that out also) I am willing to bet that the judge has
However... On the same token, if you can match the emails that were sent to logs from the SMTP server that person relayed them through (assuming its not your own mail server), and the logs of the receiving mail server (again, assuming its not your own mail server, and the IP that you sent the message from shows up as your account when you look at the radius logs (or whatever is applicable for your type of connection), then I could see that being
An easy way to disprove someone saying that an email they were sent is different from the one the person says they sent is to compare the message size(s) to what the MTA's on both sides logged the message as. Chances are no one even thought about that when they were writing up the forgery
I find this quite amusing though...
Couple of things...
/24 in class B space, without advertising the /16 also, so the route gets nuked at a border router, as quite a few providers filter based on classfull boundries, or people just not understanding how a traceroute even works, and demanding to speak to a 'routing guru' because their traceroute dies after a certain point due to an ACL (access control list), so they naturally think the web server/mail server, etc they are going too is down, even though it is not.).
1. 90% of the time when you call a large internet service provider, you speak to their frontline support, who address their level 2 support (etc) as 'routing engineers', consider how many people must call them and complain about problems (90% of which are probably caused by stupid things like them advertising a
2. As someone pointed out, number of hops != latency, etc. Most people who are just starting their quest for knowledge in this field tend to confuse the two unfortunately.
Now, while in an ideal network, 99% of things will be done at layer 2, thereby making the total hopcount in your traceroute lower (if your traffic is going through an ATM switch who doesn't know about/care about layer 3 information in an ATM cell, it will obviously not show up as a hop in your trace). The hopcount your traceroute shows doesn't matter, the simple fact that all that has to be done is the header of the ATM cell (the first 5 bytes) is read, and then the cell is forwarded to its proper destination (similar for ethernet, using cut-through switching, etc) doing switching at layer 2, vs. having to read the IP packet's headers to find the destination will provide a noticible decrease in latency in most situations.
You are however correct in that Cisco has many features out there that will greatly increase performance for people. Mind you, there aren't any official 3rd party benchmarks against this (the company the article is referring too) company's products, so we don't know if they are something to laugh at, or really are better then whats out there currently (although I am voting for the laughing part).
Also, in regards to BGP, (heh btw it has quite a bit of overhead, since it uses TCP), while it is pretty much the only good choice for an EGP (external gateway protocol), you will still need an IGP such as OSPF, etc unless you intend to have your router(s) have BGP sessions with the IP's of other routers known via directly connected (or static routes), which would be stupid (except for some situations using static routes in a very small network). Its not like you setup a BGP session with another router, and it 'magically' works, there is quite a bit of traffic engineering involved (how much is dependent on how big your network is), and cooperation among internet service providers (i.e. to set the localpref that is distributed to your IBGP mesh based on certain communities received from a peer, or the other way around, so people can control the path traffic goes back into their network in a better way then padding the route (i.e. adding more AS's to the AS_PATH which chances are wont give you the desired results), or other methods).
Lets not forget that the vulnerability code red, etc takes advantage of has had a patch out for several months, but quite a few people never bothered to patch their servers. Chances are the patch(s) will be available shortly after the mainstream ones are released if you have a good vendor.
Besides, say your running *NIX with a specially modified version of apache, and there is some remote exploit that is discovered. Obviously you can't just download the source, compile, and install, for fear of loosing those 'special features'.. You need to patch your source code, which may barf (and then you either have to modify the patch file or do it manually. Which could suck if you have no programming skills, and its heavily modified)...
While most of us would view using a patch trivial (patch, recompile, install), the point is that similar situations could happen.
Perhaps because the economy sucks right now? I imagine more people are worried about their jobs and paying rent then developing a window manager that they aren't making any money off of (or very little)...
Either that or they are really busy watching pr0n...
I deal with phone companies on a daily basis, trying to get T-1's, etc repaired. With every ILEC I have dealt with (mainly VZ, but also including Pacific Bell, and a couple of others), there are tons of horror stories, but even on a day-to-day basis, they are annoying to work with.
One of the worst is Verizon in New York, after opening tickets with them day after day for different down circuits, I have so many stories where things like VZ switching someone's voice and the data T-1's pairs around, stealing pairs to fix one customer, but break another, etc etc etc... Those things happen quite a bit, on top of the normal delays.
What the ILECs need to learn is communication (so it doesn't take an extra 20 hours because the ticket keeps getting sent to the CO and they close it without noting the ticket why, and they obviously havn't even tested the circuit... 5 times in a row.. stuff like that)
They also need to learn to get rid of the people that have been there for 20 years, and are stupid (there are quite a few people that have been with an ILEC for a very long time, and rock, but, just because someone has been there for so long shouldn't be job security in and of itself).