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.
Re: How come felons losing the right to vote isn't...
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.
I wonder if there's ever been a document where not only has it been almost if not entirely redacted, but where even the extent of the redaction was considered too sensitive and redacted?
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).
Why do your links mention the protocol at all? Relative links will adopt the protocol and host the user's using without any effort on your part. You did use relative links, right?
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.
On the post: FBI And United Airlines Shoot The Messenger After Security Researcher Discovers Vulnerabilities In Airplane Computer System
On WiFi at all?
On the post: DailyDirt: Is It Time To Change Your Passwords (Again)?
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.
On the post: Netflix Moving To Encrypted Streams, As Mozilla Moves To Deprecate Unencrypted Web Pages As Insecure
Re: Re: Development
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.
On the post: Netflix Moving To Encrypted Streams, As Mozilla Moves To Deprecate Unencrypted Web Pages As Insecure
Development
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).
On the post: Funniest/Most Insightful Comments Of The Week At Techdirt
Mason Wheeler's comment
On the post: Supreme Court Says Lifetime GPS Monitoring Of Sex Offenders May Be Unconstitutional
Re: How come felons losing the right to vote isn't...
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.
On the post: Competition In The Music Space Is Great: Fragmentation In The Music Space Is Dangerous
On the post: Google Denies Narrow Warrant Request For Emails; Government Responds By Asking For Everything Ever
Re: The reason they fed them that line...
On the post: Funniest/Most Insightful Comments Of The Week At Techdirt
Re: Syntax Error
Bug: code sets "guy" to "good" unconditionally and always calls letIn() method with an argument of True.
Status: Closed
Reason: Working as specified.
On the post: EFF Launches Awards Program For Most Outrageous Failures In FOIA Responses
On the post: Your Tax Dollars At ??: Government Agency Has No Idea How Many Of Its Employees Are Telecommuting
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.
On the post: Remember That Undeletable Super Cookie Verizon Claimed Wouldn't Be Abused? Yeah, Well, Funny Story...
can be = will be
On the post: Google, Microsoft, Wireless Carriers Form Rare Alliance To Battle Marriott's Dumb Wi-Fi 'Jamming'
On the post: NY Judge Laments The Lack Of A 'Right To Be Forgotten'; Suggests New Laws Fix That
On the post: Court: Similarities In Shortening MLB Broadcasts Doesn't Equal Patent Infringement
On the post: Chrome Security Team Considers Marking All HTTP Pages As 'Non-Secure'
Re: Re: Re: Re: Re: Re: Re:
On the post: Chrome Security Team Considers Marking All HTTP Pages As 'Non-Secure'
Re: Re: Re: Re: Re:
On the post: How Should Standard-Essential Patents Be Licensed?
Or at least specify the license terms
On the post: Will New Free Certificate Authority Help Or Hinder Online Security?
Re: Re: Pinning plus private CA
On the post: Will New Free Certificate Authority Help Or Hinder Online Security?
Pinning plus private CA
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.
Next >>