Having thought about it for a bit, it's possible for this proposal to be abused by authoritarian governments.

Suppose a government—say, Wadiya—mandated that all websites allowed on the Wadiyan Internet must ensure that visitors are using a list of verified browsers. This list is provided by the Wadiyan government, and includes: Wadiya On-Line, Wadiya Explorer, and WadiyaScape Navigator. All three of those browsers are developed in cooperation with the Wadiyan government.

Each of those browsers also happen to send a list of visited URLs to a Wadiyan government agency, and routinely scan the hard drive for material deemed "anti-social."

Because the attestations are cryptographically verified, citizens would not be able to fake the browser environment. They couldn't just download Firefox and install an extension to pretend to be Wadiya Explorer; they would actually have to install the spyware browser to be able to browse websites available on the Wadiyan Internet.

I went to one of their concerts, and their lead singer, David Draiman, was one of the most wholesome and honest guys I've ever seen. Funny headline, but I hope he recovers quickly and without any long-term effects.

Aw. I was going to post the link to his video, but you beat me to it.

But yeah, Technology Connections makes some excellent and informative videos. To anyone else who sees this: If heat pumps, refrigeration, or climate control technology aren't your cup of tea, he also covers older technology based around electromechanical designs (as in, pre-dating microcontrollers and programmable logic) and analog media recording devices.

I have a 7950X, a pile of RAM, and an unfairly expensive RTX 4000-series GPU. The cursor occasionally hitches for ~400ms whenever doing things like opening task manager or resuming from the lock screen, so that checks out unfortunately.

I hope you were being sarcastic, because, ideally, nobody implements this.

Good article. Not clickbait/ragebait, and it explains the specification simply and succinctly, while also demonstrating why it's dangerous for the open web.

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.

I glossed through some of the specifications, and it appears to be voluntary. In a way, it's similar to signing git commits: you create an image and chose to give provenance to (sign) it. If someone else edits the image, they can choose to keep the record going by signing the change with their identity. Different images can also be combined, and that would be noted down and signed as well.

So, suppose I see some image that claims to be an advertisement for "the world's cheapest car", a literal rectangle of sheet metal and wooden wheels. I could then inspect the image to try and figure out if that's a legitimate product by BestCars Ltd, or if someone was trolling/memeing. It turns out that the image was signed by LegitimateAdCompany, Inc and combined signed assets from BestCars, Ltd and StockPhotos, LLC. Seeing that all of those are legitimate businesses, the chain of provenance isn't broken, and BestCars being known to work with LegitimateAdCompany, I can be fairly confident that it's not a meme photo.

Now, with that being said...

It doesn't preclude scummy camera or phone manufacturers from generating identities unique their customers and/or hardware and signing photos without the user's consent. Thankfully, at least, it seems like you can just strip away all the provenance data by copy-pasting the raw pixel data into a new image using a program that doesn't support it (Paint?).

All bets are off if you publish or upload the photo first, though—a perceptual hash lookup could just link the image back to original one that does contain provenance data.

I suspect to get downvotes into oblivion for this, but there's nothing wrong with the concept of C2PA.

It's basically just Git commit signing, but for images. An organization (user) signs image data (a commit) with their public key, and other users can check that the image provenance (chain of signed commits) exists and the signing key is known to be owned by the organization (the signer's public key is trusted). It does signing of images created using multiple assets (merge commits), too.

All of this is opt-in, and you need a private key. No private key, no signing. You can also strip the provenance by just copying the raw pixels and saving it as a new image (copying the worktree and deleting .git).

A scummy manufacturer could automatically generate keys on a per-user basis and sign the images to "track" the creator, but C2PA doesn't make it any easier than just throwing a field in the EXIF or automatically uploading photos to some government-owned server.

Frankly, I don't trust that the end result won't hurt users. This kind of thing, allowing browser environments to be sent to websites, is ripe for abuse and is a slippery slope to a walled garden of "approved" browsers and devices.

That being said, the post title is misleading, and that was my whole reason to comment. It frames the proposal as a direct and intentional attack on users ability to locally modify the web pages served to them. I wouldn't have said anything if the post body made a reasonable attempt to objectively describe the proposal and explain why it would likely hurt users who install adblockers.

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.

But the real questions is, can we change them?

Imagine this:

• Good thing → Zelda chest opening sound.
• Bad thing →The Office "Oh, god, please no."
• User interaction → Honking goose.
• Log in → Futurama "Welcome to the world of tomorrow!"
• Log out →AOL "You've got mail"

You say that like it hasn't been happening already for two decades.

https://www.cnet.com/news/privacy/fbi-taps-cell-phone-mic-as-eavesdropping-tool/

I can't read French so I only have others' translations and intepretations to rely on, but from what I understand, the differences here are that,

1. France lawmakers are being direct with their legislation, rather than relying on precedence or judges' interpretations of anti-terrorism or national security bills; and

2. Privileged conversations (e.g. between client and attorney) can still be admissible when recorded surreptitiously this way.

Apparently it would still need to be pre-approved by a judge. That doesn't inspire much confidence in it not being hand-wave allowed, though.

Had to give up at rule 20 because I was using a phone.

::: spoiler Spoiler As much fun pain as that was, highlighting with a touch screen is nowhere near fast enough to put out the fire. :::

Would love to see a speedrun leaderboard for this, though.

I don't disagree with you. If this gets implemented, the end result is going to be a walled garden web that only accepts "trusted" browsers. That's the concern here for ad blocking: every website demanding a popular browser that just so happens to not support extensions.

My issue is with how the OP framed the post. The title is misleading and suggests that this is a direct attempt to DRM the web, when it's not. I wouldn't have said anything if the post was less sensationalized, laying out the details of the proposal and its long-term consequences in an objective and informative way.

Because I Got High by Afroman?

A couple years back, I had some fun proof-of-concepting the terrible UX of preventing password managers or pasting passwords.

It can get so much worse than just an alert() when right-clicking.

The codepen.

A small note: It doesn't work with mobile virtual keyboards, since they don't send keystrokes. Maybe that's a bug, or maybe it's a security feature ;)

But yeah, best tried with a laptop or desktop computer.

How it detects password managers:

• Unexpected CSS or DOM changes to the input element, such as an icon overlay for LastPass.

• Paste event listening.

• Right clicking.

• Detecting if more than one character is inserted or deleted at a time.

In hindsight, it could be even worse by using Object.defineProperty to check if the value property is manipulated or if setAttribute is called with the value attribute.

Would my government? Aladeen, 100%.
^If^ ^that^ ^doesn't^ ^make^ ^sense,^ ^it's^ ^a^ ^reference^ ^to^ ^a^ ^movie.^

I highly, highly recommend Prodigal. It's an absolute gem of a game if you're a fan of the Oracle games, and it's currently on sale too. It nailed the GBC art style and palette, and it has an interesting story full of mysteries.

There's also Beyond the Mountains, which is a passion project by a single developer. It's not as polished as one would hope, but it's free, and it's a fun game that can be completed in a couple of hours.

In my other comments, I did say that I don't trust this proposal either. I even edited the comment you're replying to to explain how the proposal could be used in a way to hurt adblockers.

My issue is strictly with how the original post is framed. It's using a sensationalized title, doesn't attempt to describe the proposal, and doesn't explain how the conclusion of "Google [...] [wants] to introduce DRM for web pages" follows the premise (the linked proposal).

I wouldn't be here commenting if the post had used a better title such as "Google proposing web standard for web browser verification: a slippery slope that may hurt adblockers and the open web," summarized the proposal, and explained the potential consequences of it being implemented.