A) REALLY suspicious of anyone who says this. Do you know the history of common law? It was so cruel that in the 18th century hundreds of crimes resulted in the death penalty. The courts of chancery were introduced to grant some small, very small measures of leniency.
And, there is no federal common law. Federal law derives exclusively from the constitution.
Guess I was lucky the Texas DMV didn't deny my plate for being sinful.
http://plover.net/~agarvin/chupacabra.jpg
They even granted a monopoly on adult-related TLDs to a single registry (ICM), with rules on what kinds of content is allowed on them
Uh, yeah, because .xxx is a Sponsored TLD. Use policies are not only allowed, they're expected by the nature of STLDs. ICANN is not regulating any content here; they've created a TLD where the sponsor is expected to develop its own use policies consistent with the proposed nature of the TLD.
The process for authorizing STLDs is pretty transparent: https://archive.icann.org/en/tlds/stld-apps-19mar04/
If that doesn't worry you
It doesn't.
"using WPA-2 Enterprise, combined with a RADIUS server would work. (I'm not a network guy, just paranoid enough to learn)"
Very very few consumer devices support 802.1x. I wish they did. I hate having a single PSK for the devices on my network that are probably the least secure. I isolate them and apply strict ingress and egress rules for traffic to them.
"If you haven’t configured the kettle, it’s trivially easy for hackers to find your house and take over your kettle," Munro says. ... "I send two commands and it discloses your wireless key in plain text."
If you haven't configured it yet, how can they get your PSK?
It's easy to mix up rules for eating fries dropped on the floor with rules for snooping on people's private communications. Happens nearly daily for me.
Yes, abuse of certificate authority is something that's hard to protect against. That's where we rely on the PKI infrastructure to audit CA issuing procedure--it would suck for Verizon if they were caught doing that, and Cybertrust's root CA got revoked. Why would they risk it?
"I'd love to see a protocol somewhere between http and https, that negotiates and encrypts traffic, but doesn't rely on a trust framework."
It's possible to implement TLS without X.509 PKI infrastructure. In fact, there's an RFC out there that has an alternative, RFC 5081, which allows exchange of OpenPGP keys--this has been allowed since the TLS 1.2 standard (2008 or so); actually the RFC implies other types of cert exchange may be used if it's explicitly negotiated, but 5081 is the only one I know of.
As far as I know, no one has implemented it yet. There seems to be no interest in it.
"Verizon does not need the private key since they can use their own private key to encrypt everything again. The only way that you'll notice this is when you check that public key that you've received. "
No, part of the SSL verification process on the client side is verifying that the domain you're going to matches the domain in an X.509 certificate (the CN in the Subject portion). Unless Verizon managed to acquire a certificate with www.google.com as the CN, you'll get a cert mismatch error on your browser.
TLS is well-designed to prevent MITM attacks. Now if the MITM has the private key, that's a different matter. Perfect forward secrecy prevents decrypting after the fact if the session is simply packet-captured. It's not protection against a proxy when the evil party can redirect your traffic through it. And if the cert issuing process is compromised, that's another problem. But people people notice when a CA can't be trusted.
It remains costlier to scale because of the additional computational overheard of TLS. That's still a fact in 2015. It's not necessarily prohibitive, but it has to be taken into account. Load balancers acting as SSL proxies may need additional licensing, or a lot more cpu resources. CDNs charge more for it. And, worse, if you're making that money back in ad revenue, advertising services can pay less when forced to use ssl (or, you might have to skip some sources because they don't serve ssl ads and you don't want one of those "some elements of this page are insecure" messages on your site).
It's probably important to note these are "disaster recovery tapes", not email archive tapes. As such, they're probably full disk or LUN image backups, probably taken at regular intervals (month? quarter?). A fragment of data is not particularly useful in a DR situation. So I can easily imagine that recovering email over several years requires examination of a bunch of tapes, especially if there's a regular purge going on, on the servers. DR tapes aren't going to have space-saving measures like incremental diffs or dedupe. You want to dump a full image and bring it up as fast as possible.
(Also, as for size, I have 9 years of email from a previous job, from 2005 to 2014, exported as PSTs, converted to mbox format and exported to timestamped individual files. The median size is 12k [ls -l | awk '{print $5}' | sort -n | sed -n "$(($(echo * | wc -w)/2))p"], but the average size is a much larger 180k [46k messages totalling 8.1G], and I know I would frequently delete mails with big attachments that I didn't want to save).
The magazine that introduced America to theories that Vince Foster was murdered by Clinton to suppress stories about him ordering state troopers to kidnap women and carry them to his boudoir?
Ok, they don't seem as crazy as they did 20 years ago, but does anyone pay attention to them?
This is only a small step above sending a letter to the Daily Mail saying they got some facts wrong.
I do pretty much 100% of my financial transactions online (with the single exception of tax documents mailed at the start of the year). Lock my mail box? Bah, I'd love for thieves to get into it, and still the bulk junk advertisements that fill it up every week.
(Apparently no one else needs it either. A week in, it doesn't have a single solitary contribution)
Yes, it's the switch to https. If you click past the 'don't go here' you won't even get the site. I explained elsewhere that akamai's "edgesuite" network which serves 80 is a completely different set of servers than those that serve 443 (which they used to call "edgekey" but now are branded something silly). When you go to https on edgesuite, you're connecting to their netstorage service. You get this with every akamai customer that's on their edgesuite network.
Akamai is a good way to mitigate attacks, but it's an expensive one. I've just seen this particular error before, because my last company had a pretty deal with Akamai--we got around 7 cents a gig transferred. Not necessarily good compared to other CDNs but pretty good for Akamai. We would see this error because we'd get customers on Akamai, and then they'd do a security scan, it would come back highlighting that the SSL cert didn't match, and asked to fix it. Then, we'd say, ok, just pay for an Akamaized SSL site, which will cost you 5 times as much, plus you have to use Akamai as your SSL vendor, which makes netsol look cheap, and then they'd come back and say "no thanks".
I found some other sites that will give you the same error:
https://www.pepsi.com
https://www.mountaindew.com
You can tell which sites are on the Akamai SSL network by seeing what they're CNAME'd to. If it's edgesuite.net, it'll give a cert error. If it's edgekey.net, it's good:
[agarvin@atg-home logs]$ dig +short www.pepsi.com
www.pepsi.com.edgesuite.net.
[agarvin@atg-home logs]$ dig +short www.aa.com
aa.com.edgekey.net.
Note this domain:
[agarvin@atg-home logs]$ dig +short www.dni.gov
www.dni.gov.edgesuite.net.
Look at the cert with openssl s_client and you'll see the CN is for a248.e.akamai.net.
Eh, I've set up a lot of Akamaized sites in the past 15 years. That's not a real problem: it's someone who went to an akamaized http site through https. You have to pay extra money to get their SSL versions, and then you have to CNAME your domain to another set of servers, their special SSL servers.
If you put https in front of any site CNAME'd to Akamai that isn't paying for the extra SSL, you'll get basically the same error, because it sends you through their old edge network--it supports SSL, but it's for serving individual assets like images or swfs.
It's probably historically related to the way they rolled out different offerings. Basically, for this site, they didn't want to spend a few thousand extra a month for SSL offerings.
"Most major companies now have a chief corporate security officer tasked with assessing and mitigating "threats" of all sorts -- including from nonprofit organizations."
Wat?? The scare quotes, the weasel words "of all sorts", the addition of "including nonprofits!": This is the silliest, fake-scariest description of the CSO position that I've ever seen.
Personally, I'm beginning to doubt whether the technology exists, fuzzy logic or not, that is able to cook a frozen burrito or chinese noodle box where one part is a fraction of a degree away from initiating nuclear fusion, and the next bite is cold enough to enable superconduction.
Re:
Well, the CDA modified the 1934 Communications act--explicitly. It's considered part of it now.
See: http://transition.fcc.gov/Reports/1934new.pdf