Noticing does not mean we care
Karma -= 100...
None of these protect against a volume-oriented DDoS. Many are DoS only (single / few sources) and do not apply when every IP on the Internet appears to be sending thousands of requests, or more likely, responses. Further, you've completely ignored spoofing of addresses combined with amplification attacks (send out a 64 byte DNS request pretending to be the DDoS target, get 4kB sent to the target). Finally, regardless of the 50-100Gbps pipes MS, Sony and Amazon no doubt have, they're useless when there's 1Tbps of amplified crap directed down the pipes. With the example above, you'd only need about 4Gbps of bandwidth total (40 cheap VPS on "100Mbps" connections) to generate 256Gbps of DDoS.
When 256Gbps of rubbish arrives at your servers or firewalls
And since it seems it was apk I'm replying to
Buddy, you can get a certificate for less than FIVE US dollars per year. Is that too much for you?
Actually yes, frankly it is. Because according to Google's overpaid, brain-dead Chrome developers, I need one for the KVM, one for each of the management cards in the servers, one for each of the appliances I have (from DVRs to firewalls etc), one for each little device with a web server (assuming it even supports writing a certificate to storage, and config for HTTPS), one for each workstation or server with an app or config UI. Quick count for my house alone
OK, Mr AC, care to explain how you plan to cache SSL-encrypted objects? All your caching proxy sees is the "connect me securely to server X" request - after that, it's encrypted and your proxy cannot tell what's being loaded. Worse, since SSL inflates the data sizes of whatever you've requested, your images are up to 50% more data, and your (already compressed with gzip) HTML, CSS, JS etc is the same. So you've added 50% to your traffic for
Seriously, what do you gain (actual, measurable improvements) from switching from http://www.comics.com/garfield... to https://www.comics.com/garfiel...? Nothing but overhead.
And that's leaving aside the fact that SSL no longer guarantees the source server (too many options for MITM server certificate hacks) or security (POODLE etc).
No, make no mistake, this is Google throwing its weight around, screw anybody who doesn't want or need a certificate for their site, or has made a conscious decision NOT to use SSL (not to mention all the corporates with proxies that inspect for malware - now you're mandating SSL MITM by the organisation, or you have a channel for malware into any system).
Actually, I don't know why they don't "acquiesce" somewhat to the demands - and offer to sell to the dealers at the same price as they sell in other states.
When the dealers refuse on the basis they won't be competitive with out-of-state sales, they should surely be able to use that to force the hand of the legislature (by advertising in Texas, with the tag line "Not available in Texas because none of your dealers will sell our cars" or something). Truthful. Pins the "blame" where it belongs (the dealers).
If, OTOH the dealers accept, the customers will demand to know why Texas is 25% more expensive (and Tesla can truthfully say "We sell at the same price to all comers, dealer or private, so any difference is the dealer's margin because your state gov't won't let us sell direct to you".
I'm very interested, with Tesla apparently coming to Oz next year, to see what happens here.
Sure - I could. But that's extra devices and usually extra power points at those locations (esp if you want any POE - I doubt there will ever be a switch that can be powered by, AND deliver POE at the same time). So it's extra devices to buy and support and manage which is why I decided against it. Having the extra ports doesn't stop me doing it in the future either.
The flip side of course is that a failure in one of the big switches takes a LOT of things offline and it's more expensive to replace. Not the VM cluster or servers - but about half the other devices (e.g. one of the WAPs, half the desktop points etc).
OK Telstra has to record the source and destination numbers of all the calls - right? Here's a sample record (not that drawing a table is easy so work with CSV here):
FromID, ToID, TimeStart, TimeEnd
0299999999, 0288888888, 20090617135834, 20090617140711
How would you like to determine whether the number 0299999999, which is not owned or operated by Telstra today, and which was not owned or operated by Telstra in 2009 either, was or was not an unlisted number at the time of the call? Because its state right now is completely irrelevant - the state at the time of the call is the important and relevant piece of data, and it doesn't exist. And the reason it doesn't exist is that this is a record designed for billing and cross-checking, not for customer view (if you're arguing against unlisted numbers in toto, you've never been stalked).
We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan