7 ms·

> Can we just refuse to implement it? > Unfortunately, it’s not that simple this time. Any browser choosing not to implement this would not be trusted and a

> Can we just refuse to implement it? > Unfortunately, it’s not that simple this time. Any browser choosing not to implement this would not be trusted and any website choosing to use this API could therefore reject users from those browsers. Google also has ways to drive adoptions by websites themselves. This is true of any contentious browser feature. Choosing not to implement it means your users will sometimes be presented with a worse UX if a website's developers decide to require that feature. But as a software creator, it's up to you to determine what is best for your customers. If your only hope of not going along with this is having the EU come in and slapping Google's wrist, I'm concerned that you aren't willing to take a hard stance on your own.

gunapologist99 3y ago
> If your only hope of not going along with this is having the EU come in and slapping Google's wrist, I'm concerned that you aren't willing to take a hard stance on your own. This is indeed concerning. I'd like to see Brave's response to this, and we already know how Firefox has responded.
lxgr 3y ago
What sets WEI apart is that it, in a way, exerts power over your choice on how to implement other web features, for example whether you're allowed to block elements, or even just show a developer console. Other than Encrypted Media Extensions (and these are much more constrained than WEI!), I don't know of any other web standard that does that.
- wbobeirne 3y ago
  While it's a much lesser offense, many APIs are only available in "Secure Contexts", so it's not entirely a new concept https://webidl.spec.whatwg.org/#SecureContext https://webidl.spec.whatwg.org/#SecureContext
  - lxgr 3y ago
    Getting a secure context costs $0 and takes no effort in many common webservers at this point. I do remember the controversy at the time of everybody shifting to HTTPS only, though, and how it might exclude small/hobbyist sites. Fortunately, we've found ways to mitigate that friction in the end. I'm much less optimistic here.
    - mschuster91 3y ago
      The thing is, yes it was controversial at the time to enforce HTTPS, but on the other side I 'member pwning people with ARP spoof attacks (both to steal cookies and credentials as well as simply redirecting all images to porn) at my school already way over a decade ago, and all I had was a laptop, Wireshark, Metasploit and some other piece of open source software whose name I forgot. No ARP sponge and the internet uplink was 10/10 mbit anyway so it was easy to do that shit for the entire school. A year later someone packaged all that stuff into a single software even a complete dunderhead could use to prank and steal facebook sessions at will. Basic reality and the easiness of attacks made it impossible to stick with HTTP for much longer. And hell if I watch Scammer Payback on Youtube, I'm beginning to think it might be a good idea to disable developer tools on browsers and to only unlock them if you can prove physical, un-remoteable access to a machine, similar to Apple's SIP.
      - GauntletWizard 3y ago
        Whatever proof you require, scammers will still convince Grandma to enable it.
      - chrisweekly 3y ago
        > "I'm beginning to think it might be a good idea to disable developer tools on browsers and to only unlock them if you can prove..." Strongest possible disagreement here.
        lxgr 3y ago
        How so? I don't see how a secure attention sequence (i.e. what Windows used to do with requiring ctrl + alt + esc to be pressed to log in) could be a bad thing. On the other hand, you can bet that that's absolutely something scammers will be able to convince people to do while they're on the phone with them...
  - contravariant 3y ago
    The crucial difference between the two is that I get to decide which contexts I consider insecure. For convenience I may choose to let an agent decide on my behalf. This is fundamentally different from a world where Google gets to decide if I am a risk to them.
burkaman 3y ago
Since Google also controls the most popular search engine and ad network, they can exert very significant pressure on web developers by refusing to place ads or drive traffic to websites that don't comply. I already block all ads so I'm obviously not totally sympathetic to developers who make decisions based on what will maximize ad revenue, but it still is not fair to put the burden on developers here and say "it's your choice, just say no".
- nine_k 3y ago
  Usually it's not developers who make decisions to put ads.
