Yes, Switching To HTTPS Is Important, And No It's Not A Bad Thing
from the we-need-encryption dept
Last month we wrote about Mozilla's move to deprecate HTTP in favor of encrypted HTTPS, which followed on Chrome's move to do something similar. What surprised me a bit was the response from many in our comments who didn't think this was a good idea. People talked about how it added complications to development, or pointed to problems with the whole concept of trusting certificate authorities and a variety of other problems. Some worried about the costs associated with getting a certificate. Ben Klemens, who has written eloquently for years about the problems of software patents, wrote an article noting that this would make it difficult for individuals to easily set up their own web platforms, and require them to rely on a third party with whom you'd have to identify yourself (the certificate authority).Of course, there are many attempts to deal with these issues, such as the big Let's Encrypt project from EFF and others to offer free certificates. And, if you're hosting websites online, you're likely already going through a third party hosting provider, and it's not clear how dealing with a certificate authority is really all that different.
But the most compelling argument I've seen for why this is so important comes from Eric Mill, who discusses why this is so important by highlighting the many, many ways in which the web has changed over the past few years -- allowing both companies and governments to readily abuse the unencrypted nature of the legacy web, putting all of us at risk. This is a real problem that HTTPS goes a long way in solving:
We discussed that last one last month as well, in noting how HTTPS would prevent attacks like the one China launched (and is constantly launching elsewhere as well).But when I look at the last few years, I see a very different web than the one I was introduced to:
- Verizon injects tracking headers into unencrypted traffic so they can sell your browsing activity to advertisers. This program started in 2012, after Verizon realized they "had a latent asset", but wasn't noticed until 2014.
- Other companies like Turn piggyback on Verizon's tracking header to sell your data to even more people, because they "are trying to use the most persistent identifier that we can in order to do what we do", says Turn's chief privacy officer.
- Comcast injects ads into unencrypted traffic, because "it's a courtesy, and it helps address some concerns that people might not be absolutely sure they're on a hotspot from Comcast".
- Andreas Gal (Mozilla's CTO, in his personal capacity) has claimed that Yahoo and Bing "can acquire search traffic by working with large Internet Service providers" to harvest users' Google search results to improve their own -- and strongly implies that they used to do this before Google shut them out through encryption. Even if you support better competition against Google, I doubt you expected your ISP to make deals to sell your traffic to other corporations without your knowledge.
- The nation of India tried and failed to ban all of GitHub. HTTPS meant they couldn't censor individual pages, and GitHub is too important to India's tech sector for them to ban the whole thing.
- The nation of China weaponized the browsers of users all over the world to attack GitHub for hosting anti-censorship materials (since like India, they can't block only individual pages) by rewriting Baidu's unencrypted JavaScript files in flight.
And, also, it's not just corporate abuse, but government/intelligence community abuse as well:
Pretty much everyone agrees that the security certificate system has its problems. We've been pointing that out for years. But encouraging more encryption now is solving real problems today. And, as Mill notes, Klemens' and others' concerns about this move towards HTTPS being a kind of "recentarlization" of the web are also misguided. All of those examples above show how big companies and governments are, themselves, abusing the unencrypted nature of the internet to take control and force a distributed system to act more like a centralized system by inserting themselves in the middle. HTTPS actually helps protect a more decentralized web by blocking those man in the middle attacks:The NSA scans just about everything that goes through the internet backbones and saves as much of it as possible, in collaboration with intelligence agencies around the world. This is called "upstream collection", and their "posture" is to "collect it all". The NSA's upstream collection program has not been reformed. It will not be reformed by the current draft of the USA Freedom Act, in fact was endorsed by the only government agency whose job it is to review it, and the most meaningful court victory so far -- while a wonderful and important precedent -- addresses a separate program that only touches data about telephone calls. After the Charlie Hebdo attacks, France is now making bulk internet spying explicitly legal and giving its intelligence services vast powers to work with ISPs to surveil the network. The United Kingdom is likely to do something similar, after Cameron's strong re-election means he can make good on his pledge to make all online communication subject to monitoring.
When I look at all these things, I see companies and government asserting themselves over their network. I see a network that is not just overseen, but actively hostile. I see an internet being steadily drained of its promise to "interpret censorship as damage".The security certificate system isn't perfect. But an unencrypted web has serious and dangerous flaws that put us all at risk. In the old days, people could keep their homes unlocked as well, but that got widely exploited so now most of us lock our doors. It's not perfect and it has problems, but the overall protection is worth it. That's even more true online where encryption is important in enabling greater freedom of expression and protection of privacy.
In short, I see power moving away from the leafs and devolving back into the center, where power has been used to living for thousands of years.
What animates me is knowing that we can actually change this dynamic by making strong encryption ubiquitous. We can force online surveillance to be as narrowly targeted and inconvenient as law enforcement was always meant to be. We can force ISPs to be the neutral commodity pipes they were always meant to be. On the web, that means HTTPS.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: attacks, centralized, ddos, distributed, eric mill, http, https, privacy, security
Reader Comments
Subscribe: RSS
View by: Time | Thread
Lies lies lies!
[ link to this | view in chronology ]
Re: Lies lies lies!
[ link to this | view in chronology ]
Re: Re: Lies lies lies!
I'm trolling of course your right I posted it since 6 GB is a lot for mobile(CSB), but most Land line plans are unlimited or like at least 100GB, and yah I get it that Cell sites have bigger congestion issues but it's still non sense, it's not load balancing it's made up reasons for billing, I used to work for an ISP and an they where paying $90/Mb @ 98th percentile and this was 2003 so.. bill me that then I will take you seriously about it being about network congestion!
As for the the FBI TLS may be maybe ok but and maybe it's a bit better than plain text but I still don't trust it..
[ link to this | view in chronology ]
And held for "moderation"
TSA Tech dirt! I feel more safferer!
[ link to this | view in chronology ]
Re: And held for "moderation"
[ link to this | view in chronology ]
Re: Re: And held for "moderation"
PT boat on the way to Havana!
[ link to this | view in chronology ]
Re: Re: Re: And held for "moderation"
You should feel stupid after submitting that one, too.
[ link to this | view in chronology ]
Re: Re: Re: And held for "moderation"
> not allowed to speak even if they are not stopping you!
Nobody is telling you that you are not allowed to speak.
But people can tell you to speak your mind elsewhere.
I would immediately jump to your defense if I actually believed your freedom of speech were in danger. It is not. Your ultimate remedy would be to set up your own website and speak all you want to. Yes, really! Attract vast numbers of people from far and wide who want to come and hear your wiz-dumb.
[ link to this | view in chronology ]
Re: And held for "moderation"
Yes?
[ link to this | view in chronology ]
Re: Re: And held for "moderation"
[ link to this | view in chronology ]
Re: Re: Re: And held for "moderation"
> protest when people start telling you your
> not allowed to speak
Your never going too get you're weigh on this.
Their are just two many people out they're using there words wrong too get to upset.
Sew don't loose you're cool about it.
You can sea mini common examples that exist of incorrect usage.
People pick the write words two use according too there porpoises.
But you'd have two be a fool to begin or end a sentence with the word "but".
And only an idiot would begin or end a sentence with "and".
And a preposition is a very bad word too end a sentence with.
[ link to this | view in chronology ]
Two counterpoints
Second, I find this move by Mozilla entirely disengenuous, given that it's spent much of the past decade endlessly fiddling with the Firefox UI which was perfectly fine 30 revisions ago. It's done that instead of implementing things that would actually protect users TODAY from some of the worst threats on the web: malicious scripting and malicious advertising. Instead those defenses have been relegated to Add-Ons (e.g. NoScript, AdBlock Edge).
That's wrong. They should have become part of the core functionality of the browser years ago. (And they don't represent all the defensive functionality that should be in there: they're just representative examples.) And implementing HTTPS won't solve this because of course the malicious payloads can be delivered just as easily that way -- and oh, by the way, can't be filtered by sanitizing proxies that might otherwise prevent them from attacking users' browsers.
So, borrowing from Lauren: encryption is good. Encryption everywhere is very good. It's mom and apple pie. But encryption via a forced march is a horrible idea.
[ link to this | view in chronology ]
Re: Two counterpoints
...and I can't help but assume that - at least - nation-state adversaries have access to more than one root cert and therefore have no need to crack traffic encryption when they can just perform a simple https MITM. The PKI was a band aid to begin with and is almost certainly gamed at this point. The only real fix is to trash it and build something else from the ground up based on meaningful security.
...and then all that's left for us to do is address the security issues with the hardware, OS, firmware, addons, anti-virus, every other application installed on our machines, and the lawless state of affairs regarding the collection/storage/purchasing/selling/use of personal data.
Commence breath holding in ...3, ...2, ...1
[ link to this | view in chronology ]
Sorry to derail things!
[ link to this | view in chronology ]
There are lots of great arguments but...
[ link to this | view in chronology ]
Shills, shills everywhere
Keep in mind there are likely paid shills from entities (commercial or government) with incentive to discourage people from moving to HTTPS. Be mindful of people purposefully derailing comments!
HTTPS is worth it. It's worth showing to website visitors/ customers that you're trustworthy.
[ link to this | view in chronology ]
Re: Shills, shills everywhere
1. Your suggestion that certain institutional actors might attempt to
influence a debate in particular fora covertly, with (eg) sock
puppets, is not unreasonable on its face. It is, after all, common
practice.
However, I would expect to see, in tandem with such efforts,
overt attempts to spin the discussion as well. You know, like
the FBI's "OMG we're going dark!!!" routine.
Given your demonstrated alertness to shills. can you point me to
anything overt like that arguing against the push to https, so that I
can sniff at it myself for vested interest, straw-man arguments, etc?
Anything at all. An editorial, or whatever, would be great.
2. The following argument should raise alarm bells?
[ link to this | view in chronology ]
Yes, it is important, but no it is NOT to be trusted at the end of the day.
If the NSA is your principal concern - then HTTPS simply must be treated like HTTP (though yes, it IS important to switch to it, as they are by no means the only adversary out there). Focus on knowing that your HTTPS session is 'public' (at least to them or other parties who can obtain 'keys to the kingdom'), and thus what (and all that) you can do is *anonymize* what is public and in full view.
HTTPS is not some panacea for all Internet privacy/security/anonymity woes - it is only something that 'helps'.
If the NSA is something I consider a threat (and it is), then I am only happy with personal information on the web being encrypted with a TRUST-NO-ONE form of encryption like Pre-Internet PGP or what have you.
And no, I'm NOT missing out on a great deal (life's stull of sacrifices and choices) - all public data and research is still easily within reach using powerful anonymizing technologies like Tor. (Hell, even Facebook has an official Tor .onion address!)
And as for the loss of the benefit of online communication and the powerful things that can bring - well it turns out REAL conversations with REAL people using NO technology at all ... is a WONDERFUL thing. :D In fact, there's whole worlds of knowledge, information and community that actually AIN'T on the Internet anyway. ;) The world's bigger than the Internet, just cos the NSA currently 'owns' it doesn't mean it's your great loss!
[ link to this | view in chronology ]
Let's Encrypt
[ link to this | view in chronology ]
Re: Let's Encrypt
[ link to this | view in chronology ]
Summer is soon here so... Give me. Give me. Give me. I want it and my site needs it.
Normal certificates with annual subscriptions are simply too expensive for small start-up websites.
[ link to this | view in chronology ]
Troublesome certificates...
It adds a lot of maintenance for the webmaster who hosts multiple domains. You need to renew the certificates and you need to know what SSL is and how to use it. And how to debug any SSL-related problems. It is generally a huge pain in the donkey. (Well, other word for donkey, that is.) And you have to consider if it really makes customers happy.
Client-side, same problem. When you create an app for the iPad and/or Android then using SSL requires a little more coding action. A little more knowledge that most seem to be missing.
The biggest problem is that the lack of knowledge about HTTPS and SSL will increase the vulnerability of specific systems, not decrease them. Certificates get lost or fall into the wrong hands. And it still doesn't protect you that well against a man-in-the-middle attack. Verizon could easily just intercept the HTTPS traffic, decrypt it and re-encrypt it with their own SSL certificate you your browser would not know about the "attack". Actually, they can encrypt it and just send a copy of the unencrypted data to the user, so they will analyze the content that the user was looking for. It makes tracking a bit harder but they still know whatever person at address xxx.xxx.xxx.xxx finds interesting.
So, I think HTTPS just gives a fake sense of security. And Verizon including their own headers in the HTTP traffic should be a criminal offense. They're violating Net Neutrality.
[ link to this | view in chronology ]
Re: Troublesome certificates...
Maybe I'm mistaken, but I don't think that's correct. Your ISP does not have the private key of the CA, so they could not decrypt the initial message. Then after that, both sides are using a secret key that Verizon also does not have, so again would have no way of decrypting traffic. Here's a question about it regarding proxies, and as far as I know, an ISP would be in the same boat:
https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks- by-proxy-server
They could use something like SSLStrip to change the HTTPS to HTTP, and then they would be intercepting HTTP traffic, but that would rely on nobody noticing that HTTPS connections aren't really HTTPS - the browser would show it as unsecured. They could also use a fake certificate, but that would also be obvious. I don't think they could do this covertly.
So, I think HTTPS just gives a fake sense of security.
It's not perfect, but it's real security.
Some more info on MITM:
https://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding
http://w ww.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Midd le-Attacks-ARP-Part4.html
[ link to this | view in chronology ]
Re: Re: Troublesome certificates...
You try to connect to a HTTPS site through the proxy. The proxy detects this and Connects to the HTTPS server by itself, thus receiving the public key that it needs for the communication between proxy and site. And Verizon would use its own certificate to sign the connection between user and proxy. And as a result, your browser will think it has a valid public key, which is true. The Verizon certificate is probably already in your store. But if you check the certificate, you'll see it's the wrong one!
There is a solution, though, which I think is done by Google. In Chrome a few public keys are stored in the browser executable instead of retrieved over the Internet. Thus, the Chrome browser will know if it is talking to the true Google server or not over a secure connection. If the certificate it receives differs from the one it already stored, alarmbells will go off.
And then the user clicks them away because users are generally not that smart...
[ link to this | view in chronology ]
Re: Re: Re: Troublesome certificates...
[ link to this | view in chronology ]
Re: Re: Re: Re: Troublesome certificates...
This type of MitM attack is untenable on a wide scale, particularly if you need to keep it quiet. Targeted attacks on less savvy individuals, however...
[ link to this | view in chronology ]
Re: Re: Re: Re: Troublesome certificates...
ISPs have played with this option, noticed it "broke" the Internet and stopped doing it again. Nowadays, this is still possible as a special proxy so your mobile bandwidth is reduced.
Since your provider is a trusted CA they could easily create their own certificates to use for this proxy and thus still capture all HTTPS traffic. Law Enforcement actually has the same option! And to protect yourself against it, you will have to check each certificate carefully before continuing browsing the specific webpage. That is, if you're really paranoid.
There are additional securities, though. The Chrome browser knows the public certificates for Google and other popular sites so it can validate against those. And it should be possible to have browser extensions that can do the same checks for you. It is also a good reminder for App builders to include their public key inside the app so they don't need to ask for it from the web service. There are plenty of ways to detect these attacks and if Verizon would do something like this, like here on TechDirt.
It is more secure than regular HTTP. But still, every security measure can fail and has weaknesses that can be exploited by parties willing to do so. With more and more sites moving towards HTTPS, it becomes more interesting to e.g. hack those certificates and recalculate the private key for all those public keys that are out there. It requires a lot of processing powers but it is not impossible. It is why we continuously have to find new and better encryption methods, simply because the old ones become too weak at some point in time.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Troublesome certificates...
I'm not a cryptographer, but with modern encryption and good key sizes, I don't think it's as simple as just using a lot of computing power*. The people making this stuff aren't stupid, and it's a lot easier to increase the key size than to increase computing power by a proportional amount, so I doubt the security people are sitting on their hands while computer power overtakes encryption security.
https://security.stackexchange.com/questions/54136/possible-to-derive-private-key-from-publ ic-key-given-enough-computing-power
The obvious tinfoil hat answer is that government (NSA in particular) has far more computing power than is publicly known and can decrypt whatever they please, but I think some of the Snowden documents indicate that is not true. And if the NSA can't do it, who else might be able to?
* it's possible not all current SSL implementations use good algorithms and keys, I don't know.
[ link to this | view in chronology ]
Re: Re: Re: Troublesome certificates...
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Troublesome certificates...
To check it, you would need to check the certification path, which would differ from the original certificate. Without access to the original certificate to compare, you can't know if you have the real certificate or a proxy version created by your provider.
But if your browser or App has the original certificate included in the executable, it should be able to validate the certificate with whatever the site provides.
Which only works as long as your browser or app gets updated when the certificate changes...
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Troublesome certificates...
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Troublesome certificates...
If they risk compromising their root CA then they could just make use of a different root CA by someone else. Or they will limit it to specific areas, countries or perhaps even their free WiFi, if they offer that somewhere.
Revoking a root CA isn't something Google or Mozilla will do that easily, since Verizon is big and powerful. The legal consequences might result in just a warning from Google and Mozilla and Verizon will reverse their changes.
Providers in other countries might even have it easier. The Iranian or Chinese government could force all computer users to install a government-issued certificate that they can use to listen in on all traffic. The providers would then route all traffic through this system and the people might complain, but can't do much about it. That's the power of a monopoly.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Troublesome certificates...
That will suddenly mean that all of Verizon's CA signed certificates look suspicious to millions of users.
Suddenly everyone who ever bought a certificate from Verizon will get a new one from a different CA, and possibly sue Verizon for making their old certificate suddenly worthless.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Troublesome certificates...
I would suspect that browser manufacturers are smarter than you think about this. Paranoid even.
Here is my unproven hunch. Speculation. I'll just use Chrome as an example. Google could use a private self-signed certificate that nobody else, including Verizon can impersonate. This self signed certificate is not from any CA. Google would have their own private CA. When Google's Chrome browser communicates with the mother ship to get an update, it would check that the update is signed by a certificate from Google's private CA. That way the integrity of updates is completely protected, even from a successful MITM attack against the existing CA infrastructure. The browser would not care that any other CA signed the download. Only Google's private internal CA would be the one that your existing browser on your computer would trust to sign an update before it would be accepted.
Very similarly I bet Microsoft (and Ubuntu, and others) use this approach to verify the integrity of updates to operating systems.
If an OS or browser maker were really paranoid, they might build in a list of other apparently unrelated places to check for the availability of an update. That way, it is unlikely that Verizon could block the browser or OS from discovering the availability of an update. That way, the end user would soon be told that the update cannot be obtained because it is being attacked by an MITM.
[ link to this | view in chronology ]
Re: Troublesome certificates...
> will increase the vulnerability of specific systems, not decrease them.
Making HTTPS and SSL more widely used will solve that problem. I remember when I first started using it in a commercial web application about six years ago. I had to learn a lot. But it was worth it.
[ link to this | view in chronology ]
Re: Troublesome certificates...
> protect you that well against a man-in-the-middle attack.
Certificates can be revoked.
There have only been two attempts at a third party abusing CA powers -- and they were both detected early. The ramifications of the discovery were big.
More and more parties are actively looking for MITM attacks. For example, even though Honest Achmed's Trusty Certificates of Tehran Iran may be recognized by your browser, it would be a dead giveaway if they (or Verizon) were to issue a Google.com certificate.
There is Certificate Pinning. There are browser extensions that people run to see what CA originally signed every certificate and notice if that ever changes and raise a red flag.
Despite the imperfections of the CA system, it is a whole lot better than doing nothing. And it can be improved.
[ link to this | view in chronology ]
Running a CA
If that's too much to worry about, you can always forgo a CA entirely and use self-signed certs. No one will be able to trust them, but it's the easiest way to get encryption running. The problem with https/ssl is it's playing double duty as data encryption and identity verification. Providing encryption is cheap and easy, and solves most (though not all) of the concerns about modern web browsing. Unfortunately, encryption is caught up in identity verification/trust authority, which is difficult and expensive (though progress is being made on that front by EFF/Cloudflare/others). 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 obviously wouldn't be as secure as https (MitM attacks would be much easier), so https would still need to be used for things like ecommerce, but it would be much better than http, and without the costs/difficulties of https.
[ link to this | view in chronology ]
Re: Running a CA
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.
[ link to this | view in chronology ]
Re: Re: Running a CA
I'm not surprised that there hasn't been much interest in it, though.
[ link to this | view in chronology ]
third party?
Here's the only thing I don't like, other businesses, don't recognize that google is here. And its an active business, such as, you are trying to get the news or weather off an certain website, like CBS/NBC/fox, they all ask for a carrier that you are subscribed thru, to run the article thru? And pop you a list, usually not there..even on the locals, so I have to switch to the next big city that has coverage, they usually let me see the article?
But that was the first time that happened, I get thru to my online bank, medical records, etc, but cannot check on the availability of a boat thru PS. Durn.
[ link to this | view in chronology ]
What does HTTPS have to do with you being refused connection to a military site?
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
More Profit for Shared Hosting Providers
I'm all for making the entire internet https, but Mozilla's method of doing so isn't the best way. Instead of saying "do it our way or else," they should be helping people make the transition by guiding them in the right direction, not forcing them at gunpoint. It will easily create a two-tiered system: those who are tech savvy enough to know what they're doing, and those who are at the mercy of shared hosting vultures, and the latter will be the small start-ups and individuals who can least afford the added cost. I think when we come to the point where shared hosting providers start to offer SSL by default, then we'll be ready to make the transition that Mozilla seems eager to push upon us.
[ link to this | view in chronology ]
Re: More Profit for Shared Hosting Providers
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Encourage, don't require
We force their hands, making back doors to bypass the encryption become mandatory.
[ link to this | view in chronology ]
Re: Encourage, don't require
[ link to this | view in chronology ]
Re: Encourage, don't require
> the encryption become mandatory.
If that's the way it must go, then that is better than what we have now.
If we're going to make back doors mandatory, then let's get it out in the open in front of God and everybody. None of this sneaking around crap.
That way, everyone can clearly see how their governments are acting and then judge whether it is in their best interests. That way, everyone, even politicians can see that it is them too who are being spied upon by the state apparatus.
[ link to this | view in chronology ]
The OSI model was wrong
The protocol stack is busted all the way down to layer 1. And it gets worse, since even the system bus has been compromised for some time. Not to mention the embedded exploits that come in the form of chipsets for video cards, disk controllers and NIC's, which are there from the date of purchase. And that is before discussing the OS and application software based surveillance that is installed from new or on-demand via automatic update.
In a nutshell, there isn't a single part of consumer computer service that doesn't need to be heavily refactored. But hey, we're prefering SSL now, so Yay security! SSL is a turniquette on the gangrenous neck wound of a corpse.
[ link to this | view in chronology ]
The most hilarious thing I've read all week
Ok, you can stop laughing now. Stop it! Stop it, I say!
If I am concerned whether I am on a hotspot from Comcast, I need look no further than to check my download speeds, or whether certain protocols or even port numbers get throttled.
[ link to this | view in chronology ]
[ link to this | view in chronology ]