Hey everyone, thank you for your patience, and thank you to everyone who engaged constructively. It is clear based on the feedback we’ve received that a bigger discussion needs to take place, and I’m not sure my personal repository is the best place to do that - we are looking for a better forum and will update when we have found one. We want to continue the discussion and collaborate to address your core concerns in an improved explainer.

I want to be transparent about the perceived silence from my end. In the W3C process it is common for individuals to put forth early proposals for new web standards, and host them in a team member’s personal repository while pursuing adoption within a standards body. My first impulse was to jump in with more information as soon as possible - but our team wanted to take in all the feedback, and be thorough in our response.

That being said, I did want to take a moment to clarify the problems our team is trying to solve that exist on the web today and point out key details of this early stage proposal that may have been missed.

WEI’s goal is to make the web more private and safe The WEI experiment is part of a larger goal to keep the web safe and open while discouraging cross-site tracking and lessening the reliance on fingerprinting for combating fraud and abuse. Fraud detection and mitigation techniques often rely heavily on analyzing unique client behavior over time for anomalies, which involves large collection of client data from both human users and suspected automated clients.

Privacy features like user-agent reduction, IP reduction, preventing cross-site storage, and fingerprint randomization make it more difficult to distinguish or reidentify individual clients, which is great for privacy, but makes fighting fraud more difficult. This matters to users because making the web more private without providing new APIs to developers could lead to websites adding more:

sign-in gates to access basic content invasive user fingerprinting, which is less transparent to users and more difficult to control excessive challenges (SMS verification, captchas) All of these options are detrimental to a user’s web browsing experience, either by increasing browsing friction or significantly reducing privacy.

We believe this is a tough problem to solve, but a very important one that we will continue to work on. We will continue to design, discuss, and debate in public.

WEI is not designed to single out browsers or extensions Our intention for web environment integrity is to provide browsers with an alternative to the above checks and make it easier for users to block invasive fingerprinting without breaking safety mechanisms. The objective of WEI is to provide a signal that a device can be trusted, not to share data or signals about the browser on the device.

Maintaining users’ access to an open web on all platforms is a critical aspect of the proposal. It is an explicit goal that user agents can browse the web without this proposal, which means we want the user to remain free to modify their browser, install extensions, use Dev tools, and importantly, continue to use accessibility features.

WEI prevents ecosystem lock-in through hold-backs We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported.

This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior.

Additionally, and this could be clarified in the explainer more, WEI is an opportunity for developers to use hardware-backed attestation as alternatives to captchas and other privacy-invasive integrity checks.

WEI does not disadvantage browsers that spoof their identity The hold-back and the lack of browser identification in the response provides cover to browsers that spoof their user agents that might otherwise be treated differently by sites. This also includes custom forks of Chromium that web developers create.

Let’s work together on finding the right path We acknowledge facilitating an ecosystem that is open, private, and safe at the same time is a difficult problem, especially when working on the scale and complexity of the web. We welcome collaboration on a solution for scaled anti-abuse that respects user privacy, while maintaining the open nature of the web.

  • FlickOfTheBean@beehaw.org
    link
    fedilink
    arrow-up
    19
    ·
    1 year ago

    Probably when “I use ie to download chrome” became a mainstream meme.

    Unfortunately this is a money-ocracy (data-exploitation-ocracy), not a democracy.

      • lloram239@feddit.de
        link
        fedilink
        arrow-up
        12
        ·
        1 year ago

        Chrome was way faster than anything else out there. Back when Chrome was new, Firefox would regularly freeze the whole browser when one Tab got a little busy. Chrome fixed that by using multi processes for the Tabs and Firefox took years to catch up. Only recently everybody is more or less on the same level again, but that’s largely because everybody outside of Firefox is just a repackaged Chrome.

      • FlickOfTheBean@beehaw.org
        link
        fedilink
        arrow-up
        11
        ·
        1 year ago

        I do web dev and I can say I was super guilty of this back in the 2010s. I bit the hype hard, and now we’re getting right back to the circumstances that made ie such a POS to work with. (In my defense, I got my dev job in 2013 and had to develop for ie6. It’s not a good defense, but I think that really lead to my overhype for google. I had no knowledge of chrome’s bloated whale carcass days, so it always felt like the browser that “just worked ™”)

        Market monopoly inspires evil in the good intentioned. Market monopoly also inspires nefariousness in the evil.

        I’d say this is the sort of thing that inspired Google to remove the “don’t be evil” from their guidelines.

        • StudioLE@programming.dev
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          You must mean ie7, surely?

          I was developing for ie6 back in 2010 and I considered those to be dark, dark times. I can’t believe it hung on for another 3 years?

          • FlickOfTheBean@beehaw.org
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            We had some demanding clients lol

            I remember having to use pie.htc to hack rounded corners for buttons into ie6. I remember liking ie7 a little bit better, but ie8 felt like a god send compared to 6 lmao

            I recall having to support multiple versions of ie as well at the same time as well. I can’t remember what year we dropped support for ie6 but it wasn’t too long after I started.

            I danced every time we got to drop another ie support version all the way up to 11