rezonant 3y ago
> Choosing not to implement it means your users will sometimes be presented with a worse UX if a website's developers decide to require that feature. I think this makes a category error. Most browser features/APIs are indeed treated as progressive enhancements by web developers, at least until an overwhelming number of the users have access to that feature. And even then, even if the developer makes assumptions that the feature/API is present, often the result is a degraded experience rather than an all-out broken experience. The same is not true of web attestation. If a website requires it and a browser refuses to implement it, in at least some cases (probably a concerningly high number of cases though) the result will be that the user is entirely locked out of using that website. It's also worth noting that _even if_ Vivaldi implements WEI, there's a solid chance that the attestation authority (Google, Microsoft, Apple) or possibly the website itself[1] will not accept it as a valid environment at all! After all, what makes Vivaldi not a "malicious or automated environment" in their eyes? What if Vivaldi allows full ad blocking extensions? User automation/scripting? Or any example of too much freedom to the user. Will the attestation authority decide that it is not worthy of being an acceptable environment? [1] if this ends up spiralling out of control by allowing the full attestation chain to be inspected by the website
- iforgotpassword 3y ago
  It still feels like they rather bend over and take it than risking losing market share.
  - mrguyorama 3y ago
    Vivaldi's entire reason for being is "I literally cannot bring myself to just use firefox instead so I'll bend over backwards to try and remove objectionable things from chromium and still end up supporting chrome as the web default"
- wbobeirne 3y ago
  > The same is not true of web attestation. If a website requires it... I don't think I've made a category error, that again is true of all browser features. If your browser does not support JavaScript or WebSockets or WebGL, many sites would lock you out of them entirely as well. It's a choice of the website creator what to assume and what to require, and how to degrade the experience or offer alternatives when a feature is missing. The way I imagine it, WEI will start with skipping CAPTCHA. Then it will be about serving ads (users without WEI would generate no or very limited ad revenue.) Then it's up to the owner of a site whether or not they want to allow non-WEI traffic at all. Some will choose to block users without WEI, and hopefully the number of browsers that have chosen not to implement it, and the number of users on those browsers is high enough that that option will not be appealing. I hope that Vivaldi remains one of the browsers that doesn't implement it, whether or not the EU rules against it.
nvy 3y ago
>But as a software creator, it's up to you to determine what is best for your customers. Absolutely zero large web properties do anything based on what's best for users. If this gains traction, Google will simply deny adsense payments for impressions from an "untrusted" page, and thus all the large players that show ads for revenue will immediately implement WEI without giving a single flying shit about the users, as they always have and always will.
- riku_iki 3y ago
  large properties are interested to keep their content locked from scrapping, so they will for sure be interested to implement this.
  - nvy 3y ago
    Yes. My point is that Google's done an excellent job stacking incentives against the user, here.
  - realusername 3y ago
    >large properties are interested to keep their content locked from scrapping Except Google of course, the only allowed scrapper.
- pptr 3y ago
  Why would Google not monetize unattested traffic? I mean that's like Google blocking it's own ads from being shown. I don't know much about the online ad market. I assume advertisers will pay more for attested impressions than for unattested ones. But unattested impressions will still be worth something.
  - nvy 3y ago
    >Why would Google not monetize unattested traffic? I mean that's like Google blocking it's own ads from being shown. It's very simple. Google has concerns of click/impression fraud. Unattested traffic would be more likely to be fraudulent. Not paying for unattested impressions/clicks is therefore an easy way to cut costs and combat fraud.
