Are Web Pages Still Safe?
The relentless addition of cool features in HTML5 is getting a lot of web developers excited and there’s really no doubt that it will be a huge step forward for the web. The more I follow the WhatWG mailing list though, the more I think we’re long past the era where it was considered safe to visit web pages. I’m not talking about browser security holes which have been around for a fair while and certainly do pose a risk, I’m talking about the things that are actually by design.
There’s nothing seriously threatening, just an ongoing increase in the amount of power and the amount of knowledge that web pages get. For example, it used to be possible to store a tiny amount of data in cookies in a way that was considered transient and ok to delete at anytime. Now you can store up to 5MB and there’s a strong argument being made that it should be considered user critical data and not easily cleared like cookies. In another thread people are asking for notification when the user has been idle for a period of time – great for chat applications and the like, but expanding what web pages can track about you1.
In my mind there’s a mental model of how dangerous things that’s something like:
Static data is like an jpeg image or a plain text file. You read it but it doesn’t do anything active – no scripting nothing dynamic at all. It could still trigger a buffer overflow or some other security hole in the software you’re using but otherwise it’s inert.
Active data is like a web page with some simple JavaScript that modifies the page.
Sandboxed Applications are like iPhone applications. In theory they should be contained and safe, but you should still think carefully before installing them because they’re real applications that while limited can do actual damage. On the iPhone that actual damage involves unrestricted access to all your contacts and the network among other things.
Applications are pretty obviously anything else. While most systems these days put restrictions on them in some way such as file permissions, they are essentially unrestricted.
The web started out as static data, then when JavaScript was invented became active data. When GMail came along and people worked out how to really leverage JavaScript it moved to somewhere between active data and a sandboxed application2. People want to build real applications on the web, which essentially means they need to keep being pushed along that progression. The only problem is that as you increase the abilities of web pages, you also decrease the safety, not just because it’s a bigger attack surface, but ultimately because the more a web app can do, the more likely it is that you want to have control over it.
I’m left wondering if it’s possible to create a UI that lets users choose exactly what applications can do, without either confusing them or much worse, bombarding them with permission dialogs. Flash certainly failed miserably at it – if you ever turn off local storage in flash and try to browse the web, you’ll find it almost impossible to use most flash programs because they just repeatedly ask for permission to store data. Facebook and most other web apps that allow third party access fail at it too – if you install a Facebook app it gets access to pretty much everything. I’m sure in theory and maybe even in practice they could have more fine-grained permissions but the UI never makes them obvious and I’m not sure it could.
The plus side of all this, is that so far the main issue is really that users are losing their privacy, but as web apps want to do things like monitor folders for new files or any of the other niceties that desktop applications can take advantage of3, it’s going to become more and more of an issue. How are we going to ensure that clicking a link is still safe?
1 – Currently they can only tell if you are using your browser or not, if you switch to another application they can’t tell if you walk away from your computer or if you’re busily using a different application.↩
2 – Depending on the plugins you have installed and if you approve special rights it could be completely unrestricted of course. ActiveX made a mess of that model, causing major security problems in Internet Explorer and has since been put behind a lot of scary warning/approval processes.↩
3 – and the Chrome OS is certainly going to be pushing the envelope very quickly in this area↩
September 7th, 2009 at 11:14 am
I think the only thing that can help here is a fine grained permission model, with browsers (and other apps) supporting profiles. E.g. an app can ask to access the network and your cookies in one profile, and/or the file system in another, higher level profile, and another one would allow access to hardware (think webcams and accelerated graphics).
We need to move away from the “give this app all permissions” to a “give this app certain well known, restricted permissions”.
September 7th, 2009 at 11:25 am
Yes and no. Fine grained permissions are great, except that they’re very hard for most users to understand and take a lot of time to manage. They tend to result in the user being pestered by a lot of security dialogs. For almost all cases, you probably only need a few trust levels:
Random site on the internet – todays restrictions or even tighter. You probably should discard cookies after a few days for example.
– As a sub-category, browsers might automatically take note of commonly accessed sites and not flush cookies if that extra restriction did come in.
Sandboxed – where the HTML5 spec seems to be heading. Allow a reasonable amount of local storage and treat it as critical user data, but still restricted so it can’t interact with the rest of the OS or the file system.
Full web app – like installing a desktop application but it runs in the browser. The install process should be like installing a desktop application too – more like an installer than just a permission dialog.
The key is to put a good UI around all of this that is obvious to users so they discover it (unlike IE’s current security zones) but doesn’t involve popup permission dialogs. There may be even more finegrained permissions enabled as well (via a “Custom” option or similar) but I suspect we need a short list of things to allow so users can understand it.
September 7th, 2009 at 11:55 am
I totally agree. Fine grained permissions will not work, that is what I meant with “Profiles”. And this is indeed a UI problem – I once read a study on how many users actually read message/permission/… dialogs on Windows, it’s downright scary. At least on Windows, people are used to be bombarded with lots of meaningless dialogs, and are conditioned to just click a button without reading. If that doesn’t work, they repeat and click the other button, again without reading.
No idea how to fix that without some sort of popup though. Firefox’ 3 second timeout might be useful, or maybe a query that forces you to select a specific access level instead of just confirming whatever the app wants.
September 7th, 2009 at 12:12 pm
Ah, indeed your profiles do match what I was thinking, sorry missed that somehow. FireFox’s timeout drives me nuts since it makes me wait even when I know exactly what the dialog is telling me and don’t need to wait. For non-technical users I doubt it actually helps them to understand the dialog anyway. Profiles are likely to help here – asking “how much do you trust this site” is likely to mean more than asking if you want to install something.
The other way to help matters is for browser to have a way to act as if they’ve given many of the permissions but not actually do it. For example, local storage might accept data but only store it for the current session rather than permanently. That kind of approach would let sites continue to work even if the user didn’t want to grant them access, but it’s very difficult to get right.
I’m not sure there are any good answers to this problem – with malicious sites out there, you really need to force all sites to work with restricted functionality. If you then provide APIs they can take advantage of if the user takes action to allow it that’s a bonus. So local storage is not allowed by default and sites have to deal with that, but if the user enables it they can provide faster access or an option to not store content on their servers etc. Web developers obviously want to access all this functionality all the time and be able to depend on it, but that means the malicious sites can too.