obsessive facts blog

[TAGGED: vulnerability]
  1. The JavaScript Black Hole

    A playbook for ethical engineering on the web.

    In the 25 years since JavaScript was first added to Netscape Navigator, the language has evolved from a cute little toy to an integral part of the Internet. JavaScript frameworks such as React and Angular have transformed the web, bringing us fully-fledged client side applications with functionality that could only be imagined just a decade ago. In the process, the web has become more powerful, but also much more dangerous. Malware and mass surveillance have become persistent threats, fueled by the ever-expanding amounts of user data exposed by new JavaScript features, and sucked into the black hole of omnipresent tracking networks. With real human costs, these threats have been worsened by the increasingly popular belief that "the web browser is an operating system, and everything is an app."

    This essay is written for web developers and people interested in the field. In it, I break down the problems mentioned above, demonstrate some commonly-used JavaScript practices that can expose users to harm, provide examples of actual harm being done, and ultimately propose some actionable alternatives that we, as developers, can adopt to prioritize ethical engineering and minimize harm for our users, while still building feature rich applications.

    Read More

    Posted 2020-04-04 11:40:00 CST by henriquez. 50 comments
  2. Chrome allows silent enumeration of USB devices

    User consent is baked into the spec, but Google skips it.

    Via the Web MIDI API, Google Chrome (up to at least version 70) allows silent monitoring of all connected USB MIDI devices, such as MIDI keyboards and audio interfaces. While this enables interesting web applications such as software synthesizers, it also provides a new vector for shady ad networks and malicious actors to do very precise device fingerprinting and tracking. The API is trivial to access; for example run this in a JavaScript console:

    navigator.requestMIDIAccess({sysex: false})
            function(midiAccess) {
                for (var entry of midiAccess.inputs) {
                    var input = entry[1];
                    console.log('Found device: ', input.manufacturer, input.name);
            function() { console.log('Error: no MIDI access'); }

    Assuming you have MIDI devices connected, this will output something like:

    MIDIAccess {inputs: MIDIInputMap, outputs: MIDIOutputMap, sysexEnabled: false, onstatechange: null}
    Found device:  Microsoft Corporation 3- UA-25EX
    Found device:  Midiman MIDIIN3 (Axiom Pro 61)
    Found device:  Midiman MIDIIN4 (Axiom Pro 61)

    From here, it's possible to listen for inputs on all connected MIDI devices (aka a MIDI keylogger!)

    Again, while Google most likely had noble intentions in providing this API, their implementation is half-assed. The Web MIDI Specification provides for a user consent step, similar to the confirmation dialogs that pop up around webcam access or push notifications, but Chrome skips over this and grants permission as soon as a script asks for it.

    Privacy implications

    On its face, the impact of allowing scripts to silently dump a list of USB MIDI devices seems minor—only a very small percentage of users will have MIDI keyboards or audio interfaces hooked up. But counterinuitively, this increases the privacy impact: because the number of users is small, Chrome's implementation of the Web MIDI API provides a new vector for very precise device fingerprinting.

    The Electronic Frontier Foundation (EFF) has a great write-up and demonstration of device fingerprinting techniques via their Panopticlick Project:

    When you visit a website, you are allowing that site to access a lot of information about your computer's configuration. Combined, this information can create a kind of fingerprint — a signature that could be used to identify you and your computer. Some companies use this technology to try to identify individual computers.

    To my knowledge, I don't believe EFF or anyone else has researched the impact of Web MIDI device leakage in the context of device fingerprinting. In practice, it seems like this could enable precise tracking of creative individuals in a manner that couldn't be blocked without disabling JavaScript entirely.

    Google can easily fix this!

    Again, the Web MIDI API provides a specification for user consent, and Google Chrome already has generic UI components to display user confirmation dialog prompts. It should be simple for them to implement a consent prompt and prevent malicious scripts from scooping up peoples' connected MIDI devices. While Google has a perverse incentive as the world's biggest advertiser to make it easier to track their users, again I believe the Chrome team had good intentions in setting up this API. They just did a bad job, and they should fix it.

    Posted 2018-10-20 12:14:00 PST by henriquez. Comments