Ilia Alshanetsky points out that AddHandler is the wrong directive to use for executable file types like PHP, because Apache could execute the file bad.php.jpeg (I haven’t tested this yet, but plan to).
The safer directive is apparently AddType:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
You would think that if your browser doesn’t support playing audio/mp3 content using an html5 <audio> tag, it would do the right thing and fall back to the fallback markup under it.
Consider the following html5 markup:
<audio controller=”controller”>
<source src=”sound.mp3” type=”audio/mp3”>
<a href=”sound.mp3”>Click here to play audio</a>
</audio>
I’m just getting started with html5, but it seems to me that a browser should embed an audio controller if sources of type audio/mp3 are supported, and fall back to the link if not.
Firefox (which doesn’t support mp3) embeds the controller, but shows a big red X because it can’t play the file.
So I ask you, internets, am I misinterpreting the standard?
One of my colleagues likes to use port 6667 for his development environment. As in, when he tests his code, he connects to a url like https://dev.example.org:6667/
He recently noticed that Safari and Google Chrome restrict access to that port. Apparently when you allow a browser to connect to arbitrary ports, an attacker can craft a form that will submit arbitrary data to any port. I mean, duh, right? That’s why internet services should require authentication, something we’ve known since the 90s. But Mozilla’s page on the topic gives the example of submitting email directly to a mail server behind your firewall, which is apparently a problem for someone, somewhere. So they block a bunch of ports in the browser.
Since you can’t disable the port restrictions in WebKit (like you can in Firefox), developers should know what ports are blocked so that they don’t try to put web services on them. You can find the full list of restricted ports in Safari by looking at the WebKit source code file KURL.cpp. Search for “blockedPortsList”. It’s currently at line 1705 but that will change.
Looks like my colleague will need to pick a new favorite port number, like 5234 or something.
IEEE Spectrum explores Eight [Present and Future] Technologies for Drinkable Seawater. Portfolios like this are why I subscribe to Spectrum. Way to scratch that infrastructure nerd itch!
I especially like the idea of the microbial fuel cell, which takes advantage of excess electrons generated by contaminant-eating bacteria.
I mean, whoa. Contaminant-eating bacteria that generate electricity. I think we have a replacement dream technology for flying cars in the 21st Century!
This is rocking my world:
<input type="file" name="upload[]" multiple="true">
It does exactly what you think it does, allowing a single file input to upload multiple files in one request, without js or flash.
Available today in Firefox, Safari, and Chrome. Thank you!
In Chrome Phishing, Robert Hanson blows the lid off the “Google knows what it’s doing so Chrome is secure” idea. He argues that Chrome has a long way to go before it’s a mature browser, free of easily-exploitable holes.
Remember the old username-looks-like-web-site-in-the-url trick? http://gmail.google.com@evil.net/ is an example.
Try it in Chrome. Now try it in Firefox. Security is hard, even for Google.