2OEH8eoCRo0 3y ago
Someone argued yesterday that in instances like this users are choosing what to use of their own free will. At the micro scale sure, at the macro scale I disagree. Users want their shit to work and if you play these shenanigans it's less of a choice and more of a ransom. Insects in a swarm can choose where to go but they can't choose where the swarm goes.
kyrra 3y ago
Google has been beat-down before trying to do these kinds of things. 2 ones I can think of: 1) FLoC: https://www.theverge.com/2022/1/25/22900567/google-floc-abandon-topics-api-cookies-tracking https://www.theverge.com/2022/1/25/22900567/google-floc-aban... 2) Dart: Google wanted this to replace javascript, but Mozilla and MS both said no way, as they had no part in it. So that project ended up dying. Google tries lots of things. Mozilla, MS, and Apple are still strong enough (especially outside the US) to push back on things that they think are a bad idea.
- freedomben 3y ago
  Dart is still around. The Flutter framework is growing in popularity. Apple already built and shipped this same feature last year, so they're not opposed. MS? Probably gonna love this. Mozilla hasn't said anything on it (yet at least). I'm not expecting any of those players to save us.
  - lxgr 3y ago
    > The Flutter framework is growing in popularity. Is that the one rendering [1] text and UI widgets into an HTML canvas element from JavaScript/Dart (completely coincidentally breaking ad blocking in the process)? What a beautiful piece of software. > Apple already built and shipped this same feature last year, Are you referring to Private Access Tokens (PAT)? These seem quite a bit more limited in what they do. WEI seems to specifically set out to roll back some of the blinding/anonymization aspects of PAT under the banner of debuggability/providing "feedback" to attesters. [1] https://docs.flutter.dev/platform-integration/web/renderers https://docs.flutter.dev/platform-integration/web/renderers
    - freedomben 3y ago
      > Is that the one rendering [1] text and UI widgets into an HTML canvas element from JavaScript/Dart (completely coincidentally breaking ad blocking in the process)? What a beautiful piece of software. Yep. I'm not saying Dart is a good thing - I've never used it and don't currently have plans too. All I'm saying is that it is NOT dead as GP asserted. > Are you referring to Private Access Tokens (PAT)? These seem quite a bit more limited in what they do. WEI seems to specifically set out to roll back some of the blinding/anonymization aspects of PAT under the banner of debuggability/providing "feedback" to attesters. Yes. PATs don't provide as much information about the attestation to the website, but they do provide the critical part which is "is this person using a blessed client." That's plenty for a website to block people on.
worik 3y ago
> This is true of any contentious browser feature. Makes me recall Flash. Once was a time when very large parts of the web were dark to me because I would not install Flash Not an exact comparison, but we've been (near) here beforehand
YetAnotherNick 3y ago
Can't they just return random number for attestation each time.
api 3y ago
Google can just down-rank sites that don't implement this API. Voila, full adoption across the entire web and unapproved browsers are shut out.
deleted 3y ago
[deleted]
EdwardDiego 3y ago
This change is about what's best for advertisers and publishers, not customers.
safety1st 3y ago
Well hold on. The problem with attestation is you're damned if you do and damned if you don't. If you use a browser which supports attestation you will be denied service by companies who disapprove of what you run on your computer. If you don't use a browser which supports attestation you will be denied service by companies who disapprove of what you run on your computer. So everyone loses. If this goes live everyone in the world loses. It is an utterly heinous proposal. It is perhaps the worst thing Google has ever produced. I use Firefox and will never use any browser that implements attestation, even if I have to stop using most of the WWW one day. But unfortunately individual action is not going to be enough here, because no matter what you do, you lose.
evah 3y ago
The author should have asked "Can we just implement it then?" because in some cases you literally can't implement the proposed API. That's the core issue with it. Unlike other contentious browser features, even if you wanted to implement attestation, it may be impossible to do so. More precisely, attestation may be impossible to implement on some platforms to the de facto standard that would develop over time. The de facto standard I refer to is the list of attestors web servers will accept. If your platform can't be attested by an approved attestor, you're screwed. That's why it's not that simple this time. The proposed attestation API is literally unimplementable in general. You can't implement it and you can't not implement it.
lvncelot 3y ago
This point in the blog post saddens me. Chrome's market share is huge, but Chrome is not ubiquitous. There was public outcry when Google was suspected of making youtube have "bugs" on non-Chromium browsers - having them just straight up disable services for more than a third of users would result in an actual shitstorm, more than any of us could hope to drum up with an explanation of why this change is bad. It would also drive the point home to the very same legislators that the author is deferring to. If browsers now start pre-emptively folding, Google just straight up won. It's great that the Vivaldi team is against this change, but a blog post and hoping for regulation just won't cut it. You have actual leverage here, use it.
- stOneskull 3y ago
  can't chromium be forked without wei. brave and vivaldi and others could work on and use the fork.
  - zx8080 3y ago
    Working on chromium codebase maintaining minimal fork is very hard. It requires a very competent and quite a large team (because lots of work to resolve merge conflicts) to just regularily apply a custom set of patches to newly released chromium versions. It's like staying on a dancing elephant. And it requires MONEY. Lots of. I suspect this is the desired result of Google to protect chromium despite it's opensource.
