2015-01-24
Web applications and generating alerts due to HTTP requests
One of the consequences and corollaries of never trusting anything you get from the network is that you should think long and hard before you make your web application generate alerts based on anything in incoming HTTP requests. Because outside people can put nearly anything into HTTP requests and because the Internet is very big, it's very likely that sooner or later some joker will submit really crazy HTTP requests will all sorts of bad or malicious content. If you're alerting on this, well, you can wind up with a large pile of alerts (or with an annoying trickle of alerts that numbs you to them and to potential problems).
Since the Internet is very big and much of it doesn't give much of a damn about your complaints, 'alerts' about bad traffic from random bits of the Internet are unlikely to be actionable alerts. You can't get the traffic stopped by its source (although you can waste a lot of time trying) and if your web application is competently coded it shouldn't be vulnerable to these malicious requests anyways. So it's reporting that someone rattled the doorknobs (or tried to kick the door in); well, that happens all the time (ask any sysadmin with an exposed SSH port). It's still potentially useful to feed this information to a trend monitoring system, but 'HTTP request contains bad stuff' should not be an actual alert that goes to humans.
(However, if your web application is only exposed inside what is supposed to be a secured and controlled environment, bad traffic may well be an alert-worthy thing because it's something that's really never supposed to happen.)
A corollary to this is that web frameworks should not default to treating 'HTTP request contains bad stuff' as any sort of serious error that generates an alert. Serious errors are things like 'cannot connect to database' or 'I crashed'; 'HTTP request contains bad stuff' is merely a piece of information. Sadly there are frameworks that get this wrong. And yes, under normal circumstances a framework's defaults should be set for operation on the Internet, not in a captive internal network, because this is the safest and most conservative assumption (for a definition of 'safest' that is 'does not deluge people with pointless alerts').
(This implies that web frameworks should have a notion of different types or priorities of 'errors' and should differentiate what sort of things get what priorities. They should also document this stuff.)
2015-01-10
Autoplaying anything is a terrible decision, doubly so for video
Youtube's autoplay behavior makes me so angry. No no no augh wrong. What a way to rudely demand attention.
The single thing I hate the most about Youtube is that its videos start playing the moment you open one. On the one hand I can kind of see why Youtube does this; I'm sure they have plenty of user experience studies that tell them that without autoplay people dislike having to do an extra step to get what they came to Youtube for and that a certain amount of people don't realize what they need to click to get things working and wind up giving up. On the other hand it is a terrible decision in many situations and they should have a preference for it (using a long term cookie).
There are two problems with autoplay, especially of videos. The first problem is the general problem that autoplay assumes that browsing to a page means that you want to deal with the page right now. In a world where some number of people make heavy use of browser tabs and Youtube videos are often extremely non-urgent things, this is wrong; it's not unusual to open something in a tab and then ignore it for some time until you get around to it. Autoplay puts a stop to that by giving you no choice; you have to deal with the page right away, if only to shut it up.
(And of course autoplay stomps all over anything else you may be playing at the time you open the new tab in, theoretically, the background.)
The second problem is that autoplay of videos makes going to a Youtube page (or any such page) into what is essentially a globally synchronous operation for you. Since the video will start playing the moment it loads, you'll miss the start of the video if you're not paying attention to the page at the time. Want or need to look away briefly to something else while the page loads over a potentially congested link? Better be prepared to switch your attention back on a moment's notice or you'll be restarting the video so you can see the beginning. This is okay if all you have is a full-screen browser window that's going to a Youtube page (unless you look away from the computer entirely), but there are plenty of people in the world who are still using their multi-tasking computers to multi-task.
(Given Youtube ads, the real effect may be that you miss the start and perhaps all an insert ad. This is actually probably worse from Youtube's perspective, as eventually it will cost them revenue.)
PS: from my grumpiness about this, you might correctly conclude that the pile of hacks I use to stop autoplay has stopped working recently. In this case Youtube appears to have done something that broke Flashblock. It's a reported issue but who knows when this will be fixed, given prior issues with getting Flashblock updated, although there turns out to be a workaround.