Subject: General Tech | September 8, 2016 - 11:02 PM | Scott Michaud
Tagged: google, chrome, http, https
Many software vendors want to impose security and encryption basically everywhere. Google and Mozilla are two of the more vocal organizations about it, and they have been slowly implementing ways to discourage insecure HTTP (in favor of HTTPS). Some of these make sense, like preventing insecure sites from accessing your webcam so the video stream cannot be intercepted, while others seem a bit pushy, like lowering HTTP-based sites down in search results.
This announcement's change is technologically benign, but is designed to make HTTP feel a bit uncomfortable. Rather than just promote HTTPS sites with a secure padlock symbol, Google Chrome 56 and later will begin to add a “not secure” label to HTTP sites. At first, Google claims that it will only mark sites that transmit sensitive data, like passwords and credit card info. They intend to expand this to all HTTP websites going forward.
Again, this has pros and cons. The main benefit of encryption is that it's much harder to view or manipulate what flies across the data stream. One major disadvantage is that the content needs to be authenticated, which is a concern for truly anonymous expressions. Google Chrome treats local, offline content as secure, but that use case could be easily forgotten, and that could have terrible rammifications, especially in areas controlled by oppressive governments that massively censor art.
Subject: General Tech | April 14, 2015 - 08:08 PM | Scott Michaud
Tagged: mozilla, http, https, firefox
On the Mozilla Dev-Platform Newsgroup, hosted at Google Groups, a proposal to deprecate insecure HTTP is being discussed. The idea is that HTTPS needs to be adopted and organizations will not do it without being pushed. The plan is to get browser vendors to refuse activating new features, and eventually disable old features, unless the site is loaded as a “privileged context”.
This has sparked a debate, which was the whole point of course, about how secure do we want the Web to be. What features should we retroactively disable unless it is done through HTTPS? Things that access your webcam and microphone? Things that write to your hard drive? Then there is the question of how to handle self-signed certificates to get encryption without verification, and so forth.
Note: Websites cannot access or create files on your hard drive, but standards like localStorage and IndexedDB allow websites to have their own spaces for persistence. This is to allow, for instance, a 3D game to cache textures (and so forth) so you don't need to download them every time.
Personally, this concerns me greatly. I started helping Mozilla a couple of years ago, a few weeks after I saw Microsoft's Windows 8 developer certification program. I do not like the thought of someone being able to stifle creation and expression, and the web was looking like it might be the last bastion of unrestricted development for the general public.
In the original Windows Store requirements, no browser could exist unless it was a skin of Trident. This meant that, if a site didn't work in Internet Explorer, it didn't exist. If you didn't want to play by their rules? Your app didn't get signed and your developer certificate could even be revoked by Microsoft, or someone with authority over them. You could imagine the problems a LGBT-focused developer might have in certain countries, even if Microsoft likes their creations.
This is obviously not as bad as that. In the Windows Store case, there was one authority whereas HTTPS can be authenticated by numerous providers. Also, if self-signed certificates are deemed “secure enough”, it would likely avoid the problem. You would not need to ask one of a list of authorities permission to exist; you could secure the connection yourself. Of course, that is a barrier of skill for many, and that is its own concern.
So we'll see, but I hope that Mozilla will take these concerns as a top priority in their decisions.
Subject: General Tech | June 14, 2011 - 12:02 PM | Jeremy Hellstrom
Tagged: http, tcp, spdy, Internet
Google has been working on SPDY, a new protocol which is intended to speed up HTTP without forcing changes to existing websites or protocols. This application-layer protocol sits between HTTP and TCP, replacing neither instead translating for the application layer and the transport layer to optimize certain parts of the transaction. Specifically they hope to allow multiple connections over TCP, something that up until now is provided by a workaround in the browser which creates parallel connections as well as getting servers to push data to clients more effectively. They are also working to reduce latency by reducing the size of the headers that are transported which will be very important in the near future, not only as a way to speed up SSL connections but to help with the increased size of IPv6 headers.
Up until now SPDY has only been available for Chrome and even then only for certain Google sites which utilize the new translation protocol. Now Strangeloop is offering an online service as well as hardware which will allow you to implement SPDY without the need to change your website or host. The Register covers the long overdue change to TCP here.
"Strangeloop – a Vancouver-based outfit offering an online service for accelerating website load times – has embraced Google's SPDY project, a new application-layer protocol designed to significantly improve the speed of good ol' HTTP."
Here is some more Tech News from around the web:
- Intel: Chinese microprocessor development inefficient @ SemiAccurate
- Intel new server platform expected to start large replacement trend @ DigiTimes
- Games co Epic resets passwords after hack attack @ The Register
- Research @ Intel: The cloud's future is many-core and GPU accelerated @ Ars Technica
- Planar structure extends lifetime of memristor @ Nanotechweb
- Nikon COOLPIX S570 12MP Digital Camera Review @ ThinkComputers