Browsers restrict powerful APIs to HTTPS-only secure contexts AI-researched
Dependency: Geolocation, getUserMedia, Web Audio, and other browser APIs on HTTP
Starting with Chrome 50 in April 2016, browsers began restricting 'powerful' APIs — geolocation, camera/microphone, audio context, notifications — to HTTPS pages only. Net art hosted on HTTP servers lost access to location, webcam, and audio APIs.
Fixes & Mitigations
- Migration: Migrate hosting to HTTPS with a valid TLS certificate (free via Let's Encrypt). Requires active server access.
- No fix available: For archived or unmaintained art on HTTP servers, these APIs are permanently broken with no client-side workaround.
Starting with Chrome 50 (April 2016), browsers began requiring HTTPS (“secure context”) for access to powerful web APIs. The Geolocation API was first. Firefox 55 (August 2017) followed. Subsequently, getUserMedia (camera/microphone), AudioContext, Notification API, Service Workers, Web Bluetooth, Web MIDI, and more were all restricted to secure contexts.
What changed
Any net artwork hosted on an HTTP server that used geolocation, webcam input, microphone access, or the Web Audio API stopped functioning in modern browsers. The APIs simply return errors or are undefined on insecure pages.
This is particularly damaging because many historical net art sites are hosted on personal domains, university servers, or archived infrastructure that serves over HTTP. Adding HTTPS requires active server access and maintenance — exactly what abandoned art sites lack. Even works preserved by institutions may be served from HTTP archives.
Notes
The fix is technically simple (add a TLS certificate, available free from Let’s Encrypt), but requires someone with server access and motivation. For the class of art this most affects — experimental, small-scale, hosted on forgotten infrastructure — there is often no one.