Being asked to do something illegal in your job, like molest a child, doesn't grant you immunity from prosecution. Being asked to do something thoroughly immoral in your job, like intimidate people until they're more terrified of the security line than the flight, doesn't grant you immunity from social persecution. Needing to feed your family doesn't mean society will forgive you any action - consider whores, muggers, fraudsters, extortionists, and drug dealers.

The people we all should be and remain angry at are every single person involved in the entire farce, including the lowlife scum who didn't hand in their notice the second they were trained in the "right" way to molest a child.

Or better yet, refuse to do it, and see how a jury feels about wrongful dismissal for refusing to rub a child's genitals.

He should of said so. Their is no reason to no the rite spelling of words, sense I can just look them all up.

And grammatical structure isn't important either, as taught to me by my good friends, Godwin and Hitler.

... or my good friends, Godwin, and Hitler.

Either way.

What's in a comma.

I will applaud Apple for closing any hole used to jailbreak without a USB cable involved, whether it gets to malware stage or not.

Apple seem to respond faster to these sorts of vulnerabilities than they do to ones that are only usable if you have physical control over the device, so I don't think there's any cause for concern that Apple will step up their counter-jailbreak programme if theoretical attacks become reality.

Because the registries are driven by bottom-up policy processes in which all the stakeholders who care to get involved have a hand in determining the right way to distribute addresses. Current thinking is that addresses are a global public good, and should be distributed based on responsible and efficient need, not based on depth of pocket.

I believe this is what you're looking for. Mac OS X has a sandbox facility built in to the kernel that allows you to specify a profile for applications to limit the system calls, and arguments to system calls, that can be made.

The two biggest flaws are that badly written applications need a ton of permissions to even work, or specific permissions that mean an attacker could do something terrible anyway; and that application updates can introduce new permission requirements, forcing you to keep the sandbox profile up to date to retain functionality.

Both could be fixed by application developers embracing the sandbox technology. Chrome for OS X uses this system facility to protect parts of itself, for example, so it's generally designed to only require a simple profile and updates include a new profile where necessary.

Safest is still a snapshotted VM that you roll back daily, but that's far from the most convenient :-)

Eh, not really. IPv4 will be gone. If you are an ISP, and you pursue Carrier Grade NAT (CGN) as your solution, you growth limit yourself. It's equivalent to fixing your available bandwidth permanently - you can't add more customers past a certain point without significantly degrading performance for all customers. In a few years, you'll need to deploy IPv6 anyway; your customers will pay a price for the capital cost of your CGN gear, then your customers will pay a further price for the capital cost of your v6 gear.

If you're only concerned about web+mail, deploy dual stack lite. Browsers and mail clients do IPv6 transparently already. CPE devices support v6 out of the box at the sub-$100 price range (Netcomm, Billion, and, uh, the one used in the big v6 trial by xs4all in the Netherlands). Going DS-Lite means that as more software supports v6, and more services appear on v6, the pressure on your public v4 addresses drops over time. You can sustain DS-Lite throughout transition. The capital cost is similar to CGN, and the ongoing expenses of v6 are generally covered by your existing v4 expenses (ie, bits you pay going over a v6 session are bits you no longer pay for over your v4, and if your upstream is charging you more for v6 it's time to go provider independent!)

Some of the services that don't work over CGN include, by the way, XBox Live, BitTorrent, many network games, and most VOIP solutions. Some services do work over CGN, but rely on a reasonable proportion of Internet users having a public address to do so, and thus aren't long term viable: Skype, some of the smarter BitTorrent clients that do hole punching. Some services rely on emerging protocols for dealing with CGNs, like FaceTime: ICE, STUN, and TURN.

You can get a taste for life under a CGN by configuring your home NAT device to ignore uPnP requests, and disabling any manual forwarding settings.

Also, the summary is full of shit regarding the changing estimation. The linked articles are pretty clear that it's still early 2011. Available metrics (http://www.potaroo.net/tools/ipv4/ is one of the best) show a pretty unchanging date; that link, in fact, includes a few graphs down the bottom showing the change in predicted date over time. If you're an ISP, you've got a reasonably reliable date to plan around, and it should see you unrestricted on your IPv4 clear through to 2012, plenty of time to get ipv6 upstream (typically free or very cheap, when taken alongside your v4) and implement dual stack in your core.

Break another window, the glazier in your home town needs to feed his kids.

You can save more time than seconds simply by leaving a bigger gap. You lose a lot of time slowing down and speeding back up because the car in front of you is slowing down to turn, and you were too close to let your gap simply eat up their deceleration. Traffic jams are mostly comprised of the fractions of seconds everyone loses because they're constantly needing to react to the car in front, instead of maintaining a steady, but slower, pace.

