When he was working on the Netscape browser, Marc Andreessen famously joked that the browser would reduce the operating system to a poorly-debugged set of device drivers. And over the years, browsers have indeed gained more and more of the features of an OS -- and more and more access to your devices.
That's great when it means you can use a browser with WebMIDI to control a synthesizer, downloading new samples from the cloud whenever you want a new sound to play with. You want YouTube to be able to play sound to your speakers and you want Google Hangouts to be able to turn on your camera when you join a meeting. You want webmail to be able to save a file to a USB stick plugged into your PC, and you want Skype in the browser to work with your webcam.
But do you want a web page to be able to change what's in your clipboard? Many news sites append their URL to text you copy, so that if you paste it into Facebook there's a link back to the page.
It's a bit more dangerous when you copy a command off a website when you're looking for help fixing your computer, and the characters you select and copy in the browser aren't the ones that you paste into the command line. It's not a new problem -- back in 2008, people nicknamed the idea WYSINWYC: What You See Is Not What You Copy.
How about your phone turning on its microphone to listen for an 'inaudible' tone in a TV ad or on a website, so a website or an app on your device can know you've seen the advert? That's a rather intrusive form of tracking that SilverPush tried to introduce a couple of years ago with its Unique Audio Beacon SDK.
The idea was that you'd be tagged with a profile showing where you watched the ad and how long you watched before you changed the channel, as well as what kind of phone you use. SilverPush wanted to do cross-device tracking via the web: when you visited a website with ads that used its service, not only would you get the usual tracking cookie, but it would also play a unique, inaudible sound that a SilverPush-enabled app on your phone could hear -- letting the service know about both your devices.
Ad networks would love to know what ads to show you on TV based on what you've been looking for online, as well when you looked at an ad on one device and bought the product on another.
This all raises some interesting questions about what apps and websites should be able to do on our devices, and what our web browser should protect us from.
Just as your phone shows when you're using location services with a little icon at the top of the screen, and apps and websites have to ask before they can use your location, the Web Audio specification says that once the spec covers audio input (it doesn't yet), websites will have to ask to turn on your microphone.
What about sound? Should apps and sites also have to ask before they play inaudible sounds -- whether infra or ultrasonics -- bearing in mind that infrasonics can affect your mood and even your health?
The WebAudio spec also notes that the audio hardware sample rate and timing information could be used to create a unique fingerprint that would identify your device. Firefox 52 blocked websites from using its own battery status API because it could be used to track devices in a similar way. The W3C version of the battery status API says that browsers shouldn't give out detailed enough information to identify you but like the microphone warning, that sections is also 'non-normative', which means it's up to the companies writing the browsers.
The Tor browser (and some recent nightly builds of Firefox that the Tor browser is based on) warn you if a website is rendering content on a hidden canvas element; that might just be part of the site's UI, but it could also be a way of fingerprinting your device -- something that Tor users will be particularly concerned about.
Hackers can use the timers that sites use to measure their browser performance not just to fingerprint individual devices, but also to get information out of the browser sandbox; the performance.now W3C timer standard was updated recently to try and prevent these attacks but there are plenty of ways to use timers to get information out of browsers.
The HTML5 Vibration API could help sites fingerprint your device, by vibrating it and checking how precisely the accelerometer detects that -- or make someone stand out in a crowd by making their phone buzz.
Want to get users to download malware? A website giving you a fake security warning that you need to click to dismiss is much more believable if it can make your phone buzz the way other notifications do, so it could trick you into clicking something you shouldn't. That's why the spec says your browser has to tell you about sites that use the API and let you turn it off.
The more features like this the browser gets, the better web apps can be. But equally, the more powerful the browser get, the more responsibility it has to take for being a platform the way an operating system is.
Download now: Intrusion detection policy (free PDF)
With an OS, you choose what code runs by choosing what apps and software to install. With a browser, you do it by choosing what websites to visit -- but most users don't think of websites as running code at all, just text, pictures, and videos. That means the browser needs to work a little harder protect us from anything we might come across -- because unlike in the days of Flash, you can't choose to turn those features off by turning off the plugin that provides them.
So, along with all the new features for developers, browsers need to add more options for users to understand and control what sites (and the upcoming flood of Progressive Web apps that the latest browser standards will unleash) get to do on our computers.
Browsers are starting to limit more powerful features to sites that use HTTPS. Depending on which browser you use, location, local data storage, WebVR, webcam and microphone access, using Bluetooth, displaying notifications, changing device orientation, or making the browser full screen will only work on sites that have the HTTPS 'secure contexts'.
There's a confusingly different selection of features protected in different browsers. Chrome has been suggesting this direction for a while and has the longest list of exceptions, while Firefox and Edge protect slightly different subsets like Service Workers, trackable links and payment APIs. Mozilla recently announced that new web features in Firefox, like NFC access, will only be available in secure contexts and the W3C Technical Architecture Group might be about to add that approach to its collection of design principles.
That could have an impact fairly quickly. The Chrome team tried to deprecate the Application Cache feature in 2016 unless you're looking at a page in a secure context (in case you load a malicious page on an insecure network and get the same malicious page out of the cache even on a secure network later), although wasn't able to make that the default. The WHATWG HTML standard actually says this feature is officially deprecated; now Firefox 60 will have a preference users can set to block this caching in insecure contexts and by Firefox 62 that will be the default.
Secure contexts are important but HTTPS isn't a panacea; malicious sites can get a certificate too. And we need controls for browser features that aren't going to be restricted to secure contexts.
Windows lets you see which apps you allow to see your location all in one place (with a slider to turn that on and off for each app) and mobile OSes show a lot of detail about what permissions apps have. For websites, the information is a lot more fragmented.
Ad and tracking blockers have become popular because malicious ads distribute malware and even mine cryptocurrency in your browser and so blockers give users more choice about what sites can do in the browser. They're probably used more commonly than the content controls in browsers, because those controls aren't automatic the way an ad blocker is -- you have to look for them.
Firefox and Chrome both show a list of permissions sites can have; Firefox has a fairly short list while in Chrome it covers everything from cookies and images to USB devices and PDF files, and as of Chrome 64 that will include sound -- so I'll finally get a list of which websites I've said can't play sound, and have that setting applied whenever I go to that site, not just to the tab I happen to have a site open in.
But while Chrome will also start giving users more control over autoplay videos, that's not going to be a specific permission you can turn on and off; instead it's based on whether the video has sound, whether I've played videos on that site before, and whether I've tapped or clicked on the site. So the video won't start as soon as I open a link from Twitter, just when I start scrolling down the page.
In both Firefox and Chrome, you have to open each section to see which sites have asked for that permission and whether you granted it. Edge has a unified list showing permissions like location and notification, but it's rather cryptic. If you let the site have the permissions it wanted, the site logo is in colour; if not it's a grey box -- and instead of sliders on the list, you have to open each site to change the permissions it has.
So if I want to see which websites I've allowed to use my microphone, with the option to turn them on and off, I can dig into the browser settings. Or I can click on the padlock icon in the address bar to see permissions for just the current site -- Chrome lets you make changes from there, Edge only lets you turn Flash on or off.
Granular controls like this are one approach -- but maybe it would be more useful to have a service that warns me which of those sites I shouldn't be trusting with my microphone and USB stick, or even makes the decision for me the way an ad blocker does.
If browsers want to be an OS, they're going to need the same anti-malware protection every operating system eventually needs.
Maybe the controls should even be shared with the OS; after all, if I don't want Twitter to know my location, why should I have to turn it off for the app and the site separately? With the number of threats and annoyances facing users on a daily basis, we need it to be easier to take back more control, in apps and on websites.
This isn't just about the individual permissions sites can ask for or how easy it is to turn those off. It's about whether web browsers are there to give developers more and more options for building powerful sites, whether they're there to make using the web easier and safer for the user and to protect them against mistakes and malicious sites -- or to strike a balance between what they offer developers and users. And that's the same balancing act operating systems have been performing all along.
Recent and related coverage
Tenta DNS, an open-source DNS over TLS resolver, will help preserve users' privacy after the fall of net neutrality.
This simple advice will help to protect you against hackers and government surveillance.
If you assume your browsing is private and secure, think again. Jack Wallen offers up what he believes is your best bet to safeguard your browsing sessions and data.
Microsoft's Sonar checks accessibility, interoperability, performance, Progressive Web Apps, and security.
Stop the most aggravating ways of websites.