• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle


  • In other posts, I’ve tried to point out how some of the articles and comments around WEI are more speculative than factual and received downvotes and accusations of boot-licking for it. Welcome to the club, I guess.

    The speculation isn’t baseless, but I’m concerned about the lack of accurate information about WEI in its current form. If the majority of people believe WEI is immediately capable of enforcing web page integrity, share that incorrect fact around, and incite others, it’s going to create a very good excuse for dismissing all dissenting feedback of WEI as FUD. The first post linking to the GitHub repository brought in so many pissed off/uninformed people that the authors of the proposal actually locked the repo issues, preventing anyone else from voicing their concerns or providing examples of how implementing the specification could have unintended or negative consequences.

    Furthermore, by highlighting the DRM and anti-adblock aspect of WEI, it’s failing to give proper attention to many of the other valid concerns like:

    • Discrimination against older hardware/software that doesn’t support system-level environment integrity enforcement (i.e. Secure Boot)
    • The ability for WEI to be used to discriminate between browsers and provide poor (or no) service to browsers not created by specific corporations.
    • The possibility of WEI being used in a way to force usage of browsers provided by hostile vendors
    • The ability for it to be used to lock out self-built browsers or forked browsers.
    • The potential for a lack in diversity of attesters allowing for a cartel of attesters to refuse validation for browsers they dislike.

    I very well could be wrong, but I think our (the public) opinions would have held more weight if they were presented in a rational, informed, and objective manner. Talking to software engineers as people generally goes down better than treating them like emotionless cogs in the corporate machine, you know?





  • 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.


  • 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.