munk-a 3y ago
> If your only hope of not going along with this is having the EU come in and slapping Google's wrist, I'm concerned that you aren't willing to take a hard stance on your own. I take umbridge at this implication. When a monopoly like Google takes anti-competitive actions it's not fair or just to expect individuals to stand up to it. Governments exist to counter anti-competitive behavior like this and governments have been doing a terrible job chopping down companies with too much vertical integration lately.

gunapologist99 3y ago

> If your only hope of not going along with this is having the EU come in and slapping Google's wrist, I'm concerned that you aren't willing to take a hard stance on your own. This is indeed concerning. I'd like to see Brave's response to this, and we already know how Firefox has responded.

lxgr 3y ago

What sets WEI apart is that it, in a way, exerts power over your choice on how to implement other web features, for example whether you're allowed to block elements, or even just show a developer console. Other than Encrypted Media Extensions (and these are much more constrained than WEI!), I don't know of any other web standard that does that.

wbobeirne 3y ago
While it's a much lesser offense, many APIs are only available in "Secure Contexts", so it's not entirely a new concept https://webidl.spec.whatwg.org/#SecureContext https://webidl.spec.whatwg.org/#SecureContext
- lxgr 3y ago
  Getting a secure context costs $0 and takes no effort in many common webservers at this point. I do remember the controversy at the time of everybody shifting to HTTPS only, though, and how it might exclude small/hobbyist sites. Fortunately, we've found ways to mitigate that friction in the end. I'm much less optimistic here.
  - mschuster91 3y ago
    The thing is, yes it was controversial at the time to enforce HTTPS, but on the other side I 'member pwning people with ARP spoof attacks (both to steal cookies and credentials as well as simply redirecting all images to porn) at my school already way over a decade ago, and all I had was a laptop, Wireshark, Metasploit and some other piece of open source software whose name I forgot. No ARP sponge and the internet uplink was 10/10 mbit anyway so it was easy to do that shit for the entire school. A year later someone packaged all that stuff into a single software even a complete dunderhead could use to prank and steal facebook sessions at will. Basic reality and the easiness of attacks made it impossible to stick with HTTP for much longer. And hell if I watch Scammer Payback on Youtube, I'm beginning to think it might be a good idea to disable developer tools on browsers and to only unlock them if you can prove physical, un-remoteable access to a machine, similar to Apple's SIP.
    - GauntletWizard 3y ago
      Whatever proof you require, scammers will still convince Grandma to enable it.
    - chrisweekly 3y ago
      > "I'm beginning to think it might be a good idea to disable developer tools on browsers and to only unlock them if you can prove..." Strongest possible disagreement here.
      - lxgr 3y ago
        How so? I don't see how a secure attention sequence (i.e. what Windows used to do with requiring ctrl + alt + esc to be pressed to log in) could be a bad thing. On the other hand, you can bet that that's absolutely something scammers will be able to convince people to do while they're on the phone with them...
- contravariant 3y ago
  The crucial difference between the two is that I get to decide which contexts I consider insecure. For convenience I may choose to let an agent decide on my behalf. This is fundamentally different from a world where Google gets to decide if I am a risk to them.

burkaman 3y ago

Since Google also controls the most popular search engine and ad network, they can exert very significant pressure on web developers by refusing to place ads or drive traffic to websites that don't comply. I already block all ads so I'm obviously not totally sympathetic to developers who make decisions based on what will maximize ad revenue, but it still is not fair to put the burden on developers here and say "it's your choice, just say no".

nine_k 3y ago
Usually it's not developers who make decisions to put ads.

rezonant 3y ago

> Choosing not to implement it means your users will sometimes be presented with a worse UX if a website's developers decide to require that feature. I think this makes a category error. Most browser features/APIs are indeed treated as progressive enhancements by web developers, at least until an overwhelming number of the users have access to that feature. And even then, even if the developer makes assumptions that the feature/API is present, often the result is a degraded experience rather than an all-out broken experience. The same is not true of web attestation. If a website requires it and a browser refuses to implement it, in at least some cases (probably a concerningly high number of cases though) the result will be that the user is entirely locked out of using that website. It's also worth noting that _even if_ Vivaldi implements WEI, there's a solid chance that the attestation authority (Google, Microsoft, Apple) or possibly the website itself[1] will not accept it as a valid environment at all! After all, what makes Vivaldi not a "malicious or automated environment" in their eyes? What if Vivaldi allows full ad blocking extensions? User automation/scripting? Or any example of too much freedom to the user. Will the attestation authority decide that it is not worthy of being an acceptable environment? [1] if this ends up spiralling out of control by allowing the full attestation chain to be inspected by the website

