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.
Site pinning solves most of the problem. A site can create it's own private CA and issue it's own certificates for use on it's servers, specifying that the site's own CA certificate is the only one permitted to sign certificates for it's domain. Then establish a norm of the first time you visit a site you accept it's CA certificate and pinning information. Once that's done no other CA can be used for a MITM attack because of the pinning, and since the site itself is the only one with the private key for it's CA certificate there's nobody any government can give an order to disclose the key to except for the site itself (and presumably they don't want to do that, otherwise they'd go directly to the site with the order in the first place rather than using an MITM attack).
For places that don't have an IT staff capable of dealing with OpenSSL, I can already sketch out the hardware and software for a small turnkey box that's a dedicated certificate authority capable of generating it's own root and intermediate keys and certificates, generating server and client keys and certificates and writing them out to an external flash drive for transfer, and managing a historical database of generated certificates (it wouldn't retain client or server keys for obvious reasons). The most expensive part of it would probably be the display, the rest shouldn't cost more than your average home WiFi router. Sure it's not going to be as secure as Verisign can manage, but conversely it's not going to be nearly as attractive a target as Verisign would be either and it wouldn't need network connectivity which right there severely limits possible attacks.
Let's face it, in most non-corporate situations you don't care about the absolute physical identity of the entity running the Web site. You care mostly about whether you're talking to the same site every time and that nobody's hijacked you to a bogus server. The biggest risk there isn't validating the site's server certificate, it's that someone'll have used a malicious link to take you to a completely different site in it's own domain without you realizing it.
What I don't get is why the appeals court didn't drop the hammer on the source of this by referring the prosecutor involved to the bar association for suborning perjury. Even if the bar association doesn't do anything, just having the referral on your record and having to inform every judge you go before of it would be enough of a career-ending move to make prosecutors think twice about this kind of stunt.