Unless something changed in the specification since I read it last, the attested environment payload only contains minimal information. The only information the browser is required to send about the environment is that: this browser is {{the browser ID}}, and it is not being used by a bot (e.g. headless Chrome) or automated process.

Depending on how pedantic people want to be about the definition of DRM, that makes it both DRM and not DRM. It’s DRM in the sense that it’s “technology to control access to copyrighted material” by blocking bots. But, it’s not DRM in the sense that it “enables copyright holders and content creators to manage what users can do with their content.”

It’s the latter definition that people colloquially know DRM as being. When they’re thinking about DRM and its user-hostility, they’re thinking about things like Denuvo, HDCP, always-online requirements, and soforth. Technologies that restrict how a user interacts with content after they download/buy it.

Calling web environment integrity “DRM” is at best being pedantic to a definition that the average person doesn’t use, and at worst, trying to alarm/incite/anger readers by describing it using an emotionally-charged term. As it stands right now, once someone is granted access to content gated behind web environment integrity, they’re free to use it however they want. I can load a website that enforces WEI and run an adblocker to my heart’s content, and it can’t do anything to stop that once it serves me the page. It can’t tell the browser to disable extensions, and it can’t enforce integrity of the DOM.

That’s not to say it’s harmless or can’t be turned into user-hostile DRM later, though. There’s a number of privacy, usability, ethical, and walled-garden-ecosystem concerns with it right now. If it ever gets to widespread implementation and use, they could later amend it to require sending an extra field that says “user has an adblocker installed”. With that knowledge, a website could refuse to serve me the page—and that would be restricing how I use the content in the sense that my options then become their way (with disabled extensions and/or an unmodified DOM) or the highway.

The whole concept of web environment integrity is still dubious and reeks of ulterior motives, but my belief is that calling it “DRM” undermines efforts to push back against it. If the whole point of its creation is to lead way to future DRM efforts (as the latter definition), having a crowd of people raising pitchforks over something they incorrectly claim it does it just gives proponents of WEI an excuse to say “the users don’t know what they’re talking about” and ignore our feedback as being mob mentality. Feedback pointing out current problems and properly articulating future concerns is a lot harder to sweep under the rug.

Thank you for making an informative and non-alarmist website around the topic of Web Environment Integrity.

I’ve seen (and being downvoted for arguing against) so many articles, posts, and comments taking a sensationalized approach to the discussion around it, and it’s nice to finally see some genuine and wholly factual coverage of it.

I really can’t understate how much I appreciate your efforts towards ethical reporting here. You guys don’t use alarm words like “DRM,” and you went through the effort of actually explaining both what WEI does and how it poses a risk for the open web. Nothing clickybaity, ragebaity, and you don’t frame it dishonesty. Just a good, objective description of what it is in its current form and how that could be changed to everything people are worried about.

Is there anything that someone like me could help contribute with? It seems like our goals (informing users without inciting them, so they can create useful feedback without FUD and misinformation) align, and I’d love to help out any way I can. I read the (at the time incomplete) specs and explainer for WEI, and I could probably write a couple of paragraphs going over what they promised or omitted. If you check my post history, I also have a couple of my own example of how the WEI spec could be abused to harm users.

Circular dependencies can be removed in almost every case by splitting out a large module into smaller ones and adding an interface or two.

In your bot example, you have a circular dependency where (for example) the bot needs to read messages, then run a command from a module, which then needs to send messages back.

    v-----------\
  bot    command_foo
    \-----------^

This can be solved by making a command conform to an interface, and shifting the responsibility of registering commands to the code that creates the bot instance.

    main <---
    ^        \
    |          \
    bot ---> command_foo

The bot module would expose the Bot class and a Command instance. The command_foo module would import Bot and export a class implementing Command.

The main function would import Bot and CommandFoo, and create an instance of the bot with CommandFoo registered:

// bot module
export interface Command {
    onRegister(bot: Bot, command: string);
    onCommand(user: User, message: string);
}

// command_foo module
import {Bot, Command} from "bot";
export class CommandFoo implements Command {
    private bot: Bot;

    onRegister(bot: Bot, command: string) {
        this.bot = bot;
    }

    onCommand(user: User, message: string) {
        this.bot.replyTo(user, "Bar.");
    }
}

// main
import {Bot} from "bot";
import {CommandFoo} from "command_foo";

let bot = new Bot();
bot.registerCommand("/foo", new CommandFoo());
bot.start();

It’s a few more lines of code, but it has no circular dependencies, reduced coupling, and more flexibility. It’s easier to write unit tests for, and users are free to extend it with whatever commands they want, without needing to modify the bot module to add them.

This may be an unpopular opinion, but I like some of the ideas behind functional programming.

An excellent example would be where you have a stream of data that you need to process. With streams, filters, maps, and (to a lesser extent) reduction functions, you’re encouraged to write maintainable code. As long as everything isn’t horribly coupled and lambdas are replaced with named functions, you end up with a nicely readable pipeline that describes what happens at each stage. Having a bunch of smaller functions is great for unit testing, too!

But in Java… yeah, no. Java, the JVM and Java bytecode is not optimized for that style of programming.

As far as the language itself goes, the lack of suffix functions hurts readability. If we have code to do some specific, common operation over streams, we’re stuck with nesting. For instance,

var result = sortAndSumEveryNthValue(2, 
                 data.stream()
                     .map(parseData)
                     .filter(ParsedData::isValid)
                     .map(ParsedData::getValue)
                )
                .map(value -> value / 2)
                ...

That would be much easier to read at a glance if we had a pipeline operator or something like Kotlin extension functions.

var result = data.stream()
                .map(parseData)
                .filter(ParsedData::isValid)
                .map(ParsedData::getValue)
                .sortAndSumEveryNthValue(2) // suffix form
                .map(value -> value / 2)
                ...

Even JavaScript added a pipeline operator to solve this kind of nesting problem.

And then we have the issues caused by the implementation of the language. Everything except primitives are an object, and only objects can be passed into generic functions.

Lambda functions? Short-lived instances of anonymous classes that implement some interface.

Generics over a primitive type (e.g. HashMap<Integer, String>)? Short-lived boxed primitives that automatically desugar to the primitive type.

If I wanted my functional code to be as fast as writing everything in an imperative style, I would have to trust that the JIT performs appropriate optimizations. Unfortunately, I don’t. There’s a lot that needs to be optimized:

• Inlining lambdas and small functions.
• Recognizing boxed primitives and replacing them with raw primitives.
• Escape analysis and avoiding heap memory allocations for temporary objects.
• Avoiding unnecessary copying by constructing object fields in-place.
• Converting the stream to a loop.

I’m sure some of those are implemented, but as far as benchmarks have shown, Streams are still slower in Java 17. That’s not to say that Java’s functional programming APIs should be avoided at all costs—that’s premature optimization. But in hot loops or places where performance is critical, they are not the optimal choice.

Outside of Java but still within the JVM ecosystem, Kotlin actually has the capability to inline functions passed to higher-order functions at compile time.

/rant