11–20 of 96 posts
Basically they are destroying the simplicity of the internet in order to push their own agenda. I'd get annoyed about it, but it's not going to be long before it all collapses under it's own weight and something new and lightweight turns up to take over from what http used to be good for.
I wonder how many "internet of things" things will stop working due to these changes.
Aren't IOT typically servers not clients? I can't imagine their pages require access to powerful APIs.
Bizarre. HTTPS isn't a guarantee that a site is not malicious. Its not like I could go to a CA and ask them who they signed that cert for and take on any kind of legal responsiveness. Such is the state of the CA system that they will give a cert to anyone with access to a domains MX and some bitcoins. Instead of this, maybe require there's a user mouse event on the call stack for things like fullscreen.
What if a service streams video, which requires full screen feature? It takes quite a bit more compute power to pack it into encrypted connection, and what if the video is not of any value as a secure content. Why should people be forced to encrypt and decrypt spending extra power (battery, in case of portable devices) on it?
SSL does not guarantee the security de-facto. Also, there is plenty of personal data that is being passed through a non-encrypted connection, which is way more valuable. If this is an attempt to increase amount of secure connections, it is a very inconvenient one. Why not keep giving bonus point for using it (like SEO higher ranking) rather than making pure HTTP not usable.
Basically they are destroying the simplicity of the internet in order to push their own agenda. I'd get annoyed about it, but it's not going to be long before it all collapses under it's own weight and something new and lightweight turns up to take over from what http used to be good for.
I don't understand your criticism. They are requiring HTTPS to use complex/advanced features. You're still free to serve your handwritten HTML 4.0 over unencrypted HTTP 1.1. What simplicity is being destroyed here? If anything, they're making it more costly to make complex websites.
For the rest of us who need tools to watch HTTP 1.1 this changes nothing.
Though only tangentially related I do wish EME had been properly shot in the head. It's just another Flash that hides behind being "html5" (as if they makes it all ok). At the end of the day it's proprietary code executing on my machine that I have little or no control over. It's not just a security risk, it's also a stability concern and generally a terrible idea. Copyright enforcement should be left to law, content…
What is going to be the protocol for development environment? Should one deal with ssl just to quickly test out the code? What if a service streams video, which requires full screen feature? It takes quite a bit more compute power to pack it into encrypted connection, and what if the video is not of any value as a secure content. Why should people be forced to encrypt and decrypt spending extra power (battery, in cas…
Because otherwise a MITM can abuse the fullscreen feature. SSL is a way of ensuring content integrity, not just privacy.
I do think we should have a way of signing content without mandating encryption for these use cases, but until we do, HTTPS is the only choice.
Once Let's Ecrypt [0] launches, I suppose most web developers won't have any more excuses not to use HTTPS. It'll be free, pretty easy and quick time wise, plus it'll give you an SEO boost. Browser vendors are certainly doing the right thing by making http be marked as non-secure, and not implementing unencrypted http/2 and not allowing non-HTTPS access to powerful api are completely reasonable steps to take. [0] htt…
If everybody gets an SEO boost, there is no boost. :)
Once Let's Ecrypt [0] launches, I suppose most web developers won't have any more excuses not to use HTTPS. It'll be free, pretty easy and quick time wise, plus it'll give you an SEO boost. Browser vendors are certainly doing the right thing by making http be marked as non-secure, and not implementing unencrypted http/2 and not allowing non-HTTPS access to powerful api are completely reasonable steps to take. [0] htt…
If everybody gets an SEO boost, there is no boost. :)
For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.
And it's not like there aren't already strong enough protections in place. Try for example visiting this mock attack site:
http://feross.org/html5-fullscreen-api-attack/
In every browser I tried it was already obviously fake. It doesn't work already with current security tech:
1) browsers ask for fullscreen permission (with big unmissable dialogs)
2) emulated fake layout is very different from real layout (missing all per-user specific browser settings, e.g. bookmarks or extension buttons or any theme customizations, also font rendering looks different)
3) emulated fake browser UI doesn't respond to interactions in the same way as native UI