4 ms·

After reading through the proposal, I really don't think it was that bad. As a recap, websites never see any information about your device but basically receiv

After reading through the proposal, I really don't think it was that bad. As a recap, websites never see any information about your device but basically receive a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with. There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS, where there are a relatively large number of trusted providers including some like LetsEncrypt that are non-profit and considered a public good. In that sense it would allow quite a bit of flexibility in what 'untampered' means based on the trust source which would be a good thing. IMO the dialogue around this was incredibly disappointing. I understand and support the hesitation around a proposal like this that could do harm to the web, but people were basically attacking these people and having meltdowns in the GitHub comments. Given how much large platforms have struggled to fight bots, and that it's only going to get worse with the rise of AI, I think something like this is going to end up being a necessity eventually. This won't be the last we will see of something like this.

j0hnyl 3y ago
I absolutely agree that it's very much a big nothing burger compared to the reaction it got.
- saltymug76 3y ago
  [flagged]
danShumway 3y ago
> In that sense it would allow quite a bit of flexibility in what 'untampered' means based on the trust source which would be a good thing. The problem is that the APIs for botting are the same APIs that are used for browser automation and extension support and that are implemented by experimental browsers that are building new tools for the web. You're correct to bring up that people didn't trust Google; that's part of it. But there's a more fundamental problem: there is no way to restrict someone from using APIs to automate a browser without also killing a lot of more traditionally accepted use-cases for those APIs. Every accessibility API and presentation API is an adblocking API. Every web extension and request redirector is a bot API. Google didn't seem to understand this; they came into the discussion believing that as long as they could get people to believe Google wouldn't abuse the API, everything would be fine (whether or not that was an honest claim is another discussion, the problems with WEI were numerous). But beyond the discussions of Google's motivations, at a fundamental level what critics were saying was that there was no such thing as a working version of this API that would be effective at reducing bots without reducing user freedom. Making the API more Open or getting more implementers on board wouldn't change that. It simply isn't possible to truthfully verify to a server that a user environment is "trusted" without blocking the user from accessing normal browser APIs.
yjftsjthsd-h 3y ago
> but basically receive a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with. Where "untampered with" means blocking anyone with an adblocker installed, using accessibility tools, or running Linux. DRM for the whole web is Bad.
- mindwok 3y ago
  That is definitely a possible outcome which is why I believe people are right to be concerned about a proposal like this, however my thought was that if there were many trusted providers it would drastically reduce the likelihood of a scenario like this. For example, I could imagine an organisation like Brave as a trusted provider who would almost certainly not restrict ad blockers or Linux use.
  - clhodapp 3y ago
    Why would websites want to trust Brave? And what if I want to compile my own browser? Now I can't use my bank website...
    - mindwok 3y ago
      I'm not denying there are challenges and potential bad outcomes with this, you're asking valid questions that I don't claim to have a good answer for. My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web. And, there's at least a possible outcome where we have many trusted providers that maintain the core parts of the open web that we love while giving these providers some better solution than what exists now. As for why would they trust Brave? I imagine it'd be similar to TLS now, where website owners probably wouldn't even think about this and they'd just use CA chains provided by browsers, operating systems, etc.
      - clhodapp 3y ago
        The security model of TLS is chained to the DNS. What one proves by holding a TLS cert is that one owns a given domain, no more no less (I mean there's EV certs but no one cares about EV certs). You won't ever have that with browser builds because there's nothing like that to tie them to.. (user agent string?). There will be no basis upon which to build trust except for market share, and to gain market share you have to already be trusted. Also, for WEI to work, you need to certify a lot more then just the build of the browser.... You need to certify all of the shared libraries it pulls in (including the userspace graphics libraries), everything that runs in kernel mode, the firmware, and the actual hardware. I would assert that the idea you are proposing is simply not going to happen. There is just no way that anything other than an unmodified build of a big-name browser running on an OS from a big-name vendor gets certified.
clhodapp 3y ago
...but if it was executed well I could see a situation where it ends up similar to TLS, where there are a relatively large number of trusted providers including some like LetsEncrypt that are non-profit and considered a public good The proposal didn't include anything like that and I don't see how it possibly could while still meeting its goals... It seems to me that WEI's goals are fundamentally incompatible with letting end users compile their own software.
marwis 3y ago
> There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS If you are that naive look where Android is now today. Despite being open source and having some alternative distributions, many banking and other "serious" institutions apps only work on official builds blessed by Google. They also block screenshots and remote screen. All thanks to Android\Google Play Protect DRM. If DRM is added to the web expect these same institutions to be early adopters so they can restrict access to their websites to only the browsers controlled by big tech and only without extensions.
- charcircuit 3y ago
  DRM already exists on the web and most sites gracefully degrade when a user's browser does not support it. They don't just restrict access.
  - marwis 3y ago
    The only DRM currently available on the web that I'm aware of relates to video. Banks don't have to restrict their apps against unauthorized Android builds and rooted devices with Play Protect but they do. There is nothing to gracefully degrade when your goal is actually to just restrict access.
    - TeMPOraL 3y ago
      Also the banks already just plain restrict access on the web, unconditionally, by making a smartphone app a mandatory auth / confirmation factor. And the app itself, of course, makes full use of Google's attestation APIs like you describe.
      - charcircuit 3y ago
        So at this point allowing for the web to be nearly as secure as a native app would allow for these sites to potentially start working on the web again.
matheusmoreira 3y ago
> a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent. I am the user and the owner of the machine, I am entitled to "tamper" with anything I want.
- gruez 3y ago
  >Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent. Says who? The government? At the end of the day, any voluntary interaction between two entities is a two way street. Either side can refuse to engage with the other side for any reason.
  - matheusmoreira 3y ago
    The government should definitely say so by implementing laws and regulations. Computer freedom and choice should be law.

j0hnyl 3y ago

I absolutely agree that it's very much a big nothing burger compared to the reaction it got.

saltymug76 3y ago
[flagged]

danShumway 3y ago

> In that sense it would allow quite a bit of flexibility in what 'untampered' means based on the trust source which would be a good thing. The problem is that the APIs for botting are the same APIs that are used for browser automation and extension support and that are implemented by experimental browsers that are building new tools for the web. You're correct to bring up that people didn't trust Google; that's part of it. But there's a more fundamental problem: there is no way to restrict someone from using APIs to automate a browser without also killing a lot of more traditionally accepted use-cases for those APIs. Every accessibility API and presentation API is an adblocking API. Every web extension and request redirector is a bot API. Google didn't seem to understand this; they came into the discussion believing that as long as they could get people to believe Google wouldn't abuse the API, everything would be fine (whether or not that was an honest claim is another discussion, the problems with WEI were numerous). But beyond the discussions of Google's motivations, at a fundamental level what critics were saying was that there was no such thing as a working version of this API that would be effective at reducing bots without reducing user freedom. Making the API more Open or getting more implementers on board wouldn't change that. It simply isn't possible to truthfully verify to a server that a user environment is "trusted" without blocking the user from accessing normal browser APIs.

yjftsjthsd-h 3y ago

> but basically receive a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with. Where "untampered with" means blocking anyone with an adblocker installed, using accessibility tools, or running Linux. DRM for the whole web is Bad.

mindwok 3y ago
That is definitely a possible outcome which is why I believe people are right to be concerned about a proposal like this, however my thought was that if there were many trusted providers it would drastically reduce the likelihood of a scenario like this. For example, I could imagine an organisation like Brave as a trusted provider who would almost certainly not restrict ad blockers or Linux use.
- clhodapp 3y ago
  Why would websites want to trust Brave? And what if I want to compile my own browser? Now I can't use my bank website...
  - mindwok 3y ago
    I'm not denying there are challenges and potential bad outcomes with this, you're asking valid questions that I don't claim to have a good answer for. My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web. And, there's at least a possible outcome where we have many trusted providers that maintain the core parts of the open web that we love while giving these providers some better solution than what exists now. As for why would they trust Brave? I imagine it'd be similar to TLS now, where website owners probably wouldn't even think about this and they'd just use CA chains provided by browsers, operating systems, etc.
    - clhodapp 3y ago
      The security model of TLS is chained to the DNS. What one proves by holding a TLS cert is that one owns a given domain, no more no less (I mean there's EV certs but no one cares about EV certs). You won't ever have that with browser builds because there's nothing like that to tie them to.. (user agent string?). There will be no basis upon which to build trust except for market share, and to gain market share you have to already be trusted. Also, for WEI to work, you need to certify a lot more then just the build of the browser.... You need to certify all of the shared libraries it pulls in (including the userspace graphics libraries), everything that runs in kernel mode, the firmware, and the actual hardware. I would assert that the idea you are proposing is simply not going to happen. There is just no way that anything other than an unmodified build of a big-name browser running on an OS from a big-name vendor gets certified.

clhodapp 3y ago

...but if it was executed well I could see a situation where it ends up similar to TLS, where there are a relatively large number of trusted providers including some like LetsEncrypt that are non-profit and considered a public good The proposal didn't include anything like that and I don't see how it possibly could while still meeting its goals... It seems to me that WEI's goals are fundamentally incompatible with letting end users compile their own software.

marwis 3y ago

> There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS If you are that naive look where Android is now today. Despite being open source and having some alternative distributions, many banking and other "serious" institutions apps only work on official builds blessed by Google. They also block screenshots and remote screen. All thanks to Android\Google Play Protect DRM. If DRM is added to the web expect these same institutions to be early adopters so they can restrict access to their websites to only the browsers controlled by big tech and only without extensions.

charcircuit 3y ago
DRM already exists on the web and most sites gracefully degrade when a user's browser does not support it. They don't just restrict access.
- marwis 3y ago
  The only DRM currently available on the web that I'm aware of relates to video. Banks don't have to restrict their apps against unauthorized Android builds and rooted devices with Play Protect but they do. There is nothing to gracefully degrade when your goal is actually to just restrict access.
  - TeMPOraL 3y ago
    Also the banks already just plain restrict access on the web, unconditionally, by making a smartphone app a mandatory auth / confirmation factor. And the app itself, of course, makes full use of Google's attestation APIs like you describe.
    - charcircuit 3y ago
      So at this point allowing for the web to be nearly as secure as a native app would allow for these sites to potentially start working on the web again.

matheusmoreira 3y ago

> a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent. I am the user and the owner of the machine, I am entitled to "tamper" with anything I want.

gruez 3y ago
>Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent. Says who? The government? At the end of the day, any voluntary interaction between two entities is a two way street. Either side can refuse to engage with the other side for any reason.
- matheusmoreira 3y ago
  The government should definitely say so by implementing laws and regulations. Computer freedom and choice should be law.