iforgotpassword 3y ago
It still feels like they rather bend over and take it than risking losing market share.
- mrguyorama 3y ago
  Vivaldi's entire reason for being is "I literally cannot bring myself to just use firefox instead so I'll bend over backwards to try and remove objectionable things from chromium and still end up supporting chrome as the web default"
wbobeirne 3y ago
> The same is not true of web attestation. If a website requires it... I don't think I've made a category error, that again is true of all browser features. If your browser does not support JavaScript or WebSockets or WebGL, many sites would lock you out of them entirely as well. It's a choice of the website creator what to assume and what to require, and how to degrade the experience or offer alternatives when a feature is missing. The way I imagine it, WEI will start with skipping CAPTCHA. Then it will be about serving ads (users without WEI would generate no or very limited ad revenue.) Then it's up to the owner of a site whether or not they want to allow non-WEI traffic at all. Some will choose to block users without WEI, and hopefully the number of browsers that have chosen not to implement it, and the number of users on those browsers is high enough that that option will not be appealing. I hope that Vivaldi remains one of the browsers that doesn't implement it, whether or not the EU rules against it.

nvy 3y ago

>But as a software creator, it's up to you to determine what is best for your customers. Absolutely zero large web properties do anything based on what's best for users. If this gains traction, Google will simply deny adsense payments for impressions from an "untrusted" page, and thus all the large players that show ads for revenue will immediately implement WEI without giving a single flying shit about the users, as they always have and always will.

riku_iki 3y ago
large properties are interested to keep their content locked from scrapping, so they will for sure be interested to implement this.
- nvy 3y ago
  Yes. My point is that Google's done an excellent job stacking incentives against the user, here.
- realusername 3y ago
  >large properties are interested to keep their content locked from scrapping Except Google of course, the only allowed scrapper.
pptr 3y ago
Why would Google not monetize unattested traffic? I mean that's like Google blocking it's own ads from being shown. I don't know much about the online ad market. I assume advertisers will pay more for attested impressions than for unattested ones. But unattested impressions will still be worth something.
- nvy 3y ago
  >Why would Google not monetize unattested traffic? I mean that's like Google blocking it's own ads from being shown. It's very simple. Google has concerns of click/impression fraud. Unattested traffic would be more likely to be fraudulent. Not paying for unattested impressions/clicks is therefore an easy way to cut costs and combat fraud.

2OEH8eoCRo0 3y ago

Someone argued yesterday that in instances like this users are choosing what to use of their own free will. At the micro scale sure, at the macro scale I disagree. Users want their shit to work and if you play these shenanigans it's less of a choice and more of a ransom. Insects in a swarm can choose where to go but they can't choose where the swarm goes.

kyrra 3y ago

Google has been beat-down before trying to do these kinds of things. 2 ones I can think of: 1) FLoC: https://www.theverge.com/2022/1/25/22900567/google-floc-abandon-topics-api-cookies-tracking https://www.theverge.com/2022/1/25/22900567/google-floc-aban... 2) Dart: Google wanted this to replace javascript, but Mozilla and MS both said no way, as they had no part in it. So that project ended up dying. Google tries lots of things. Mozilla, MS, and Apple are still strong enough (especially outside the US) to push back on things that they think are a bad idea.

