Google does not care about the later and only wishes to make more money from the former. Google has a clear and blatant monopoly position over ad-based web monetization so most of the web will follow Google's will. We all need paychecks. The group of old farts who saw the world change are growing older and irrelevant.

I am extremely pessimistic about the future of "the (open) web" as the vehicle of our modern low-friction economy as these corporate gatekeepers (Google and Microsoft) are making such big wins recently.

Good luck out there. The World Wide Web (old school) and Old Fashioned HTTP+HTML are under grave threat from carpetbaggers.

It's actually a very interesting frontend platform to design for, because you don't get any Javascript support, but you get full modern CSS support.

I never thought I'd say this, but HTML4, with all its billions of warts, was a pinnacle of this vision. Later developments swung too hard towards an excessively content-focused vision first (XHTML, the "semantic web"), and then swung all the way in the opposite direction, turning web protocols into dumb pipes for the general-purpose VM runtime that modern JS/HTML engines have become.

Unfortunately, the industry always, always wanted this runtime. Plugins, applets, ActiveX -- people just refused to accept basic form-based interaction. DarkWeb properties accept it only because doing otherwise would be too dangerous, in the same way people don't wear jewelry when going through a ghetto.

I've been experimenting with DuckDuckGo's .onion site. Below is example of how to search the light web over Tor without Tor Browser.

I'm curious .onion sites because it sounds like .onion solves the reachability problem. Anyone could have a website. No requirement for reachable IP address from ISP. No requirement for domain name and hosting subscriptions. No commercial middlemen. (Assuming Tor network operators are true volunteers.) Not every website has to be commercial or reach large scale.

