Brave's stance on Web-Environment-Integrity?

What is the official stance of Brave with regards to the new proposal Web-Environment-Integrity affecting all chromium based browsers?

I have been avid user of brave for years and switched many of my friends to Brave.

However if Brave is goin to submit to this blatant restriction of web users freedoms and their privacy, I will be forced to do exactly the opposite.

So how is Brave goin to fight this threat to web users freedom, security and privacy?

3 Likes

WEI is more than just DRM, it lets websites block users based on extensions and capabilities, effectively preventing ad-blocking and other privacy focused features that are core to Brave.

Web developers do not need to implement it, Cloudflare is onboard and that’s 18% of the internet straight away.

It’s also started to make its way into Chromium: https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd

So yeah, I share OPs concern and it would be nice to know what Brave’s opinion on this so concerned users know whether or not to start migrating to other browsers.

I appreciate there may be others who think it’s much ado about nothing. That’s fine, people have different risk tolerances, but please save everyone some time and get on with your day rather than turn this into yet another pointless internet argument.

1 Like

Just a FYI, I know I’ll be reaching out to various people on it. What I can tell you in general is Brave has always been about privacy and security. So the likelihood of them implementing this into the browser is slim. If they do have it, I’m sure it will be similar to how they have Widevine that we can enable.

The big issue here is that websites might build to require it. So just like how content on Netflix or other places might not be displayed within Brave if you don’t use Widevine, some of these websites might block content if browsers aren’t using WEI. There won’t be a whole lot of things that can legally be done to circumvent this. But at least adding a toggle would be a way for users to control what they want to sacrifice in order to access content.

1 Like

The below quote is from co-founder & CEO of Brave.

"BrendanEich:
We are a fork, have been all along, the “reskinned” claim is complete nonsense. We won’t be shipping WEI support, just as we disable or otherwise nullify lots of other junk that Google puts into Chromium."

Source:
https://www.bleepingcomputer.com/news/google/browser-developers-push-back-on-googles-web-drm-wei-api/

Therefore – as expected from an organisation like Brave – Brave won’t be shipping WEI support. Apple and Microsoft however, seem awfully quiet on the topic…

It is better to link Brave’s Github about this:

with the PR:

I mean, Brendan Eich can be quoted saying something, doesn’t mean much, but if it is being implemented in the source code, that’s what matters.
Eich has been wrong about some stuff about Brave in the past, which means while he is the CEO and Founder, he still doesn’t know exactly how stuff is implemented sometimes by the Brave developers.

About WEI, the problem is not disabling the WEI, they are doing it; the problem is, what will happen when websites start to implement it and force you to use it? I think it will be just like, Widevine is optional and not turned on by default unless needed.
So as long as it is off by default, it should be okay, but to be honest, we don’t know the future: will many websites implement this?

Not all websites have anti-adblocker scripts, even if it is easy to implement, they can be advanced or basic, and they will work in most Browsers, where people will disable the adblocker, especially on mobile it will work, unless you use uBlock/Adguard or it has a native advanced adblocker like Brave does, that means most devs don’t care.
And then, not many websites require widevine, not many websites Block Brave because of Brave’s own API. or make the use of AMP crap, or are behind a paywall like a lot of ‘news’ outlets or blogs.
But some do, and they are the problem Brave has to deal later with, if WEI gets implemented, because so many things go to Trial and never make it to Chromium, so making still drama about it, is pointless, it might just be dropped.
And we don’t know the consequences of WEI or what some developers will do with it and how much can it be avoided in the future.

So the whole “we won’t ship it and disable it” sounds unrealistic.

Big thing is I questioned Sampson, Brendan Eich, and others on it. The answer is that they will be having Peter Snyder and team look at it later, then will have a blog post. Right now there’s not enough known on it and people keep making a lot of assumptions. We don’t even know if it’s actually going to become “a thing.”

A lot of articles try to weigh in on FUD because it sparks a lot of attention/views, which means more money for them. Tread carefully as you hear rumors and opinions, especially when the majority of it is all just assumptions and hearsay.

2 Likes

Yeah the Bandwagon effect, especially when it comes to this, nobody knows what will really happen, but still comment as if it was the worst thing. Like happened with Manifestv3, where still today you have people saying “no adblocker will work with Manifestv3”.