freedomben 3y ago
Dart is still around. The Flutter framework is growing in popularity. Apple already built and shipped this same feature last year, so they're not opposed. MS? Probably gonna love this. Mozilla hasn't said anything on it (yet at least). I'm not expecting any of those players to save us.
- lxgr 3y ago
  > The Flutter framework is growing in popularity. Is that the one rendering [1] text and UI widgets into an HTML canvas element from JavaScript/Dart (completely coincidentally breaking ad blocking in the process)? What a beautiful piece of software. > Apple already built and shipped this same feature last year, Are you referring to Private Access Tokens (PAT)? These seem quite a bit more limited in what they do. WEI seems to specifically set out to roll back some of the blinding/anonymization aspects of PAT under the banner of debuggability/providing "feedback" to attesters. [1] https://docs.flutter.dev/platform-integration/web/renderers https://docs.flutter.dev/platform-integration/web/renderers
  - freedomben 3y ago
    > Is that the one rendering [1] text and UI widgets into an HTML canvas element from JavaScript/Dart (completely coincidentally breaking ad blocking in the process)? What a beautiful piece of software. Yep. I'm not saying Dart is a good thing - I've never used it and don't currently have plans too. All I'm saying is that it is NOT dead as GP asserted. > Are you referring to Private Access Tokens (PAT)? These seem quite a bit more limited in what they do. WEI seems to specifically set out to roll back some of the blinding/anonymization aspects of PAT under the banner of debuggability/providing "feedback" to attesters. Yes. PATs don't provide as much information about the attestation to the website, but they do provide the critical part which is "is this person using a blessed client." That's plenty for a website to block people on.

worik 3y ago

> This is true of any contentious browser feature. Makes me recall Flash. Once was a time when very large parts of the web were dark to me because I would not install Flash Not an exact comparison, but we've been (near) here beforehand

YetAnotherNick 3y ago

Can't they just return random number for attestation each time.

api 3y ago

Google can just down-rank sites that don't implement this API. Voila, full adoption across the entire web and unapproved browsers are shut out.

deleted 3y ago

[deleted]

EdwardDiego 3y ago

This change is about what's best for advertisers and publishers, not customers.

safety1st 3y ago

Well hold on. The problem with attestation is you're damned if you do and damned if you don't. If you use a browser which supports attestation you will be denied service by companies who disapprove of what you run on your computer. If you don't use a browser which supports attestation you will be denied service by companies who disapprove of what you run on your computer. So everyone loses. If this goes live everyone in the world loses. It is an utterly heinous proposal. It is perhaps the worst thing Google has ever produced. I use Firefox and will never use any browser that implements attestation, even if I have to stop using most of the WWW one day. But unfortunately individual action is not going to be enough here, because no matter what you do, you lose.

evah 3y ago

The author should have asked "Can we just implement it then?" because in some cases you literally can't implement the proposed API. That's the core issue with it. Unlike other contentious browser features, even if you wanted to implement attestation, it may be impossible to do so. More precisely, attestation may be impossible to implement on some platforms to the de facto standard that would develop over time. The de facto standard I refer to is the list of attestors web servers will accept. If your platform can't be attested by an approved attestor, you're screwed. That's why it's not that simple this time. The proposed attestation API is literally unimplementable in general. You can't implement it and you can't not implement it.

lvncelot 3y ago

This point in the blog post saddens me. Chrome's market share is huge, but Chrome is not ubiquitous. There was public outcry when Google was suspected of making youtube have "bugs" on non-Chromium browsers - having them just straight up disable services for more than a third of users would result in an actual shitstorm, more than any of us could hope to drum up with an explanation of why this change is bad. It would also drive the point home to the very same legislators that the author is deferring to. If browsers now start pre-emptively folding, Google just straight up won. It's great that the Vivaldi team is against this change, but a blog post and hoping for regulation just won't cut it. You have actual leverage here, use it.

stOneskull 3y ago
can't chromium be forked without wei. brave and vivaldi and others could work on and use the fork.
- zx8080 3y ago
  Working on chromium codebase maintaining minimal fork is very hard. It requires a very competent and quite a large team (because lots of work to resolve merge conflicts) to just regularily apply a custom set of patches to newly released chromium versions. It's like staying on a dancing elephant. And it requires MONEY. Lots of. I suspect this is the desired result of Google to protect chromium despite it's opensource.

munk-a 3y ago

> If your only hope of not going along with this is having the EU come in and slapping Google's wrist, I'm concerned that you aren't willing to take a hard stance on your own. I take umbridge at this implication. When a monopoly like Google takes anti-competitive actions it's not fair or just to expect individuals to stand up to it. Governments exist to counter anti-competitive behavior like this and governments have been doing a terrible job chopping down companies with too much vertical integration lately.