Well... It appears that the first google hit for 'chrome add-ons' links to mychromeaddons.com
This site is made to look like google's, but is LITTERED WITH ADS. The whois information reveals it's a third-party site.
The OFFICIAL chrome add-on site also does list an AdBlock extension, but something is fishy about it. When trying to install it, Chrome warns that "this extension is trying to access your data on api.flickr.com." What the hell?

We'll see if and how Google will try to combat these issues...

Would apple seriously ever consider USING such a thing? It would be most terrible. But of course, apple is so obsessed with its image that I doubt they would ever employ this technology.
Of course, having a patent on this atrocious god-awful piece of work will effectively prevent other, less image-conscious vendors from doing similar things, which might mean (could it be?) less intrusive advertising on other platforms.

Get Eagle. It's free and there are a lot of part libraries out there. It's quite backward, but you will soon learn that most electronics CAD tools are. I guess there isn't all THAT much overlap between ECE and HCI people... Have Eagle produce a Gerber file and then send it off to your favorite board house. Happy routing :)

In a connection-oriented system, it is easier to provide QoS (guaranteed bandwidth, delay, etc) because the routers know which packet belongs to which flow. Thus, the routers can maintain per-flow bookkeeping, and drop any packets from a connection that is exceeding its allocated bandwidth. At the same time, the network is told the amount of requested bandwidth per connection ahead of time. Since each router knows its available bandwidth (and the bandwidth reserved so far), each router can definitely answer whether or not it can support X amount of extra bandwidth. This way, a proper path can be negotiated through the network, at connection time, such that every node along the way can handle the requested bandwidth, delay, jitter, etc.

As for security, knowing your path to someone else isn't the issue. The issue is being able to manipulate that path (and others) at will. There are a number of hijacking, redirection, man-in-the-middle, etc attacks that rely on issues within the way IP packets are routed. In a circuit-switched system, like MPLS, the control plane basically lives in its own separate world and is essentially decoupled from the data plane (like with the phone network). That is, forwarding decisions are made based on an extra attribute connected to every packet (the so-called label ID) and not on some user-accessible field within the data itself. The only time that the user has access to this attribute is when specifying the "connection ID" associated with each outgoing packet, but that is strictly an agreement between the user and his serving router and has little relation to the upstream label tables.

Well, of course we need to specify the destination address. In the MPLS case, we would signal the router serving us that we wish to talk to a certain address, and the router would send back a label ID that corresponds to that connection. (While the destination addresses are global, the label IDs can be reused per pair of devices, but that is besides the point). At this point, the path is set up and cannot really be "messed with" and you reference it by the label ID.
The security benefit is that the routing mechanism is invisible to the end user. He needs to specify the destination and the rest of the connection is up to the network.
Of course, the other benefits are efficiency and traffic engineering. With the network being aware of the actual connections (unlike with TCP, where packets are essentially disjoint from a router's point of view), it is relatively easy to provide features like bandwidth reservation, QoS guarantees, etc. And the actual switching process for circuit switching is a lot more efficient. It is far easier for a router to perform a label lookup and then push/pop/swap labels than it is to carry out the longest prefix match lookup. In fact, such technology is already used internally by some ISPs, but it is not available globally or end-to-end.

How is that vague and meaningless? One of the issues is that users are able to exercise direct control over the network through the same "port" which is used to send data. Sure, you would have to send some messages to set up a connection to your destination, but that control action should be done by the network, as it sees fit, instead of letting the user set the source and destination addresses on every packet. The user should be able to ask the network to set up a connection and then send data, and the network handles all the internal operations. Going back to the phone analogy, are you able to pick up the phone and make a call to someone while faking your own phone number? No. Are you able to place a call to and directly manipulate telephone switching equipment? Not since decades ago. Are you able to hijack someone's conversation, or force a specific path for your phone call? I don't think so.
The original design of the internet did not anticipate the need for isolated control, management, and data planes. There was just no reason to do it back then. But with 30 years of development and growth, things have changed...

There has been some talk about separating the control plane from the data plane (ie, packet header from data). The phone network had its share of unsecurities when they were using in-band signalling, but since the two planes were separated, phones became far more secure. The same technique can be applied to the data network. If we separate the control information from the actual user data, we may achieve better security, as it would thwart any attempts to mess with the packet header, redirection attacks, prefix hijacks, or any of that other garbage. And the technology already exists. Look at MPLS- your computer can signal the upstream equipment to set up a connection to a specific address, and all you have to do is send forward data with the given label ID. The technology is already being used to route traffic within ISPs, but the security benefits of it won't really materialize until it's pushed out to the user level. Of course, good luck getting everyone switched over.

Thank you sir. It is the first thing I hit ^F for when this page loaded.

That doesn't quite constitute using (overall) signal strength, and neither is it the primary location method. Yes, it is possible to use the carrier phase information as well as the L2 carrier phase (and L1/L2 discrepancy) to get a more accurate fix, but this information is only used to adjust the TDOAs of the PRN signals and compensate for varying ionospheric delays. Signal strength of each satellite is much more affected by random low clouds and even the receiver's immediate environment, than by distance from the satellite. In fact, if your receiver provides an SNR readout for each satellite, you can get an idea about just how dramatically these values are affected by, say, a tree that partially obscures a portion of the sky.