pts/1

    x=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
    socat -d -d -d tcp4-l:443,fork,reuseaddr,bind=127.0.0.42 socks4a:127.0.0.1:$x:443,socksport=9050 

     # Usage: echo query | $0 > 1.htm; 
              links -no-connect 1.htm;
              firefox ./1.htm;

     #!/bin/sh
     h=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
     read x;
     curl -v0dq="$x" --resolve $h:443:127.0.0.42 https://$h/lite/

     #!/bin/sh
     h=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
     read x;
     x=q=$(echo "$x"|yy046);
     export httpMethod=POST;
     export Content_Type=application/x-www-form-urlencoded;
     export Content_Length=${#x};
     export httpVersion=1.0;
     export Connection=close;
     echo https://$h/lite/|yy025|if sed w/dev/stderr;then 
      echo $x;echo $x >&2;fi \
     |socat stdio,ignoreeof ssl:127.0.0.42:443,verify=0

For example, when using Tor Browser to connect to regular public websites, your goal is usually just to obscure your connecting location, hide your traffic from your ISP, and punch through and firewalls between you and the destination, without first being required to establish a relationship with some specific proprietary VPN company (where doing so might not even be possible if you're in some countries.) So people doing this tend to be willing to enable JS, at least on a per-site basis.

It's only really when you're in the kind of trouble where state actors are trying to correlate your IP address through inadvertent connections you might make to state-owned-honeypot Tor hidden sites, that the full no-JS paranoia is warranted.

But, to vouchsafe the anonymity of those people, it's better for anti-fingerprinting if more people who are using Tor Browser for more mundane things, also have JS disabled. So Tor Browser disables JS by default.

Which means that it's pretty much a given that if you're doing web design specifically for a Tor hidden site, then you have to assume that people accessing your site will have JS disabled. (And that you can't just ask them to enable it — they'll say "nice try FBI" and close the tab.)

We'll build our own internet! With blackjack and hookers!

More seriously, I see echoes of the gentrification cycle. At the end of the cycle nobody wants to live in the soulless corporate hellscape they've helped create, so they follow the cool kids to the next up-and-coming neighbourhood. It works for social media sites, so why not for an entire protocol?

If you can figure out a protocol where ads don't work, I'm in.

Is it even theoretically possible to create such a protocol? Preventing tracking is feasible, but telling apart ads from real content does not sound solvable on a protocol level.

I believe that wherever we go, marketers will follow us. But wouldn't it be great if I was wrong...

The only hope is anti-trust breakup of Google. Chrome has to be pried forcefully from their hands.

We should launch massive campaigns not just in the US, but also Europe and other critical markets.

We shouldn't back down even if they abandon WEI. They'll just keep trying as they have with AMP, Manifest v2, WHATWG [1], etc.

Google can never be allowed to build browser tech so long as they control search.

The web must remain open.

[1] WHATWG took unilateral control over the HTML spec. They abandoned the Semantic Web, which had led to RSS, Atom, etc., and would allow documents to expose information you could scrape and index without Google Search. Google wanted documents to remain forgiving and easy to author (but messy, without standard semantics, and hard to scrape info from)

Mozilla is barely able to fund itself, and a big chunk of that funding comes from Google. Surely Google is careful to avoid any overt impropriety with that relationship, since they don't want to come under more regulator scrutiny. But why would a Chrome, Inc. care about that sort of thing? They'd take the same money from Google Search, Inc. that Mozilla does to keep Google as its default search engine. They'd still happily implement WEI and other garbage that Google Ads, Inc. wants, and Google Productivity, Inc. would still ensure that Docs, Sheets, Drive, etc. are all super-compatible with Chrome (and work with the Chrome team to ensure that's the case), and not care so much about other browsers.

I have no doubt that things would be better if we were to break up big conglomerated companies like this, but I'm not entirely sure that breaking up Google would achieve the goal of helping the web remain open.

I want to see it; I don't know the path there.

Sure. It's really just a matter of mass appeal. We could fork the existing browser base and eliminate the new attestation API. Some projects are already doing this from what I understand.

What will keep attestation from being used is websites will lose business if their customers can't access the site. We went through this with user-agent string checking in the 90's/00's when IE and Netscape/Mozilla were at war and every site had a very strong opinion on which browser they would support. Even today you occasionally see sites that will hit you with "unsupported browser" errors if you aren't running a specific version of something.

The solution to this was everyone realized they were throwing money away by excluding a large portion of their customer base. At the time no single browser really dominated the market share so it was easy to see that an IE-only site was losing 33% of internet traffic. These days everything is basically chrome-based so this hasn't been as much of an issue.

So in the future we'll see this same thing. Non-attestable browsers will be locked out of attested sites and it will be a numbers game to see if sites want to risk losing these customers/viewers.

At the end of the day, you have to remember that everything on the web is just a TCP socket and some HTTP which is a flexible text protocol. We can build pretty much anything we want but it takes inertia to keep it going.

Rather than being completely blocked, I think non-attestable browsers will be subject to more CAPTCHAs and other annoyances, similar to what TOR users see today from anti-DDOS services. Perhaps ad-supported services using large amounts of bandwidth will decide not to support non-attested users, since the ad revenue from those isn't enough to pay for the bandwidth.

What I would like to see is a solution for anonymous microtransactions, so web sites have a monetary incentive to serve users who want to use a non-attestable browser (and don't want to see ads).

I would like to think so but as someone who's tried to hack on the chromium codebase I'd say it's easier to make a new browser from scratch than to figure out how to make meaningful changes to chromium.

Anything that allows companies to exert more control, will be used to exert more control.

And that's fine; if some people want their own sandbox so they can avoid the horrors of the WWW as much as possible, more power to them.

But let's not pretend this is going to be come a widely-used platform where people are going to be able to do but a small fraction of the things they can do on the web. Again: that's fine! But it can't and won't replace the web.

>My web browser (currently Mozilla Firefox running on Debian GNU/Linux, thank you very much) will never cooperate with this bizarre and misguided proposal.

Mozilla used to be about user freedoms. Lately Mozilla has been a front-runner on turning off and disabling non-TLS just HTTP support. They will likely be one of the first browsers to remove support for it and eventually HTTP/1.1 as a whole. ref: https://blog.mozilla.org/security/2015/04/30/deprecating-non...

Given that HTTP/3 as implemented by Mozilla cannot connect to self-signed TLS cert websites this means the future of Firefox is as a browser that can only visit websites that third party TLS CA corporations periodically approve (even if those corporations are currently benign, like LetsEncrypt). Does this remind you of anything? That's not to say other browsers are better in this respect. Mozilla's Firefox and it's forks are the least worst... it's just everything is getting much worse all together.

And speaking of that, let's not forget about downgrade attacks! Removing HTTP is the least worst option in much the same way that you disallow RC4 when negotiating encryption for an SSH connection.

But there is more to the web than just the commercial, institutional, and the like. Websites that are run by human people without profit motive and without any need to be constrained by the realities of CA TLS exist. The major browsers are all about money these days so they'll prioritize the safety of monetary transactions above user freedoms. But just because this is the right decision for an profit driven company or institution doesn't mean it's the right thing for everyone and should be applied to everyone. In fact doing so will ruin the web.

Personal and non-profit (non-incorporated) websites are mostly static html and files in directories and do not require everything everywhere be encrypted and verified. This "execute everything blindly" practice is only accepted because it's required for businesses which require JS execution. I reject this premise because no, it doesn't apply in all contexts and risks of MITM attacks (on personal websites) are very low once you question and mitigate it. The document web is much safer and requires less sacrifices than the application web.

Er... no. It means that Firefox will only connect to websites that the domain administrator of the system approves of. You, as the administrator of a computer, can install whatever X.509 roots of trust you want. Including a root of trust you own, which can issue certificates for whatever websites you approve of.

Today, where there are residential users who can't get the attention of big companies, you'd probably then run a local forward-proxy that re-wraps connections to sites you trust, with certificates rooted in your root-of-trust.

But this is just a sociological evolution of the original design intent of X.509: where each corporate/institutional/etc domain would directly manage its own trust, acting as its own CA and making its own trust declarations about each site on the internet, granting each site it trusts a cert for that site to use when computers from that domain connect to it. Just like how client certs work — in reverse.

(How would that work? You'd configure your web server with a mapping from IP range to cert+privkey files. Made sense back when there was a 1:1 relationship between one class-A or class-B IP range, one Autonomous System, and one company/institution large enough to think of itself as its own ISP with its own "Internet safety" department.)

That is a completely unreasonable assumption. The barriers of entry have been greatly increased.

How many users have devices that they are really administrators of? Fewer and fewer.

What is the technical challenge of setting up your own HTTP server that can be browsed with an off the shelf browser on your local computer?

As long as nobody has forced you to join your computer to a domain and accept the installation of group-policy overrides, you're still fundamentally an administrator of that machine.

You might not ever feel the need to administrate it, because the OS vendor is often co-administering the machine (see: Windows or macOS when you use a local account rooted in their cloud SSO) but the OS vendor hasn't restricted you from doing your own administration in the way that a corporation or institution administering the domain your device belongs to would restrict you. You still have the ambient authority to administer your machine, whether you ever bother to elevate yourself or not.

You can still install your own X.509 roots of trust. Even on, say, iOS! (You must administer the iOS device using tools — e.g. https://github.com/ProfileCreator/ProfileCreator — that run outside of the device on a "real computer"; but that's just a fact of history, to do with how system administrators generally prefer to interact with computers, not a property of the target device's security. A config profile is just a file format; if someone ever wanted to make a profile editor that ran on iOS itself, they could.)

(And if we're talking about a machine that is corporate or institutionally controlled? Well, then it's the responsibility of the people who manage your device — your IT department — to decide whether a given cert should be given trust. Like it always was under X.509.)

> What is the technical challenge of setting up your own HTTP server that can be browsed with an off the shelf browser on your local computer?

The approach where you run a proxy that wraps untrusted connections into trusted ones is fully general, but yes, only really applicable to the most advanced users. But then, only the most advanced users really need and/or should want the full power of this approach. Only someone with a lot of experience in network security should consider themselves capable of vouchsafing a non-TLS HTTP connection as worth being trusted. You have to basically come up with a [continuously falsifiable!] "attestation heuristic" for the remote yourself — that it stays on the same IP, that its DNS records haven't changed owner, that the server is still sending the same Server response header, etc.

(In fact, if the point is just to look at old websites that were never updated to use TLS, it's probably better to let someone else solve this specific problem for you, through a full application-layer compatibility forward-proxy service like https://theoldnet.com/ .)

If your needs are slightly weaker — if you can assume that every remote is at least using self-signed TLS certs rather than not using TLS at all — then the problem is vastly simplified: you can directly trust any cert by putting that cert directly into your X.509 trust store (in effect making it a root-of-trust — though it doesn't have the X.509 property that enables other certs signed by the cert to be trusted transitively, so it's a leaf-node root-of-trust. A "stump of trust", if you will.) You don't need to run any local servers to do this. And, at least in some cases (e.g. macOS Safari) it's just a few clicks to get from "this cert is invalid" over to "add this cert as a root-of-trust" (i.e. https://i.imgur.com/IXpF4ld.png).

The only problem with this approach, is that there will be no continuity of identity if the X.509 cert of the remote gets to the end of its lifetime and must be renewed. You must act in the capacity of the CA, figuring out again, from scratch, whether the new remote cert should be trusted.

If your goal is to get together with a bunch of your buddies to escape the "X.509 CA cabal" by doing your own cert signing, you'd therefore be better off not using self-signed certs, but rather creating your own CA (probably an automated one using ACME!); importing that CA cert onto all your devices as a root-of-trust; and then having that CA sign certs for all your group members' sites. Then you'll get all the advantages of regular X.509, just in a sort of "overlay world" where your group's browsers can trust both regular sites and your private-world sites, while regular people who aren't part of your group will see a certificate error when visiting your group's sites (unless they also decide to import your CA as a root-of-trust.)

(TBH, this would be kind of a cool "member's only club" to join. In theory, with sufficiently-advanced ACME probes, you could also enforce whatever properties of each site you liked, at least at time of issuance. You could create an "overlay web" that acts like Gopher/Gemini or whatever else you like, just by doing this.)

I still don’t understand your distain for the idea of a 100% encrypted web.

Rather than saying “does this remind you of anything”, can you tell us what it reminds you of?

I guess the issue is, eventually, CA’s can decide not to issue certificates to certain people classified as malicious/nefarious/etc?

Can you clearly articulate your position on this point?

Instead the current system depends on some set of built in trusted root certificate that's run by opaque monopolies (at least pre Let's Encrypt) plus a lot of hassle to add self signed certs if it's even supported at all. (IIRC some browsers like Chrome will ignore system trusted CAs in an attempt to "help the user be more secure" ref: https://serverfault.com/questions/946756/ssl-certificate-in-...)

* There is precedent for this, for things like Remote Desktop or SSH where only encryption is the goal, their default behavior is exactly this: confirm upon first access, and remember the approved cert for the future. You do not need to get your server blessed by a CA to connect over ssh :)

It's bad that it's run by corporations, but it's still a good thing overall. Maybe it should be run by different people(like IDK ICANN over something like the UN)

OTOH SSL has done nothing for preventing phishing, since no CAs actually verify anything beyond you owning the domain.

Also, “remember this cert forever” (cert pinning) has been an ops disaster for a lot of sites that have tried it. So in practice “the first time” might be more like every week or every month. What the risk that a coffee shop will not serve you a malicious cert once a week?

Also if they do it and you move back to your home connection… the site is broken there because now it’s returning a different one than was pinned (by the attacker!).

I think a good idea might be to have TOFU and self-signed only as a fallback. If there was no initial mismatch, and then upate cert periodically.

All the little green lock icons in the world haven't put a dent in phishing or spoofing.

And there's too many countries that have power to mess with their citizen's DNS resolving, and too many ways for domain names to be taken down.

This is creating a system filled with more absolutes than there should be. And the people doing the encrypting aren't willing to put in any time or effort for other basic affordances. If we could do opportunistic encryption, which isn't really trustworthy (that it's not being mitm) but has many upsides like letting you know you're still talking to the same people for ex - I think if we had an ever more robustening and not ever narrowing stance for what we could do to encrypt the picture of security happening would be much less scary. But we are letting more and more layers of systems have to be involved, with more chokepoints for governments, in a way that seems ossifying & fragile.

When HTTP/1.1 is a thing of the past and Firefox won't load any endpoint without CA TLS on HTTP/3 then the fact that there are only a handful of corporate entities you can get a TLS cert from means they'll be an even more tempting target for those that wish to apply pressure and restrict access to whatever topics they don't like. It wouldn't be the first time a CA has been pressured to drop a site and it certainly won't be the last if things go this way.

Additionally, it significantly increases the complexity of setting up visitable personal website. There are packages for acme2 and some CAs that can hide this complexity but it is there and does break. It acts as a roadblock to what I see as one of viable contributors to keeping the web open: self hosting.

But again, I brought it up because the original linked article suggests Mozilla would never accept something as bad as WEI. With the way FF HTTP/3 is implemented they already have done something similar in outcome. So I do think we need to make noise about WEI (and HTTP/3).

Centralising trust will always be a bad idea, regardless of context.

Security people can complain as much as they want, but it's these kinds of anti-user practices that makes users hate updating.

Indeed, I've always thought the classic saying about those who give up freedom for security is very relevant in the current times. I'm quite certain that it's possible to respect the user and improve security (for the user), but instead they've been using security as an excuse to do worse to the users.

I manually only update banking apps and the likes.

And if an app forces me to update (lazy API devs!) I usually delete it and find a new one.

When companies create a culture that updating is harmful to the user then users will learn to not update.

A quick nod to Tor Browser, the Firefox fork which will always support HTTP in order to support the vast majority of Tor hidden services.

If I want to visit scary non encrypted websites I should be able to do so.

But I would prefer my grandma be blocked from all non-encrypted sites, sorry!

That said, there should be a toggle in preferences or about:config to allow it for those who know what they are doing.

(Seriously tho, how would you frame the question in a way my grandma, whose only access to the internet is via an iPad, could understand)

Which is fundamentally still better than insecure HTTP, because it's at least possible to take steps to trust it and make sure it's the same server you expect to talk to.

[0]: https://wiki.mozilla.org/Add-ons/Extension_Signing

[1]: https://developer.apple.com/documentation/safariservices/saf...

You can run an unsigned add-on in regular Firefox by opening about:debugging#/runtime/this-firefox and clicking Load Temporary Add-on...

In both cases, it only lasts until you quit the app.

This fundamentally comes down to "do you really control your computer, or does someone else?":

https://youtu.be/Ag1AKIl_2GM?t=57

- "Who should your computer take its orders from? Most people think their computers should obey them, not obey someone else. With a plan they call “trusted computing,” large media corporations (including the movie companies and record companies), together with computer companies such as Microsoft and Intel, are planning to make your computer obey them instead of you. (Microsoft's version of this scheme is called Palladium.) Proprietary programs have included malicious features before, but this plan would make it universal."

https://www.gnu.org/philosophy/can-you-trust.en.html

So many things posted to HN about it have been the grand overview, which is a perspective worth diving into but also has drowned out every other perspective to the point where it's very difficult to figure out what's really happening with the proposal here.

1. Authors don't understand what tech they use. (I will leave it to your belief - but that would be even worse for Internet)

2. Authors don't understand that something unrealistic is unrealistic.

Idea that you can give companies or corporations tools to check "did user modify his environment" and they would not use it to exclude users is stupid or disingenuous because advocates for this did exactly comment in such way: We want this proposal to do precisely that.

Again Google tries to defend it by saying "we will return invalid 'false' for some of the users/times of Chrome users" [to make sure that website will not do that] which for me is not only bad because it then creates "when google revokes this policy we are in even worse situation" but then leaves the issue how google decides "who" to give back this 'false':

I will reject times immediately not only because this can be easily circumvented by website [check n-times] to detriment of user but it would also contradict official documentation of WEI (same token for same input from user).

And this leads us to another point - if Google wants to return false negatives it would need to either keep information that is supposed to return 'false' - EU will not be very happy with that (also it does contradict this "chrome users"); or more likely it will be implemented in chrome.

Now when we established that implementation in chrome is most probable - we can also establish that:

A) Implement this on profile basis - companies will ask you to reset profile if you are this false negative.

B) Implement on connection basis - companies will ask you to refresh.

C) Implement on device age / os version / type - Google can even make the manufacturers happy with this one.

… as you can see at most this will be nuisance and if by some weird way:

Z) Implement on Super-complicated basis - this will be still possible because…

3. Google plays disingenuous word game with us here by saying - We won't destroy open web

Other Chromium browsers may ignore that Google X% false negative (Google may loose few % of users before it scrapes this policy). And there is 0 need for Google to actually do something when companies will misuse this API.

In simple words the part that should worry you is not that "Google will destroy web by using this API on Chrome and it services", what must worry you is that other companies will do that for Google and Google will wash their hands from this by saying "We wanted good but didn't work". You can see that tone from the Google - We don't want that so we created these "holdouts".

Don't let Google move Overton window, they are proposing thing that any sensible person see as clear cut attack (or stupid idea that can only work this way) on Privacy and Your Right to use Your Device (and for some people Your OS and/or Your Browser) as You want to use. They are at fault here.

The proposal literally is not about extensions. The only context in which extensions are mentioned is to explicitly say that the mechanism is not for policing the installed extensions or other browser features.

So how exactly are you determining that this is what the proposal is really about? It seems that it can only be by ignoring the proposal text and making up your own ideas of what it is about.

The premise is unacceptable and discussion on the technical merits will only give it the fuel to make it more material.

[0] - https://en.wikipedia.org/wiki/Overton_window

We're in it now, and fully understanding the issue and the problems it purports to solve is incredibly important.

Dialogue is all we have, and to even build a solid argument against WEI, understanding the details matters.

For instance, one of the framings of WEI is that it gives advertisers a way to verify the client so they don't "have" to do fingerprinting. Except WEI does nothing to take away fingerprinting, so advertisers will then have fingerprinting and WEI. (Even if it did simultaneously take away fingerprinting it would still not be OK, but the current framing is not even offering the user benefit it claims to offer.)

Despite what Google say, fingerprinting will never go away - any new feature in that space will just be in addition to existing and future fingerprinting techniques.

doing bad things (for example, any of the 3 above options) is more irresponsible than implementing bad things poorly

…

You can not. Because that is not how world works - crime did happen, happens, and will happen. You can stop attempts or fight it by education or by arresting criminals but never eliminate or prevent it.

"You need signals of some kind to know whether a visitor is likely to be malicious or not."

Innkeeper in 13 century: "I need signals of some kind to know whether a visitor is likely to be malicious or not before he enters." - See how ridiculous it is?

You are being being wrong here - you don't have 'visitor' but 'client' and as far as I'm concerned you do not spy on every client to "know" if he "is likely to be malicious or not". You may be suspicious of client activities but that is what you can realistically do.

Also define "fraud and abuse" because this can mean many things which may have many solutions.

That innkeeper would have used the signal of how the visitor looks. If a visitor was being malicious and got kicked out, that person could not just come right back in as the inkeeper would be able to tell that he was the same person as before.

Also your metaphor is not great because WEI can only happen after the first page load since it requires the site to use javascript to use the api.

Not like that ever backfired.

>inkeeper would be able to tell

assuming that he have photographic memory and visitor did not change his looks by any way (shaving, getting scar etc.).

if you have to refer to 'looks' you have IP - it has exactly same power as signal as looks.

>Also your metaphor is not great because WEI can only happen after the first page load since it requires the site to use javascript to use the api.

for user that is irrelevant point. As people do not care about how you run server - only if they can use the page.

To put simple - I run My browser of choice on my OS of choice with my stack as I wish (otherwise I wouldn't run Linux). The idea that server owner should get any say about this is simply intrusive.

maybe your wish is possible, maybe not at all!

in any case, WEI and fingerprinting are both still bad regardless of the answer anyone might provide

said the giving-alcohol-and-cigarettes-to-children lobby,

"As much as people like to invent nefarious motives, in reality there are important players manufacturing alcohol and cigarettes who have valid use cases for children consuming them which cannot be broken carelessly."

Otherwise I agree that examining the details doesn't move the Overton window - the broad idea already did that.

Chrome on android is completely unusable due to no adblocker, is this what WEI will do everywhere?

Remote attestation might reduce the amount of cheaters in games and fraud in banks if implemented properly. So, through potential indirect means.

I don't think any of this is worth the loss of user freedom and functionality, though. So I will vehemently oppose WEI and similar to be used outside of internal facilities.

And cheating isn't a significant problem in in-browser games, it's not like anyone modified the browser source to create cheats for in-browser games. And for competitive online games, we have a great imperfect attempt at showing what remote attestation would look like. Anti cheat in games.

We have AAA titles that work flawlessly under Proton but you can't play them on Linux because anti-cheat needs to do DKOM on your Windows kernel before it lets you play.

I agree with the rest of your post though.

So what exactly are we even talking about here? The idea of attestation or just this proposal or is it a Google thing? Does this compare to cloudflare private tokens or safetynet or are they completely different? If proposal goes through what does that functionally mean for browsers both ones based on chromium and ones not?

I don't know why it's so difficult to find these details and I'm instead being told to just accept the idea that the premise is unacceptable.

https://github.com/mozilla/standards-positions/issues/852 https://github.com/RupertBenWiser/Web-Environment-Integrity/...

I stopped reading after the explainer’s intro section. The first example is making it easier for websites to sell adds (lmao) and the other 3 are extremely questionable whether if the proposed remedy even helps. And it’s presented as a benevolent alternative to browser fingerprinting, as if we must choose between these two awful choices. It’s an absolute joke of a proposal.

The public should have an entity that will receive detailed attestation data to assess that. Failing the attestation will revoke business permit along with an announcement.

Because they will pinky promise.

I find it funny that for some reason companies get the benefit of the doubt when it comes to dealing with data in a responsible matter. Yes, it's possible that they do. But it is also possible that they don't and no matter what they say in public that's just words, it doesn't prove anything about what is really going on and that's before we get to honest mistakes.

There is simply no way to be sure, all you know is that once you transmit data to any other host on the internet that it is quite literally out of your hands whether or not that data will one day show up elsewhere.

It goes a bit deeper than that. Many companies these days "choose" to get certified under a variety of standards (the most common one is ISO 27001), everyone who hasn't been completely ignorant is looking for or already got cybersecurity insurance and on top of that comes the entire GDPR saga. Basically, you got three levels of auditors that at least make sure the basics are covered, and on top of that come industry specific requirements such as TISAX [1], US SOX Act compliance or whatever AWS had to go through for GovCloud.

[1] https://en.wikipedia.org/wiki/Trusted_Information_Security_A...

These audits check paper. They don't check what is actually going on, they will check that documentation is in place and that processes and various controls are in place and that periodic checks have been performed. They don't actually check any of the underlying tech. For instance: ISO27001 asks for 'regular pentests'. But it doesn't do anything to ensure that those pentests are of a good quality. There are plenty of 'check the box' automated pentest services that get you past that hurdle but that won't do much for your security. They might even give you a false sense of security.

So yes, there are all kinds of audits. But like with everything else the devil is in the details and the quality of the work is very important (obviously!). Many companies treat these certifications like a 'license to operate'. You need to have them so then you do the absolute minimum required to satisfy the auditors rather than to see the certificate as a minimum level of proof required that you have your house in order and that your intent is to deal responsible with your data subjects (and customers) data. The latter is extremely rare.

Side note: This at least would occasionally happen if you tried to spend Scotland or NI £5 notes in England.

It's like Android SafetyNet where apps can work out if the device is rooted and running custom software underneath the browser/app.

Pretty much all non-technical users -- and a great many technical users -- have never heard of SafetyNet and don't know what it does.

Metaphors are imperfect; that's inherent to their very nature. That doesn't make them useless.

I'm not sure how a non technical user is meant to get any kind of understanding of WEI from that metaphor. It can be explained quite simply "Websites can check if your browser has extensions or if your OS has been modified, and refuse access based on this information"

I don't know why Britain doesn't just implement a national printing press.

There are English banknotes and Scottish banknotes, but they're the same currency.

It will lead to three webs: the remainder of the open web, the new closed web, and the pirate web.

Personally I'll do my bit to preserve openness, even if that means working socially and technically to support the new world of piracy. It will always be a losing battle without institutions fighting for openness, though.

This is a moment when Sun's old line - "the network is the computer" - starts to look hideous and dystopian. Prophetic, but maybe not how we thought.

Your online banking will stop working on your unapproved software, just like your baking app stopped working on your rooted/old Android phone some 3-5 years ago.

People justify the latter by speaking about companies wanting control over employees' environments, but IMHO that shouldn't be allowed either. This is also why "zero trust" is problematic; they want to replace humanity with centralised control.

Governments are scared because they realise cryptography is being used against them.

Now users should realise the same.

Strong encryption is classified as a weapon for good reason. Just like you'd want a gun in your hands, but not one pointed at you.

Then again, the fact that you call them "consumers" instead of "users" already shows what side of the debate you're on.

No they don't. No single person on this planet wants this. What they want is to be allowed to buy/stream/consume stuff with as little friction as possible.

You're barking up the wrong tree mate.

That depends on Mozilla. As long as our software comes from corporations, we will just be reduced to begging.

It's more like, if you want to borrow a book from the library, you have to bring an FBI agent home with you too, so they can certify that you don't have a photocopier or scanner (or even a pen and paper), that only you can read the book, and not another family member, that if you want to read aloud, your windows can't open and let anyone else listen in, that you read it from cover to cover including the back-page ads for other books in the series, that you can't leave home with the book, to re-lend it out, and so on.

NO. Not on my machines.

On the other hand, it's infuriating that advertising is the first front in this war. I specifically don't want advertisers to have my identity. I'm fine with like my Mastodon server or a site like HN to know I'm me because I'm actively interested in interacting with them. I don't want to interact with advertisers, or for them to have my identity, but they're going to wall off half the internet for people who opt out.

https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_...

Additionally, if a place of business asks you for state id, you are free to choose not to share it. It's not your choice whether they get to ask you nor your right to provide a fake id and expect it works. Views on the website make it sound like everyone should be allowed to own a gun without a licence. I bet most people don't feel that way in reality.y

Wei will get integrated with your CBDC.

> On that Web, if you send a valid request with the right data, you get a valid response.

Explain DoS protection then.

You can also choose not to send this header. By default I do not send it. The RFCs do not require it^1 and very rarely do I find sites that do. When I do find such sites,^2 I just add them to the proxy config so that a UA is added on the way out. Almost invariably these sites will accept a made-up UA, so long as it is well-formed, which is interesting.^3 It suggests no one knows what new UA strings will appear.

The origin of changing the User-Agent header dates back to one of the earliest browsers, written in part by a well-known Silicon Valley VC.^4 It was always possible for the user to control HTTP headers such as UA and the designers knew it. Later in the "browser wars" Microsoft changed its UA header to match Mozilla's.^5

1.

https://towardsdatascience.com/the-user-agent-that-crazy-str...

2.

For example, www.federalregister.com and sec.gov.

3.

Many users want to "blend in" and use common strings so perhaps use of made-up strings remains largely untested.

4.

https://raw.githubusercontent.com/alandipert/ncsa-mosaic/mas...

5.

https://webaim.org/blog/user-agent-string-history/comment-pa...

https://humanwhocodes.com/blog/2010/01/12/history-of-the-use...

As for WEI, I'm inclined to think that the terms "abuse" and "fraud" in the spec may actually refer to ad fraud, including potential fraud by Google itself in marketing its ad services because it hides the true extent of ad fraud from its customers.

People who like to access the web with uncommon TCP/HTTP clients may not be a significant problem. There are no details given in the spec about this alleged "fraud"; perhaps that's intentional. Although by being vague in the spec, real humans that prefer not to use popular browsers may jump to conclusions.^6

It could be that we're on the cusp of exposing the true extent of ad fraud with respect to Google, and the ultimate unworkability of Google's core "business" (selling ad services). Perhaps Google believes its advertiser customers could begin to lose trust; maybe direct more ad spend to Apple.

6.

Some pre-spec discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...

Google's WEI doesn't threaten your right to be silent.

Based on Google's previous behavior, if your web site doesn't go along with its plan, it will be more than happy to silence/delist/derank it.

Sure, as the technologists we are, we can see just how dangerous this can be, and why it's offensive to even consider. Without getting the masses on board though, we're pretty outmatched and outgunned.

There is, however, an explicitly enumerated right to freedom of speech. There are only a handful of recognized categories of non-protected speech. Lying isn't one of them.

Fraud, defamation, perjury, and obstruction of justice are illegal. That's a much narrower restriction than a ban on lies.

Google Crawlers and User Agent Strings – 2023 List

https://www.stanventures.com/blog/googlebot-user-agent-strin...

This is the important part.

Tell that to the police.

You are conflating the alleged benefit of locking down devices to assure users don't break them [1], with websites and services getting the ability to remotely verify your software/hardware stack is "approved", and block you if it isn't.

It's not about what you want - it's about taking away your ability to choose. The "fun toys" that can be modified to your liking will get increasingly useless as they'll be blocked from large chunks of the web, especially after Google will start pushing WEI if sites want ad revenue, under the logic of preventing click-fraud.

[1] There are plenty of ways to limit unlocking to the technically-savvy, and making it tamper evident to the owner (e.g. a "bootloader unlocked" notification during boot), and many existing phones implement them, so any claims by phone or other device manufacturers that making devices impossible to unlock are outright lies.