I mean, if you go to Chrome Status, and you check around, you will see how many weird things Chromium team has already implemented in the Browser, stuff that can be easily abused by any developer.

Like

Feature: Open popups as fullscreen windows (still on trial)

Adds the ability to open a popup directly to full-screen. Adds an additional windowFeatures parameter to the window.open() JavaScript API which allows the caller to open a popup directly to full-screen on the display that would contain the popup (based on screenX/screenY). This eliminates the need for the developer to manually transition a popup into full-screen which could require a new user activation signal.

Motivation

Sites cannot open full-screen windows without multiple user gestures. This particularly restrains web applications that launch full-screen content on another display (via the window management API) by requiring multiple user interactions which degrades user experience.

What can go wrong with it? especially for the non tech people who will be browsing around in their Chrome browser and will probably click something malicious because it just decided to open full screen, and developers didn’t have to do anything because the window.open() API made it easier for them to implement that.

The Popover API

An API that can be used to build transient user interface (UI) elements that are displayed on top of all other web app UI. These include user-interactive elements like action menus, form element suggestions, content pickers, and teaching UI. This API uses a new popover content attribute to enable any element to be displayed in the top layer. This is similar to the dialog element, but has several important differences, including light-dismiss behavior, popover interaction management, animation and event support, and the lack of a “modal” mode.

Motivation

When building a web application, there are many cases in which an author needs to create transient user interface (UI) elements that are displayed on top of all other web app UI. These include user-interactive elements like action menus, form element suggestions, content pickers, teaching UI, and the listbox portion of a select control. These paradigms will be collectively referred to as popovers. For many such use cases, it is incumbent upon the author to handle the popover’s styling, positioning and z-index stacking, focus management, keyboard interactions, and accessibility semantics. Because no platform-native solutions exist to comfortably handle all these use cases, individual authors and framework developers must continuously re-write the same classes of controls. This results in duplicative work for the web development community, and inconsistent experiences for users of these web applications. The web platform can be extended such that authors can get popover interactions and styling “for free”, but have enough flexibility to support their individual use cases.

So what could go wrong with it as well, when developers can show popovers with any content easier now, that could have anything good or malicious, and just as any other technology, it can be used for good and bad things.

There is also Feature: Topics API which if you read the Github page, it is yet another way they want to continue and implement FLoC, but they want to add some more stuff and say it is more private and better but it is the same Interest-based advertising and Google being an advertising company, it is obvious why they would add that.
It was shipped in 115 and never heard anyone speaking about it.

So, in resume, what I mean is simple, many things Chromium team adds are weird or can be abused by developers against the users, so WEI and Manifestv3, and FLoC were/are not the only things being added that can affect the users.

In the end, if WEI gets implemented, then nobody can’t do much about it anyway, not even Brave, apart from disabling and enabling when it is needed because Washington post or new your times need it, there is not much it can be done.
Just like today we deal with DRM and Playready and Widevine and Windows users can watch Netflix 4k through the web and others only 1080p, and then paywalls and anti-adblock technologies and trackers and pagers like Instagram or Tiktok, which stops the video if you aren’t actively watching it and put it on the background, and malicious ads, malicious popups, and website using different domains to deliver bad scripts so you block them one day, and the next day they will not be blocked, and ad networks in apps and apps pushing ads every minute etc etc etc, everything being implemented by developers in their apps or websites, so they are not exactly friends either.

1 Like

I just hope that there are enough people pushing back so that it dies before it gets any more toeholds.

My biggest concern with it is it becomes like Android and the moves to hardware attestation which is happening with financial apps especially. I have just had to buy a new phone as could not spoof Safety Net on an ongoing basis - phone is rooted and a specific bank has closed it’s online portal so no choice…

Google/Alphabet seem determined to be able to mine as much as they can in pursuit of ad revenues and this is another potential step in that direction although they are trying to sell it in terms of “security”.

Do you trust Google…

Rant over!

They have official blog post out now at https://brave.com/web-standards-at-brave/9-web-environment-integrity/ for anyone who has questions.

Also want to point out they have a Github to remove anything from it over at https://github.com/brave/brave-core/pull/19476 which Emi also shared.

2 Likes