Cox's IP assignments are relatively static. I've had the same IP address for several years now. As far as I can tell they associate a DHCP lease with the cable modem's serial number and check whether an address is in use before handing it out, so the only times it'll assign a new address is if you replace your modem, your router's off-line long enough for the lease to expire and then for someone else to request a new lease while your router's unable to respond to the head-end's in-use test, or your router's off-line when they reset the head-end (clearing the lease database) and stays off-line long enough for the head-end to hand out your address to someone else.
And even if IP addresses changed regularly, the DHCP servers log the assignments so given an address and a timestamp you can determine from the logs which subscriber had that address at that time. At least as long as the logs haven't aged out, anyway.
My reaction was "Why is anything related to aircraft safety or control on WiFi at all?". That sort of stuff should be running on a hardwired network where getting access wouldn't be a trivial job or, if it absolutely must be broadcast, on a securely-encrypted network on a band not usable by common consumer electronics. This isn't just a vulnerability in the system, it's a fatal flaw in the very foundation of the system itself: as long as it exists the system can't be adequately secured.
Full-disk encryption won't protect you from most attacks. They most often occur when your system's operating normally and decrypting the disk for the attacker. It only protects you against physical theft of the drive or, in hosted data centers, access to the physical drives your volumes reside on. I'd only use it on a mobile device that was at a relatively high risk of being stolen.
Why not in a hosted data center? Because there's the issue of how your host gets the decryption key during startup so it can mount the volume. All practical methods allow the attacker to get the plaintext key if he could access the encrypted volume, so it might as well not be encrypted. If it's not encrypted, nobody gets fooled into thinking it's secured against things it isn't.
Notice that I said "yet". I definitely want to add it, but not when it's just running on my local workstation or on the developer network and I'm trying to get the code itself working. One thing at a time.
And what are they going to do with IPv6 and built-in IPSec, where the authentication and encryptiong are handled at the IP level rendering SSL/TLS redundant? IPSec is an RFC-level standard, after all.
I can see an issue here: development environments and internal operations where by design it's not necessary to verify the endpoint's identity or secure the content from eavesdropping, either because the client and endpoint are on the same machine via 127.0.0.1, because everything's running over a VPN that handles the encryption or because they're on a secured network where if an intruder's in a position to spoof an endpoint or eavesdrop on traffic you've got far, far bigger problems than HTTP traffic to worry about.
Especially when I'm developing software I don't want to add SSL and it's complications to the mix yet. I have enough bugs without adding SSL certificate issues (including such fun as "I can't get real SSL certificates for the domain, security policies on the systems prevent me from adding a local root CA certificate and bits of software don't have the ability to handle self-signed certificates without errors.") and having to correctly configure SSL on both ends before I can even start seeing output.
I'm strongly of the opinion that protocol layers should be independent. HTML shouldn't depend on features of HTTP nor require that it only be served over HTTP. HTTP likewise shouldn't care whether it's running over TCP or SSL or SNA for that matter (yes, even in this decade good old LU6.2 and SNA over bisync is alive and well despite all attempts to correct the situation).
Cabreja wasn't asked whether the NDA would legally permit them to withhold the evidence if ordered by the court to produce it. He was asked whether the NDA said to withhold it, which it did regardless of whether or not he can legally comply with that instruction. Lawyers and legal cases live or die by that kind of non-obvious distinction.
The court isn't saying it violates the Constitutional rights of the person. They're saying the lower court erred in not considering the issue at all. Now the lower court's got to go back and reconsider the balancing between the 4th Amendment and the case the state presents for why they have a compelling need to monitor the offender after he's served his time. As far as voting rights, most convicted felons regain their right to vote after completing their sentence. Only a minority of states don't automatically restore suffrage, and almost all of them allow for a petition to restore it. Only in very limited cases is the right to vote lost permanently.
I'm of the opinion that these sorts of programs should be thrown out entirely. If he's that dangerous that he can never be trusted again, why is he being let out of jail? And if he's safe enough to re-enter the community, why are we treating him like he'll never be? Either up-front sentence him to a lifetime or other term on parole, or let him get on with his life.
To make a streaming service profitable while paying the artists a decent rate, you have to do the one thing the music publishing industry won't allow: pay the artists. Directly. Without going through the labels and their one-sided contracts with the artists that see 90+% of the royalty payment going to the label. Without that, you'll fail. (Even with it you may still fail, but at least you'll have a chance.)
It sounds like the Feds asked, not for e-mail to/from the accounts in question and the Yahoo address, but all e-mails in the date range that were in response to the ad. Google's problem then is that they can't take a particular e-mail and programmatically decide definitively whether it's in response to that ad or not (and doing that manually for every e-mail to/from every GMail address for a date range is infeasible). Probably the form of their response was then a result of someone at Google going "Screw this, I'm tired of the government's games. Just tell them we can't respond and let them figure out how to correct their mistake, it's not our job to teach them how to request what they want.". The government's correct reaction then should've been to ask for all e-mails between the GMail accounts in question and the Yahoo account in question, which is something Google can produce easily. Instead the government's throwing a tantrum because they aren't being allowed to have their way.
Solution's simple: start with the OCPO and tell them that if the corrections outlined aren't at least well under way in 90 days they'll be found to be grossly negligent in the performance of their duties and will not be permitted to resign, they'll be fired for cause and forfeit all accrued benefits (ie. no pension, no severance, the most they'll get is their unused days off paid out). If they try to resign before then, their resignation won't be accepted. They can still leave, but it'll be considered abandonment of their job and it'll still cost them all accrued benefits.
Talk is cheap. When people start getting fired (as opposed to being allowed to resign and moving on without any penalties) for failures like this you'll see the failures cleared up in a hurry.
NB: I've seen equivalent situations in private business as well, where managers and executives constantly cost the company large sums of money on projects that weren't wanted by customers or who allowed employees to screw up and harm the business repeatedly without doing anything about them. I'd say that, as a portion of the total company, the problem's probably worse in private business than in government. So while this is definitely a problem for government agencies, it's not a problem of government agencies in particular.
*sigh* If it can be abused, it will be abused. A good test is how the perpetrator reacts to the inverse: if they have no plans to abuse something, they won't mind removing the parts that can be abused. If they object to that or back-peddle, you can bet they've got plans to abuse it to within an inch of it's life and they don't want to admit to them.
I wonder what'd happen if a properly-licensed ham operator set up an access point? Normally unlicensed users have to give way and avoid interfering with a licensed operator in bands the operator's licensed to use, and when last I looked the higher grades of ham license allowed operation in the 2.4GHz and 5GHz WiFi bands.
Anyone who's worked in the corporate world knows what happens when the "right to be forgotten" exists: management makes a dumb decision, are told why it's dumb, and insists on having it's way anyway. Then when the inevitable train wreck happens they disavow any knowledge of their original decision, delete all evidence of it and try to blame the people they ordered to follow the dumb decision for following their orders. And management hates it when it turns out I've kept a copy of the e-mails documenting the entire chain safely tucked away in a file folder and immune to the effects of Exchange's recall-message and delete-message functionality and the normal time-based purging of older messages (I delete messages when they're no longer relevant, not just because an arbitrary amount of time has passed). I file "right to be forgotten" right there alongside corporate "records retention" policies: their primary purpose is to give an excuse for the destruction of evidence of wrong-doing or willful stupidity before it can be used against the guilty parties.
I think the complex part of Baseball Quick's system isn't the "delete the parts that aren't the game" idea but the algorithms and processing needed to identify [i]which[/i] parts aren't the game. That's where any valid patents would lie.
That's going to be a problem for all external content regardless, as content moves or disappears as people maintain/update their own sites. If you care about keeping links up-to-date, you'll catch this in your regular checks for broken links and it's actually a lot easier to fix than most (you just need to update the protocol, rather than having to puzzle out the new path to the content or confirm that it's no longer there).
If not RF, at the very least if a patent's to be included in a standard the patent-holder should agree to a fixed set of licensing terms and rates and they should be specified in the standard. Then there'd be no ambiguity. Everybody would know exactly what the licenses would cost going in. The only question later would be whether a licensee had paid the rate and abided by the conditions stated in the standard, and if they had then there's no infringement period.
Yes, there's that vulnerability. But you're only vulnerable if the attacker intercepts you before you've ever visited the site. Most of the time the attacker won't be able to manage that since it'd involve having started the MITM before they knew they wanted to do an MITM on that site, and it's certainly better than the current situation where an MITM can be initiated at any time without any indication to the user.