My commute time isn't really different for leaving a gap, since it's counter-intuitive and too few other drivers do it, but my commute is far less stressful both for me and for anyone who needs to merge into my lane. Sucks to be rear-ended because other people think they're better drivers than they are, too.

Here's to the future, and hoping it comes soon! :-)

The computer would need to:

• Recognise something warm very close to the road.

Doesn't matter if it's a child, a drunk, a goat, or an insurance fraudster. Doesn't matter if they're playing, standing waiting for a pedestrian crossing, or taking a leak on a fire hydrant. If it's alive, and very close to the road, there's a risk it will begin a motion that ends in intersection with the car. Mitigate the risk: slow down, change lanes. A computer will ALSO be able to see if the lane is clear beside, if the vehicle behind is maintaining a safe distance, at the same time, with a decision made and enacted in milliseconds.

It's still possible that the accident is unavoidable. I'd expect computers to do a much better job much more often. Computers, for one, won't fail to recognise that an adult standing waiting at a pedestrian crossing may be jostled, stumble, and fall into your path, even though they're neither a child nor playing.

Multicast is common - at constrained scopes. It's used for router communication (OSPF, IS-IS, RIP2, GLBP), rendezvous/zero-conf (mDNS), and as some other commenters have noted, also for single-carrier IP TV, depending on the carrier. There's a few education and research networks that use it, too.

Global multicast is non-existent, because it's hard to charge for.

The well known ports part is right, the rest is not quite right.

TCP connections are identified on each host by a 4-tuple of (my IP, my Port, their IP, their Port). So as a web server I can have multiple active connections on port 80, but they must all be with distinct combinations of remote IP and port. As a web browser, I can open multiple connections to the web server as long as I use different local ports.

I can demonstrate this by running a network socket listening program on two hosts (let's call them 10.0.0.1 and 10.0.0.2 to protect the innocent) both on port 9001. I can then use one of those hosts to open two TCP connections, one to each of the hosts, and both from source port 9002. My netstat output after doing this:

tcp4 0 0 10.0.0.1.9001 10.0.0.1.9002 ESTABLISHED
tcp4 0 0 10.0.0.1.9002 10.0.0.1.9001 ESTABLISHED
tcp4 0 0 10.0.0.1.9002 10.0.0.2.9001 ESTABLISHED

You can see that host 10.0.0.1 has both halves of the same connection (10.0.0.1:9002 -> 10.0.0.1:9001) and one half of the other connection (10.0.0.1:9002 -> 10.0.0.2:9001). All three connections are uniquely identified by their 4-tuples; if I try to create another connection from 10.0.0.1:9002 to 10.0.0.1:9001, I get an error: "Address already in use." Slightly misleading, since it's the entire 4-tuple that's already in use, but nevertheless could be solved by using a different local address.

They're the same authors who use nothing but a big Flash object.

In any case, a canvas element is not opaque. If you do your own obnoxious advertising, it's an easy decision to avoid your site. If you pull it in from a partner, it's easy to filter out that scripting resource request based on domain.

Not too worried about HTML5 'filling the void' myself. NoScript covers a large number of the potentially obnoxious uses already. The same techniques used for blocking Flash object/embed elements can be trivially extended to canvas, video and audio elements. CSS animations can be manipulated in the DOM (or at load time) to either strip them out completely, remove unconstrained animations, or toggle them on and off.

Better yet, though, video and audio elements can just have autoplay disabled. The asset can begin to download, so you don't need to wait, but there's no way for some fuckface web designer to decide their choice about when the video plays trumps yours; no more videos starting up in two or three tabs at once. Very hard to do with Flash, very easy to do with a video element.

From TFSummary:

... security researcher Mila Parkour reported it to Adobe after analyzing a rogue PDF document attached to spam.

Reads like Parkour reported an exploit being used actively in the wild to Adobe, to me. Which would make the sequence of events (1), (2), and this a zero day exploit. Silly term in any case, the relevant terms are, imo, "fixed" and "ongoing."

See the iOS Programming Guide information for details. The second last bullet point in the transition guide that, of course, every developer read before rebuilding for iOS 4.0 is:

Remove sensitive information from views before moving to the background. When an application transitions to the background, the system takes a snapshot of the application's main window, which it then presents briefly when transitioning your application back to the foreground. Before returning from your applicationDidEnterBackground: method, you should hide or obscure passwords and other sensitive personal information that might be captured as part of the snapshot.

I guess whatever map you were looking at doesn't count as sensitive personal information. Sounds like there's a market opportunity for iThief - obscures your maps so the cops don't know where you picked your kids up from last week when they catch you in the vicinity of a crime via cell tower triangulation!