1 files changed, 86 insertions, 0 deletions
diff --git a/https-cuts.txt b/https-cuts.txt
index 3178c29..5b2f3a5 100644
--- a/https-cuts.txt
+++ b/https-cuts.txt
@@ -1,3 +1,89 @@
+
+
+
+
+
+
+So long as browsers stop there the current plan seems well-suited to bringing more security to the web. 
+
+
+
+
+
+This might 
+
+Both also plan to limit many HTML APIs to HTTPS only, starting with the geo-location APIs, hardware access APIs and anything else that would be a security risk over unsecured connections.
+
+
+It's not difficult to imagine a day and age when browsers treat HTTP sites they way the treat suspected malware sites now and simply not load them. To be clear, that's not happening right now. But it would be foolish to assume that it never will. 
+
+
+
+My personal website does not ask you to log in, it loads no third-party scripts, ad networks or any other code. Yet without encryption I have no way to ensure that some other party isn't inserting code of their own. As Hoffman-Andrews says, anyone could "insert their own ads, their own tracking cookies, they can insert malware and do their own tracking". In other words, I would like to make sure no one is tracking you when you visit my site, and that you see no ads, but I can't. Unless I use HTTPS.
+
+Think no one is doing that to your site? Think again. ISPs are and will likely be doing more of this in the future, particularly mobile service providers. Their primary responsibility is to their shareholders and it would negligent of them to not increase profits by increasing tracking.
+
+It's worth noting here that this kind of manipulation is very likely at the heart of Google's love of HTTPS. Google did not respond to my inquires for this article, but it's a kind of open secret that ISPs harvest search queries. Without HTTPS it's pretty easy for ISPs to track not just search queries but which results users clicked on, which is vital information for building a better search engine. In other words, info Google would prefer its potential competitors don't get.
+
+Winer calls out Google specifically and he's not the only one to do so. Yes, Google is acting in its own best interests and Winer is right to question the motives of a company so massive it has the power to [potentially control elections](https://aeon.co/essays/how-the-internet-flips-elections-and-alters-our-thoughts). However, in this case, Google's interests are aligned with the web at large (for now). Google doesn't want that data captured and sold, but remember that data is actually about you. It's your data first and foremost and regardless of what you think about Google gathering it, you certainly don't want it bought and sold by others.
+
+
+
+
+Read through Mozilla's bug report on the subject and you'll find quite a few people talking about this content as if it were somehow tainted. "It's time we start treating insecure connections as a Bug," writes one Mozilla developer on a bug report entitled "Switch generic icon to negative feedback for non-https sites." Mozilla is a big company, with many different voices, but even Barnes wants to make sure that the web is secure and he's not alone, the Chromium project has similar bug threads and outspoken HTTPS proponents, but the web is not Mozilla's, not Google's, not even the W3C's. The web belongs to everyone who uses it and creates things for it.
+
+
+
+
+
+
+
+
+
+What Winer and others fear is that at some point browsers may stop loading HTTP content entirely. For now that's still a ways off, but Mozilla's plans make it clear that it is part of the future of Firefox. Mozilla's [FAQ](https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf) on the subject reads: "Q: Does this mean my unencrypted site will stop working? Not for a long time."
+
+While browsers ceasing to load HTTP sites at all is wrong, as Winer puts it "the browser is broken. It has totally the wrong idea of its role."
+
+
+
+
+
+
+The flip side to this is that if your site does serve up ads and you want to make sure that no one is stripping out those ads -- which, with companies like [Shine](https://www.getshine.com/), is starting to happen at the network level -- HTTPS is also your friend.
+
+
+Which brings us back to today. HTTPS is becoming more and more common, easier and easier for anyone to get up and running. Where does it go from here?
+
+
+
+
+
+HTTPS will, however, stop some of the mass surveillance that currently happens on the web. It will stop your ISP from injecting code to track you, it will stop unknown parties from using your browser to launch DDoS attacks as you browse and it stops ISP and nation states from censoring specific pages they don't like.
+
+
+
+
+In general, the pieces seems a little scattershot and could use a tighter focus. From our perspective, that HTTPS does not solve every problem is not an issue; that HTTPS is oftentimes *presented* as being synonymous with "security", however, *is* the issue. This seems like it should be the central thesis of the piece—that the meaning and importance of HTTPS has been poorly communicated by most advocates.
+
+Dan Goodin and Peter Bright had some further specifics about individual arguments within the piece or other larger questions if you’d like, but the following outline was suggested and I think it might be a good roadmap to recast your draft towards:
+
+* but it's not all good news
+* the (HTTP) legacy of the Web is important, so what are we doing to ensure that doesn't break, or disappear from search engines, or cause (technically spurious) warnings in our browsers. This strikes me as probably the most interesting issue to explore, especially as it has Tim Berners-Lee on its side.
+* calling HTTPS sites "secure" and non-HTTPS sites "insecure" is deeply dishonest (just because a site uses HTTPS doesn't mean it's not storing your password and credit card number in unauthenticated plaintext somewhere, and doesn't mean that it hasn't been hacked to serve malicious javascript, etc.). Browsers do not make clear that it is a statement about the connection *to* the site, and not the site itself. People are given advice like "don't send passwords to insecure sites"--how the hell would you even know?
+* HTTPS's protection is actually quite narrow (tbh it's not great against nation state adversaries due to the number of certificate authorities they control), though there are schemes in place to make it more powerful (HSTS, for example)
+* HTTPS is *still* burdensome and/or inconvenient (though Let's Encrypt is a good step in the right direction)
+* is this the kind of thing that google, in particular, should simply decree?
+
+With this in mind, would you be willing to take a second crack at the topic? I’d be happy to discuss the original draft with you further over the phone (or connect you with Dan or Peter if you’d like), but hopefully the outline above is clear and makes sense to you as a strong direction.
+
+In terms of a second draft, I understand this will take more than an afternoon. What if we said you could take ’til the end of March if necessary?
+If that sounds a bit weak to you, you're not alone. This is currently, the biggest problem with HTTPS.
+
+Behind the scenes what handles all the encryption and authentication is a bit of technology known as TLS, which is short for Transport Layer Security. In fact the full name of HTTPS is really HTTP over TLS. TLS is the successor to the now vulnerable Secure Sockets Layer (SSL), though to further complicate things you will often hear both referred to as "SSL". In the context of this article, HTTPS will refer to TLS connections.
+
+TLS is made up of two layers, the TLS Record Protocol and the TLS Handshake Protocol. Together these two tools allow your web browser to securely connect to a validated site and encrypt all your communications thereafter.
+
+
 Unused links:
 
 https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/